9 ms·

As 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 re

As 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 way, and so easy to deploy. Sure, it renders slower. I've just signed my 25th professional client, and I have never yet had a client who even mentioned rendering speed, let alone was willing to make any trade-off for it. Server-side rendering or writing raw HTML are over-rated.

haecceity 6y ago
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.
- ketzo 6y ago
  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”
- bigiain 6y ago
  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/ 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.)
  - imtringued 6y ago
    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.
    - bigiain 6y ago
      > I don't think rerendering an entire webpage on the server side every time a new chat message arrives is a good idea. Sure, but that's pretty much cherry picked whataboutism when the parent comment we're talking about said: "Most people are happy if the page loads in reasonable amount of time". So apart from people writing chat messaging widgets for websites, do you have data to contradict the conclusions about webpage load times and rates of change of user behaviour that can be obviously drawn from the Google/Amazon/Walmart/Mozilla/Yahoo data?
  - bryanrasmussen 6y ago
    a 1% increase in sales and most people not caring are not definitely incompatible viewpoints. That said I am definitely one of the people for whom it does matter.
- hawski 6y ago
  If everyone has only shit sandwiches people won't say they don't like shit sandwiches, but just don't enjoy sandwiches in general. Then when they try a ham sandwich for the first time they will tell that this one is better and they prefer it to others. Modern web is serving people mostly with nice looking shit sandwiches.
brailsafe 6y ago
What kind of stuff are you building and is it the job of the person paying you to actually use the thing?
arkis22 6y ago
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. Rendering speed as you mentioned (client or sever), is basically never a consideration. So why bother explicitly writing javascript to bind html components together when I could just simply render the correct server side HTML? Ajax is fantastic, but you don't really need an SPA. If you want to be wildly productive, minimize the javascript you write. I'm a big fan of intercooler.js btw.
- em-bee 6y ago
  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.
  - arkis22 6y ago
    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
Waterluvian 6y ago
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.
- arkis22 6y ago
  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.
  - imtringued 6y ago
    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.
    - arkis22 6y ago
      You always keep client state on the server in the sense that the DB keeps track of sessions and the server keeps track of caching. Never trust the state of the client... Never trust client's input... No idea what JSF is. Sorry it didn't give you access to the data you needed when you rendered files.
tdeck 6y ago
This misses the part where with an SPA I have to figure out what data and access patterns my frontend code is going to want, define an API+schema for the frontend-backend interactions, and (often) write data validation on both the frontend and the backend - all this in addition to the data definition I would have to do on the backend in any case. If I'm able to render things from the backend, I just have to query the data and slot it into the page. No need to design an API that's flexible enough for application use but still inflexible enough to prevent security holes. Also, if I decide later to update how the data is represented (a common activity in early-stage projects), I only have to edit only one thing instead of two things.
- MattGaiser 6y ago
  > I have never yet had a client who even mentioned rendering speed, let alone was willing to make any trade-off for it. This section also frequently applies to security. > but still inflexible enough to prevent security holes. Unless it involves a transaction or government secrets, security is usually way down the list of priorities.
- davnicwil 6y ago
  Curious what you mean by the API flexibility Vs security point. To me, the API for a SPA is just another view over the exact same data that would be accessible in the HTML output of a server render (which, indeed, is the 4th point in the article). Your access to that data is gated by a cookie with a token in it in both cases. On the code level, it's really not all that different - the operations you perform 'directly' through function calls in a pure server render model you simply put behind another HTTP interface. I get that this mapping work might be a bit cumbersome and take some extra work, but I'm unconvinced that it introduces some kind of security tradeoff - the client ultimately has the ability to call through to exactly the same operations, just getting the data back in a different format, right?
  - tdeck 6y ago
    By security I mean pretty basic things like "client should only be able to query objects the user account has access to" and "client should only be able to perform certain kinds of transactions and mutations". On the back end that's not too tedious - just make sure I only query for what I want. But with a SPA I can't just assume the client will make only the "right" queries, otherwise I could just expose a SQL query endpoint to the client and never have to think about APIs again. Instead I have to figure out what data access patterns my frontend will need and implement those, along with whatever visibility restrictions are required. I'm forced to do the former in the backend (as well as the frontend) because the latter can only be done in the backend. (Aside: I realize that back in the day people did indeed use database mechanisms like DB users and stored procedures to do what I describe, and then client apps connected directly to the database. But this practice seems to have faxed and isn't readily doable on the web anyway).
