5 ms·

> Has it occured to you you might simply not understand the advantages of this approach? I find it pretty rude to use the "you don't like it because you don't

> Has it occured to you you might simply not understand the advantages of this approach? I find it pretty rude to use the "you don't like it because you don't understand it" argument. I build SPAs at work, I know their benefits, and I still believe that they're more difficult to develop than adding JS on top of classic HTML (not saying they're worse, but certainly I don't find them easier). > So when the author says that classic HTML with sprinkled js on top is "easier to develop", I smirk. If it were, developers would not be flocking en masse towards SPAs and the like. Those are gaining traction because they are easier to develop and easier to maintain. I'd say that we, developers, often move to overcomplicated and difficult tools/approaches. Or we move to tools that are simple only to see them grow in size and complexity. The fact that something becomes popular doesn't mean that it's necessarily better or easier to maintain.

ryan-allen 7y ago
> I'd say that we, developers, often move to overcomplicated and difficult tools/approaches. Smart people with simple problems, we get bored, I guess. There's a lot of boring work out there. I agree though, I went from Angular to ASP.NET back to React, and server side despite being less 'flashy' was much more productive with less effort.
scrollaway 7y ago
> I still believe that they're more difficult to develop than adding JS on top of classic HTML (not saying they're worse, but certainly I don't find them easier). You're right, I should have been clearer. Emphasis on develop and maintain. If you're just building a near-static site with, say, some slideshow that needs basic JS then I'd use jQuery too. I'm sure there's a bazillion plugins that already do what I want and it'll be done in 5 minutes. But if you're building something that will scale beyond the current page, that will need more features in the future, etc then it's not a viable approach. And I'm not saying SPAs are necessarily the best choice/tool available, but they're definitely going to be easier to work with than HTML+jQuery, unless the requirements are ridiculously basic. > I'd say that we, developers, often move to overcomplicated and difficult tools/approaches. Or we move to tools that are simple only to see them grow in size and complexity. The fact that something becomes popular doesn't mean that it's necessarily better or easier to maintain. Lots of devs adopt technologies for fun; because the approach is interesting; because they want to learn; because they're bored with their current stack. But this is different. This is a huge movement within the ecosystem moving towards a very specific model. The model is not necessarily the best in every situation, but the pros that come with it are significant. And honestly, nowadays in modern browser JS, if an app is simple enough to build with jQuery, it's simple enough to build without any third party lib.
- EGreg 7y ago
  Funny that a mere two mo ths ago, when I posted this, many on HN begged to differ: https://news.ycombinator.com/item?id=19534060 https://news.ycombinator.com/item?id=19534060
- iforgotpassword 7y ago
  > You're right, I should have been clearer. Emphasis on develop and maintain. Did you ever think that you might want to put the user experience first? Look at YouTube with their great SPA. If I'm on mobile and not using a flagship phone with 3gb of ram, it's just great: I scroll through my search results which are these idiotic incrementally loading page, then I select a video, watch it and want to go back. Surprise! I see the loading spinner again an my scroll position is lost. State seems so broken with SPAs that it only ever works in some demo apps that were solely built to prove that you can have SPAs with a working back button. Great, I already had that on YouTube in 2006 with a fancy and handy feature called pagination for the search results. But I guess once we kill Firefox this will become much better since Google will just do whatever the duck they want with the web.
  - scrollaway 7y ago
    > Did you ever think that you might want to put the user experience first? As I've repeatedly explained in the comments, I'm not arguing that you should use an SPA, and I'm not arguing that SPAs have necessarily better UX. You still have to be a good dev. SPAs are not footgun-protections and the issues you're listing are fairly easily solved. Maybe they're not natively solved by SPAs, but other approaches also have their natively-unsolved problems, so this is moot. > But I guess once we kill Firefox this will become much better since Google will just do whatever the duck they want with the web. I don't even know what you're on about or how it relates to this discussion. Did you mean to post this on a different article?
    - iforgotpassword 7y ago
      > I don't even know what you're on about or how it relates to this discussion. Did you mean to post this on a different article? Nope, that was just a small addendum in relation to my example since experience has shown that often times the back button is broken in different ways depending on browser. Having just one engine left would at least mean some more consistency here, but that's about the only advantage I can see in that.
