11 ms·

This may be a mean thing to say, but basically I think SPA's are massively overused, because developers want to demonstrate that they can do them. Why? Becaus

This may be a mean thing to say, but basically I think SPA's are massively overused, because developers want to demonstrate that they can do them. Why? Because big companies like Facebook and Google use them. Why? Because they actually are doing things that require them. 99% of the SPAs in production are things that should have been done the old Rails/Django/Laravel way, but that would not set you up as a developer who can do SPA's. I have also witnessed discussions where management admits that they want something done in an SPA so that they can show that work to their investors, as a means of getting funding to do other projects. So basically the same reason, except for managers to impress investors instead of developers to impress potential employers. Not saying all SPAs are mistakes; some uses clearly are not. But most of them are.

kerkeslager 8y ago
Yeah, some people go so far as to directly claim that something is good because Google uses it. And when Google uses it, it probably IS good for solving Google's problems. But most people aren't Google and don't have Google's problems.
- deleted 8y ago
  [deleted]
- Freak_NL 8y ago
  Ugh… We've had one of those developers. Now we're stuck with a legacy GWT¹ SPA that sucks the life out of any developer who touches it. 1: Google's abandoned webapp toolkit where you get all of the drawbacks of writing Java code with none of the benefits.
  - james_s_tayler 8y ago
    GWT ouch. Or as I call it "get with the times!"
- slifin 8y ago
  Do Google still use their closure library + compiler on all their big properties? https://github.com/google/closure-library/ https://github.com/google/closure-library/ I'm learning Clojure at the moment, don't think I would have heard of Google Closure otherwise
  - nojvek 8y ago
    Closure language and closure compiler are two different things. One is a lispy functional language with its own syntax, the other is a jsdoc typechecker and optimizer/monicker. A lot of what clojure does, Typescript does it really well with it’s types in jsdocs.
    - wilsonthewhale 8y ago
      They're related. The ClojureScript compiler uses Google Closure as a backend and runtime library
- expertentipp 8y ago
  > some people go so far as to directly claim that something is good because Google uses it. Angular everything and everywhere and sprinkle it with Material Design!
  - tracker1 8y ago
    Not a fan of Angular, am a fan of most of Material Design.
- tracker1 8y ago
  Yeah... "because google|apple|microsoft|ibm|facebook ..." is generally a bad idea on its' own merit. I do like React though. I like similar JSX tooling around inferno and preact too. It's just something close to what I wanted when first playing around with e4x with flash/flex and mozilla browsers.
brightball 8y ago
You're not wrong. There are clearly good uses for SPAs, but the author is totally correct that most sites are "open, check, close" experiences. If it's not essentially a web based, desktop app...it's much harder to justify. Real tools. If it's not a tool and the user workflow is "open, check, close"...it's serious overkill.
- tracker1 8y ago
  Having worked on web based applications (not sites) for a couple decades, I have to agree... I'm a fan of either SPA + Node API (other APIs behind it as needed) or, can it build to a static deployment. I push to one end or the other.
s_y_n_t_a_x 8y ago
It's really simple, if you're developing a web app, use a SPA stack. If you're developing a web page, use the minimal amount of tech you need on top of HTML, ideally where the HTML functions without JS.
- repsilat 8y ago
  Does that help much? The distinction between "web app" and "web page" seems fuzzier than the question "would a SPA lib/framework be useful here?" Is Reddit a web app? Is Twitter? Facebook? They all started with server-generated HTML, all kinda feel "document-like", all of them involve scrolling (if that means anything.) Is the "app" boundary further along the chain, like at Google Docs? I think instead of trying to come up with definitions to classify things (and probably argue for the meaning of those definitions from the conclusions we want to draw) we should ask, - Will this help developers? - Will this make users lives better?
  - Slartie 8y ago
    None of them is a web app. All of them want to provide certain views on their content that are uniquely identified by their URLs. This is especially true for Twitter and Reddit, which both aim to have their views on tweets and threads to be indexed by search engines. Facebook is probably the least clear one, since they put great effort into eliminating discoverability and accessibility from "outside", i.e. without a Facebook account. They're basically the AOL of today, which was a classic application back then that tried to contain a proprietary "web" of stuff in itself, only accessible if you ran their "browser" application, had an account with them and were logged in, and that "AOL Internet" of course had its own search mechanisms, just like Facebook has its own sophisticated search. However, they're not fully closed-up, they just try really hard to nag you into having an account, which is why I'm inclined to still put them in the "website" camp. However, all of these web sites surely contain certain parts that are in itself "web apps" and that are pretty much isolated from the basic parts of the site (albeit possibly interacting with it at well-defined points through APIs). I guess that this is a logical result of the large engineering teams that are working constantly on what is basically the same big website - at some point, in order to scale out further, it just becomes economic and practical to effectively isolate certain features into mostly separated "apps".
klodolph 8y ago
Microservices are in the same camp. I use them, I love them, I advocate for them. But microservices don't make any sense if your application doesn't call for it or if you don't have the orchestration infrastructure to roll them out and test them easily. I've worked at places in all four quadrants of should/shouldn't and do/don't use microservices.
- arcticwombat 8y ago
  Yeah microservices is another one that suffers from the One Solution To Rule Them All mentality. They're GREAT when they're the right fit. Most websites aren't really a right fit and do fine with a classic webserver->DB setup.