untog 6y ago
> 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 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.
- quxpar 6y ago
  "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"
  - arkis22 6y ago
    I have no idea what you are trying to communicate
    - teddyh 6y ago
      It’s a meme variant. Here is another, for comparison: https://knowyourmeme.com/memes/money-printer-go-brrr https://knowyourmeme.com/memes/money-printer-go-brrr
SPBS 6y ago
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.
- MattGaiser 6y ago
  > The layers of abstraction will take its toll. As an industry, this is called job security. It is fascinating to be in an industry where systems requiring high levels of maintenance are preferred by the client.
- _waqas_ali_ 6y ago
  This only applies to the use case of creating static websites with React. A lot of React websites are dynamic and comparable with websites built using PHP or other server-side frameworks. Even if you write html by hand while using PHP, you still need to maintain the server code and constant upkeep/maintenance will be required.
- jjav 6y ago
  So much this. There is tremendous value in longevity. Writing content which is guaranteed to be unusable in a few years is anathema to me. On my website I have pages which date back to 1993-94. Still readable just fine. I used to post those links to mailing lists back then and they still get regular hits from people in that community because I've also maintained the URLs constant.
  - ehnto 6y ago
    In my personal life I serve HTML, CSS and native, gracefully degrading JS (if any), for the same reasons. In my professional life though, I realised that 95% of the things I build will be changed in the next year or so. We often inherit projects that were only just finished, and our first task is to start changing it entirely. So I aim for robustness of maintenance rather than robustness of the finished product. It's inevitable that it will change, but I can anticipate that in the same way a well engineered car can anticipate it's maintenance cycles.
grey-area 6y ago
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.
GrumpyNl 6y ago
Its for sure not easier, building a web page in react.
ehnto 6y ago
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.
- danielheath 6y ago
  I don’t know; I’ve got 8 years building JS-heavy frontends and more than that building backends / ops. React isn’t too bad, as such things go, but compared to server rendering SPAs are such a slog. There are good reasons to build them sometimes, but “fast and easy” is not one of them IME.
- stevage 6y ago
  No, not exactly. I learnt JavaScript in the very early days, when we called it "Dynamic HTML". I mostly built very raw non-frameworked sites until a couple of years ago. I actually found learning Vue (~2 years ago) kind of difficult because of how inside out everything was, and I was still trying to picture what click handlers were being attached where, etc etc. I was halfway through building a site when I switched to Vue. It ended up reducing the number of lines of code by 30-40%, and made the interactions much simpler to reason about. Now that I know Vue, I think it's a vastly better way to develop than without it.
catwell 6y ago
> If you have the option of writing an SPA, it's simpler quicker to build this way, and so easy to deploy. It's simpler if you only write the front-end, because it de-couples the work with the back-end. If you are in charge of both front-end and back-end, server-side rendering is easier. It's a case of Conway's Law. Knowing that, you may choose to have a back-end team and a front-end team or a team of full stack developers depending on the end result you want. Personally I think it depends on whether the Web is just another client for you, which consumes APIs like native applications, or if your product is entirely web-based.
- randompwd 6y ago
  > It's simpler if you only write the front-end, because it de-couples the work with the back-end. This is nonsense. Both the frontend and the backend influence the design of each other(and for good reason). The notion that you can build one without the other and be done with it is just wishful thinking.
