9 ms·

Do we need all this JS? I’m starting to look back at classic web development where you had a server rendered mvc style app. There was a controller and templates

Do we need all this JS? I’m starting to look back at classic web development where you had a server rendered mvc style app. There was a controller and templates populated on the server. Every page was a full rerender, but it was small html. Proper caching kept the minimal CSS and images on the client for a regular session under 30 minutes. This seems better. I know we switched because front end experts told us that users found the full refreshes annoying. They said that users really wanted native desktop like seamless change pages. Never did I see proof of these claimed. Is the modern JS based design our cubicle moment? Did we get suckered in by experts making productivity claims with nothing to back them up?

scientistem 9y ago
I think there is (limited) semantic value to single page forms. They also encourage api first design. Is this always worth it? Certainly not. But it does have value.
cabaalis 9y ago
I think the problem is in all the data-binding of JSON responses to the front end. I don't care what anyone says, it's slow.
- andrewstuart2 9y ago
  If you don't care what anyone says, then I guess there's no point in presenting data.
- osrec 9y ago
  Slow in what sense? I mean, for almost all actual use cases, it seems to be quick enough when done right.
andrewstuart2 9y ago
Good single-page app development is just as clean (I've done both), and will be faster over the long term, and scales out better. It keeps all the components cacheable and DRY. The benefits are all about data locality. If your code and data are cached on the client, then the only the minimal subset that has changed needs to be invalidated and updated. If it's only data that has changed, that's all that's retrieved. If it's only code, same goes here. For old-school MVC, if a single character has changed, the whole page is invalidated and must be re-rendered. The tangible benefits when done right (there's lots of crappy code in every language and system) are greatly reduced user-perceived latency (the system reacts immediately, indicating that something is currently being updated, etc).
systematical 9y ago
I prefer the "classic" MVC design approach. It may not be flashy and some may turn their noses for not being hip, but its easy to develop, test, and scale. I certainly use JavaScript, but I use it when it adds to the workflow of the application.
sliverstorm 9y ago
It's probably predicated on a lot of other assumptions. Full refresh might be really annoying if your site is slow and bandwidth heavy. But, for example, squirrelmail is so fast I don't notice the full refreshes.
herbst 9y ago
MVC + Turbolinks. I still barely use any JS except frontend libs for fancy utils.
encoderer 9y ago
Multi page flows are fine for many data entry style apps which covers a lot of the web. But for more nuanced software, responsive and rich ui is very important to user uptake. Examples: Gmail, Facebook, Maps, Slack, SoundCloud, every autocomplete search box everywhere. If you accept that parts of the page should be interactive then you need to consider the benefit of an isomorphic approach to eliminate code duplication. Usually it's not just a single interactive component.
- Retric 9y ago
  You can do all of that with very lightweight JavaScript though. 10+ years ago I did autocomplete using a few carefully crafted lines of code and the page still renders just fine. The problem is JS frameworks make development easier but have high real world costs that are often ignored.
  - andrewstuart2 9y ago
    Your second sentence describes engineering trade-offs. The simplest engineering solution to a canyon is to walk around it. The most practical or productive solution over the long run is a different question entirely from the simplest or easiest to implement.
    - Retric 9y ago
      Frameworks are simpler to implement and maintain, that does not make them better for users.
    - TeMPOraL 9y ago
      Yup, those are engineering trade-offs. Making your life a little easier by causing users a disproportionate amount of resource waste, frustration and security issues is just shitty engineering. Even though the business types may like it, because externalities are good for profit.
  - ozim 9y ago
    "I did autocomplete using a few carefully crafted lines of code" Now take 10 developers to reuse that autocomplete in the same project in 10 different places. I bet those carefully crafted lines become 100 little monsters, one without eye other with 3 legs. Not that they have to be stupid, it is just they think differently.