hombre_fatal 8y ago
Well, SPAs are attractive even for websites that don't particularly benefit from them because of the technical attractiveness of having the website be like any other client that consumes your server's API.
- bryanrasmussen 8y ago
  sure but there are very few websites in the world that need to publicize an api, basically only sites that need to be able to function as applications. once you have a site that needs to be an application arguing for it to be single page is not that great a leap.
  - hombre_fatal 8y ago
    Sure, I meant to make the point that developers are drawn to SPAs for more understandable reasons than just being a bunch of lemmings. Also, it's hard to realize how much work a SPA actually entails until you get your hands dirty. SPAs generally sound great on paper from a technical standpoint.
  - quonn 8y ago
    If you have a mobile app, you need an API, even if you‘re site does not function as an application.
    - rossdavidh 8y ago
      The great majority of websites, though, DON'T need a mobile app; they need a website that works on mobile. Most smartphone users are unwilling to download more than a few apps for websites, anyway; if your website is a restaurant, a news source, or anything else that works well on a website, most users are unwilling to download and install your app anyway. So, if you want their business, you need to make your website work for mobile. Once you have done, that, in most (not all) cases, you don't need to develop an app anyway.
    - theonething 8y ago
      unless you use Turbolinks with IOS/Android adapters or another hybrid app alternative
deleted 8y ago
[deleted]
freehunter 8y ago
The other day I was arguing this exactly in a thread here about Ruby. People argue that Rails is outdated and is irrelevant for "modern web development", even though the web is not as modern as most people might think. Even what Facebook does, the only really hard part is the sheer scale they operate at. Facebook (the website) is not a single page app and other than the scale could be done in Rails with some AJAX sprinkled in or even Wordpress with some plugins. People use SPA frameworks and make SPAs with them and those SPAs end up functioning exactly the same as any Rails/Django/Laravel site except the URL bar doesn't change. MVC is still the way the web is built, except for the people who got bored and wanted to make web development even harder than it already is. YAGNI.
- bryanrasmussen 8y ago
  sure, although modern browser apis mean the url bar can change in a reasonable way
  - Freak_NL 8y ago
    Having the address bar behave sensibly is one of guiding principles of the Ember JavaScript framework. A good modern SPA framework should be able to handle proper routing out of the box.
  - mixmastamyk 8y ago
    What about tabs? SPA can make tabs troublesome. If I can't open a site in tabs it is broken to me.
    - sangnoir 8y ago
      Browser-side routing/state management is a solved problem - SPAs can make tabs troublesome if the developer didn't put in the effort.
      - JetSpiegel 8y ago
        Using web API means tabs work even if the developer doesn't put in the effort.
scruple 8y ago
> I have also witnessed discussions where management admits that they want something done in an SPA so that they can show that work to their investors, as a means of getting funding to do other projects. Absolutely. This extends well beyond SPAs, too, in my experience. I recently burned part of a month explaining to my senior management chain why you don't just, literally, "do machine learning." Of course, it turns out that the ask was coming from the C-suite, who wanted to put it on a slide somewhere because "everyone is doing machine learning, we need to do machine learning."
- ageitgey 8y ago
  I do machine learning consulting and I see the flip side of this. I get new clients reaching out asking me to "add some AI" with no specific use cases in mind other than satisfying their investors that they are "leveraging AI."
  - mipmap04 8y ago
    Had a client that wanted a machine learning solution to determine if one name that was in one list was also in another list...
    - ycombobreaker 8y ago
      lol... Train your model with the dataset of "another list" i.e. populate a lookup table. Slap a sigmoid on top of that boolean "presence" result. Perfect precision/recall!
- irrational 8y ago
  In my experience the C-suite people don't even know what machine learning or AI even is. Why don't you just tell them that you've incorporated machine learning into your website? It's not like they would know the difference.
- cosmie 8y ago
  Ha! I've seen higher ups not even bother to go to that length. They checked the "validation to put it on a slide somewhere" box by just implicitly rebranding AI to be short for Augmented Intelligence. In the context of executive presentations the play on semantics tends to get lost, while the "We do AI[1]" remains true! [1] https://www.informationweek.com/big-data/ai-machine-learning/its-about-augmented-intelligence-not-artificial-intelligence/a/d-id/1331460 https://www.informationweek.com/big-data/ai-machine-learning...
tomc1985 8y ago
It isn't a mean thing to say, it's the truth, and the insanity that is modern software dev needs to have its truths spoken more often.
GVIrish 8y ago
> This may be a mean thing to say, but basically I think SPA's are massively overused, because developers want to demonstrate that they can do them. Unfortunately this is another side effect of the broken hiring process in IT. Recruiters are scanning resumes for the hottest buzzwords, hiring managers want people who have experience with whatever is currently hyped, so developers naturally steer towards those technologies. So a developer may even be aware it doesn't quite make sense to use a single page architecture, but they know that if they have it on their resume it'll help them make more money at the next job. It's a whole maladaptive signaling phenomenon that arises out of organizations overvaluing the wrong things in hiring.
- geebee 8y ago
  I agree. It's also not simply a matter of making more money on the next job, it can be a matter of having a next job.
  - deleted 8y ago
    [deleted]
- reading-at-work 8y ago
  100% correct, and I'm guilty as charged. If leadership likes the sound of SPAs, and my next job wants me to have experience with SPAs, I'm using SPAs.
- bunderbunder 8y ago
  It can be the same story on the hiring side: Teams will decide to build $new_thing using $NEW_THING! simply because they know it will help them attract more (and often less expensive) applicants.
