Server-side rendering is a better choice for many applications (2020) • Hacker News Board

Re: Server-side rendering is a better choice for many applications (2020)

#251

Post by flimsypremise » Wed, Aug 23, 2023, 7:49 PM UTC

umvi wrote: post #169

flimsypremise wrote: post #137

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…

If you're using JS modules and ESLint, you are using a frontend build. You can certainly go back to the days of jquery and vanilla CSS with none of the advantages of modern dependency management, transpilation and module loading, but if you try to do that at even a small company you are not going to last long. These tools exist for a reason, and most people who don't see the point of them were not around for the bad times before the existed.

Re: Server-side rendering is a better choice for many applications (2020)

#252

Post by flimsypremise » Wed, Aug 23, 2023, 7:59 PM UTC

rwalle wrote: post #178

flimsypremise wrote: post #137

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…

> single language applications are single build applications I don't know your background but most teams don't view "single language" as an advantage over other options. People choose a certain language because of internal infrastructure, libraries/ecosystem, performance, and whether it is the best suited for a project etc, rarely because "we use that language for backend so we should also use it for frontend" or vic…

Not sure what you're really saying here. Teams often use languages because their existing codebases and the proficiencies of their existing members, but "we use that language for backend so we should use it for frontend" is totally a thing. You're somehow seeing multiple languages as an advantage when its actually a form of debt. Teams work in multiple languages because prior choices force them to, but if you can limit the number of languages and technologies in use it allows you to streamline and automate spinning up new services, make it easier to hire, and greatly simplifies deployment configuration. This is one of the major things that happen as you transition from an early stage to late stage as a startup. You hire professionals after a few years of not knowing what you're doing, and they cull all of the non-standard shit, lock in your architecture and languages, and then template our your apps, your configuration and your deployments.

Re: Server-side rendering is a better choice for many applications (2020)

#253

Post by umvi » Wed, Aug 23, 2023, 8:00 PM UTC

flimsypremise wrote: post #251

umvi wrote: post #169

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…

If you're using JS modules and ESLint, you are using a frontend build. You can certainly go back to the days of jquery and vanilla CSS with none of the advantages of modern dependency management, transpilation and module loading, but if you try to do that at even a small company you are not going to last long. These tools exist for a reason, and most people who don't see the point of them were not around for the bad…

> If you're using JS modules and ESLint, you are using a frontend build

Browsers natively support JS modules with no frontend builds needed (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...).

You just need to specify `type="module"` in your `` tag

Re: Server-side rendering is a better choice for many applications (2020)

#254

Post by lakomen » Wed, Aug 23, 2023, 8:02 PM UTC

granshaw wrote: post #203

lakomen wrote: post #180

Earlier quoted context omitted.

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…

Just use Rails

With Rails you're back in the low performance camp sadly, might as well go full JS.

I want my cake and eat it too.

For Go, unless I missed some new development, there's Kyoto and jfyne/live . And that's it for Go.

Kyoto IMHO is more of a poc. And live is not very appealing, you're back in complicated camp with it.

Re: Server-side rendering is a better choice for many applications (2020)

#255

Post by flimsypremise » Wed, Aug 23, 2023, 8:18 PM UTC

bob1029 wrote: post #191

rwalle wrote: post #178

Earlier quoted context omitted.

> single language applications are single build applications I don't know your background but most teams don't view "single language" as an advantage over other options. People choose a certain language because of internal infrastructure, libraries/ecosystem, performance, and whether it is the best suited for a project etc, rarely because "we use that language for backend so we should also use it for frontend" or vic…

> I don't know your background but most teams don't view "single language" as an advantage over other options. We view it as a massive advantage, assuming we are on the same page with "single language, plus HTML/CSS/JS" Our language is C#. Our web "framework" consists of the string interpolation and verbatim operators. Most of our views take the form of: var finalHtmlResponse = @$" {DiyPHPViewEngineRabbitHoleEntrance…

I mean, JS is a language, so this would not really qualify. I have to wonder how you expose the state of your C# app to the JS when that needs to happen. Perhaps... with JSON? In which case you are just doing JSON API + distributed state, except in a more complicated way with C# thrown in for good measure. You could simply render your DOM in JS/TS on the backend and save yourself a step. Hell if you are really that opposed to writing JSON APIs, you can just write a Node app that queries the database directly. I don't really recommend doing this since I think exposing data via APIs is good, but whatever floats your boat.

Either way, at some point your app is running JS/TS and CSS, and those two resources require some type of build process to manage beyond a certain degree of complexity. I lived through the hell of having to determine the load order of JS and CSS files by where the script and style tags occurred in the DOM. It was incredibly difficult to do simple things. Now we can do much more complicated things more easily, but language chauvinists object to doing complex things in what they view as "lightweight" languages. The thing is, the "correct" language to use is generally just the one that does the job best, and in this case JS/TS is specifically optimized for writing applications that interface with the DOM.

Re: Server-side rendering is a better choice for many applications (2020)

#256

Post by flimsypremise » Wed, Aug 23, 2023, 8:32 PM UTC

ki_ wrote: post #209

flimsypremise wrote: post #137

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…

1. You can share templates between front & back-end using any language. (im not talking about WASM) 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…

Man if you think 2MB is big, you should check out the size of the build product from a compiled language. And if you have an issue with nested dependencies, you've should check out the build a Python or C application which similarly require you grab all the dependencies, and then the dependencies of the dependencies, before building. That's just what dependency management is about.

