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

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.

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.

> I consider it the single biggest mistake in my career

I have to ask... what went so wrong? If you had a time machine, what would you tell your younger self?

Oh I'm so sorry, I didn't see the replies.

It was a mistake because we needed to move fast and figure out if we had something or not. A simple CRUD website (say Ruby on Rails, Elixir/Phoenix, or even straight up Node/Express) would have been faster to build and iterate on.

There was one section of it that would benefit from being able to work while offline, so that could perhaps have been built as a small SPA. But the rest, that was in hindsight a mistake.

If you had to redo what would you pick? Why not jQuery?

jQuery would have been fine, but honestly the website did not need that much js (if any). It should just have been a CRUD website.

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.

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.

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.

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.

GWT ouch. Or as I call it "get with the times!"

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

Not a fan of Angular, am a fan of most of Material Design.

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.

Do Google still use their closure library + compiler on all their big properties? https://github.com/google/closure-library/

I'm learning Clojure at the moment, don't think I would have heard of Google Closure otherwise

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.

They're related. The ClojureScript compiler uses Google Closure as a backend and runtime library

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.

I've started thinking of this phenomenon as "blog driven design". It's what happens when you fall into the assumption that what bloggers are writing about is what everyone is (or should be) doing.

The problem with that is, blogs are a poor barometer for that sort of thing. Nobody needs to write new blog posts about tried-and-true things that are already plenty well documented. The more solid and stable a technology is, the less incentive there is for anyone to bother writing how-to blogs about it.

In order to have dynamic UI you either have to use jQuery or SPA library like Vue or similar.

For me the major advantage of vuejs over jquery is the way data drives UI

But... people had dynamic UIs before jQuery and Vue. The main benefit of jQuery was back in the days when the browsers were so different from each other, but that's not the case anymore. I'd recommend learning some vanilla JS before thinking that you need jQuery/Vue/React to create dynamic UIs.

The difference is imperative vs reactive UI. The impact of this is hard to overstate.

Why do you need jQuery for this?

You don't strictly need jQuery for this. jQuery simply has a terser API than the standard DOM. That's why I still use it.

sure, although modern browser apis mean the url bar can change in a reasonable way

What about tabs? SPA can make tabs troublesome. If I can't open a site in tabs it is broken to me.

I'm not sure when/why tabs should be an issue... it depends. To me it's a difference between localStorage and sessionStorage for the most part.

If links don't fully address an item then opening it in a tab won't work.

That isn't a limitation of SPA or browser based apps though. For that matter, even having an option to open an app multiple times is often a limitation of desktop apps. That doesn't make them somehow deficient as a platform.

It does. You don't open the "app" multiple times, you open lists or records in separate windows and/or tabs. That is a thing in desktop apps also. SPAs usually break it by tunneling everything through a single url, perhaps with anchors.

But opening lists/records in another window/tab isn't a limitation of the browser environment, or SPA in particular. With proper router/caching in place it can be done within a browser app as well.

Browser-side routing/state management is a solved problem - SPAs can make tabs troublesome if the developer didn't put in the effort.

For God's sake, STOP trying to re-implement my browser's interface with Javascript! I don't want you to "put in the effort" to make my URL bar, back/forward buttons, and tabs work the way they naturally do in my browser; that's what my browser is FOR! Even when the developer does put in the effort, the results are usually _just_ different enough in various subtle ways from the browser's native behviour as to be annoying.

Just build a normal website and let my browser do what it was built to do. The APIs that allow SPAs are great and useful. The Pixlr online photo editor has a good reason to be a SPA, and that works great for it. Your forum/email interface/management API would work better as a normal website.

> Your forum/email interface/management API would work better as a normal website.

Good for you with your fast, always-on internet, I guess. Some consumers have to deal with expensive and unreliable 3G internet (that downgrades to 2G occasionally) - an offline-capable email (or management) SPA is indispensable for them. Sure, you could write 4 native offline apps for MacOS, Windows, iOS and Android but that is a bigger investment than targeting browser standards.

SPA is orthogonal to storage, nor are lightweight web techniques exclusive to it, and often in opposition. Native email clients already exist of course.

Using web API means tabs work even if the developer doesn't put in the effort.

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.

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

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

Had a client that wanted a machine learning solution to determine if one name that was in one list was also in another list...

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!

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.

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

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.

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.

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.

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.

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.

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.

And they pay them peanuts compared to software businesses.

Speaking from experience, not necessarily.

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.

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.

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.

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.

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

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

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.

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.

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.

If you have a mobile app, you need an API, even if you‘re site does not function as an application.

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.

unless you use Turbolinks with IOS/Android adapters or another hybrid app alternative

exactly that. since 2012 i build all my websites as SPAs for this reason. more so, i am not even writing any new backends. i reuse the same backend over and over. most websites (at least the ones i have been building) are just CRUD and don't really need a custom backend.

