201–210 of 286 posts
You're absolutely correct, which is why we had Rails, Django, Laravel,etc. Why do we need node.js-based SSR and hydration etc these days? It seems it's just remaking an already solved problem with fancier terms, bottom line is that it's way more complex, what's the point?
Modern web development has become a wasteland of over-engineered solutions, and the real issue isn't client-side vs. server-side rendering; it's the industry's obsession with frameworks. Frameworks are not just tools; they're ideologies that developers subscribe to, often blindly. This has led to a monoculture where questioning popular frameworks like React is heretical. Ironically, this 'framework-first' mentality s…
I think the reality of web development is that outside a few minority of “apps”: figma, google maps, etc. is that basic html, js and css is more than enough. Maybe some jquery, or something like rails or php to update values server side before it’s sent out. Most websites are just text, with some pictures and some forms. Most frameworks are total overkill.
Earlier quoted context omitted.
I say save yourself the trouble and just avoid all "modern" web development tooling. Avoid "frontend builds" at all costs (everything except for esbuild is insanely slow anyway). Most websites do not need npm for frontend (or backend). Most web applications are barely "applications" at all but rather mostly-static content with a few forms, tables, and/or menus. I use vanilla html/css/js for frontend + golang for the…
Been there, done that. I don't agree. Go's native html/template and even pongo2 or quicktemplate etc have a big problem when it comes to conditional fragments of some text. It's messy and you end up writing helper functions for pretty much everything. Need a href aware navbar? Custom function and macro time. Bleh. Performance is great, maintainability isn't. I dislike graphql because it's too mich overhead. RESTful i…
Modern web development has become a wasteland of over-engineered solutions, and the real issue isn't client-side vs. server-side rendering; it's the industry's obsession with frameworks. Frameworks are not just tools; they're ideologies that developers subscribe to, often blindly. This has led to a monoculture where questioning popular frameworks like React is heretical. Ironically, this 'framework-first' mentality s…
While this is your opinion, a majority of the frontend development experience has borne these solutions out of real problems, not in spite of them. Every take like this reeks of never having built large and interactive frontend projects that involve more than 1 developer. Sure you can get by on htmx/html/css/tailwind/whatever simplistic thing you can conjure up but those things don't SCALE, which is what these framew…
Earlier quoted context omitted.
While this is your opinion, a majority of the frontend development experience has borne these solutions out of real problems, not in spite of them. Every take like this reeks of never having built large and interactive frontend projects that involve more than 1 developer. Sure you can get by on htmx/html/css/tailwind/whatever simplistic thing you can conjure up but those things don't SCALE, which is what these framew…
I find it funny, even creative, that you managed to slip in something against tailwind in your comment.
One of the fastest, lowest latency websites I use is HN, and it’s entirely server rendered. It’s also a massively popular website with probably thousands of hits per minute. Anyone who tells you server side rendering is too slow, probably has no idea what they’re talking about.
Server-side rendering can absolutely be slow, and client-side can absolutely be fast. It's all dependent on the quality of the developer.
Information-theoretic, there is no way you can beat SSR in this scenario. You will not win against a machine that returns a complete HTML document on the very first request if your users only receive hints regarding where to actually find the princess upon their first request.
I look at every client-side argument along the axis of "well now that the universe is already here, we can get started". Server-side explains how that universe got into existence in the first place. Your fancy incremental update shadow DOM system cannot work until it is already bootstrapped via some means.
Modern web development has become a wasteland of over-engineered solutions, and the real issue isn't client-side vs. server-side rendering; it's the industry's obsession with frameworks. Frameworks are not just tools; they're ideologies that developers subscribe to, often blindly. This has led to a monoculture where questioning popular frameworks like React is heretical. Ironically, this 'framework-first' mentality s…
While this is your opinion, a majority of the frontend development experience has borne these solutions out of real problems, not in spite of them. Every take like this reeks of never having built large and interactive frontend projects that involve more than 1 developer. Sure you can get by on htmx/html/css/tailwind/whatever simplistic thing you can conjure up but those things don't SCALE, which is what these framew…
This article misses the single most important reason to use SSR: single language applications are single build applications. Frontend builds are basically a requirement for any application with a UI. You're always going to have CSS, and some degree of user interaction for even the simplest website, which means JS/TS. One of the most important developments for frontend assets in the past decade is dependency managemen…
I say save yourself the trouble and just avoid all "modern" web development tooling. Avoid "frontend builds" at all costs (everything except for esbuild is insanely slow anyway). Most websites do not need npm for frontend (or backend). Most web applications are barely "applications" at all but rather mostly-static content with a few forms, tables, and/or menus. I use vanilla html/css/js for frontend + golang for the…
Don’t get me wrong, I’m very unhappy with the state of today’s JS ecosystem but if you’re building a project of any complexity ditching absolutely everything that can help you along the way is not going to work out. Nor is it going to work out for the person taking over the code from you.
Every now and then I’ll be putting together a tiny landing page type thing and write it all in vanilla JS and it’s bliss. But as soon as I start dealing with non-trivial state you’d better believe I’m reaching for a framework.
This article misses the single most important reason to use SSR: single language applications are single build applications. Frontend builds are basically a requirement for any application with a UI. You're always going to have CSS, and some degree of user interaction for even the simplest website, which means JS/TS. One of the most important developments for frontend assets in the past decade is dependency managemen…
2. CSS has NOTHING to do with js/ts.
3. Most single page js applications require SSR anyway, otherwise you have a blank screen or spinner until the browser has downloaded & intialized everything.
Personally, i dont care if it's SSR or SPA. But the js/ts community tends to use things like webpack in combination with ~20 packages which themselfs rely on ~20 packages, resulting in index.js files that are +2MB... That's bad programming.
Earlier quoted context omitted.
I say save yourself the trouble and just avoid all "modern" web development tooling. Avoid "frontend builds" at all costs (everything except for esbuild is insanely slow anyway). Most websites do not need npm for frontend (or backend). Most web applications are barely "applications" at all but rather mostly-static content with a few forms, tables, and/or menus. I use vanilla html/css/js for frontend + golang for the…
Yeah, no. Don’t get me wrong, I’m very unhappy with the state of today’s JS ecosystem but if you’re building a project of any complexity ditching absolutely everything that can help you along the way is not going to work out. Nor is it going to work out for the person taking over the code from you. Every now and then I’ll be putting together a tiny landing page type thing and write it all in vanilla JS and it’s bliss…