- Casperin 8y ago
  Some years ago, 3 of us picked React for a startup. I consider it the single biggest mistake in my career, but we picked it not for the reason you mention. We didn't think that far (I was perhaps a junior, but the others weren't). It was just a matter of picking the frontend framework that we liked the best (I think the options were between Backbone, Ember, AngularJS, React). In our minds we did pick the simple option. Some may be aware, but certainly not everyone.
alexbanks 8y ago
Unfortunately for most devs, the only way to set yourself up for "better" work later, is to force current mediocre work to use the tooling of the future work. In 2019 if you have on your resume that you're only familiar with Rails and ERB-sites, and you suggest using them for pretty much everything, you'll never get a new job. At a certain point, career-minded devs have to do the "resume driven development" game a little bit, if only to know what others are doing. But in reality most work is very simple. Most work does not require new shiny technology. Most work is insanely mundane.
- pjmlp 8y ago
  Depends pretty much where one wants to work. Outside the software business, on companies whose focus is totally unrelated to software, no one cares that much how things work. They just have a couple of devs, or hire some freelancers do do some stuff, no matter how, it just has to look pretty.
  - beefalo 8y ago
    And they pay them peanuts compared to software businesses.
    - pjmlp 8y ago
      Speaking from experience, not necessarily.
  - alexbanks 8y ago
    I feel like this is pretty specific and/or lucky. In my experience, the companies you're referring to also have a person that's worked there for 15+ years and "architected" all of their infra from scratch, in an incredibly unmaintainable way. Sure, they could've done whatever they wanted, but that does not mean that it's better than the alternative.
nickjj 8y ago
Yep exactly. I remember a while back I wrote a blog post where the main topic was "You're not Google (unless you're Google)"[0]. It was related to micro-services but the same thing applies to SPAs too. [0]: https://nickjanetakis.com/blog/microservices-are-something-you-grow-into-not-begin-with https://nickjanetakis.com/blog/microservices-are-something-y...
- rossdavidh 8y ago
  Well put. Imagine if every building in a city were built with a foundation capable of supporting a skyscraper, because what if you eventually need a skyscraper?
sl1ck731 8y ago
As someone who started developing not long ago, is there any reason to not make an SPA when it is the workflow you are used to? I just don't see a practical difference between SPA or not. The argument I usually see is that its harder...but like me I expect there are more and more people who have learned this way first. I mean for SEO sure, but I usually am not concerned with SEO at all.
- sabizmil 8y ago
  Building an SPA for every single project is like using a semi-trailer to commute everywhere you go. Sure, it will always get you where you need and sometimes turns have to be taken pretty wide, but what's the downside? Well, if you're destination is just 2 blocks down the road then why not walk? If you just need a simple page and the content doesn't need to be updated often, why not some flat HTML/CSS/JS? Many times SPA frameworks are used because it's flashy and more exciting than writing basic html and css, but more often than not that's all you need.
  - sl1ck731 8y ago
    I didn't consider small static sites. I agree with that and have done some landing pages that way that stand in front of SPAs. I guess I was commenting on OP wanting to use Rails or Spring MVC for views instead of only using them for APIs. I'm not sure what the term for it is, monolith maybe.
    - nicoburns 8y ago
      I believe the term would be "Server-rendered MVC framework". I think the argument for server-rendering is simply productivity. You can probably get stuff done about twice as fast if the use case fits the paradigm.
- yellowapple 8y ago
  It's nice when I don't have to enable JavaScript just to use a website. My battery appreciates it at the very least. Forcing me to run arbitrary Turing-complete code from the Internet just to, say, read an article or buy something online is not okay, especially when that code exists solely to either 1) spy on me or 2) reimplement half of my browser.
CM30 8y ago
I think you've hit the nail on the head here. People seem to have lost sight of how a company like Google and a company like say, a local agency don't have the same needs or problems. As you mention, many of these trendy bits of technology are great if you're running a company at the scale of Google/Amazon/Facebook/Microsoft/whatever, but they're overkill for smaller companies or ones with simpler needs. And yeah, they're also common in situations where they're not the right solution because either devs want to turn their current employer into the next Google, want to build up the CV to look good when interviewing for Google or have a boss/investors who like shiny things in general.
eeeeeeeeeeeee 8y ago
It's similar to people gravitating to NoSQL when they probably actually needed a relational database because they don't really think about their data model and how it will be accessed. That being said, as someone who has done a lot of infrastructure work, I do like web technologies that can fit into something like serverless and Ruby/Rails really isn't there. Speed, file size, and boot time all become much more important. Or if you can make it work, fully static pages that can live on S3/Cloudfront and any dynamic needs are abstracted away to API gateway/Lambda and pulled in. I would much rather have an app running inside of Lambda instead of having to manage a load balancer and AWS auto-scaling, or even elastic beanstalk. So many problems can be dissolved down into people picking the wrong tool for the job.
- rossdavidh 8y ago
  Yeah to be honest, even RoR/Django/whatever is often more than is necessary. Sometimes static HTML/CSS is what's necessary. A lot of the time, really. I wonder what percentage of React websites could be well served with static HTML and at least one employee who knows HTML.
