"The web is built around server-side rendering."
That's the React definition of "server side rendering", where HTML gets generated on the server. Real "server side rendering" would mean generating an image server side and shipping that.
Advice to Young Web Developers
201–210 of 328 posts
Re: Advice to Young Web Developers
#202As 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.
Rule of thumb I’ve heard is, in order to feel “natural”, you should be at:
- 10ms response time for interactions (scroll, click, entering text)
- 100ms for in-page context switch (changing tabs in a dashboard, loading the next picture, etc.)
- 1000ms for page load
these are obviously rough guidelines — page load in particular is obviously gonna depend on your user’s internet speed if you have any kind of media — but they’re helpful when thinking about “reasonable”
Re: Advice to Young Web Developers
#203As 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.
What do you base that thinking on?
Amazon, Google, Walmart, Mozilla, and Yahoo all have numbers that say otherwise.
"Amazon and others found that removing 100 milliseconds of latency improves sales by 1%."
I'm 100% sure there are people who care about 1% differences in sales, and the fact that has been rediscovered independently by different organisations shows that "people" at least "aren't happy" with very small increases in page load times, at least when making purchase decisions. (Whether that extends to people reading your latest blog post or endless scrolling your social media site's newfeed is a reasonable question, which I'm not sure 've got a good enough handle on to have an opinion worth sharing.)
(From an earlier HN submission today: https://instant.page/ - click the [1] link n that page after that "Amazon and others found that removing 100 milliseconds of latency improves sales by 1%." sentence for sources.)
Re: Advice to Young Web Developers
#204Earlier quoted context omitted.
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 h…
we won't be able to answer this without specifically comparing framework by framework. some frameworks make your code more complex, some help keep it simple.
i have used different backend and frontend frameworks, and i found that backend frameworks do not make things simpler in the sense that you are talking about, if you want to create clean and maintainable code.
sure you can put everything in one file, but the number of files is a meaningless metric. more useful is the number of functions and abstractions. an API is an abstraction. you can do away with that if you generate html in the backend, but the price you pay is with a much closer coupling of interface and business logic that will make future changes harder. in any sufficiently large site you can't afford that and you end up rewriting your site to create the same architectural complexity simply because you need it.
Re: Advice to Young Web Developers
#205Earlier quoted context omitted.
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 h…
we won't be able to answer this without specifically comparing framework by framework. some frameworks make your code more complex, some help keep it simple. i have used different backend and frontend frameworks, and i found that backend frameworks do not make things simpler in the sense that you are talking about, if you want to create clean and maintainable code. sure you can put everything in one file, but the num…
No, we're really pretty close.
SPA frameworks query the server for JSON and then render HTML right?
Simpler in the sense of what? You prefer to not have all of the variables available when you render HTML? It's simpler to only render client side HTML and to query 4 different AJAX endpoints for resources?
Why are you trying to separate business and interface logic? Why are you displaying anything that the business logic doesn't understand?
The entire point of good code is that I can edit 1 file instead of editing 3.
Back end frameworks don't help you organize code? That's kind of their point?
Re: Advice to Young Web Developers
#206Re: Advice to Young Web Developers
#207As 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…
Its for sure not easier, building a web page in react.
Re: Advice to Young Web Developers
#208As 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 like a post from an upside-down world to me.
I suspect that perhaps you've learned primarily front-end frameworks for the majority of your career (an assumption, sorry if that's not right), which will make it seem as though frontend is easy compared to all this mystery stuff you're not used to working with.
It's the same for me, but the other direction. I've always worked with server-rendered applications, so to me all that stuff is super simple and working with frontend technologies involved learning a swath of new paradigms and tooling, so it seems like the more complicated one.
I think the learning point for me is simply that you're probably not going to care about what my arguments for server-side languages are, because it's never going to map to your experience of them. Just like I don't agree with any of your general points in the second paragraph.
Re: Advice to Young Web Developers
#209Earlier quoted context omitted.
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.
What do you base that thinking on? Amazon, Google, Walmart, Mozilla, and Yahoo all have numbers that say otherwise. "Amazon and others found that removing 100 milliseconds of latency improves sales by 1%." I'm 100% sure there are people who care about 1% differences in sales, and the fact that has been rediscovered independently by different organisations shows that "people" at least "aren't happy" with very small in…
I don't think rerendering an entire webpage on the server side every time a new chat message arrives is a good idea.
There might be people that misuse SPAs when server side rendering is the better choice but SPAs clearly have use cases that are not possible with just HTML.
Re: Advice to Young Web Developers
#210Earlier quoted context omitted.
It’s also fundamentally impossible for any website/app based around more complex ideas. I get that most of the web and most of what web developers do these days are just regurgitations of the same basic website designs. But man there is some really powerful tech in JS and WASM just waiting for someone to make brilliant stuff from.
any JSON request you make to the server to render html can be replaced by a single request to the server that replaces HTML. It's simpler to do the latter.
No it isn't. Now you need to keep client state on the server. Have you ever used JSF? It's doing what you describe and it's the worst framework I have ever used. Yes it's even worse than using PHP+Apache without a framework.