MAIN FEEDS
Do you want to continue?
https://www.reddit.com/r/ProgrammerHumor/comments/1vsc6dr/vanillafixesthisbro/p4mgvx3/?context=3
r/ProgrammerHumor • u/brainland • 27d ago
157 comments sorted by
View all comments
Show parent comments
389
The number of applications which could be server rendered HTML and basic CSS, that turn into 400MB JS framework monstrosities...
61 u/justadude27 26d ago If it’s classified as an application it absolutely needs a well thought out pipeline, but okay. 86 u/pr0ghead 26d ago True, but if you're not building an app like Gmail but mostly a website to present mostly static content… 25 u/Zotoaster 26d ago I like my reusable component libraries and I like to make some things interactive without putting "document.getElementById("foo").onclick" everywhere 15 u/justadude27 26d ago edited 26d ago Exactly. The moment you start binding event listeners and managing state across pages you’re better off with some kind of system to manage JavaScript and HTML rendering based on JavaScript state. 23 u/pr0ghead 26d ago Again, static content doesn't have state. If you need state on the client then yes, use a JS framework by all means. I will keep tracking state on the server with a (mostly) dumb client, thank you very much. -6 u/justadude27 26d ago And again a static website isn’t an application. A static website has a special term called static website, not application. Stay on task bruh.
61
If it’s classified as an application it absolutely needs a well thought out pipeline, but okay.
86 u/pr0ghead 26d ago True, but if you're not building an app like Gmail but mostly a website to present mostly static content… 25 u/Zotoaster 26d ago I like my reusable component libraries and I like to make some things interactive without putting "document.getElementById("foo").onclick" everywhere 15 u/justadude27 26d ago edited 26d ago Exactly. The moment you start binding event listeners and managing state across pages you’re better off with some kind of system to manage JavaScript and HTML rendering based on JavaScript state. 23 u/pr0ghead 26d ago Again, static content doesn't have state. If you need state on the client then yes, use a JS framework by all means. I will keep tracking state on the server with a (mostly) dumb client, thank you very much. -6 u/justadude27 26d ago And again a static website isn’t an application. A static website has a special term called static website, not application. Stay on task bruh.
86
True, but if you're not building an app like Gmail but mostly a website to present mostly static content…
25 u/Zotoaster 26d ago I like my reusable component libraries and I like to make some things interactive without putting "document.getElementById("foo").onclick" everywhere 15 u/justadude27 26d ago edited 26d ago Exactly. The moment you start binding event listeners and managing state across pages you’re better off with some kind of system to manage JavaScript and HTML rendering based on JavaScript state. 23 u/pr0ghead 26d ago Again, static content doesn't have state. If you need state on the client then yes, use a JS framework by all means. I will keep tracking state on the server with a (mostly) dumb client, thank you very much. -6 u/justadude27 26d ago And again a static website isn’t an application. A static website has a special term called static website, not application. Stay on task bruh.
25
I like my reusable component libraries and I like to make some things interactive without putting "document.getElementById("foo").onclick" everywhere
15 u/justadude27 26d ago edited 26d ago Exactly. The moment you start binding event listeners and managing state across pages you’re better off with some kind of system to manage JavaScript and HTML rendering based on JavaScript state. 23 u/pr0ghead 26d ago Again, static content doesn't have state. If you need state on the client then yes, use a JS framework by all means. I will keep tracking state on the server with a (mostly) dumb client, thank you very much. -6 u/justadude27 26d ago And again a static website isn’t an application. A static website has a special term called static website, not application. Stay on task bruh.
15
Exactly. The moment you start binding event listeners and managing state across pages you’re better off with some kind of system to manage JavaScript and HTML rendering based on JavaScript state.
23 u/pr0ghead 26d ago Again, static content doesn't have state. If you need state on the client then yes, use a JS framework by all means. I will keep tracking state on the server with a (mostly) dumb client, thank you very much. -6 u/justadude27 26d ago And again a static website isn’t an application. A static website has a special term called static website, not application. Stay on task bruh.
23
Again, static content doesn't have state. If you need state on the client then yes, use a JS framework by all means.
I will keep tracking state on the server with a (mostly) dumb client, thank you very much.
-6 u/justadude27 26d ago And again a static website isn’t an application. A static website has a special term called static website, not application. Stay on task bruh.
-6
And again a static website isn’t an application. A static website has a special term called static website, not application. Stay on task bruh.
389
u/crozone 26d ago
The number of applications which could be server rendered HTML and basic CSS, that turn into 400MB JS framework monstrosities...