ehnto 9y ago
It's not a thing of the past. The majority of websites still use this capable and pragmatic approach. I haven't got any information to support it, but I suspect it was mostly cargo culting from big vendors with big platforms that has made JS Single Page App style sites seem ubiquitous, because everyone in the spotlight is talking about the cool stuff they are doing with it. But in reality they still make up a minority of the web.
rictic 9y ago
Most sites can do with very little JS. Many do well with just a bit, like hacker news, which uses JS for little stuff like voting. Appier sites, like video, music, games, maps, etc are gonna need a lot more client-side logic to be pleasant to use.
iamthepieman 9y ago
I agree with you for content sites or primarily consumption driven apps but I haven't written one of those in 8 years. I'm currently working on an application that we are having to purposefully keep features out of, not because they are slowing the page down, or increasing TTI, but because we risk offending our business partners by building a one for one replacement of their multi-thousand dollar per seat desktop software. There's just no getting around the MB of JavaScript we need for this app. And for this type of application, we are much more concerned about the speed of individual actions on the page than page load. The site still loads faster than the desktop application opens.
- davidgh 9y ago
  This. Set aside the performance of the initial load for a moment. When I interact with the SPAs we’ve built in recent years, I am still shocked how snappy they are as I perform actions throughout the site. Every “pageview” requires the download of a tiny REST API response and comparably tiny HTML fragment. As a user - that experience is a pure delight compared to a full blown page re-load, re-download and re-render with every action. As a user it infuriates me when I fill out a long form, hit submit and find out I forgot to select the proper “Mr. Mrs. Ms” title and my password, credit card number and PIN have all be blown away. As a user I’m willing to pay a few more seconds upfront for snappy and seamless interactions as I use the app. I think the mistake that is more often committed (and where I myself as a user have less patience) is treating everything that can be accessed via URL as an “app”. If the user is coming to just download bytes, don’t build an app. An app is only justified when a user is coming to manipulate data.
  - samsonradu 9y ago
    > As a user it infuriates me when I fill out a long form, hit submit and find out I forgot to select the proper “Mr. Mrs. Ms” title and my password, credit card number and PIN have all be blown away. I'm quite sure this is a sign of poor development, regardless of the form being validated on the server or the client. There is no reason for the server not to send back a fully pre-populated form.
feelin_googley 9y ago
"Do we need all this JS?" I know at least one user who is asking this same question. He does not believe it is needed. Is it possible that "what users want" and what developers want may be two different things? Could developers have wants that are unique to developers? Purely anecdotal but I do not know any fellow users who "want javascript". I know many who do not want a number of common annoyances though. And I know these hassles are in many cases enabled via javascript. The tactic leveraged against users is to tell them they need javascript for some thing to work. Then users want it. But I think really they just want the thing to work. They have no particular affection for javascript, let alone any knowledge of why they need it. One thing I have observed over the years the web has existed early 1990's to today is that users can adapt to anything. Whether it was learning keyboard shortcuts on the console and using text-only programs like Pine, or running www searches that took minutes to finish, or communicating with 140 characters or less, or working with tiny touchscreens and horribly slow web pages and mobile apps. Many more examples if I gave it some more thought. From what I have seen, users accept what they are given and find a way to make it work.
- aaron-lebo 9y ago
  How do you notify a user of errors in input without a complete page refresh if you do not use Javascript (ignoring the most basic HTML stuff)? Without at least some scripting capability, you're talking about making the experience worse for the user to the benefit (ease of the request/response model) of the developer. Don't throw the baby out with the bathwater. It is the responsibility of devs to use technology well. You don't want all of this JS, but you do want some of it. Too many people are making their assumptions about what is possible and what JS is capable of based upon views of web development that are 5-10 years out of date or based on bad software. Bad software is endemic to the industry, it's not representative of any single tech stack.
  - jaggederest 9y ago
    > How do you notify a user of errors in input without a complete page refresh if you do not use Javascript (ignoring the most basic HTML stuff)? Well, it used to be that submitting a form and rendering errors on the server took the same ~100ms that evaluating a javascript framework validation does now, and so it was... not a problem. If you mean "leaving aside the most trivial html stuff" to include things like html5 inputs, that's the most significant part of what Javascript provides in form validation.
jrs95 9y ago
Even the full page loads aren't necessary with Turbolinks or PJAX. If I had a choice, thats definitely what I'd be using for what I'm working on now at an ecommerce company. But the boss insists on microservices, and the once the advantages that come with a monolith are gone the SPA is just a better approach imo
- sanderjd 9y ago
  Correct me if I'm wrong, but don't Turbolinks and PJAX work through JS as well?
  - jrs95 9y ago
    Yes, but way less. Turbolinks in particular basically just requires you to add the library, which is very lightweight, and then you get page changes without the bad visuals of the whole screen flashing white, and it's not too difficult to keep it fast too.