zelphirkalt 6y ago
> Server-side rendering or writing raw HTML are over-rated. Just to be sure: These two are not the same and server-side rendering does not necessitate writing raw HTML. In fact, I think that most advanced languages used on the server-side have means of not writing raw HTML. There are template engines and some languages offer SXML, which already provides you with a kind of template engine. Personal opinion: I really don't like having to write raw HTML in form of it being just a string, allowing for all kinds of markup issues, formatting issues etc. A programming language or used framework/library should have awareness of the HTML tags and prevent mistakes. SXML prevents mistakes in nesting for example. In Racket and I think in Scheme dialects as well, SXML prevents cross-site scripting by design as well. What many many people get wrong is how they split up their documents. They forget about composability and use only concatenation (looking at you, wordpress themes ...). This severely limits reuse of code. Good templating languages try to nudge you into the direction of making things composable.
onion2k 6y ago
Sure, it renders slower. I've just signed my 25th professional client, and I have never yet had a client who even mentioned rendering speed, let alone was willing to make any trade-off for it. That's because understanding rendering speed is your job, not the client's job. What the client will be saying is things like "Why are my conversions so low?", "My site doesn't appear in search results." and "My friend's neighbour's dog-sitter told me my website sucks because it takes ages to load." It's your job to translate those comments in to meaningful actions, like optimizing rendering speed.
- stevage 6y ago
  I guess so. Fortunately, none of my clients are in those kinds of businesses. Which is sort of a weird point. So much of the web development blogosphere assumes that the reader is working on a site that sells some product direct to the public, who are very fickle, and will abandon your site quickly. Undoubtedly that industry does exist, but I've just never been anywhere near it.
chiefalchemist 6y ago
"I love how slow this site is," said no visitor. Ever. If your clients are like mine, there are likely a lot of things your clients don't ask for. For instance, accessibility. Do we ignore that as well? You're also not factoring in ongoing maintenance. What's easy for you to build and deploy might be less so for someone else. React, Vue, etc. are great tools - when they are the correct tool for the job - but they are still relatively niche. If you're not taking a "what if I get hit by a bus approach" then you're doing your clients a disservice. You might want to try being a typical user for a month or so. Use a smaller monitor, an older mobile device, a slower internet connection, etc. Then take that lens and apply it to your SPA genius.
- stevage 6y ago
  >If your clients are like mine, there are likely a lot of things your clients don't ask for. For instance, accessibility. Do we ignore that as well? Well, some of my clients are government, so they do care about accessibility. For the rest, I put in some effort, because it's the right thing to do. (As opposed to rendering speed, which I really don't think matters, within reason.)
collyw 6y ago
Sounds like nonsense to me. If I write something in Django, I can let the forms be auto-generated to whatever degree I like. If I do it as a SPA, I essentially need to twice as much work, as I have to write a backend to serve and consume JSON and a frontend to display and interact with it. Then you have got the nightmare of debugging the mess.
kls 6y ago
I am an old developer and I completely disagree with some of the advice. Specifically a lot of older developers think we should be delivering thin client applications which was how the early web did it, but the early web did it for two important reasons. The first being bandwidth and the second being because Sun had a big hand in the early web and sun saw the world as selling big iron that a bunch of dumb terminals with low processing power connected to. It was a dumb idea and Sun partly died because of it. It is a painful user experience and I would dread trying to build modern web delivered applications via the old page-post model. If anything I see today's SPA's as correcting a world gone wrong and finally killing the completely stupid idea of dumb terminals once and for all. They also got rid of flash and a host of other browser plugins. To sum it up, i was programming before the web existed, I hated the old page-post model, I don't build web pages, I build large apps. I am happy that I can deliver them via the web and I am happy about the state of the art. I think it can be improved on quite a bit, but not by going backwards.
dirtnugget 6y ago
My third client was a SPA breaking down from its usage of redux. They would pull chunks search results from the backend in a loop (and this could be many hundred chunks of 100 objects each), indexing them in their reducers causing heavy rerenders. But they "needed" to do that in order to build their filters. All in the frontend. The machine (2019 MacBook Pro 13) would go full CPU load. So yeah it happens. Their old server side solution was near instant. Definitely the design flaw was to index it in the frontend in the first place instead of preparing that data somewhere in between to easily be consumed by the client but still draws the picture of how many people approach SPAs these days.
Apofis 6y ago
If any of your clients rely on "pay-per-click" advertising, your care-free attitude toward page load speed will simply cost them money. The difference between a subsecond load time and a 5-10 second load time is a lot of lost revenue. Not a lot of people will wait over 5 seconds for your fancy webapp SPA to load. They will click back or just exit. It has nothing to do with standards, businesses don't care about standards in the long run, they care about making money.

haecceity 6y ago

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.

ketzo 6y ago
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”
bigiain 6y ago
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/ 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.)
- imtringued 6y ago
  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.
  - bigiain 6y ago
    > I don't think rerendering an entire webpage on the server side every time a new chat message arrives is a good idea. Sure, but that's pretty much cherry picked whataboutism when the parent comment we're talking about said: "Most people are happy if the page loads in reasonable amount of time". So apart from people writing chat messaging widgets for websites, do you have data to contradict the conclusions about webpage load times and rates of change of user behaviour that can be obviously drawn from the Google/Amazon/Walmart/Mozilla/Yahoo data?
