Slack, Dropbox, Google, Notion, Spotify, superhuman, 1Password, Robinhood…

Basically most web tools/apps are SPAs if they have been built in the last ~10years. Github, Reddit and Airbnb were founded ~15 years ago when Rails was still a thing.

As a frontend dev this has always been my stance, but I’ve been consistently shunned for it.

How much of that was naïveté vs. misaligned incentives I’m not sure.

In any case, these thing always leave me with the feeling the industry is getting way too saturated with script kiddies. It just feels immature, and the culture that’s grown around web dev seems to reflect that. Or more likely I’m just bitter and old.

Or more likely I’m just bitter and old.

Farmville Devs <- Facebook Devs <- Chrome Devs <- OS Devs <- Chip Devs <- Factory Devs

The abstractions are not, however, good enough yet.

Once you start adding conditions and context to the heuristic, it starts to look a lot like a Design Pattern.

What I was describing could maybe be conceptualized as multiple applications that serve one larger site. You have the public facing staticly rendered site, built in whichever way, but that ultimately has accessible rendered content on page load and as fast as possible. Then you also have interfaces to the data that is rendered there, which might be completely separate codebases for different purposes.

These could also take place in things like a reporting portal inside a company, where stakeholders need to regularly see static or filterable reports of pre-rendered data, and then you have other internally available apps that different departments can use to manipulate that data in ways that they can easily receive immediate feedback on whether or not it's valid or how it looks etc..

Maybe we don’t talk about the same thing, but isomorphic code with react is great for websites too: server side render, instant page change on client side. Reuse of exact code. Huge benefits.

I am just curious, why would I use Rails over something like .Net in today's time? I am no apologist for .Net or anything, I am just genuinely curious.

It's an engineering decision with tradeoffs, like every engineering decision.

Actually the latter is a candidate to k8s because the team knows less and less of server management. I think they are going to replace complexity with complexity for something that fits well in a small VM. We will see.

About Elixir, I don't think it's an overkill. I find its pattern matching much better than anything similar in Python and Ruby. Running a background job without having to use Celery or Sidekiq is great. The deploy story is worse than Ruby's (IMHO) in part because it's compiled (I prefer to deploy with Capistrano than having to build and deploy.) Python's deploy story just doesn't exist. According to the project I'm using a self made Capistrano equivalent, git pull or sending git patches to the server.

Unless you have some specific requirements for you app like high concurrency or memory safety and so on, then you can pick whatever you (or your team) are most comfortable with: Django, Rails, Symphony, .. are all excellent.

It's more about solving business problems and building great systems than anything else. All tools have pros and cons of course, it's simply up to us to review the requirements and pick the right one for the job.

You are not wrong though, and it's quite annoying when hopping between multiple .Net versions. I feel like I have a bit of insight into what it would have been like to be developing in Python during the 2.x to 3.x schism years back.

Then, they come up with The New Thing every few years, which is not backwards compatible and only handles 20% of what the old thing did + a few new things, but they promise this is the future and will eventually have all the features. The Old Thing is always there if you want it, so there's no reason to revolt when this happens.

The New Thing will eventually be replaced by a Newer Thing, get frozen in its current status, and the Newer Thing will be promised to be the future.

A nice example is Windows GUI. The Old Thing is GDI. Then they invented WinForms in .NET, then WinForms was abandonned in favor of WPF, then WPF was abandonned in favor of Metro/Modern/Universal apps, and last I checked they had some new HTML+JS-based stack available. All of these frameworks still work - you can take an app built with any of them and run it on the latest Windows, and you can even build a new App based on any of them and still find resources for it etc. But none of the old ones are getting new features, and MS will steer you to one of the newer ones instead.

The same kind of thing happened with communication frameworks (COM, then WCF, then???), with ORMs (ADO.NET, LINQ to SQL, Entity Framework, Entity Framework Core) and I'm sure others.

I detect a similar strategy with Apple and the app store: make it so that the long tail of small developers can't invest in more than one platform by moving goalposts so frequently you spend any spare cycles you have trying to keep up.

But all t he other stuff common to popular libraries still applies, tons of community support, huge extensibility, large population of devs that have experience building large apps.

That means it's not likely to make huge breaking changes without lots of notice. Its development team isn't going to find something more interesting to do tomorrow. Lots of people know it. There are lots of libraries and tools that work with it. Its capabilities and limitations are well understood and predictable. Its future isn't tied to a single vendor. Lots of people know it.

I mean, I solve most of my problems with the hammers I have at hand. But I try not to fall exclusively in this trap of “I will use tech X because that’s what I know.”

But I see a majority of my programming peers who will avoid moving “forward” because it’s easier to “stay behind.” At first, this works, because the difference between what’s new and evolving versus what’s established and a “core competency” is trivial and easy to marginalize. As it persists over time though, the investment can become a real millstone.