SPAs bring back the client-server architecture we had before the web. you build desktop clients that consume server-api's.

server-side html generation now feels like cruft and an awkward way of building applications.

It should be trivial to build a server-side client app in the same manner, using an API for any persistence instead of directly accessing the database. Most of the full-stack frameworks (Django, Rails, Laravel etc) are unfortunately still conflating the persistent state entities with business logic objects.

you are of course right. there is no stopping anyone from doing that. in fact the university which initially developed the backend i am using has been doing just that, using the backend like a database, creating "frontends" in PHP.

though that doesn't negate the point of SPA which enables building clients that run directly on the users devices and are not hampered by the difficulty of emulating stateful clients on a server.

You are falling into a comfortable trap where it is easier to do the same. If you took the time to learn laravel your development time can be cut in half.

the backend i have is of course written in such a framework. (it's not laravel[0], but it could be)

i am not trying to diss backend frameworks here as bad. any of these would be a good choice for the backend.

the point is that thanks to SPA and CRUD i get to reuse that same backend over and over with little or no modification. (modifications amount to fixing bugs and very rarely adding new features to the API)

my backend development time now is effectively 0!

[0] (i have been working with laravel, django and others (primarily roxen and pike) before, and while i am not a fan of php, i did find laravel pleasant to work with)

You can do this with a non-SPA website just fine if the website's backend is the API client. Sure, it adds an extra layer of indirection between the browser and your data, but if the separation of concerns is really your goal, then that's probably as good as it gets.

Well, with a SPA, 0% of your website may be rendered on the server just like your other clients. That's basically the defining feature, though of course they can be rendered on the server as an optimization detail. They even still use AJAX, so I didn't quite understand that bit.

I'm not sure what you meant with the rest of your post. There are technical upsides to having zero web client presentation logic implemented on the server at all. But it's just trade-offs.

Maybe you're suggesting with your "grunt work" comment that most complexity for most applications lives in the UI rather than the API? I'd agree. It's why there are upsides to keeping UI implementation off the server.

I just like to avoid the HN cargo cults of "this = good, that = bad" and "the people who do $X are probably incompetent."

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.

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

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.

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.

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.

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

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.

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?

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

Deep-linking URLs are available to SPAs as well, though.

I run a somewhat popular media site implemented as an endless-scrolling SPA. Clicking on an image or video opens its detail page in a floating modal and changes the URL. I specifically wanted people to be able to link to content this way, and my SPA will load that modal and the media-gallery behind it.

Quickly, SPA just becomes implementation detail. It's the level of user-interaction that dictates your implementation. For example, if you insist on your site being server-rendered with heavy Javascript that takes over, there may be a point where it would've been simpler for you to just implement it all in Javascript (the SPA).

I could've implemented my media site without Javascript. Or maybe just with AJAX that returns HTML. But I know from experience that, while simple upfront, those become more complicated as you try to build more interactive UX and starting wishing your Javascript had more access to the context. At which point a SPA is just another tool for managing client complexity in some other quadrant of the graph. But there's some nuance to the question of whether your site is or should also be in that quadrant.

It's really easy to throw the baby out with the bathwater in this conversation as well.

A more interactive Javascript-heavy UI can improve a lot of aspects of even websites we consider to be a server-side-rendered gold standard like a forum or message board.

For example, look at the right-sidebar scrubber on Flarum that lets you quickly scroll to arbitrary parts of a long forum thread: https://discuss.flarum.org/d/17745-flarum-0-1-0-beta-8-relea...

Or look at how clicking a submission on Reddit's new UI opens it in a floating modal window so that you don't lose track of where you are when you click out of it. It makes opening submissions feel cheaper/faster to me where, in the old UI, I tended to open everything up in a new tab.

There's a more thoughtful consideration that needs to be had here than just "webapp or website?" Else you're back to cargo-culting.

Both of those are just fixing problems caused by the reliance on JS in the first place.

The first could be done easily with anchor links - if the content wasn't loaded dynamically.

And browsers are perfectly able to return you to the same position in the page - unless it's all loaded dynamically.

Hrm. I apparently angered it by scrolling to fast, and it froze for about a second. I think I prefer ordinary forums...

Or this, this blog post (I wrote) about how Hacker News itself can be improved, and it's about SPA things:

https://www.talkyard.io/-32/how-hacker-news-can-be-improved-...

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

All three of these are examples of websites where JavaScript should be entirely optional. With the exception of the realtime chat functionality in reddit and Facebook, there is very little that any of those three platforms couldn't do exclusively with server-side-rendered HTML and CSS. It might be ugly, but it'd be usable. Any client-side scripting should build on top of that and implement the fancier features.

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

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?

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.

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.

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.

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.

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.

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.