- bryanrasmussen 6y ago
  a 1% increase in sales and most people not caring are not definitely incompatible viewpoints. That said I am definitely one of the people for whom it does matter.
hawski 6y ago
If everyone has only shit sandwiches people won't say they don't like shit sandwiches, but just don't enjoy sandwiches in general. Then when they try a ham sandwich for the first time they will tell that this one is better and they prefer it to others. Modern web is serving people mostly with nice looking shit sandwiches.

brailsafe 6y ago

What kind of stuff are you building and is it the job of the person paying you to actually use the thing?

arkis22 6y ago

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. Rendering speed as you mentioned (client or sever), is basically never a consideration. So why bother explicitly writing javascript to bind html components together when I could just simply render the correct server side HTML? Ajax is fantastic, but you don't really need an SPA. If you want to be wildly productive, minimize the javascript you write. I'm a big fan of intercooler.js btw.

em-bee 6y ago
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.
- arkis22 6y ago
  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

Waterluvian 6y ago

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.

arkis22 6y ago
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.
- imtringued 6y ago
  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.
  - arkis22 6y ago
    You always keep client state on the server in the sense that the DB keeps track of sessions and the server keeps track of caching. Never trust the state of the client... Never trust client's input... No idea what JSF is. Sorry it didn't give you access to the data you needed when you rendered files.

tdeck 6y ago

This misses the part where with an SPA I have to figure out what data and access patterns my frontend code is going to want, define an API+schema for the frontend-backend interactions, and (often) write data validation on both the frontend and the backend - all this in addition to the data definition I would have to do on the backend in any case. If I'm able to render things from the backend, I just have to query the data and slot it into the page. No need to design an API that's flexible enough for application use but still inflexible enough to prevent security holes. Also, if I decide later to update how the data is represented (a common activity in early-stage projects), I only have to edit only one thing instead of two things.

MattGaiser 6y ago
> I have never yet had a client who even mentioned rendering speed, let alone was willing to make any trade-off for it. This section also frequently applies to security. > but still inflexible enough to prevent security holes. Unless it involves a transaction or government secrets, security is usually way down the list of priorities.
davnicwil 6y ago
Curious what you mean by the API flexibility Vs security point. To me, the API for a SPA is just another view over the exact same data that would be accessible in the HTML output of a server render (which, indeed, is the 4th point in the article). Your access to that data is gated by a cookie with a token in it in both cases. On the code level, it's really not all that different - the operations you perform 'directly' through function calls in a pure server render model you simply put behind another HTTP interface. I get that this mapping work might be a bit cumbersome and take some extra work, but I'm unconvinced that it introduces some kind of security tradeoff - the client ultimately has the ability to call through to exactly the same operations, just getting the data back in a different format, right?
- tdeck 6y ago
  By security I mean pretty basic things like "client should only be able to query objects the user account has access to" and "client should only be able to perform certain kinds of transactions and mutations". On the back end that's not too tedious - just make sure I only query for what I want. But with a SPA I can't just assume the client will make only the "right" queries, otherwise I could just expose a SQL query endpoint to the client and never have to think about APIs again. Instead I have to figure out what data access patterns my frontend will need and implement those, along with whatever visibility restrictions are required. I'm forced to do the former in the backend (as well as the frontend) because the latter can only be done in the backend. (Aside: I realize that back in the day people did indeed use database mechanisms like DB users and stored procedures to do what I describe, and then client apps connected directly to the database. But this practice seems to have faxed and isn't readily doable on the web anyway).