tracker1 8y ago
Not to completely disagree, but I've worked mostly with web based applications, not specifically static content (with few exceptions)... I find working with React and similar far easier for mid-large applications than most of what came before. I was optimistic around ASP.Net (webforms not mvc) and in practice it was a bloated mess without doing a lot of goofy things. If you're building web applications, it's usually easier to build with components than to think in terms of web controls. If you can separate state slightly from the components even better. This is why react + redux scales well. It makes very little sense in smaller apps, or those that are mostly static. It makes huge sense when you have hundreds or thousands of components, and a lot of application logic and structure. It isn't just because management wants an SPA... sometimes an SPA is the best option.
- dbb01 8y ago
  In my experience SPAs are actually much more prone to bloat and the resultant performance issues. If you have thousands of components you definitely need to dive into all the complexity of code splitting and server side rendering to make your app fast. You can very quickly find that you have a 4MB JS download. Of course each application has different needs, but for large multi-developer UIs, I think a better option is to split your front end into distinct server based pages where you leverage React/GraphQL/SPA/PWA features for great DX within those pages. That way you can keep it fast and potentially limit some of the complexity.
  - tracker1 8y ago
    I'm on a moderately complex UI right now, that has a JS payload around 364kb gzipped, react-dom, chart.js and material-ui/core bits accounting for most of the heavy bits. I've also been heavy handed with pulling out libraries that could be done easy enough with just React and JS. Svg is suprisingly easy in React, and a couple events while tricky aren't as bad as some other tooling I've used in the past. Overall it loads in right around 1s, as I mentioned the splitting for async load on demand doesn't work at the moment, which I had the initial load for a page not using chart.js down to around 115kb gzipped. Part of that also includes the embedded SVG icons as well as the JSS for styling. It's not paying attention when lodash + underscore, + rambda + momentjs, etc. all get loaded via dependencies... most of that can expressly be avoided with specific smaller frameworks and tooling. https://i.imgur.com/gf5cpNd.png https://i.imgur.com/gf5cpNd.png
JetSpiegel 8y ago
> Because they actually are doing things that require them. Citation needed. G-Suite's admin pages are half "modern" SPA monstrosities that suck up my RAM and peg my CPU to render a bunch of whitespace with bits of information strewn around, and ugly but functional regular pages whose performance is killed for being framed inside a SPA frankenapp.
- yellowapple 8y ago
  Right? Sure, there are Google products that certainly warrant being SPAs (like Google Docs), but the vast majority should be possible to implement without a single line of Javascript at all, let alone as a single-page application.
rsynnott 8y ago
> This may be a mean thing to say, but basically I think SPA's are massively overused, because developers want to demonstrate that they can do them. This may be even meaner, but they usually end up demonstrating they can’t. 99% of them are terrible. Even Google’s latest efforts are a bit on the slow, low-information-density side.
nojvek 8y ago
I don’t get the hate against SPA’s. An SPA done right offers amazing interactibily and instant navigation to new views. You already have the templates cached. They probably load from a cdn with good caching policy. If done well you can totally run offline. Sure you can build with php, laravel, django. The promise of SPA is a clean separation of UI from the APIs. The same REST APIs that external customers use is the same API you develop on. See travis-ci as an example. It’s the same api that the mobile apps can use. This separation allows the api to return very lightweight stateless responses. You can scale much better when there is less state kungfu. The UI can manage the state in very responsive manner. No round trips, instant 60fps render. And no JavaScript is not slow. It’s just that people don’t know it well and end up loading megs of bloated libs with a 1000 ad tracking libraries. Don’t throw the baby with the bathwater.
- mercer 8y ago
  > An SPA done right offers amazing interactibily and instant navigation to new views. You already have the templates cached. They probably load from a cdn with good caching policy. Most of the time I find the initial delay loading/parsing the js to be more problematic than the often tiny speed increase of subsequent loads. Furthermore, these days it takes minimal to no tweaking to get server-side rendered pages to load fast enough to barely notice the difference (in particular if the client-side is retrieving and parsing JSON in the background through an API request). Perhaps non-webdevs are even less likely to notice this stuff. > If done well you can totally run offline. That's definitely an advantage, but most SPAs I encounter don't offer offline functionality, or it's entirely unnecessary to offer it. > Sure you can build with php, laravel, django. The promise of SPA is a clean separation of UI from the APIs. The same REST APIs that external customers use is the same API you develop on. See travis-ci as an example. It’s the same api that the mobile apps can use. In some cases that's definitely an advantage. But it's entirely feasible to build an API-based backend and use that API internally for server-side rendering. If you want an app that plays nice with search engines you have to do this anyways. > This separation allows the api to return very lightweight stateless responses. You can scale much better when there is less state kungfu. That doesn't make sense to me. One of the biggest issues I have with SPAs is that you now have to deal with the backend state (DB) and a subset of this state on the client, which dramatically increases complexity (state management, sync, etc.). I rather like the old-fashioned approach where all state remains in the backend, except perhaps for the tiny bits you'd put in a cookie (and I suppose the URL could be considered client-site state too). > The UI can manage the state in very responsive manner. No round trips, instant 60fps render. How many apps do you use where you really need anything below say, sub-second rendering? Frameworks like Phoenix and/or caching can be much faster than that even (in the order of microseconds). > And no JavaScript is not slow. It’s just that people don’t know it well and end up loading megs of bloated libs with a 1000 ad tracking libraries. Clearly if so many SPAs are bloated Mb-size messes, it's not trivial to solve. And it's a problem you can almost entirely avoid if you keep the rendering on the server. After years of agonizing over bundle sizes, I find it incredibly liberating to not have to think about this anymore (much of the time, anyways). > Don’t throw the baby with the bathwater. I do agree that there are plenty of use cases for SPAs, but I also agree with many here who say they're very over-used. I'll add that there are some interesting initiatives to have 'old-fashioned' applications that also get to be dynamic enough for many if most use cases. Phoenix LiveView [1], for example, takes advantage of very fast server-side rendering, websockets, and sending subsets of the templates as HTML snippets to the client, where morphdom simply diffs the HTML string with the element it's supposed to replace. With great performance. [1]: https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-real-time-apps-no-need-to-write-javascript https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...