I am pretty comfortable with Python. We use it some pretty key areas in our product. It’s an established technology and competency for us. Last year, I needed to construct a service that was going to involve spinning up LOTS of little long lived threads. I was concerned about doing this in Python. Doing so would be easy and straightforward. “Because I know it” would definitely have said “do this in Python right now, deal with scaling issues later.” Instead I looked around and deemed this a good reason to take Elixir for a spin. I’m glad I did. It turned out to be a good fit for this problem. “Because I don’t know it” caused others around me to raise their eyebrows and question my approach initially. Was it the 100% best choice? Who knows for sure. But it’s worked out well. Ironically, just the other day, a data serialization library I have in both systems, the Python one needed to run faster (new use case for it suddenly needed speed that we didn’t hitherto care about). After some profiling, I rearchitected the python algorithm to be more similar to the Elixir one and gained about 50% speed up.

That would be a VERY interesting case study. Any chance you could write it up as a blog post or similar?

You could just fade out rails as you could with any other monolith, but many companies aren't doing it because it offers legitimate advantages.

Database driven sites and apps have experienced great performance and functional gains since the marketing teams pushed SPAs onto everything and it's tragic that billions of dollars will be thrown off a cliff (once again) to refactor everything back to prior methods... Hubris always wins until it fails massively.

That being said, SPAs do work well for certain things, but people just keep losing track of the right shoe for the right foot.

On big, sprawling, multipage content-rich websites, not so much if at all.

It depends. Web people should have this tattooed on their foreheads.

I'm aware that Google can run JS, but its support is limited compared to server rendering and there are other crawlers behind Google which probably will never be as sophisticated.

The other way is to add a few lines to your `robots.txt`.

If you mean "google" as "google properties as a whole", then yeah (the fusion of google maps and google earth is something absolutely _mind blowing_ to see in a web browser, for example).

If you mean "google" as "the search engine", then I was perfectly fine with a server side rendered, non-so-much-semantic search it was until last decade. Advanced search worked well, fast as hell already. Hell, there were two search text boxes if you wanted to search for something else once you scrolled down to the bottom of the page.

The whole concept of Single Page Applications was misguided from the start, and the reason for that is even in the name. Pages and applications should never have been mashed together. The moment we decided we needed apps, we should have abandoned the static document-based "page" concept altogether.

We shoul've replaced it with a browser-hosted VM-based execution environment in which proper apps could be built.

It's never been a question of MPA vs SPA. The question has always been how do you build browser-based applications in a way that escapes the impedance mismatched document/html model?

And, we're now delivering entire frameworks to the browser to support, essentially, a kludgy VM-based approach that just shoehorns app concepts onto the HTML document model.

So, what I'm suggesting is more of an in-browser hybrid.

Assuming the only two approaches are Flash or React seems like an industry-wide failure of imagination.

I'd venture to guess that even an MPA comprising multiple SPA 'pages' is an unsurprising composition especially for captive audience apps like internal, or government etc.

How many micro-interactions do you want --- the more you have, the more likely you want an application rather than a site.

When you first go to aws.amazon.com, you get a website with content about AWS.

Once you log in, you’re in the AWS web application, and it’s time to start doing things.

Forums like HN, I would consider websites because there is a lot of reading and not much doing.

Wikipedia and blogs are mostly for consuming content and it's the same content for everyone. Clearly a website. Instagram usually isn't super interactive, but it's extremely personalized, so it's much more like an app. Gmail also clearly a web app.

Amazon is highly personalized and fits well into the standard web page paradigm. What about Instagram's "personalization" wouldn't work as a standard web page?

Really nothing. But for most people Instagram is primarily a mobile application and comes with the usual experience of a mobile application. Transitions, fast reactions, no "whole page" reloads, etc.

Continuing this experience into the less frequently used browser version only makes sense, especially given the fact that Instagram's tooling allows for a relatively easy transfer (iirc large parts of the mobile apps are implemented using React Native)

Firstly if it's "transactional" it fits more often into the label of "application". If it is there mainly for consumption of media, it's more "Web site".

Secondly, I think it's useful to think about what it'd feel like as a desktop app. Stuff like say Google Sheets would feel perfectly normal running on your desktop. It's super snappy, all on-page. Something like the BBC or HN, not so much.

The only clear line I've seen is javascript. If it uses javascript for anything nontrivial, people believe it's a web app. This comes up all the time in threads about "the old web" or "how you would fix the web," in the context of what seems to be a prevalent belief on HN that the web should be split up between the two paradigms, with purely static, noninteractive "sites" in one place, and "apps" in the other.

Problem is, as mentioned upthread, the vast majority of sites using javascript, including SPAs, are still meant to be read as documents. If you include any form of interactivity, including backend processing and rendering, even more sites become apps.

In practice, it seems to me to be more of a religious taxonomy than a technical one, based on the belief that the modern web has become tainted by complexity and needs to be made pure again.

I see it more being whether a page uses progressive enhancement. If I can disable JavaScript and at least be able to read a page's content, then its a web page rather than an app. If JavaScript is an absolute requirement for any functionality it's an app.