samsonradu 9y ago
Regarding full refreshes, I was thinking the other day why do browser vendors not implement them more graciously, as in Pjax style, but a clean reload. The problem with Pjax is that it still keeps state around, when I want to simply remove all state (setTimeouts, setIntervals, websocket connections, events binded to $window etc.)
blattimwind 9y ago
> They said that users really wanted native desktop like seamless change pages. This perhaps roots in the behaviour of browsers ten and more years past. Back in the day, you'd often get a "flash of white" during page loads. Today, not any more. A full-reload and a "seven million lines of JS client-side renderer" application are virtually indistinguishable. Chances are that the "full-reload" app is faster.
amelius 9y ago
How would you implement collaborative editing, where users can see each other type instantly?
mac01021 9y ago
I'm no fan of “modern js-based design”, but I can pay for a lot less server if I can get the client to do all the rendering for me.
- albertgoeswoof 9y ago
  I would wager that most people who say this have never actually calculated the cost of server side rendering vs bandwidth costs + users dropping off the site
- TeMPOraL 9y ago
  Yup. But the thing to consider is - a lot of things can be pre-rendered and cached. Your server can render it once and serve to many clients. With client-side rendering, each client is rendering the same thing for themselves, possibly slower than on your server because JS is not exactly the sharpest tool in the shed. So you've saved yourself $N in compute but externalized $N * number of users * relative JS inefficiency. This is not a nice thing to do.
kevincennis 9y ago
It’s all about how and where you use it. Imagine a world without AJAX. This is obviously an opinion, but it would be super annoying if every button I clicked sent a raw POST to the server and refreshed the page. Do news sites need to be rendered client-side with React + Redux + React Router + all the Babel polyfill garbage? No, I don’t think they do. But some sites are definitely better in my mind for being SPAs. The problem is that people pick technology that they like or are familiar with instead of working backwards from the ideal user experience. What we should be doing is picking the minimal set of technology that achieves the UX goals of a project. Instead, you have people loading 200kB of dependencies to render pages with a level of interactivity that could be achieved with 30 lines of vanilla JS. Oh, and then Google, FB, Twitter, and Optimizely tracking scripts.
- adambyrtek 9y ago
  One important and more subtle advantage of SPAs is that they enforce a clean architectural separation of concerns between the untrusted view layer and the backend API. This decoupling allows the frontend team to iterate quickly on user experience and run experiments without affecting the underlying business logic. This also makes it easier to build alternative interfaces (e.g. mobile apps) that share the same API. Of course these benefits matter only when building more complex applications (not simple content sites).
- mratzloff 9y ago
  > Imagine a world without AJAX. This is my favorite HN quote of the month.
  - falcolas 9y ago
    I remember gmail before it used AJAX. In many ways, I miss that interface - it just worked. Sure, I didn't get real time email notifications, but come on, it's email. Sure, there were a lot of page refreshes, but they were super quick since there wasn't several MB of scripts being parsed and run with each load. Just some HTML with a few JS interactions. They even still offer that interface - check it out. It works remarkably well (and quickly) to this day.
liveoneggs 9y ago
people want (in ecommerce sites, news sites, actual websites, etc): working back buttons, regular scrolling, open-in-new-tab that works, elements that don't move around, obvious and not-hidden navigation, and also tons of gimmicky/flashy crap. people want (in desktop replacement spa's where they spend hours and hours): app-appropriate usages of keyboard nav; background tasks with status windows, working back buttons that don't stop the music stream; links that work like links & app-clickables that work like buttons; refresh buttons that refresh (via a page reload) their current full state, but working.
mratzloff 9y ago
> Do we need all this JS? The answer to this question is always no.
nickjj 9y ago
I wrote about this exact topic last week at https://nickjanetakis.com/blog/server-side-templates-vs-rest-api-and-javascript-front-end https://nickjanetakis.com/blog/server-side-templates-vs-rest.... The TL;DR is, the classic web development model still works amazingly well today and you can get real-time aspects by sprinkling in Javascript where needed.
jrobn 9y ago
I think today the web is trying to be two things. 1) classic text documents with links to other text documents. 2) a cross-platform runtime for desktop class apps. Over time 2) has been increasigly shoe-horned into limitations of 1) and its all a giant cluster fuck now. Leave HTML to linked documents and give us an efficient runtime that we can plug into to deliver desktop class apps written in whatever language we want that works with a standardized runtime and UI language shipped built-in with every browser. Why the hell cant we build web UIs With a standardized UI markup (not HTML), wire it with whatever lanaguage our company uses, and compile it down to WebAssembly and ship it to clients browsers? Instead we have to write these monstrosities in shitty JavaScript with virtual doms, and hacks everywhere. Madness!
- krapp 9y ago
  >Why the hell cant we build web UIs like we do desktop apps, wire it with whatever lanaguage our company uses, and compile it down to WebAssembly and ship it to clients browsers? Instead we have to write these monstrosities in shitty JavaScript with virtual doms, and hacks everywhere. Madness! We can, but probably not now, because WebAssembly isn't quite ready yet. It still lacks garbage collection and efficient DOM access, and the specs aren't even finalized. There are already experimental targets for a few languages like Rust[0] and Lua[1], and WASM targets C/C++ out of the box. Eventually, you'll probably be able to import arbitrary languages and environments with a few HTML tags, similar to Javascript today, or whatever the Webassembly version of a package/dependency/VM manager turns out to be, then compile and run any application ever made in the browser. [0]https://news.ycombinator.com/item?id=12619017 https://news.ycombinator.com/item?id=12619017 [1]https://news.ycombinator.com/item?id=13899829 https://news.ycombinator.com/item?id=13899829