untog 6y ago

> 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 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.

quxpar 6y ago
"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"
- arkis22 6y ago
  I have no idea what you are trying to communicate
  - teddyh 6y ago
    It’s a meme variant. Here is another, for comparison: https://knowyourmeme.com/memes/money-printer-go-brrr https://knowyourmeme.com/memes/money-printer-go-brrr

SPBS 6y ago

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.

MattGaiser 6y ago
> The layers of abstraction will take its toll. As an industry, this is called job security. It is fascinating to be in an industry where systems requiring high levels of maintenance are preferred by the client.
_waqas_ali_ 6y ago
This only applies to the use case of creating static websites with React. A lot of React websites are dynamic and comparable with websites built using PHP or other server-side frameworks. Even if you write html by hand while using PHP, you still need to maintain the server code and constant upkeep/maintenance will be required.
jjav 6y ago
So much this. There is tremendous value in longevity. Writing content which is guaranteed to be unusable in a few years is anathema to me. On my website I have pages which date back to 1993-94. Still readable just fine. I used to post those links to mailing lists back then and they still get regular hits from people in that community because I've also maintained the URLs constant.
- ehnto 6y ago
  In my personal life I serve HTML, CSS and native, gracefully degrading JS (if any), for the same reasons. In my professional life though, I realised that 95% of the things I build will be changed in the next year or so. We often inherit projects that were only just finished, and our first task is to start changing it entirely. So I aim for robustness of maintenance rather than robustness of the finished product. It's inevitable that it will change, but I can anticipate that in the same way a well engineered car can anticipate it's maintenance cycles.

grey-area 6y ago

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.

GrumpyNl 6y ago

Its for sure not easier, building a web page in react.

ehnto 6y ago

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.

danielheath 6y ago
I don’t know; I’ve got 8 years building JS-heavy frontends and more than that building backends / ops. React isn’t too bad, as such things go, but compared to server rendering SPAs are such a slog. There are good reasons to build them sometimes, but “fast and easy” is not one of them IME.
stevage 6y ago
No, not exactly. I learnt JavaScript in the very early days, when we called it "Dynamic HTML". I mostly built very raw non-frameworked sites until a couple of years ago. I actually found learning Vue (~2 years ago) kind of difficult because of how inside out everything was, and I was still trying to picture what click handlers were being attached where, etc etc. I was halfway through building a site when I switched to Vue. It ended up reducing the number of lines of code by 30-40%, and made the interactions much simpler to reason about. Now that I know Vue, I think it's a vastly better way to develop than without it.

catwell 6y ago

> If you have the option of writing an SPA, it's simpler quicker to build this way, and so easy to deploy. It's simpler if you only write the front-end, because it de-couples the work with the back-end. If you are in charge of both front-end and back-end, server-side rendering is easier. It's a case of Conway's Law. Knowing that, you may choose to have a back-end team and a front-end team or a team of full stack developers depending on the end result you want. Personally I think it depends on whether the Web is just another client for you, which consumes APIs like native applications, or if your product is entirely web-based.

randompwd 6y ago
> It's simpler if you only write the front-end, because it de-couples the work with the back-end. This is nonsense. Both the frontend and the backend influence the design of each other(and for good reason). The notion that you can build one without the other and be done with it is just wishful thinking.

zelphirkalt 6y ago

> Server-side rendering or writing raw HTML are over-rated. Just to be sure: These two are not the same and server-side rendering does not necessitate writing raw HTML. In fact, I think that most advanced languages used on the server-side have means of not writing raw HTML. There are template engines and some languages offer SXML, which already provides you with a kind of template engine. Personal opinion: I really don't like having to write raw HTML in form of it being just a string, allowing for all kinds of markup issues, formatting issues etc. A programming language or used framework/library should have awareness of the HTML tags and prevent mistakes. SXML prevents mistakes in nesting for example. In Racket and I think in Scheme dialects as well, SXML prevents cross-site scripting by design as well. What many many people get wrong is how they split up their documents. They forget about composability and use only concatenation (looking at you, wordpress themes ...). This severely limits reuse of code. Good templating languages try to nudge you into the direction of making things composable.

