9 ms·

> In my experience server-side generated templates lightly sprinkled with “progressive enhancement”-style JavaScript are still the best way to do that. Those ap

by sgift 7y ago

> In my experience server-side generated templates lightly sprinkled with “progressive enhancement”-style JavaScript are still the best way to do that. Those apps are easier to develop, tend to be faster, tend to have fewer bugs, and your laptop’s fan won’t wake the neighbours. Thanks for that part. Really. A heartfelt thank you. Every time I see another "hey, I only want to show you text, but for some reason I thought using one of the modern js frameworks for it is a good idea" pages I feel years older. Instead of showing me text using html they pack that text in js on the server (it usually exists in an html compatible form already), then they shove that JS down the connection, then my browser has to interpret the JS, so it can get the html, which it then has to interpret too. And then, finally, I see my text. And because all of this is so slow we get techniques like "server-side rendering". The first time I read about server-side rendering I didn't understand what it was: so, you produce the html on the server. And send it to the client. Yes ..? What is the new part? Why is this something that people present as the next savior of the web? This is some special kind of madness and I wonder when it will stop.

scrollaway 7y ago
Has it occured to you you might simply not understand the advantages of this approach? There's a lot of crazy things in the world. Talk to a child about the economy or country borders and you'll realize how some things are just not straightforward to explain the advantages of. Serverside rendering in JS is no different to SSR in classic frameworks. You generate HTML serverside. Except in this case, you do it using JavaScript, because as it turns out, people develop with JavaScript. Putting aside how useful it is to only have one language to learn in a stack... Typescript is actually incredible to work with. Working on a typescript and react app is the most productive environment I have ever worked with my past 16 years of programming. The JavaScript world has an immense amount of tooling development behind it it's not even funny. So when the author says that classic HTML with sprinkled js on top is "easier to develop", I smirk. Developers are flocking en masse towards the SPA model usually BECAUSE it's easier to develop (both with a single language, and in general having the entire app be self-contained). And it's monumentally easier to maintain at scale, too. EDIT: Clarified that last paragraph.
- englishrookie 7y ago
  I'm an old php dev, still doing server side development exclusively, and these are genuine questions: 1. What tooling is there available? Do you mean something along the lines of vim or IntelliJ? 2. How do these techniques make the user experience better, compared to e.g. ajax?
  - scrollaway 7y ago
    > 1. What tooling is there available? So here's the thing about the JS world: You have access to essentially all the tooling ever developed for frontend dev. Linters, code formatters, IDEs, etc. Tons of crazy techniques invented to speed up development (hot-reloading in various frameworks; remote debugging with the various browser inspectors…). All this becomes available to your server development experience the moment you choose to share the language. And having developed with Python for over a decade, I can safely say I no longer enjoy doing that after seriously using typescript for just under a year. This also does have to do with the IDE; VSCode with TypeScript is a better dev experience than Python with any of the popular Python IDEs, even with added typings (python types are awful). > 2. How do these techniques make the user experience better, compared to e.g. ajax? They don't. They do enable you to take advantage of them in order to make a better user experience, but you still have to actively pursue that. Someone gave the example of Reddit lower down which is possibly the worst SPA I've ever seen on a popular site. OTOH, if you look at well-built NextJS websites, they're often ridiculously fast both to load and to use.
- asadkn 7y ago
  > If it were, developers would not be flocking en masse towards SPAs and the like. Argumentum ad populum. That's not an indicator of something being better. I do like using the modern SPA frameworks for well, (web)apps but I strongly disagree with using them in every case.
  - scrollaway 7y ago
    This has nothing to do with an "Argumentum ad populum". I'm saying devs are flocking towards it because it's a lot easier to work with and maintain. There's a lot of reasons why this is true. One is using a single programming language. Another is having the server app be aware of the entire app rendering rather than just templating-in bits and pieces. I could go on but that's not the point I'm trying to make.