- amelius 9y ago
  And then there are media companies that try to shoe-horn 1) into 2) because it gives them more control over the user and allows them to track the user and serve them ads. If only there was a way to collectively punish this type of behavior.
  - kakarot 9y ago
christophilus 9y ago
For me, this sums it up [0]. I prefer HN to Redit because it's snappy. But every site I've ever worked on that didn't start off with a good front-end framework wound up being a huge mess on the front-end. The front end generally becomes more and more complex even for simple sites. "Can we add discussions to this page?" "Great! Now, can they be live-updating?" "Great! Now, can we have a nice little notification counter?" "Great! Now can it be collaboratively edited?" Eventually, the front end becomes a monstrosity. When starting out, if you just plan for a complex front end, and choose a well-structured framework, your life as a developer will be much less painful. Yes. It's overkill for a blog. But who among us is really building a simple blog? We're building applications that happen to run in the browser. [0] https://hackernoon.com/why-does-this-site-require-javascript-d7dc4dfb1118 https://hackernoon.com/why-does-this-site-require-javascript...
naasking 9y ago
> I know we switched because front end experts told us that users found the full refreshes annoying. They said that users really wanted native desktop like seamless change pages. Never did I see proof of these claimed. Even so, you can have that experience with server-side rendering and simpler client-side updating.
tomaskafka 9y ago
This. Several old-style 'server side rendered' pages I made seem superfast with https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks .

scientistem 9y ago

I think there is (limited) semantic value to single page forms. They also encourage api first design. Is this always worth it? Certainly not. But it does have value.

cabaalis 9y ago

I think the problem is in all the data-binding of JSON responses to the front end. I don't care what anyone says, it's slow.

andrewstuart2 9y ago
If you don't care what anyone says, then I guess there's no point in presenting data.
osrec 9y ago
Slow in what sense? I mean, for almost all actual use cases, it seems to be quick enough when done right.

andrewstuart2 9y ago

Good single-page app development is just as clean (I've done both), and will be faster over the long term, and scales out better. It keeps all the components cacheable and DRY. The benefits are all about data locality. If your code and data are cached on the client, then the only the minimal subset that has changed needs to be invalidated and updated. If it's only data that has changed, that's all that's retrieved. If it's only code, same goes here. For old-school MVC, if a single character has changed, the whole page is invalidated and must be re-rendered. The tangible benefits when done right (there's lots of crappy code in every language and system) are greatly reduced user-perceived latency (the system reacts immediately, indicating that something is currently being updated, etc).

systematical 9y ago

I prefer the "classic" MVC design approach. It may not be flashy and some may turn their noses for not being hip, but its easy to develop, test, and scale. I certainly use JavaScript, but I use it when it adds to the workflow of the application.

sliverstorm 9y ago

It's probably predicated on a lot of other assumptions. Full refresh might be really annoying if your site is slow and bandwidth heavy. But, for example, squirrelmail is so fast I don't notice the full refreshes.

herbst 9y ago

MVC + Turbolinks. I still barely use any JS except frontend libs for fancy utils.

encoderer 9y ago