If you have a frontend app that requires loading a 2MB bundle in the browser, then whoever configured that application did not know what they are doing. There are lots of ways of optimizing JS bundle sizes, and SSR is actually one of the best. With SSR, only the code that executes on the frontend gets included in the client bundle. Webpack is one of many build orchestration frameworks you could use, though honestly at this point you rarely have to actually write custom configuration for frontend applications. A great deal of standardization has happened over the last 5 years, and generally you just use a template for your use case.

As someone who has worked all over the stack, from API development to data pipelines to infrastructure to client-facing application, I find the dismissive attitude of other parts of the stack incredibly bizarre. It's a tool, it exists for a reason, and if you don't see the reason it's probably because you don't understand the problem.

Re: Server-side rendering is a better choice for many applications (2020)

#257

Post by flimsypremise » Wed, Aug 23, 2023, 8:40 PM UTC

umvi wrote: post #253

flimsypremise wrote: post #251

Earlier quoted context omitted.

If you're using JS modules and ESLint, you are using a frontend build. You can certainly go back to the days of jquery and vanilla CSS with none of the advantages of modern dependency management, transpilation and module loading, but if you try to do that at even a small company you are not going to last long. These tools exist for a reason, and most people who don't see the point of them were not around for the bad…

> If you're using JS modules and ESLint, you are using a frontend build Browsers natively support JS modules with no frontend builds needed ( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid... ). You just need to specify `type="module"` in your ` ` tag

I mean, you could do that, but as someone who has been doing this for a very long time, I would not recommend it. If your application is very simple and has very few dependencies it might work, though I think you'll have a lot of trouble managing your dependencies across multiple environments. You wouldn't distribute a C application without a Makefile, and you shouldn't distribute or deploy a frontend application without the equivalent dependency management and build orchestration. These tools exist not just to help one developer create and app that works, but to help teams manage code contribution and dependency management across environments.

Re: Server-side rendering is a better choice for many applications (2020)

#258

Post by busymom0 » Wed, Aug 23, 2023, 8:54 PM UTC

ninepoints wrote: post #197

ninkendo wrote: post #115

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.

I'm sure this is an unpopular opinion here, but I hate this website's UX. Replying to a comment loads a new page, losing the entire context of the thread. There is no UI to indicate if there's a reply to an earlier comment made. The typograph is ugly as sin, and hard to read (too small on desktop, looks bad on mobile, poor contrast). With new pages needed for basic reply/editing capabilities, the site doesn't even ac…

For what it's worth, my iOS and Android hacker news app called HACK includes push notifications for replies to posts and comments.

Re: Server-side rendering is a better choice for many applications (2020)

#259

Post by msm_ » Wed, Aug 23, 2023, 8:57 PM UTC

mg wrote: post #102

philote wrote: post #81

Earlier quoted context omitted.

Django is a super heavy framework that includes most anything you'd ever want. There's a ton to learn. Have you tried lighter-weight ones like Flask? I much prefer a lightweight web framework with an easy-to-use ORM/ODM. Also, even though you don't use frameworks, I assume you use various libraries to handle web requests and such, right?

How is Django more heavy than Flask? When I think about heavy, I think about how hard it would be to replace the framework with my own code in the future. So I don't like magic. One thing that keeps me from investigating Flask further is that Django seems to be way more popular: https://trends.google.com/trends/explore?date=all&q=django%2... So it will probably stay around longer. Me and other devs maintain this repo…

>How is Django more heavy than Flask?

Because it is, by far, much larger project? Django has 551k LoC in 31933 commits, Flask has 27k LoC in 5156 commits. Django philosophy is "be opinioated, and bundle everything necessary for developers". Flask philosophy is "do just one thing and just be a good HTTP server, let users pick a solution to all the other problems". Django is a full-blown framework, whereas flask is almost a library. Both approaches are OK, but from your previous message (GP) you prefer lightweight and magic-less frameworks (and Django relies on some conventions to do its magic).

>One thing that keeps me from investigating Flask further is that Django seems to be way more popular:

Both Django and Flask are way more popular that what you're doing (writing everyting yourself. By the way does it mean you write your own HTTP server too?), so I don't know why that stops you. Flask is not going anywhere.

>Me and other devs maintain this repo which shows how to get from a fresh Debian install to a running web app via different frameworks:

Interesting project, thanks for sharing! But that's a bit random - what was your intention when linking it? Also I can't help but notice that the flask example there has three third-party dependencies other than flask (flask-sqlalchemy, flask-login and wtforms). Since you like rolling your own solutions, maybe you would prefer Flask without such libraries? (I personally don't use flask-login and wtforms, and only sometimes use flask-sqlalchemy - I usually use standard sqlalchemy, my custom ORM, or just write SQL directly for simpler projects).

Re: Server-side rendering is a better choice for many applications (2020)

#260

Post by LAC-Tech » Wed, Aug 23, 2023, 9:07 PM UTC

Pxtl wrote: post #214

jakelazaroff wrote: post #93

Earlier quoted context omitted.

Agreed, I came into this article emotionally prepared to disagree after just reading the title.

At the risk of reductio ad absurdum: "Title: A Stalin-inspired Look at Webfarm Management Body: Apocryphally, Stalin once said that quantity has a quality all its own. As such, our hosting system involves an absolutely bonkers number of servers."

We both know that on HN in 2023 Thiel is much more despised than Stalin.