onion2k 6y ago

Sure, it renders slower. I've just signed my 25th professional client, and I have never yet had a client who even mentioned rendering speed, let alone was willing to make any trade-off for it. That's because understanding rendering speed is your job, not the client's job. What the client will be saying is things like "Why are my conversions so low?", "My site doesn't appear in search results." and "My friend's neighbour's dog-sitter told me my website sucks because it takes ages to load." It's your job to translate those comments in to meaningful actions, like optimizing rendering speed.

stevage 6y ago
I guess so. Fortunately, none of my clients are in those kinds of businesses. Which is sort of a weird point. So much of the web development blogosphere assumes that the reader is working on a site that sells some product direct to the public, who are very fickle, and will abandon your site quickly. Undoubtedly that industry does exist, but I've just never been anywhere near it.

chiefalchemist 6y ago

"I love how slow this site is," said no visitor. Ever. If your clients are like mine, there are likely a lot of things your clients don't ask for. For instance, accessibility. Do we ignore that as well? You're also not factoring in ongoing maintenance. What's easy for you to build and deploy might be less so for someone else. React, Vue, etc. are great tools - when they are the correct tool for the job - but they are still relatively niche. If you're not taking a "what if I get hit by a bus approach" then you're doing your clients a disservice. You might want to try being a typical user for a month or so. Use a smaller monitor, an older mobile device, a slower internet connection, etc. Then take that lens and apply it to your SPA genius.

stevage 6y ago
>If your clients are like mine, there are likely a lot of things your clients don't ask for. For instance, accessibility. Do we ignore that as well? Well, some of my clients are government, so they do care about accessibility. For the rest, I put in some effort, because it's the right thing to do. (As opposed to rendering speed, which I really don't think matters, within reason.)

collyw 6y ago

Sounds like nonsense to me. If I write something in Django, I can let the forms be auto-generated to whatever degree I like. If I do it as a SPA, I essentially need to twice as much work, as I have to write a backend to serve and consume JSON and a frontend to display and interact with it. Then you have got the nightmare of debugging the mess.

kls 6y ago

I am an old developer and I completely disagree with some of the advice. Specifically a lot of older developers think we should be delivering thin client applications which was how the early web did it, but the early web did it for two important reasons. The first being bandwidth and the second being because Sun had a big hand in the early web and sun saw the world as selling big iron that a bunch of dumb terminals with low processing power connected to. It was a dumb idea and Sun partly died because of it. It is a painful user experience and I would dread trying to build modern web delivered applications via the old page-post model. If anything I see today's SPA's as correcting a world gone wrong and finally killing the completely stupid idea of dumb terminals once and for all. They also got rid of flash and a host of other browser plugins. To sum it up, i was programming before the web existed, I hated the old page-post model, I don't build web pages, I build large apps. I am happy that I can deliver them via the web and I am happy about the state of the art. I think it can be improved on quite a bit, but not by going backwards.

dirtnugget 6y ago

My third client was a SPA breaking down from its usage of redux. They would pull chunks search results from the backend in a loop (and this could be many hundred chunks of 100 objects each), indexing them in their reducers causing heavy rerenders. But they "needed" to do that in order to build their filters. All in the frontend. The machine (2019 MacBook Pro 13) would go full CPU load. So yeah it happens. Their old server side solution was near instant. Definitely the design flaw was to index it in the frontend in the first place instead of preparing that data somewhere in between to easily be consumed by the client but still draws the picture of how many people approach SPAs these days.

Apofis 6y ago

If any of your clients rely on "pay-per-click" advertising, your care-free attitude toward page load speed will simply cost them money. The difference between a subsecond load time and a 5-10 second load time is a lot of lost revenue. Not a lot of people will wait over 5 seconds for your fancy webapp SPA to load. They will click back or just exit. It has nothing to do with standards, businesses don't care about standards in the long run, they care about making money.