Tade0 7y ago
This is some special kind of madness and I wonder when it will stop. There's light at the end of this tunnel in the form of compilers like Svelte or Stencil.js replacing frameworks. The improvement here is that since there's no special runtime the bundles are very small, so there isn't a lot of JS to parse. Also the code you have to write is much shorter comparing to frameworks.
- rbanffy 7y ago
  > There's light at the end of this tunnel in the form of compilers like Svelte or Stencil.js replacing frameworks. I am a bit skeptical that adding more complexity to something that's already much more complex than it should can be a solution.
  - Tade0 7y ago
    That's a healthy response to anything new in the front-end community. Nevertheless I encourage you to check out this presentation: https://youtu.be/AdNJ3fydeao https://youtu.be/AdNJ3fydeao Which explains the idea much better than I ever could. Two things had me sold on this: 1. They managed to make the thing so easy to use, that even people who's line of work involves mostly Excel sheets were able to create something useful after a short introduction. 2. The output is relatively readable JS. There are some surprises like a few one-letter method names, but overall you could open up the source of a running Svelte app(provided it weren't minified) and figure out what it's doing just by reading the code.
  - baddox 7y ago
    What are you saying that Svelte or Stencil are adding to? They are both complete toolchains.
kangoo1707 7y ago
Server-side rendering is the best front-end architecture at the moment. Superior first content paint and is better at SEO than SPA, and have a better architect than MVC. So in what way does if differ from traditional MVC? In MVC, the final output is HTML strings. Easy example: supposed you have an array of Posts in your controller, and a HTML template. The final result will be the combination of both of them. But when the HTML strings get sent to browser, you lose the array !!! It's gone. The client never receives an actual array, just DOM nodes. In Front-end framework SSR (NextJS or NuxtJS), what you work with is a component. A component can have data (an array), and the data is pushed (serialize) as-is to browsers. On the browser, you won't ever have to work with low level DOM nodes. You continue to see the component and data in its original form. This is the biggest win of SSR that is easily overlooked.
- provolone 7y ago
  If you need that array you could just embed a script tag in your html template.
saltminer 7y ago
The worst I've seen is where the main content is served (if you curl the website, you can see the text content is there), but it's hidden by a full-page loading animation which is removed by JS.
- ds_ 7y ago
  AMP? (https://amp.dev/documentation/guides-and-tutorials/learn/spec/amp-boilerplate https://amp.dev/documentation/guides-and-tutorials/learn/spe...)
- oefrha 7y ago
  The saving grace in these cases is that often the reader mode would work with the HTML just fine and you don’t need to wait for the useless 3MB JS bundle which you may have blocked. The same reader mode trick sometimes works against subscribe-to-read-the-rest-of-the-article paywalls and no-scroll anti-adblock modals, too.
jabart 7y ago
Currently dealing with a situation where a SPA app doesn't work with FB Sharing, because it exepects a set of META/Open Graph tags. So now we are going back to rendering a portion of the HTML on the server to support this. In JIRA, if I hit enter in the wrong field, it does a post out to somewhere and returns me a weird xml page and I lose my work. SPA apps are like building a browser, in a browser, and on the server. You lose some built in functionality and have to ship the framework down to the client.
- scruple 7y ago
  JIRA is a case study in bad UI/UX and web anti-patterns, IMHO. I think my team at work is finally ready to ditch it in favor of basically anything else.
  - luismbo 7y ago
    What else?
    - scruple 7y ago
      We're evaluating Basecamp, Asana, Codegiant, and Nuvro.
  - josefx 7y ago
    One of the managers at work swears that JIRA is the next great thing to happen to us. From all the negatives I have heard I get the feeling that the request to adopt it getting stuck somewhere in our parent company is a good thing.
- kureikain 7y ago
  In Jira, I constantly have a fear that I will update wrong thing. Every single click make something editable and the page jump around.
candu 7y ago
This is the part that often gets forgotten in these discussions: it shouldn't be "SPA for everything" vs. "vanilla HTML / CSS / JS for everything"; rather, we should be using the most appropriate set of tools for the job. I've worked on simple static sites, for which I typically lean more on vanilla HTML / CSS with a sprinkling of JS as recommended here. I've also worked on heavy-lifting applications, for which the limitations of this approach quickly become evident; in those cases, I use reactive component frameworks like Vue and React. But there's also approaches in between! For mid-complexity sites / apps, I've used vanilla HTML / CSS / JS, with some additional Python / Makefile plumbing to generate more repetitive parts. I've also used hybrid approaches, where vanilla HTML / CSS / JS is used for more static parts of the site and Vue is used for more dynamic parts. You can use Vue in full-on SPA mode with "server-side rendering"...but you can also just generate HTML server-side as you would have before, then progressively enhance parts of it with Vue / jQuery / whatever. I've also used "unfashionable" frameworks like Spring before, simply because it met the client's available in-house expertise. As developers, it's incumbent upon us to step back, assess the task / team / environment at hand, and pick tools accordingly.
- brightball 7y ago
  Yep. This is one of the reasons that so many people are excited about Phoenix Live View being released. It bridges that gap much farther and let’s you avoid the SPA until you hit the “is absolutely necessary” point.
- goostavos 7y ago
  On a side project I recently tried the middle ground approach and absolutely loved it. There was really only one part of the application that had complex user interactions, so that was the only place that I shipped a React bundle. The rest was just plain ol' templates and HTML. On the whole, I'd say that I loved it. It is _staggering_ how quickly you can knock pages out when you're not coordinating data representations across different pieces of your app. The static-ness also lets you embrace a kind of UI feature simplicity. Does that form _really_ need live validation, or can we just pop the errors after submit? The latter is the only option unless you wanna (a) either vanilla Javascript or JQuery the interactions or (b) start shipping a React bundle down to this page. And thus, form validation was part of the request/response cycle, which further speeds up development. It does get a little awkward when a static page starts having dynamic features begin to creep in. You have to decide when to awkwardly cut over to having that page powered by React. That said, without a framework supporting this kind of development directly, I'm skeptical of how well it would work on a team. I did this style on a solo project, so there was no one complaining about 'mixing technologies' or bemoaning 'why don't we just use React everywhere.' I imagine that the first time we rewrote a page in SPA tech because it picked up enough UX to warrant it, people would be up in arms about how much time we've 'wasted' by not doing it in the first place.
Bahamut 7y ago
I've seen the flip side of the coin in an app I inherited at work - it turns out server-side rendering can be significantly slower than client side rendering if you're rendering a lot of content, to the point where we hit an automatic timeout. If this app was a fat JS app, we probably wouldn't be trying to decommission it & it probably would load in seconds at worst, but the investment to modernize it/improve performance & scalability so it would meet our users' needs is too much.
- brightball 7y ago
  That’s true in a lot of cases mainly because of the approach to rendering. So many languages focus on rendering the entire HTML structure before sending the first byte back, specifically so that the page can be wrapped in a cache. This forces a lot of memory allocation to build up strings and parts of strings that takes time on its own, is often repetitive over the same HTML tags and then all of that has to be garbage collected at the end of the request. The approach taken by Elixir’s Phoenix framework is so fast because it avoids all of those pitfalls. Most people have to do a double take when they see the speed comparisons. Here’s a great write up: https://www.bignerdranch.com/blog/elixir-and-io-lists-part-2-io-lists-in-phoenix/ https://www.bignerdranch.com/blog/elixir-and-io-lists-part-2...
- andrewf 7y ago
  Your older app may be serializing a lot of work. For instance, it could be issuing 10 SQL queries, one after another, which take 200ms each to answer - that's 2s total just waiting for the database. Compare to a JS client which issues 10 backend API calls, each being a 200ms request from the server's perspective (and the JS may parallelize many of those requests) If this is a factor, rearchitecting the backend wouldn't necessarily be easier than an SPA rewrite. But it's not a fundamental limitation of server-side rendering.
baddox 7y ago
Of course I agree that if you’re only showing text with a few interactive enhancements, you can probably get away with jquery. The trouble is that too often a few enhancements turns into a few more enhancements, then a lot of enhancements, and then you end up with a huge mess of jquery spaghetti. It quickly becomes comical to claim that jquery would result in fewer bugs than pretty much any post-backbone UI library or framework you can think of.
- LocalPCGuy 7y ago
  I don't use jQuery much these days, but you can absolutely write quality jQuery code that is well structured and architected. It doesn't need to devolve into spaghetti code. It doesn't have guard rails like some frameworks might, and it's base examples don't really promote non-spaghetti code, but it's not that difficult for experienced JS devs to write good, high-quality jQuery code.
azdacha 7y ago
Why stop now when we got so much out of it? Maybe we will have even better solutions coming now that we have learnt so much. It's like "Please stop enhancing stuff it's good enough" - I like to enhance stuff, yeah it has costs but you can master them. That's definitely not the end of it. I hope we will do better. Maybe your "problems" will be resolved as well!
udfalkso 7y ago
Elixir/Phoenix’s new LiveView seems to really hit this sweet spot
JustSomeNobody 7y ago
If all the cool kids are doing a thing, you have to do that thing else you’re not a cool kid. There’s no other explanation.

by sgift 7y ago

scrollaway 7y ago

Has it occured to you you might simply not understand the advantages of this approach? There's a lot of crazy things in the world. Talk to a child about the economy or country borders and you'll realize how some things are just not straightforward to explain the advantages of. Serverside rendering in JS is no different to SSR in classic frameworks. You generate HTML serverside. Except in this case, you do it using JavaScript, because as it turns out, people develop with JavaScript. Putting aside how useful it is to only have one language to learn in a stack... Typescript is actually incredible to work with. Working on a typescript and react app is the most productive environment I have ever worked with my past 16 years of programming. The JavaScript world has an immense amount of tooling development behind it it's not even funny. So when the author says that classic HTML with sprinkled js on top is "easier to develop", I smirk. Developers are flocking en masse towards the SPA model usually BECAUSE it's easier to develop (both with a single language, and in general having the entire app be self-contained). And it's monumentally easier to maintain at scale, too. EDIT: Clarified that last paragraph.

englishrookie 7y ago
I'm an old php dev, still doing server side development exclusively, and these are genuine questions: 1. What tooling is there available? Do you mean something along the lines of vim or IntelliJ? 2. How do these techniques make the user experience better, compared to e.g. ajax?
- scrollaway 7y ago
  > 1. What tooling is there available? So here's the thing about the JS world: You have access to essentially all the tooling ever developed for frontend dev. Linters, code formatters, IDEs, etc. Tons of crazy techniques invented to speed up development (hot-reloading in various frameworks; remote debugging with the various browser inspectors…). All this becomes available to your server development experience the moment you choose to share the language. And having developed with Python for over a decade, I can safely say I no longer enjoy doing that after seriously using typescript for just under a year. This also does have to do with the IDE; VSCode with TypeScript is a better dev experience than Python with any of the popular Python IDEs, even with added typings (python types are awful). > 2. How do these techniques make the user experience better, compared to e.g. ajax? They don't. They do enable you to take advantage of them in order to make a better user experience, but you still have to actively pursue that. Someone gave the example of Reddit lower down which is possibly the worst SPA I've ever seen on a popular site. OTOH, if you look at well-built NextJS websites, they're often ridiculously fast both to load and to use.
asadkn 7y ago
> If it were, developers would not be flocking en masse towards SPAs and the like. Argumentum ad populum. That's not an indicator of something being better. I do like using the modern SPA frameworks for well, (web)apps but I strongly disagree with using them in every case.
- scrollaway 7y ago
  This has nothing to do with an "Argumentum ad populum". I'm saying devs are flocking towards it because it's a lot easier to work with and maintain. There's a lot of reasons why this is true. One is using a single programming language. Another is having the server app be aware of the entire app rendering rather than just templating-in bits and pieces. I could go on but that's not the point I'm trying to make.

Tade0 7y ago

This is some special kind of madness and I wonder when it will stop. There's light at the end of this tunnel in the form of compilers like Svelte or Stencil.js replacing frameworks. The improvement here is that since there's no special runtime the bundles are very small, so there isn't a lot of JS to parse. Also the code you have to write is much shorter comparing to frameworks.

rbanffy 7y ago
> There's light at the end of this tunnel in the form of compilers like Svelte or Stencil.js replacing frameworks. I am a bit skeptical that adding more complexity to something that's already much more complex than it should can be a solution.
- Tade0 7y ago
  That's a healthy response to anything new in the front-end community. Nevertheless I encourage you to check out this presentation: https://youtu.be/AdNJ3fydeao https://youtu.be/AdNJ3fydeao Which explains the idea much better than I ever could. Two things had me sold on this: 1. They managed to make the thing so easy to use, that even people who's line of work involves mostly Excel sheets were able to create something useful after a short introduction. 2. The output is relatively readable JS. There are some surprises like a few one-letter method names, but overall you could open up the source of a running Svelte app(provided it weren't minified) and figure out what it's doing just by reading the code.
- baddox 7y ago
  What are you saying that Svelte or Stencil are adding to? They are both complete toolchains.

kangoo1707 7y ago

Server-side rendering is the best front-end architecture at the moment. Superior first content paint and is better at SEO than SPA, and have a better architect than MVC. So in what way does if differ from traditional MVC? In MVC, the final output is HTML strings. Easy example: supposed you have an array of Posts in your controller, and a HTML template. The final result will be the combination of both of them. But when the HTML strings get sent to browser, you lose the array !!! It's gone. The client never receives an actual array, just DOM nodes. In Front-end framework SSR (NextJS or NuxtJS), what you work with is a component. A component can have data (an array), and the data is pushed (serialize) as-is to browsers. On the browser, you won't ever have to work with low level DOM nodes. You continue to see the component and data in its original form. This is the biggest win of SSR that is easily overlooked.

provolone 7y ago
If you need that array you could just embed a script tag in your html template.

saltminer 7y ago

The worst I've seen is where the main content is served (if you curl the website, you can see the text content is there), but it's hidden by a full-page loading animation which is removed by JS.

ds_ 7y ago
AMP? (https://amp.dev/documentation/guides-and-tutorials/learn/spec/amp-boilerplate https://amp.dev/documentation/guides-and-tutorials/learn/spe...)
oefrha 7y ago
The saving grace in these cases is that often the reader mode would work with the HTML just fine and you don’t need to wait for the useless 3MB JS bundle which you may have blocked. The same reader mode trick sometimes works against subscribe-to-read-the-rest-of-the-article paywalls and no-scroll anti-adblock modals, too.

jabart 7y ago

Currently dealing with a situation where a SPA app doesn't work with FB Sharing, because it exepects a set of META/Open Graph tags. So now we are going back to rendering a portion of the HTML on the server to support this. In JIRA, if I hit enter in the wrong field, it does a post out to somewhere and returns me a weird xml page and I lose my work. SPA apps are like building a browser, in a browser, and on the server. You lose some built in functionality and have to ship the framework down to the client.

scruple 7y ago
JIRA is a case study in bad UI/UX and web anti-patterns, IMHO. I think my team at work is finally ready to ditch it in favor of basically anything else.
- luismbo 7y ago
  What else?
  - scruple 7y ago
    We're evaluating Basecamp, Asana, Codegiant, and Nuvro.
- josefx 7y ago
  One of the managers at work swears that JIRA is the next great thing to happen to us. From all the negatives I have heard I get the feeling that the request to adopt it getting stuck somewhere in our parent company is a good thing.
kureikain 7y ago
In Jira, I constantly have a fear that I will update wrong thing. Every single click make something editable and the page jump around.

candu 7y ago

This is the part that often gets forgotten in these discussions: it shouldn't be "SPA for everything" vs. "vanilla HTML / CSS / JS for everything"; rather, we should be using the most appropriate set of tools for the job. I've worked on simple static sites, for which I typically lean more on vanilla HTML / CSS with a sprinkling of JS as recommended here. I've also worked on heavy-lifting applications, for which the limitations of this approach quickly become evident; in those cases, I use reactive component frameworks like Vue and React. But there's also approaches in between! For mid-complexity sites / apps, I've used vanilla HTML / CSS / JS, with some additional Python / Makefile plumbing to generate more repetitive parts. I've also used hybrid approaches, where vanilla HTML / CSS / JS is used for more static parts of the site and Vue is used for more dynamic parts. You can use Vue in full-on SPA mode with "server-side rendering"...but you can also just generate HTML server-side as you would have before, then progressively enhance parts of it with Vue / jQuery / whatever. I've also used "unfashionable" frameworks like Spring before, simply because it met the client's available in-house expertise. As developers, it's incumbent upon us to step back, assess the task / team / environment at hand, and pick tools accordingly.

brightball 7y ago
Yep. This is one of the reasons that so many people are excited about Phoenix Live View being released. It bridges that gap much farther and let’s you avoid the SPA until you hit the “is absolutely necessary” point.
goostavos 7y ago
On a side project I recently tried the middle ground approach and absolutely loved it. There was really only one part of the application that had complex user interactions, so that was the only place that I shipped a React bundle. The rest was just plain ol' templates and HTML. On the whole, I'd say that I loved it. It is _staggering_ how quickly you can knock pages out when you're not coordinating data representations across different pieces of your app. The static-ness also lets you embrace a kind of UI feature simplicity. Does that form _really_ need live validation, or can we just pop the errors after submit? The latter is the only option unless you wanna (a) either vanilla Javascript or JQuery the interactions or (b) start shipping a React bundle down to this page. And thus, form validation was part of the request/response cycle, which further speeds up development. It does get a little awkward when a static page starts having dynamic features begin to creep in. You have to decide when to awkwardly cut over to having that page powered by React. That said, without a framework supporting this kind of development directly, I'm skeptical of how well it would work on a team. I did this style on a solo project, so there was no one complaining about 'mixing technologies' or bemoaning 'why don't we just use React everywhere.' I imagine that the first time we rewrote a page in SPA tech because it picked up enough UX to warrant it, people would be up in arms about how much time we've 'wasted' by not doing it in the first place.

Bahamut 7y ago

I've seen the flip side of the coin in an app I inherited at work - it turns out server-side rendering can be significantly slower than client side rendering if you're rendering a lot of content, to the point where we hit an automatic timeout. If this app was a fat JS app, we probably wouldn't be trying to decommission it & it probably would load in seconds at worst, but the investment to modernize it/improve performance & scalability so it would meet our users' needs is too much.

brightball 7y ago
That’s true in a lot of cases mainly because of the approach to rendering. So many languages focus on rendering the entire HTML structure before sending the first byte back, specifically so that the page can be wrapped in a cache. This forces a lot of memory allocation to build up strings and parts of strings that takes time on its own, is often repetitive over the same HTML tags and then all of that has to be garbage collected at the end of the request. The approach taken by Elixir’s Phoenix framework is so fast because it avoids all of those pitfalls. Most people have to do a double take when they see the speed comparisons. Here’s a great write up: https://www.bignerdranch.com/blog/elixir-and-io-lists-part-2-io-lists-in-phoenix/ https://www.bignerdranch.com/blog/elixir-and-io-lists-part-2...
andrewf 7y ago
Your older app may be serializing a lot of work. For instance, it could be issuing 10 SQL queries, one after another, which take 200ms each to answer - that's 2s total just waiting for the database. Compare to a JS client which issues 10 backend API calls, each being a 200ms request from the server's perspective (and the JS may parallelize many of those requests) If this is a factor, rearchitecting the backend wouldn't necessarily be easier than an SPA rewrite. But it's not a fundamental limitation of server-side rendering.

baddox 7y ago

Of course I agree that if you’re only showing text with a few interactive enhancements, you can probably get away with jquery. The trouble is that too often a few enhancements turns into a few more enhancements, then a lot of enhancements, and then you end up with a huge mess of jquery spaghetti. It quickly becomes comical to claim that jquery would result in fewer bugs than pretty much any post-backbone UI library or framework you can think of.

LocalPCGuy 7y ago
I don't use jQuery much these days, but you can absolutely write quality jQuery code that is well structured and architected. It doesn't need to devolve into spaghetti code. It doesn't have guard rails like some frameworks might, and it's base examples don't really promote non-spaghetti code, but it's not that difficult for experienced JS devs to write good, high-quality jQuery code.

azdacha 7y ago

Why stop now when we got so much out of it? Maybe we will have even better solutions coming now that we have learnt so much. It's like "Please stop enhancing stuff it's good enough" - I like to enhance stuff, yeah it has costs but you can master them. That's definitely not the end of it. I hope we will do better. Maybe your "problems" will be resolved as well!

udfalkso 7y ago

Elixir/Phoenix’s new LiveView seems to really hit this sweet spot

JustSomeNobody 7y ago

If all the cool kids are doing a thing, you have to do that thing else you’re not a cool kid. There’s no other explanation.