kerkeslager 8y ago

Yeah, some people go so far as to directly claim that something is good because Google uses it. And when Google uses it, it probably IS good for solving Google's problems. But most people aren't Google and don't have Google's problems.

deleted 8y ago
[deleted]
Freak_NL 8y ago
Ugh… We've had one of those developers. Now we're stuck with a legacy GWT¹ SPA that sucks the life out of any developer who touches it. 1: Google's abandoned webapp toolkit where you get all of the drawbacks of writing Java code with none of the benefits.
- james_s_tayler 8y ago
  GWT ouch. Or as I call it "get with the times!"
slifin 8y ago
Do Google still use their closure library + compiler on all their big properties? https://github.com/google/closure-library/ https://github.com/google/closure-library/ I'm learning Clojure at the moment, don't think I would have heard of Google Closure otherwise
- nojvek 8y ago
  Closure language and closure compiler are two different things. One is a lispy functional language with its own syntax, the other is a jsdoc typechecker and optimizer/monicker. A lot of what clojure does, Typescript does it really well with it’s types in jsdocs.
  - wilsonthewhale 8y ago
    They're related. The ClojureScript compiler uses Google Closure as a backend and runtime library
expertentipp 8y ago
> some people go so far as to directly claim that something is good because Google uses it. Angular everything and everywhere and sprinkle it with Material Design!
- tracker1 8y ago
  Not a fan of Angular, am a fan of most of Material Design.
tracker1 8y ago
Yeah... "because google|apple|microsoft|ibm|facebook ..." is generally a bad idea on its' own merit. I do like React though. I like similar JSX tooling around inferno and preact too. It's just something close to what I wanted when first playing around with e4x with flash/flex and mozilla browsers.

brightball 8y ago

You're not wrong. There are clearly good uses for SPAs, but the author is totally correct that most sites are "open, check, close" experiences. If it's not essentially a web based, desktop app...it's much harder to justify. Real tools. If it's not a tool and the user workflow is "open, check, close"...it's serious overkill.

tracker1 8y ago
Having worked on web based applications (not sites) for a couple decades, I have to agree... I'm a fan of either SPA + Node API (other APIs behind it as needed) or, can it build to a static deployment. I push to one end or the other.

s_y_n_t_a_x 8y ago

It's really simple, if you're developing a web app, use a SPA stack. If you're developing a web page, use the minimal amount of tech you need on top of HTML, ideally where the HTML functions without JS.

repsilat 8y ago
Does that help much? The distinction between "web app" and "web page" seems fuzzier than the question "would a SPA lib/framework be useful here?" Is Reddit a web app? Is Twitter? Facebook? They all started with server-generated HTML, all kinda feel "document-like", all of them involve scrolling (if that means anything.) Is the "app" boundary further along the chain, like at Google Docs? I think instead of trying to come up with definitions to classify things (and probably argue for the meaning of those definitions from the conclusions we want to draw) we should ask, - Will this help developers? - Will this make users lives better?
- Slartie 8y ago
  None of them is a web app. All of them want to provide certain views on their content that are uniquely identified by their URLs. This is especially true for Twitter and Reddit, which both aim to have their views on tweets and threads to be indexed by search engines. Facebook is probably the least clear one, since they put great effort into eliminating discoverability and accessibility from "outside", i.e. without a Facebook account. They're basically the AOL of today, which was a classic application back then that tried to contain a proprietary "web" of stuff in itself, only accessible if you ran their "browser" application, had an account with them and were logged in, and that "AOL Internet" of course had its own search mechanisms, just like Facebook has its own sophisticated search. However, they're not fully closed-up, they just try really hard to nag you into having an account, which is why I'm inclined to still put them in the "website" camp. However, all of these web sites surely contain certain parts that are in itself "web apps" and that are pretty much isolated from the basic parts of the site (albeit possibly interacting with it at well-defined points through APIs). I guess that this is a logical result of the large engineering teams that are working constantly on what is basically the same big website - at some point, in order to scale out further, it just becomes economic and practical to effectively isolate certain features into mostly separated "apps".

klodolph 8y ago

Microservices are in the same camp. I use them, I love them, I advocate for them. But microservices don't make any sense if your application doesn't call for it or if you don't have the orchestration infrastructure to roll them out and test them easily. I've worked at places in all four quadrants of should/shouldn't and do/don't use microservices.

arcticwombat 8y ago
Yeah microservices is another one that suffers from the One Solution To Rule Them All mentality. They're GREAT when they're the right fit. Most websites aren't really a right fit and do fine with a classic webserver->DB setup.

hombre_fatal 8y ago

Well, SPAs are attractive even for websites that don't particularly benefit from them because of the technical attractiveness of having the website be like any other client that consumes your server's API.

bryanrasmussen 8y ago
sure but there are very few websites in the world that need to publicize an api, basically only sites that need to be able to function as applications. once you have a site that needs to be an application arguing for it to be single page is not that great a leap.
- hombre_fatal 8y ago
  Sure, I meant to make the point that developers are drawn to SPAs for more understandable reasons than just being a bunch of lemmings. Also, it's hard to realize how much work a SPA actually entails until you get your hands dirty. SPAs generally sound great on paper from a technical standpoint.
