> “Many important, profitable, applications aren't used enough to make a native mobile app worthwhile. Most online shops, banking, festival ticketing, government forms, etc. Therefore you will not have to support both server-side rendering and an API for your native apps”
A well done native app is always, faster, more robust and more enjoyable to use than a web UI. Even if your app is used relatively rarely, offering a significantly better user experience means it will be used more. And that’s a very important thing.
But users won't install it though. Your app can be a smooth magical experience but you have to get over the hump of getting users to go to the store and download it.
Unless I'm using your service daily I'm not going to bother with an app and just use the website.
Same here. In fact, unless can understand why whatever it is can’t be offered through a web page, or I have no choice, I will not install an app. The reason is security. The more closed-source binaries you put on your phone, the larger your attack surface.
I also had this sentiment, but I feel like VSCode as of late has pretty much proved this wrong. There's no discernable difference in responsiveness to me between it and any other native IDE I've used. And it's a pretty complex example.
What site are you criticizing exactly? The blog is a bunch of HTML served up with only the usual google panopticon JS, and is certainly not doing client-side rendering. HN is also a bunch of HTML with just a titch of JS - and little of it generates HTML (which would be client-side rendering). Tell me again, what are you complaining about?
Relax, I was complimenting the site, which performs beautifully on a mobile device. And rhetorically pointing out that it is rendered by browser technology (WebKit), which, last time I checked, was considered client side. But hey I could be wrong, so feel free to educate me.
In web dev parlance client side rendering refers to dynamically generating HTML from some data format (eg, serving a template and having the JS render it and add it to the DOM, instead of applying the template on the server and sending the resulting HTML). You're right that the browser's rendering engine ultimately does all the work of generating the images that get displayed, but that has to happen anyway and isn't a distinction that gets talked about (much) in web dev land.
I believe it was LinkedIn who took a hybrid approach a while back. I have no idea if this is still the way things are done, but somewhere in the 2012/2013 time period they would in general render things server-side. If the site was having load issues, they would turn the server-side rendering off and then the clients would render instead.
I feel like we are going to go full circle pretty soon, with more people realizing that server-side rendering is better for most websites/apps. I say this as someone who has used Angular and Vue extensively (and still do). The problem is, it is extremely easy to get things wrong, and I have seen mediocre (not great, but not bad) front-end devs make a complete mess using these frameworks.
The fundamental problem with serverside rendering is that it requires a round trip if the model changes. With modern interactive apps, the model changes a lot. People don't like waiting for things.
Not to mention that server side rendering increases cpu load on your servers. Of course that may be a feature if you're a customer who's tired of slowly loading webapps.
There's a factor, though, that never seems to find its way into this conversation: the native web handles a lot of client-side state (model) for you, for free. We forget this because React and Vue elevate things like temporary input buffers, and dropdown states, and validation, to the application-logic level. This gives you the flexibility to do with it whatever you want: want to bind your text input's content to something else in real time? Go for it! But it also means that for the bottom 90% of common cases, application logic has to manually juggle all of those values itself, which it didn't used to have to do. This means our mental concept of "model changes" has become much larger in scope than it actually is for a server-rendered app.
In server-rendered apps, the client/server boundary plays the role of a natural boundary between transient and domain-model state. Of course the pain points come when that approximation is wrong, but in most cases that's a pretty rare occurrence.
This is actually the primary thing I like about server-rendering. Not the performance side, but the reduction in state. The reduction in contingencies and in the potential for broken cases. When most of your state gets thrown away on every view change, there's so much less to keep track of.
Even for small projects, I would choose Vue client-side rendering over back-end rendering. I'm a back-end dev so I don't do it because I love front-end work, I just haven't found a better way to do it. I can update the back-end API and front-end use on one machine and deploy both in a minute.
Sometimes all the work is client-side with third-party services as back-ends.
The only other solution I like is to have server-side rendering with live updates like Phoenix/Elixir, Vaadin/Java, or Rails/Ruby. These have scaling limitations but probably beyond what most of our apps need to support.
I think the other thing to worry about with live updating is client interaction security footprint. In most platforms you better be damn sure that your client rerendering code is bulletproof, because if an adversary finds an input permutation that hogs CPU or worse, panics your backend you'll really be up the creek, though Phoenix/liveview can take advantage of erlang process isolation in a way that it's way less of a concern.
> So is your app mostly forms or displaying content? User preference panels? Mortgage applications? Implement it with server-side rendering with a sprinkling of JS to implement widgets the web lacks. If only part of your app requires low-latency interactions, use client-side rendering only there.
While I understand it's easy to make the argument that SSR is better, lighter, etc. It's easy to quickly violate the "Single Responsibility Principle" in that you now have two systems with little knowledge of each other both in control of rendering the UI.
I lived the era of jQuery with apps just being a bunch of jQuery extensions + SSR. Eventually the app needs to make XHR (type ahead search, nested picklists, etc), and you end up in a situation where there was just one thing controlling presentation.
well no, you have a very strict layering of control
server owns it at first, and generates the base system
client-side js then owns it, and does whatever it wants
there's no back and forth, or dual simultaneous control of the UI. There's only one owner at a time; just two different systems who ever own it (and single-responsibility-wise: separating static UI from dynamic UI)
The concern is not about race conditions or shared memory where two things would be editing it at a time. Even though the server always renders it first then the frontend, you still need to share knowledge across both the backend and frontend about all the details of all the components to know how to change the values in jquery or whatever you want to do. Any time you change something on the backend, you have to make sure the jquery stuff is updated to still work, and potentially in many different places if you have different interactions that can update the same state. It makes for very tightly coupled and brittle code.
It’s still a matter of preference, you might still prefer that over a full frontend react codebase. But having seen both nightmare jquery messes and react messes, they can both be painful to work with. I definitely don’t agree that things were much simpler in the old days.
Ah but there's alot more "front end engineers" who know some javascript in the world than graybeards who know how to write server-side code well. So the business case for saving money on new hires is a strong argument for "make a javascript mess".
Who said it needs to be written well? I'd wager that the kids these days making messes in JavaScript could probably manage to do the same in Python or Ruby. Also, heck, this has been going on long enough that this point that some of them may even be starting to have a bit of grey in their beards and recognize a few of these tradeoffs...
I think it also has alot to do with the current zeitgeist in the industry. We have tech heavyweights like Facebook with React and Google with Angular pushing this method of web development which is causing a bandwagon effect. I don't think businesses see it so much as a cost saving measure but think this must be the "right" way to do it because that's what Facebook and Google do. Nobody gets fired for choosing React or Angular. Suddenly there's a huge demand for "front end engineers" so if you're just starting out and want to get your foot in the door as a webdev you're probably going to need to know something like React or Angular. I don't believe it's an issue of younger devs not being able to learn server-side coding but just a lack of demand for it outside of the enterprise.
I've seen another problem, that's probably not going to happen with any of you careful hackers, but still seen it: where developers barely implement any security on their backend API and just go with filtering the results on the frontend side ...
With server side rendering of course you can still not-secure user input, but at least with template rendering, what you see is what you can see.
It "feels" (my personal biases and experience caveats apply) like "full stack" engineers aren't really that, but are rather great front-end developers with the back-end being an after thought.
Agreed, for me "full stack" really means the opposite: system and networks, backend / databases, and frontend. In most projects, even just mastering half of jquery does the job, as long as you at least know HTML with SEO and CSS well.
46 comments
[ 226 ms ] story [ 1185 ms ] threadInfrastructure has direct and indirect costs, must be built maintained scaled monitored paid for etc etc.
You need a very very good reason to choose to implement optional back end infrastructure.
None of these reasons would be strong enough to convince me to start building and maintaining and paying for that infrastructure.
A well done native app is always, faster, more robust and more enjoyable to use than a web UI. Even if your app is used relatively rarely, offering a significantly better user experience means it will be used more. And that’s a very important thing.
Unless I'm using your service daily I'm not going to bother with an app and just use the website.
Do you have data that shows otherwise?
But getting regular visitors to your web to install your app is by far the easiest way to get installs.
Oh no, you say. The article didn’t say “all” apps should be done with server-side rendering, it said “many.”
OK then, which ones? Well since we’re quoting the article, I’ll just put this here:
“the less complex your client-side is ... the less justification there is for client-side rendering.”
Now again, tell me, how is this site implemented?
This was achieved using their fork of DustJS: https://github.com/linkedin/dustjs
https://laravel-livewire.com/
There are similar projects for Phoenix/Elixir and Django:
https://github.com/phoenixframework/phoenix_live_view
https://github.com/edelvalle/reactor/blob/master/README.md
In server-rendered apps, the client/server boundary plays the role of a natural boundary between transient and domain-model state. Of course the pain points come when that approximation is wrong, but in most cases that's a pretty rare occurrence.
This is actually the primary thing I like about server-rendering. Not the performance side, but the reduction in state. The reduction in contingencies and in the potential for broken cases. When most of your state gets thrown away on every view change, there's so much less to keep track of.
Given how long I have to wait for the ever fashionable JS heavy SPA's to do _anything_, I'd almost be willing to bet it would still take less time.
My home server was more responsive when I was half way across the world.
HTML+CSS is a beautiful thing for ui. Its JS thats holding it back. If we had, say C# on the client side, imagine the web landscape by now.
> By itself, WebAssembly cannot currently directly access the DOM; it can only call JavaScript
https://developer.mozilla.org/en-US/docs/WebAssembly/Concept...
Sometimes all the work is client-side with third-party services as back-ends.
The only other solution I like is to have server-side rendering with live updates like Phoenix/Elixir, Vaadin/Java, or Rails/Ruby. These have scaling limitations but probably beyond what most of our apps need to support.
While I understand it's easy to make the argument that SSR is better, lighter, etc. It's easy to quickly violate the "Single Responsibility Principle" in that you now have two systems with little knowledge of each other both in control of rendering the UI.
I lived the era of jQuery with apps just being a bunch of jQuery extensions + SSR. Eventually the app needs to make XHR (type ahead search, nested picklists, etc), and you end up in a situation where there was just one thing controlling presentation.
server owns it at first, and generates the base system
client-side js then owns it, and does whatever it wants
there's no back and forth, or dual simultaneous control of the UI. There's only one owner at a time; just two different systems who ever own it (and single-responsibility-wise: separating static UI from dynamic UI)
It’s still a matter of preference, you might still prefer that over a full frontend react codebase. But having seen both nightmare jquery messes and react messes, they can both be painful to work with. I definitely don’t agree that things were much simpler in the old days.
With server side rendering of course you can still not-secure user input, but at least with template rendering, what you see is what you can see.
But then again, that's also IMHO