threatofrain 7y ago
Even the auto-frameworking approaches are starting to surpass old school web development for "classical" web purposes. I can tell when I'm on a static documentation site and things work almost instantly. JavaScript is both the reason why some websites feel faster and other websites feel slower. I also think that being nice to mobile (data efficiency) and being fast (UX latency) are starting to show as moderately contradictory values.
baddox 7y ago
Do you believe that SPAs are more difficult to build than building the same functionality with server-rendered HTML and jquery on top? In my experience, that would only be true in the most trivial of SPAs. I’m thinking like a blog with AJAX “like” buttons. A good rule of thumb for me is that as soon as you have some interactive widget that involves adding and removing items from a list where the individual items also change interactively, you’re probably better off ditching jquery because things are about to get messy.

ryan-allen 7y ago

> I'd say that we, developers, often move to overcomplicated and difficult tools/approaches. Smart people with simple problems, we get bored, I guess. There's a lot of boring work out there. I agree though, I went from Angular to ASP.NET back to React, and server side despite being less 'flashy' was much more productive with less effort.

scrollaway 7y ago

> I still believe that they're more difficult to develop than adding JS on top of classic HTML (not saying they're worse, but certainly I don't find them easier). You're right, I should have been clearer. Emphasis on develop and maintain. If you're just building a near-static site with, say, some slideshow that needs basic JS then I'd use jQuery too. I'm sure there's a bazillion plugins that already do what I want and it'll be done in 5 minutes. But if you're building something that will scale beyond the current page, that will need more features in the future, etc then it's not a viable approach. And I'm not saying SPAs are necessarily the best choice/tool available, but they're definitely going to be easier to work with than HTML+jQuery, unless the requirements are ridiculously basic. > I'd say that we, developers, often move to overcomplicated and difficult tools/approaches. Or we move to tools that are simple only to see them grow in size and complexity. The fact that something becomes popular doesn't mean that it's necessarily better or easier to maintain. Lots of devs adopt technologies for fun; because the approach is interesting; because they want to learn; because they're bored with their current stack. But this is different. This is a huge movement within the ecosystem moving towards a very specific model. The model is not necessarily the best in every situation, but the pros that come with it are significant. And honestly, nowadays in modern browser JS, if an app is simple enough to build with jQuery, it's simple enough to build without any third party lib.

EGreg 7y ago
Funny that a mere two mo ths ago, when I posted this, many on HN begged to differ: https://news.ycombinator.com/item?id=19534060 https://news.ycombinator.com/item?id=19534060
iforgotpassword 7y ago
> You're right, I should have been clearer. Emphasis on develop and maintain. Did you ever think that you might want to put the user experience first? Look at YouTube with their great SPA. If I'm on mobile and not using a flagship phone with 3gb of ram, it's just great: I scroll through my search results which are these idiotic incrementally loading page, then I select a video, watch it and want to go back. Surprise! I see the loading spinner again an my scroll position is lost. State seems so broken with SPAs that it only ever works in some demo apps that were solely built to prove that you can have SPAs with a working back button. Great, I already had that on YouTube in 2006 with a fancy and handy feature called pagination for the search results. But I guess once we kill Firefox this will become much better since Google will just do whatever the duck they want with the web.
- scrollaway 7y ago
  > Did you ever think that you might want to put the user experience first? As I've repeatedly explained in the comments, I'm not arguing that you should use an SPA, and I'm not arguing that SPAs have necessarily better UX. You still have to be a good dev. SPAs are not footgun-protections and the issues you're listing are fairly easily solved. Maybe they're not natively solved by SPAs, but other approaches also have their natively-unsolved problems, so this is moot. > But I guess once we kill Firefox this will become much better since Google will just do whatever the duck they want with the web. I don't even know what you're on about or how it relates to this discussion. Did you mean to post this on a different article?
  - iforgotpassword 7y ago
    > I don't even know what you're on about or how it relates to this discussion. Did you mean to post this on a different article? Nope, that was just a small addendum in relation to my example since experience has shown that often times the back button is broken in different ways depending on browser. Having just one engine left would at least mean some more consistency here, but that's about the only advantage I can see in that.

threatofrain 7y ago

Even the auto-frameworking approaches are starting to surpass old school web development for "classical" web purposes. I can tell when I'm on a static documentation site and things work almost instantly. JavaScript is both the reason why some websites feel faster and other websites feel slower. I also think that being nice to mobile (data efficiency) and being fast (UX latency) are starting to show as moderately contradictory values.

baddox 7y ago

Do you believe that SPAs are more difficult to build than building the same functionality with server-rendered HTML and jquery on top? In my experience, that would only be true in the most trivial of SPAs. I’m thinking like a blog with AJAX “like” buttons. A good rule of thumb for me is that as soon as you have some interactive widget that involves adding and removing items from a list where the individual items also change interactively, you’re probably better off ditching jquery because things are about to get messy.