- quonn 8y ago
  If you have a mobile app, you need an API, even if you‘re site does not function as an application.
  - rossdavidh 8y ago
    The great majority of websites, though, DON'T need a mobile app; they need a website that works on mobile. Most smartphone users are unwilling to download more than a few apps for websites, anyway; if your website is a restaurant, a news source, or anything else that works well on a website, most users are unwilling to download and install your app anyway. So, if you want their business, you need to make your website work for mobile. Once you have done, that, in most (not all) cases, you don't need to develop an app anyway.
  - theonething 8y ago
    unless you use Turbolinks with IOS/Android adapters or another hybrid app alternative

deleted 8y ago

[deleted]

freehunter 8y ago

The other day I was arguing this exactly in a thread here about Ruby. People argue that Rails is outdated and is irrelevant for "modern web development", even though the web is not as modern as most people might think. Even what Facebook does, the only really hard part is the sheer scale they operate at. Facebook (the website) is not a single page app and other than the scale could be done in Rails with some AJAX sprinkled in or even Wordpress with some plugins. People use SPA frameworks and make SPAs with them and those SPAs end up functioning exactly the same as any Rails/Django/Laravel site except the URL bar doesn't change. MVC is still the way the web is built, except for the people who got bored and wanted to make web development even harder than it already is. YAGNI.

bryanrasmussen 8y ago
sure, although modern browser apis mean the url bar can change in a reasonable way
- Freak_NL 8y ago
  Having the address bar behave sensibly is one of guiding principles of the Ember JavaScript framework. A good modern SPA framework should be able to handle proper routing out of the box.
- mixmastamyk 8y ago
  What about tabs? SPA can make tabs troublesome. If I can't open a site in tabs it is broken to me.
  - sangnoir 8y ago
    Browser-side routing/state management is a solved problem - SPAs can make tabs troublesome if the developer didn't put in the effort.
    - JetSpiegel 8y ago
      Using web API means tabs work even if the developer doesn't put in the effort.

scruple 8y ago

> I have also witnessed discussions where management admits that they want something done in an SPA so that they can show that work to their investors, as a means of getting funding to do other projects. Absolutely. This extends well beyond SPAs, too, in my experience. I recently burned part of a month explaining to my senior management chain why you don't just, literally, "do machine learning." Of course, it turns out that the ask was coming from the C-suite, who wanted to put it on a slide somewhere because "everyone is doing machine learning, we need to do machine learning."

ageitgey 8y ago
I do machine learning consulting and I see the flip side of this. I get new clients reaching out asking me to "add some AI" with no specific use cases in mind other than satisfying their investors that they are "leveraging AI."
- mipmap04 8y ago
  Had a client that wanted a machine learning solution to determine if one name that was in one list was also in another list...
  - ycombobreaker 8y ago
    lol... Train your model with the dataset of "another list" i.e. populate a lookup table. Slap a sigmoid on top of that boolean "presence" result. Perfect precision/recall!
irrational 8y ago
In my experience the C-suite people don't even know what machine learning or AI even is. Why don't you just tell them that you've incorporated machine learning into your website? It's not like they would know the difference.
cosmie 8y ago
Ha! I've seen higher ups not even bother to go to that length. They checked the "validation to put it on a slide somewhere" box by just implicitly rebranding AI to be short for Augmented Intelligence. In the context of executive presentations the play on semantics tends to get lost, while the "We do AI[1]" remains true! [1] https://www.informationweek.com/big-data/ai-machine-learning/its-about-augmented-intelligence-not-artificial-intelligence/a/d-id/1331460 https://www.informationweek.com/big-data/ai-machine-learning...

tomc1985 8y ago

It isn't a mean thing to say, it's the truth, and the insanity that is modern software dev needs to have its truths spoken more often.

GVIrish 8y ago

> This may be a mean thing to say, but basically I think SPA's are massively overused, because developers want to demonstrate that they can do them. Unfortunately this is another side effect of the broken hiring process in IT. Recruiters are scanning resumes for the hottest buzzwords, hiring managers want people who have experience with whatever is currently hyped, so developers naturally steer towards those technologies. So a developer may even be aware it doesn't quite make sense to use a single page architecture, but they know that if they have it on their resume it'll help them make more money at the next job. It's a whole maladaptive signaling phenomenon that arises out of organizations overvaluing the wrong things in hiring.

geebee 8y ago
I agree. It's also not simply a matter of making more money on the next job, it can be a matter of having a next job.
- deleted 8y ago
  [deleted]
reading-at-work 8y ago
100% correct, and I'm guilty as charged. If leadership likes the sound of SPAs, and my next job wants me to have experience with SPAs, I'm using SPAs.
bunderbunder 8y ago
It can be the same story on the hiring side: Teams will decide to build $new_thing using $NEW_THING! simply because they know it will help them attract more (and often less expensive) applicants.
Casperin 8y ago
Some years ago, 3 of us picked React for a startup. I consider it the single biggest mistake in my career, but we picked it not for the reason you mention. We didn't think that far (I was perhaps a junior, but the others weren't). It was just a matter of picking the frontend framework that we liked the best (I think the options were between Backbone, Ember, AngularJS, React). In our minds we did pick the simple option. Some may be aware, but certainly not everyone.

