Hacker News Reader

Comment by franze | Hacker News Reader

I make a difference between website and webapp.

a website is a collection of webpages, where the maingoal is to display some mostly static information (i.e. an article)

a webapp has the main goal of managing and reacting to a complex, non trivial user state.

website, go server side all in, do not add the tax of client side rendering / hydration to the frontend. if necessary embed small enclosed client side webapps on the frontend.

webapp, go client side all in, screw server side rendering.

yes, you can marry website and webapp via server side rendering / hydration. but the cost to make this really really fast and spiralling complexity and edge cases, does not make it worth it.

choose the right tool for the job, and just because it has web** in its name, does not make it automatically a job for react/angularjs/newest-coolest-framework

View on HN

In principle I agree with what you say, but I'd like to make a more fine grained distinction.

If the website is just static content, go for static-site generation.

If it's a webapp, where you have some interactions but there's only a few of these and the site is not that complex, then go for server-side rendering.

If it's a web app with complex interactions, go for client-side rendering.

What's Amazon in this example? Hacker News? Google Search? All of these are problems that are still perfectly well suited to server-side HTML generation - the dominant user interaction replaces all / a significant part of the page, with relatively minimal non-database state preserved between interactions (a cart for amazon, your user name, your search term). All of that can be built perfectly simply by a traditional request-response cycle with some Javascript enhancement.

Going SPA for most "webapps" (if app is defined as something that isn't purely static) is a massive waste of time. Use Javascript on the few items that require more interactively, but if most of the time major interactions are replacing > 50% of the UI, a SPA isn't buying you anything.

A great distinction and way to think about your work.

However, I would prefer server side rendering as the best thing to do in all cases, because, while user state may be complex in webapp, it can be easily handled securely in a server side environment.

More so, until the ecosystem around webassembly becomes more mature, the choice of languages and frameworks on the server side are far more than what is available on the client side.

Thinking and architecting apps that render on the server is much easier than client apps.

Also, client apps are slow and laggy. It takes a lot of effort to make them work well, effort that could be used to improve bottomline otherwise.

> I make a difference between website and webapp.

Everyone says this, which doesn't solve anything. 99,9% of what we build is just something in between. It is not as easy as you make it look like.

Especially the web sites that get built by developers are almost by definition "something in between" or more. It's the reason they need developers in the first place. As soon as it needs to have anything bespoke and is updated by non-technical people it is a web app anyways. If not they could use a pre-built no-code solution.

There is a lot of value in rendering the shell of an app on the server and populating the rest on the client. The outer layout of a given view is mostly static. Doing this correctly gives you stable loading with no reshuffling as the rest loads.

And some views in apps can have page-y aspects like reports that might as well be static. Though this is an optimisation, and can be deferred till later.

Reply on news.ycombinator.com