Multi page flows are fine for many data entry style apps which covers a lot of the web. But for more nuanced software, responsive and rich ui is very important to user uptake. Examples: Gmail, Facebook, Maps, Slack, SoundCloud, every autocomplete search box everywhere. If you accept that parts of the page should be interactive then you need to consider the benefit of an isomorphic approach to eliminate code duplication. Usually it's not just a single interactive component.

Retric 9y ago
You can do all of that with very lightweight JavaScript though. 10+ years ago I did autocomplete using a few carefully crafted lines of code and the page still renders just fine. The problem is JS frameworks make development easier but have high real world costs that are often ignored.
- andrewstuart2 9y ago
  Your second sentence describes engineering trade-offs. The simplest engineering solution to a canyon is to walk around it. The most practical or productive solution over the long run is a different question entirely from the simplest or easiest to implement.
  - Retric 9y ago
    Frameworks are simpler to implement and maintain, that does not make them better for users.
  - TeMPOraL 9y ago
    Yup, those are engineering trade-offs. Making your life a little easier by causing users a disproportionate amount of resource waste, frustration and security issues is just shitty engineering. Even though the business types may like it, because externalities are good for profit.
- ozim 9y ago
  "I did autocomplete using a few carefully crafted lines of code" Now take 10 developers to reuse that autocomplete in the same project in 10 different places. I bet those carefully crafted lines become 100 little monsters, one without eye other with 3 legs. Not that they have to be stupid, it is just they think differently.

ehnto 9y ago

It's not a thing of the past. The majority of websites still use this capable and pragmatic approach. I haven't got any information to support it, but I suspect it was mostly cargo culting from big vendors with big platforms that has made JS Single Page App style sites seem ubiquitous, because everyone in the spotlight is talking about the cool stuff they are doing with it. But in reality they still make up a minority of the web.

rictic 9y ago

Most sites can do with very little JS. Many do well with just a bit, like hacker news, which uses JS for little stuff like voting. Appier sites, like video, music, games, maps, etc are gonna need a lot more client-side logic to be pleasant to use.

iamthepieman 9y ago

I agree with you for content sites or primarily consumption driven apps but I haven't written one of those in 8 years. I'm currently working on an application that we are having to purposefully keep features out of, not because they are slowing the page down, or increasing TTI, but because we risk offending our business partners by building a one for one replacement of their multi-thousand dollar per seat desktop software. There's just no getting around the MB of JavaScript we need for this app. And for this type of application, we are much more concerned about the speed of individual actions on the page than page load. The site still loads faster than the desktop application opens.

davidgh 9y ago
This. Set aside the performance of the initial load for a moment. When I interact with the SPAs we’ve built in recent years, I am still shocked how snappy they are as I perform actions throughout the site. Every “pageview” requires the download of a tiny REST API response and comparably tiny HTML fragment. As a user - that experience is a pure delight compared to a full blown page re-load, re-download and re-render with every action. As a user it infuriates me when I fill out a long form, hit submit and find out I forgot to select the proper “Mr. Mrs. Ms” title and my password, credit card number and PIN have all be blown away. As a user I’m willing to pay a few more seconds upfront for snappy and seamless interactions as I use the app. I think the mistake that is more often committed (and where I myself as a user have less patience) is treating everything that can be accessed via URL as an “app”. If the user is coming to just download bytes, don’t build an app. An app is only justified when a user is coming to manipulate data.
- samsonradu 9y ago
  > As a user it infuriates me when I fill out a long form, hit submit and find out I forgot to select the proper “Mr. Mrs. Ms” title and my password, credit card number and PIN have all be blown away. I'm quite sure this is a sign of poor development, regardless of the form being validated on the server or the client. There is no reason for the server not to send back a fully pre-populated form.

feelin_googley 9y ago

"Do we need all this JS?" I know at least one user who is asking this same question. He does not believe it is needed. Is it possible that "what users want" and what developers want may be two different things? Could developers have wants that are unique to developers? Purely anecdotal but I do not know any fellow users who "want javascript". I know many who do not want a number of common annoyances though. And I know these hassles are in many cases enabled via javascript. The tactic leveraged against users is to tell them they need javascript for some thing to work. Then users want it. But I think really they just want the thing to work. They have no particular affection for javascript, let alone any knowledge of why they need it. One thing I have observed over the years the web has existed early 1990's to today is that users can adapt to anything. Whether it was learning keyboard shortcuts on the console and using text-only programs like Pine, or running www searches that took minutes to finish, or communicating with 140 characters or less, or working with tiny touchscreens and horribly slow web pages and mobile apps. Many more examples if I gave it some more thought. From what I have seen, users accept what they are given and find a way to make it work.