alexbanks 8y ago

Unfortunately for most devs, the only way to set yourself up for "better" work later, is to force current mediocre work to use the tooling of the future work. In 2019 if you have on your resume that you're only familiar with Rails and ERB-sites, and you suggest using them for pretty much everything, you'll never get a new job. At a certain point, career-minded devs have to do the "resume driven development" game a little bit, if only to know what others are doing. But in reality most work is very simple. Most work does not require new shiny technology. Most work is insanely mundane.

pjmlp 8y ago
Depends pretty much where one wants to work. Outside the software business, on companies whose focus is totally unrelated to software, no one cares that much how things work. They just have a couple of devs, or hire some freelancers do do some stuff, no matter how, it just has to look pretty.
- beefalo 8y ago
  And they pay them peanuts compared to software businesses.
  - pjmlp 8y ago
    Speaking from experience, not necessarily.
- alexbanks 8y ago
  I feel like this is pretty specific and/or lucky. In my experience, the companies you're referring to also have a person that's worked there for 15+ years and "architected" all of their infra from scratch, in an incredibly unmaintainable way. Sure, they could've done whatever they wanted, but that does not mean that it's better than the alternative.

nickjj 8y ago

Yep exactly. I remember a while back I wrote a blog post where the main topic was "You're not Google (unless you're Google)"[0]. It was related to micro-services but the same thing applies to SPAs too. [0]: https://nickjanetakis.com/blog/microservices-are-something-you-grow-into-not-begin-with https://nickjanetakis.com/blog/microservices-are-something-y...

rossdavidh 8y ago
Well put. Imagine if every building in a city were built with a foundation capable of supporting a skyscraper, because what if you eventually need a skyscraper?

sl1ck731 8y ago

As someone who started developing not long ago, is there any reason to not make an SPA when it is the workflow you are used to? I just don't see a practical difference between SPA or not. The argument I usually see is that its harder...but like me I expect there are more and more people who have learned this way first. I mean for SEO sure, but I usually am not concerned with SEO at all.

sabizmil 8y ago
Building an SPA for every single project is like using a semi-trailer to commute everywhere you go. Sure, it will always get you where you need and sometimes turns have to be taken pretty wide, but what's the downside? Well, if you're destination is just 2 blocks down the road then why not walk? If you just need a simple page and the content doesn't need to be updated often, why not some flat HTML/CSS/JS? Many times SPA frameworks are used because it's flashy and more exciting than writing basic html and css, but more often than not that's all you need.
- sl1ck731 8y ago
  I didn't consider small static sites. I agree with that and have done some landing pages that way that stand in front of SPAs. I guess I was commenting on OP wanting to use Rails or Spring MVC for views instead of only using them for APIs. I'm not sure what the term for it is, monolith maybe.
  - nicoburns 8y ago
    I believe the term would be "Server-rendered MVC framework". I think the argument for server-rendering is simply productivity. You can probably get stuff done about twice as fast if the use case fits the paradigm.
yellowapple 8y ago
It's nice when I don't have to enable JavaScript just to use a website. My battery appreciates it at the very least. Forcing me to run arbitrary Turing-complete code from the Internet just to, say, read an article or buy something online is not okay, especially when that code exists solely to either 1) spy on me or 2) reimplement half of my browser.

CM30 8y ago

I think you've hit the nail on the head here. People seem to have lost sight of how a company like Google and a company like say, a local agency don't have the same needs or problems. As you mention, many of these trendy bits of technology are great if you're running a company at the scale of Google/Amazon/Facebook/Microsoft/whatever, but they're overkill for smaller companies or ones with simpler needs. And yeah, they're also common in situations where they're not the right solution because either devs want to turn their current employer into the next Google, want to build up the CV to look good when interviewing for Google or have a boss/investors who like shiny things in general.

eeeeeeeeeeeee 8y ago

It's similar to people gravitating to NoSQL when they probably actually needed a relational database because they don't really think about their data model and how it will be accessed. That being said, as someone who has done a lot of infrastructure work, I do like web technologies that can fit into something like serverless and Ruby/Rails really isn't there. Speed, file size, and boot time all become much more important. Or if you can make it work, fully static pages that can live on S3/Cloudfront and any dynamic needs are abstracted away to API gateway/Lambda and pulled in. I would much rather have an app running inside of Lambda instead of having to manage a load balancer and AWS auto-scaling, or even elastic beanstalk. So many problems can be dissolved down into people picking the wrong tool for the job.

rossdavidh 8y ago
Yeah to be honest, even RoR/Django/whatever is often more than is necessary. Sometimes static HTML/CSS is what's necessary. A lot of the time, really. I wonder what percentage of React websites could be well served with static HTML and at least one employee who knows HTML.

tracker1 8y ago

Not to completely disagree, but I've worked mostly with web based applications, not specifically static content (with few exceptions)... I find working with React and similar far easier for mid-large applications than most of what came before. I was optimistic around ASP.Net (webforms not mvc) and in practice it was a bloated mess without doing a lot of goofy things. If you're building web applications, it's usually easier to build with components than to think in terms of web controls. If you can separate state slightly from the components even better. This is why react + redux scales well. It makes very little sense in smaller apps, or those that are mostly static. It makes huge sense when you have hundreds or thousands of components, and a lot of application logic and structure. It isn't just because management wants an SPA... sometimes an SPA is the best option.