A page with some client-side form validation, AJAX submissions, or even just some dynamic content are awesome uses of JavaScript so long as the pages themselves don't hinge on me running the JavaScript. Posting a comment might be a POST and clicking an image thumbnail might load it in a new tab instead of a light box. The functionality is all still there if for any reason the JavaScript doesn't load.

One of my big problems with "apps" is they have zero provisions for JavaScript not running. Most "apps" don't even give an error page telling you explicitly JavaScript is required. Even when you have JavaScript enabled they tend to break in stupid ways if you've got an ad blocker.

anything that can be done offline ought to be an SPA so that it can be made to actually still work without internet access.

So the "It's even in the name" argument is not an easy decision point as you make it look like.

    Slack, Dropbox, Google, Notion,
    Spotify, superhuman, 1Password, Robinhood…

Thanks for letting us know everyone was waiting for you stating your personal preferences, so they can follow suit.

For me it's because the new design is hilariously slow in every way. And also it looks really, really bad. Meanwhile old.reddit.com loads instantly and doesn't burn my retinas.

https://www.reddit.com/r/bugs/comments/rj0u77/reddit_redesig...

Also... I wouldn't have thought that by default it would include screenshots of potentially private/sensitive information such as the the titles of other open tabs.

FWIW if you're logged in you can go to your profile and make it so www.reddit.com just shows old reddit

Again: teddit.net solves that problem. RELIABLY

There's the added bonus that I can't vote or comment. Yes, bonus.

1. Not log in to Reddit unless I must.

2. To use old.reddit.com exclusively. Or another which won't revert to www.reddit.com

The mechanism you describe fails on both counts.

So are controls or useful UI or... :D

Not saying you should do either of these, as the UX would be worse, but you could if you really want to :)

Seems SPA to me.

My current gig for a smaller corp (<50 employees) I am with 3 other developers (1 FE, 2 BE) and all that team has been doing for almost 1.5 years is to develop a SPA webapp that is exclusively used by the on-call phone support staff, which are no more than 4 actively working supporters at the same time. Admittedly, the business customers deal in huge amounts of money so having qualified phone support is a must here, and upselling/sales also happens on those calls.

It's either use an application provided by an authorised third party (who take a cut of every transaction) or become directly authorised to run solo with your own application that meets legislative requirements.

https://viewcomponent.org/

It's the right balance in-between React/SSR hydration and Railsy server-side apps, taking the best of both worlds.

This is a really good talk about how we got here from Jquery->Backbone.js->SPAs + React/Vue->Stimulus/ViewComponent/ActionCable

https://www.youtube.com/watch?v=sIxvxp7E0xg

There's another similar project called AnyCable which combines websockets with an ActionCable style approach:

https://anycable.io/

This is similar to how React Server Components work, except that they work for arbitrary server-side rendering updates to the client as well as navigation. And it’s conceptually similar to how Qwik works, only the “partials” are typically client chunks. And again with Qwik, not tied to navigation, but that’s pretty much how I’d imagine a client routing solution for Qwik would (will?) look.

This blog post (and my linked talk above) opened my eyes on the subject: https://evilmartians.com/chronicles/anycable-actioncable-on-...

Right now the complexity is a bit high on this approach^ and I personally just use a mix of Vue + Turbolinks/Rails at work for legacy/simplicity reasons. But I'm watching the space.

But GitHub doesn't use turbolink. They wrote their own implementations that lies at app/assets/modules/github/behaviors/pjax.ts.

Check out https://api.github.com/users/defunkt:

> "id": 2

pjax was written by a GitHub founder for use in github.com.

Does anyone know how to block that page reload and associated movement of stories and scroll position on the page you're returning back to?

    history.back()

I remember being pretty interested in it at the time.

https://techcrunch.com/2013/04/19/airbnb-open-sources-rendr-...

> Hackernews, Amazon, AirBnB, Booking.com, Wikipedia, GithHub

I don't know about AirBnB. Booking has a little bit of interactivity that is more annoying than helpful¹, like the GP's example for Reddit. None of the others can be described as "applications".

1 - The map is good. The stuff on the map is very good. The map itself is an SPA. For all the rest of the site, if they removed all the Javascript it wold be an improvement.

Overall, I would count that as MPA?

The apartment pages seem to be client side rendered. When I CTRL+u and look a the source code, I see a lot of JSON and not much HTML.

I resisted "learning" typescript for like 5 years or more and I hope it's been validated somewhat.

Being a web dev is hard enough dealing with myriad devices and ever changing trends without consolidating every aspect of web/app into that role because Facebook wanted to cut down on their server costs.

And I don't enjoy using those bloated electron apps either, the difference between native and JS is stark.

What does TS have to do with SPA/MPA?

I can't speak for others but my company (of 50k) has dozens of internal facing SPAs each with their own dev teams. Each of these apps are used by at least hundreds of not thousands of people on a weekly basis.

Sometimes SPAs are literally apps that you install on your computer.