aaron-lebo 9y ago
How do you notify a user of errors in input without a complete page refresh if you do not use Javascript (ignoring the most basic HTML stuff)? Without at least some scripting capability, you're talking about making the experience worse for the user to the benefit (ease of the request/response model) of the developer. Don't throw the baby out with the bathwater. It is the responsibility of devs to use technology well. You don't want all of this JS, but you do want some of it. Too many people are making their assumptions about what is possible and what JS is capable of based upon views of web development that are 5-10 years out of date or based on bad software. Bad software is endemic to the industry, it's not representative of any single tech stack.
- jaggederest 9y ago
  > How do you notify a user of errors in input without a complete page refresh if you do not use Javascript (ignoring the most basic HTML stuff)? Well, it used to be that submitting a form and rendering errors on the server took the same ~100ms that evaluating a javascript framework validation does now, and so it was... not a problem. If you mean "leaving aside the most trivial html stuff" to include things like html5 inputs, that's the most significant part of what Javascript provides in form validation.

jrs95 9y ago

Even the full page loads aren't necessary with Turbolinks or PJAX. If I had a choice, thats definitely what I'd be using for what I'm working on now at an ecommerce company. But the boss insists on microservices, and the once the advantages that come with a monolith are gone the SPA is just a better approach imo

sanderjd 9y ago
Correct me if I'm wrong, but don't Turbolinks and PJAX work through JS as well?
- jrs95 9y ago
  Yes, but way less. Turbolinks in particular basically just requires you to add the library, which is very lightweight, and then you get page changes without the bad visuals of the whole screen flashing white, and it's not too difficult to keep it fast too.

samsonradu 9y ago

Regarding full refreshes, I was thinking the other day why do browser vendors not implement them more graciously, as in Pjax style, but a clean reload. The problem with Pjax is that it still keeps state around, when I want to simply remove all state (setTimeouts, setIntervals, websocket connections, events binded to $window etc.)

blattimwind 9y ago

> They said that users really wanted native desktop like seamless change pages. This perhaps roots in the behaviour of browsers ten and more years past. Back in the day, you'd often get a "flash of white" during page loads. Today, not any more. A full-reload and a "seven million lines of JS client-side renderer" application are virtually indistinguishable. Chances are that the "full-reload" app is faster.

amelius 9y ago

How would you implement collaborative editing, where users can see each other type instantly?

mac01021 9y ago

I'm no fan of “modern js-based design”, but I can pay for a lot less server if I can get the client to do all the rendering for me.

albertgoeswoof 9y ago
I would wager that most people who say this have never actually calculated the cost of server side rendering vs bandwidth costs + users dropping off the site
TeMPOraL 9y ago
Yup. But the thing to consider is - a lot of things can be pre-rendered and cached. Your server can render it once and serve to many clients. With client-side rendering, each client is rendering the same thing for themselves, possibly slower than on your server because JS is not exactly the sharpest tool in the shed. So you've saved yourself $N in compute but externalized $N * number of users * relative JS inefficiency. This is not a nice thing to do.

kevincennis 9y ago

It’s all about how and where you use it. Imagine a world without AJAX. This is obviously an opinion, but it would be super annoying if every button I clicked sent a raw POST to the server and refreshed the page. Do news sites need to be rendered client-side with React + Redux + React Router + all the Babel polyfill garbage? No, I don’t think they do. But some sites are definitely better in my mind for being SPAs. The problem is that people pick technology that they like or are familiar with instead of working backwards from the ideal user experience. What we should be doing is picking the minimal set of technology that achieves the UX goals of a project. Instead, you have people loading 200kB of dependencies to render pages with a level of interactivity that could be achieved with 30 lines of vanilla JS. Oh, and then Google, FB, Twitter, and Optimizely tracking scripts.

adambyrtek 9y ago
One important and more subtle advantage of SPAs is that they enforce a clean architectural separation of concerns between the untrusted view layer and the backend API. This decoupling allows the frontend team to iterate quickly on user experience and run experiments without affecting the underlying business logic. This also makes it easier to build alternative interfaces (e.g. mobile apps) that share the same API. Of course these benefits matter only when building more complex applications (not simple content sites).
mratzloff 9y ago
> Imagine a world without AJAX. This is my favorite HN quote of the month.
- falcolas 9y ago
  I remember gmail before it used AJAX. In many ways, I miss that interface - it just worked. Sure, I didn't get real time email notifications, but come on, it's email. Sure, there were a lot of page refreshes, but they were super quick since there wasn't several MB of scripts being parsed and run with each load. Just some HTML with a few JS interactions. They even still offer that interface - check it out. It works remarkably well (and quickly) to this day.

