100% agree with the sentiment that client side rendering is overused.
Advice to Young Web Developers
181–190 of 328 posts
Re: Advice to Young Web Developers
#182As a web developer, I frequently see these posts about how we should write (or at least transpile to) HTML because it's so much simpler, and the browsers can render it so fast, and it's the right thing to do etc etc. But they all miss the point: writing with client-side JS based frameworks (React, Vue, whatever) is easier, faster, more versatile. If you have the option of writing an SPA, it's simpler quicker to build…
This is the opposite of what I would expect. React (or basically all JS SPAs) uses components which are essentially HTML elements populated by JSON data. It then stitches them together so that they can communicate via JS. I can explicitly tie together components/html client side via JS (annoying). Or I can simply render the correct html (no need for json routes) while I have access to all of the data on the server. R…
the efforts to write code for a javascript frontend framework vs a backend framework are exactly identical. there really is no difference. you save absolutely no effort by keeping html generation in the backend.
the differences are rather in the architecture.
you can win or loose a lot there, by choosing the right or wrong one.
by creating an SPA you win a much simpler backend, you separate data storage and processing from data presentation.
you win the ability to have multiple different frontends against the same backend, or run multiple backends against the same frontend.
you win the ability to upgrade/replace backend or frontend independently.
you win the ability to develop with multiple independent teams because the connection between frontend and backend is smaller and easier to define.
you win the ability to reuse generic backends over multiple projects...
these are a lot of advantages, if you need them.
but there are downsides.
you no longer have a single codebase.
you need to maintain an API
rendering is slower in the browser.
depending on what kind of application you create, you may need to be careful to not put any business logic into the frontend. (anything with business logic goes into the backend with an api to access it)
it should be clear by now that i am a strong supporter of this architecture.
i may miss some downsides of an SPA and i'd love to get more input on other potential downsides, however, loss of productivity from writing javascript is not one.
Re: Advice to Young Web Developers
#183As a web developer, I frequently see these posts about how we should write (or at least transpile to) HTML because it's so much simpler, and the browsers can render it so fast, and it's the right thing to do etc etc. But they all miss the point: writing with client-side JS based frameworks (React, Vue, whatever) is easier, faster, more versatile. If you have the option of writing an SPA, it's simpler quicker to build…
> I have never yet had a client who even mentioned rendering speed Because they rarely know about it. And why would they? It's a very technical choice. Factoring in things like render speed is your job when picking the most appropriate solution for the problem at hand. When you're doing this you are placing your own comfort and ease above that of anyone using the site. Google already factors site speed into rankings…
"Nooo you can't just use an SPA, it's your job to know the most appropriate solution for the problem at hand! Google already factors site speed into rankings and with all the Web Core Vitals stuff they've been pushing lately it's only going to be more important. You're failing your clients!"
"Haha react goes brrrr"
Re: Advice to Young Web Developers
#184Agree we should deliver the html directly to the browser in most of the cases. SPA are often abused and some 'webapp' sites need to load for more than 10 seconds to download the js files...
On the other hand, we want to deliver reactive experience. LiveView is an interesting approach. It returns the html with all content at the initial GET request, and apply partial UI update from the server. It processes the user interactions and application logics from the server. This way you don't need to explicitly maintain web API at all, because the render and update functions can directly access the data repository on the server. And we don't need to do validation twice. Liveview is implemented in Elixir and Typescript, also saw similar implementation in php and python.
Re: Advice to Young Web Developers
#185As a web developer, I frequently see these posts about how we should write (or at least transpile to) HTML because it's so much simpler, and the browsers can render it so fast, and it's the right thing to do etc etc. But they all miss the point: writing with client-side JS based frameworks (React, Vue, whatever) is easier, faster, more versatile. If you have the option of writing an SPA, it's simpler quicker to build…
I think only developers care about rendering speed like that. Most people are happy if the page loads in reasonable amount of time. UX people probably know what that means exactly.
Re: Advice to Young Web Developers
#186Earlier quoted context omitted.
Firefox must have performed poorly on Windows / MacOS in the past, because Firefox on Linux was never actually that bad. I've used Firefox for 15+ years now and never had the problems that people talk about.
I left Firefox in 2011 because it was unusably slow on my macbook. My recent experience has been that it is much faster and I am considering switching back.
It's the snappiest browser at the moment and I love its render as text function and automatic ad blocking on mobile. I've made a permanent switch on mobile, but I tend to miss the Chrome dev tools whenever I use it on a computer.
It's also wonderful that the browser is truly privacy conscious.
Re: Advice to Young Web Developers
#187As a web developer, I frequently see these posts about how we should write (or at least transpile to) HTML because it's so much simpler, and the browsers can render it so fast, and it's the right thing to do etc etc. But they all miss the point: writing with client-side JS based frameworks (React, Vue, whatever) is easier, faster, more versatile. If you have the option of writing an SPA, it's simpler quicker to build…
If you want site longevity, HTML is the way to go. It's fine if you clients aren't expecting to maintain their website for the next 10 years, go ahead and use the JavaScript framework.
Tell me that React websites today will still be around in 10 years time. With constant upkeep and maintenance, maybe. If a website is just a static website, not making it plain HTML is a disservice. The layers of abstraction will take its toll.
Re: Advice to Young Web Developers
#188Seems like a list of every web development ideal that gets upvoted on Hacker News. Still, I think the list can pretty much condensed down to one point: Use whatever technology is appropriate for this site or web app. Because a lot of developers seem to have a 'when all you have is a hammer' attitude towards web development. They learn React/Vue/Angular/whatever, then seemingly decide everything they will ever build w…
Yeah a developer should distinguish between using a static html, some javascript + html, server side rendering html, and full react app
Re: Advice to Young Web Developers
#189Earlier quoted context omitted.
This is the opposite of what I would expect. React (or basically all JS SPAs) uses components which are essentially HTML elements populated by JSON data. It then stitches them together so that they can communicate via JS. I can explicitly tie together components/html client side via JS (annoying). Or I can simply render the correct html (no need for json routes) while I have access to all of the data on the server. R…
the efforts to write code for a javascript frontend framework vs a backend framework are exactly identical. there really is no difference. you save absolutely no effort by keeping html generation in the backend. the differences are rather in the architecture. you can win or loose a lot there, by choosing the right or wrong one. by creating an SPA you win a much simpler backend, you separate data storage and processin…
Loose is a word that describes knots.
You are obviously writing more code for client side HTML generation based on JSON than regular server side rendering... I am saving effort if I need to write fewer files...
Your feature requires a JSON route, html rendering, and javascript that pulls everything together. Mine is just a route that returns HTML. Why is there absolutely no difference in effort? You have 3 files, I have one.
separating data from presentation is not new. It has nothing to do with SPAs
Re: Advice to Young Web Developers
#190As a web developer, I frequently see these posts about how we should write (or at least transpile to) HTML because it's so much simpler, and the browsers can render it so fast, and it's the right thing to do etc etc. But they all miss the point: writing with client-side JS based frameworks (React, Vue, whatever) is easier, faster, more versatile. If you have the option of writing an SPA, it's simpler quicker to build…
The only tradeoff is not rendering speed, you're also required to use javascript, create an api to serve data(depending on the site this may be overkill), ship huge gobs of framework code to users, work with an ever-changing and complex landscape of tools which mostly demand you convert all your code to use that framework, put up with the slower speed, and run js on the server side too for SEO.
There are very few upsides if you already serve pages server side and look at current client side js development.