dbb01 8y ago
In my experience SPAs are actually much more prone to bloat and the resultant performance issues. If you have thousands of components you definitely need to dive into all the complexity of code splitting and server side rendering to make your app fast. You can very quickly find that you have a 4MB JS download. Of course each application has different needs, but for large multi-developer UIs, I think a better option is to split your front end into distinct server based pages where you leverage React/GraphQL/SPA/PWA features for great DX within those pages. That way you can keep it fast and potentially limit some of the complexity.
- tracker1 8y ago
  I'm on a moderately complex UI right now, that has a JS payload around 364kb gzipped, react-dom, chart.js and material-ui/core bits accounting for most of the heavy bits. I've also been heavy handed with pulling out libraries that could be done easy enough with just React and JS. Svg is suprisingly easy in React, and a couple events while tricky aren't as bad as some other tooling I've used in the past. Overall it loads in right around 1s, as I mentioned the splitting for async load on demand doesn't work at the moment, which I had the initial load for a page not using chart.js down to around 115kb gzipped. Part of that also includes the embedded SVG icons as well as the JSS for styling. It's not paying attention when lodash + underscore, + rambda + momentjs, etc. all get loaded via dependencies... most of that can expressly be avoided with specific smaller frameworks and tooling. https://i.imgur.com/gf5cpNd.png https://i.imgur.com/gf5cpNd.png

JetSpiegel 8y ago

> Because they actually are doing things that require them. Citation needed. G-Suite's admin pages are half "modern" SPA monstrosities that suck up my RAM and peg my CPU to render a bunch of whitespace with bits of information strewn around, and ugly but functional regular pages whose performance is killed for being framed inside a SPA frankenapp.

yellowapple 8y ago
Right? Sure, there are Google products that certainly warrant being SPAs (like Google Docs), but the vast majority should be possible to implement without a single line of Javascript at all, let alone as a single-page application.

rsynnott 8y ago

> This may be a mean thing to say, but basically I think SPA's are massively overused, because developers want to demonstrate that they can do them. This may be even meaner, but they usually end up demonstrating they can’t. 99% of them are terrible. Even Google’s latest efforts are a bit on the slow, low-information-density side.

nojvek 8y ago

I don’t get the hate against SPA’s. An SPA done right offers amazing interactibily and instant navigation to new views. You already have the templates cached. They probably load from a cdn with good caching policy. If done well you can totally run offline. Sure you can build with php, laravel, django. The promise of SPA is a clean separation of UI from the APIs. The same REST APIs that external customers use is the same API you develop on. See travis-ci as an example. It’s the same api that the mobile apps can use. This separation allows the api to return very lightweight stateless responses. You can scale much better when there is less state kungfu. The UI can manage the state in very responsive manner. No round trips, instant 60fps render. And no JavaScript is not slow. It’s just that people don’t know it well and end up loading megs of bloated libs with a 1000 ad tracking libraries. Don’t throw the baby with the bathwater.

mercer 8y ago
> An SPA done right offers amazing interactibily and instant navigation to new views. You already have the templates cached. They probably load from a cdn with good caching policy. Most of the time I find the initial delay loading/parsing the js to be more problematic than the often tiny speed increase of subsequent loads. Furthermore, these days it takes minimal to no tweaking to get server-side rendered pages to load fast enough to barely notice the difference (in particular if the client-side is retrieving and parsing JSON in the background through an API request). Perhaps non-webdevs are even less likely to notice this stuff. > If done well you can totally run offline. That's definitely an advantage, but most SPAs I encounter don't offer offline functionality, or it's entirely unnecessary to offer it. > Sure you can build with php, laravel, django. The promise of SPA is a clean separation of UI from the APIs. The same REST APIs that external customers use is the same API you develop on. See travis-ci as an example. It’s the same api that the mobile apps can use. In some cases that's definitely an advantage. But it's entirely feasible to build an API-based backend and use that API internally for server-side rendering. If you want an app that plays nice with search engines you have to do this anyways. > This separation allows the api to return very lightweight stateless responses. You can scale much better when there is less state kungfu. That doesn't make sense to me. One of the biggest issues I have with SPAs is that you now have to deal with the backend state (DB) and a subset of this state on the client, which dramatically increases complexity (state management, sync, etc.). I rather like the old-fashioned approach where all state remains in the backend, except perhaps for the tiny bits you'd put in a cookie (and I suppose the URL could be considered client-site state too). > The UI can manage the state in very responsive manner. No round trips, instant 60fps render. How many apps do you use where you really need anything below say, sub-second rendering? Frameworks like Phoenix and/or caching can be much faster than that even (in the order of microseconds). > And no JavaScript is not slow. It’s just that people don’t know it well and end up loading megs of bloated libs with a 1000 ad tracking libraries. Clearly if so many SPAs are bloated Mb-size messes, it's not trivial to solve. And it's a problem you can almost entirely avoid if you keep the rendering on the server. After years of agonizing over bundle sizes, I find it incredibly liberating to not have to think about this anymore (much of the time, anyways). > Don’t throw the baby with the bathwater. I do agree that there are plenty of use cases for SPAs, but I also agree with many here who say they're very over-used. I'll add that there are some interesting initiatives to have 'old-fashioned' applications that also get to be dynamic enough for many if most use cases. Phoenix LiveView [1], for example, takes advantage of very fast server-side rendering, websockets, and sending subsets of the templates as HTML snippets to the client, where morphdom simply diffs the HTML string with the element it's supposed to replace. With great performance. [1]: https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-real-time-apps-no-need-to-write-javascript https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...