liveoneggs 9y ago

people want (in ecommerce sites, news sites, actual websites, etc): working back buttons, regular scrolling, open-in-new-tab that works, elements that don't move around, obvious and not-hidden navigation, and also tons of gimmicky/flashy crap. people want (in desktop replacement spa's where they spend hours and hours): app-appropriate usages of keyboard nav; background tasks with status windows, working back buttons that don't stop the music stream; links that work like links & app-clickables that work like buttons; refresh buttons that refresh (via a page reload) their current full state, but working.

mratzloff 9y ago

> Do we need all this JS? The answer to this question is always no.

nickjj 9y ago

I wrote about this exact topic last week at https://nickjanetakis.com/blog/server-side-templates-vs-rest-api-and-javascript-front-end https://nickjanetakis.com/blog/server-side-templates-vs-rest.... The TL;DR is, the classic web development model still works amazingly well today and you can get real-time aspects by sprinkling in Javascript where needed.

jrobn 9y ago

I think today the web is trying to be two things. 1) classic text documents with links to other text documents. 2) a cross-platform runtime for desktop class apps. Over time 2) has been increasigly shoe-horned into limitations of 1) and its all a giant cluster fuck now. Leave HTML to linked documents and give us an efficient runtime that we can plug into to deliver desktop class apps written in whatever language we want that works with a standardized runtime and UI language shipped built-in with every browser. Why the hell cant we build web UIs With a standardized UI markup (not HTML), wire it with whatever lanaguage our company uses, and compile it down to WebAssembly and ship it to clients browsers? Instead we have to write these monstrosities in shitty JavaScript with virtual doms, and hacks everywhere. Madness!

krapp 9y ago
>Why the hell cant we build web UIs like we do desktop apps, wire it with whatever lanaguage our company uses, and compile it down to WebAssembly and ship it to clients browsers? Instead we have to write these monstrosities in shitty JavaScript with virtual doms, and hacks everywhere. Madness! We can, but probably not now, because WebAssembly isn't quite ready yet. It still lacks garbage collection and efficient DOM access, and the specs aren't even finalized. There are already experimental targets for a few languages like Rust[0] and Lua[1], and WASM targets C/C++ out of the box. Eventually, you'll probably be able to import arbitrary languages and environments with a few HTML tags, similar to Javascript today, or whatever the Webassembly version of a package/dependency/VM manager turns out to be, then compile and run any application ever made in the browser. [0]https://news.ycombinator.com/item?id=12619017 https://news.ycombinator.com/item?id=12619017 [1]https://news.ycombinator.com/item?id=13899829 https://news.ycombinator.com/item?id=13899829
amelius 9y ago
And then there are media companies that try to shoe-horn 1) into 2) because it gives them more control over the user and allows them to track the user and serve them ads. If only there was a way to collectively punish this type of behavior.
- kakarot 9y ago

christophilus 9y ago

For me, this sums it up [0]. I prefer HN to Redit because it's snappy. But every site I've ever worked on that didn't start off with a good front-end framework wound up being a huge mess on the front-end. The front end generally becomes more and more complex even for simple sites. "Can we add discussions to this page?" "Great! Now, can they be live-updating?" "Great! Now, can we have a nice little notification counter?" "Great! Now can it be collaboratively edited?" Eventually, the front end becomes a monstrosity. When starting out, if you just plan for a complex front end, and choose a well-structured framework, your life as a developer will be much less painful. Yes. It's overkill for a blog. But who among us is really building a simple blog? We're building applications that happen to run in the browser. [0] https://hackernoon.com/why-does-this-site-require-javascript-d7dc4dfb1118 https://hackernoon.com/why-does-this-site-require-javascript...

naasking 9y ago

> I know we switched because front end experts told us that users found the full refreshes annoying. They said that users really wanted native desktop like seamless change pages. Never did I see proof of these claimed. Even so, you can have that experience with server-side rendering and simpler client-side updating.

tomaskafka 9y ago

This. Several old-style 'server side rendered' pages I made seem superfast with https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks .