Hacker News Reader

Comment by TekMol | Hacker News Reader

Where are those SPAs everybody is talking about?

All sites I use regularly are MPAs:

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

Reddits new design is kind of a hybrid. It is MPA when you hop between subreddits and other pages. But it shows a post on the same page when you click on it in a subreddit feed. I actually are annoyed by the new Reddit enough to switch to old.reddit.com most of the time when I end up on Reddit. Not sure why. But maybe it tells something, that the only "somewhat SPA" I know makes me switch to its MPA version regularly.

View on HN

Apps, not sites. It’s even in the name, Single Page Application. You probably shouldn’t build websites as SPAs but you probably should build most apps as SPAs.

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.

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

I don't use any of these. With the exception of Google (the search engine). Which I don't think is a SPA. When I type a search query and hit enter, it loads a new page. When I click on the next page at the bottom, it also loads a new page.

Both Google Maps and Gmail were among the very first SPA's.

Wasn’t the first SPA actually Microsoft’s Outlook Web Access 5.0, back in 1997?

> I don't use any of these

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

Rails never went away.

Rails is still “a thing” and is better today than it has ever been.

only because the companies that use rails are stuck on it :P

Majority of the ones I know are making billions. Why change something that’s already profitable?

Why make billions when you can make millions (not dealing with bad async primitives and type safety that doesn't need some third party project like sorbet)

Nope.

Many start-ups (especially ones that aren't backed by millions of VC money) choose Rails because of the super high developer productivity and the broad availability of well tested packages.

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.

Really? I miss it sometimes. I haven't kept up with it in over 5 years (switched to .Net now).

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.

I haven’t kept up with either, but remember that “because you know it” is a perfectly reasonable and fine reason!

I struggle with this a little. Or rather, I struggle with the counter corollary: “Because you don’t 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.

There's so much more to this then Stack X runs faster or has better concurrency - there's development time, there's the team's ability to maintain the code, there's community size. Performance is overrated most of the time - it simply doesn't matter much to the business if you save some money on AWS bills compared to human cost.

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

A lot of places suffer from not believing they have the capacity to use the right tool for the job if it's not in the tech stack they already have. Similarly, people over-index on having a comfortable implementation path for feature X in technology Y, whereas technology Z, if they cared to look at it, would halve (or better) the implementation time.

Rails has added a lot of cool built in stuff. SPA like stuff that is done over sockets but written in ruby (Hotwire is the name of it) is the most germane to this conversation.

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.

With net you can accomplish the same with HTMX. And you can do the a SPA frontend fully in C# using Blazor.

I imagine that one reason why you might want to use it is if you don't like the "let's reinvent the wheel incompatibly every three years" approach from the .NET world.

I'll be honest, this made me chuckle.

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.

Never knew this was the case, I thought these enterprisey stacks were all about moving slow and being compatible. Why are they doing this then?

Microsoft has a strong stance of backwards compatibility, but they achieve this by freezing the The Old Thing as much as possible and keeping it working as is.

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.

And don't forget about silverlight and frameworks build on top of it (for enterprisy like form apps). That one was one hell of a swamp that almost drowned my friend's startup after MS decided to kill it. Years of hard work went down the drain at a snap of a finger.

This is exactly why I got off the MS merry-go-round. The strategy seems to be to keep developers constantly chasing the Next Thing so they haven't got time to explore alternatives.

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.

Because you or a team knows it, because it's still a hell of a lot more of a batteries included ecosystem than the last Scala or node projects I was involved in which had to reinvent a shocking number of wheels that are table stakes in Rails-land (can't speak to .net, never been an MS stack dev), because you're working with some other Ruby or Rails thing and its easiest to stay compatible, because there's a lot of mature, profitable projects out there hiring in it with high salaries ;), etc

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

My gut feel is that the .Net ecosystem is probably more complete than the Rails ecosystem, but part of that is because there's a larger market for commercial components. Like you say, tradeoffs.

I don't think there is any particular "reason". Majority of the languages and tools are really good enough to achieve 90% of business use cases out there.

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.

Hot take: Phoenix does almost everything Rails does but better. Ruby is still superior for scripting, but OTP gives you so much flexibility for integrating your backend (supervision is built in, process abstraction is built in, rpc is built in, microservice architecture is built in). The only other thing I don’t care for with Phoenix is the amount of metaprogramming which I think is even worse than Rails

Hot take: Everyone now uses k8s, I don't get why forcing our devops team to learn OTP and understand how to integrate Elixir with k8s is a benefit, it will only be harder for them. So you get most of the benefits like scalablity/reliability etc even if you're on the Rails - but you don't have to expose junior devs to a complicated and obscure stack like Elixir.

All those people using k8s don't include any of my customers. Current projects are Django sites running on VMs, Rails sites on a kind of Heroku service and a Phoenix app running on VMs plus some Elixir services running on Google Cloud serverless services.

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.

They sound like small clients, no offense. Indeed for them k8s is probably an overkill - as is Elixir.

No offense taken. Small contractor, small customers. The long tail doesn't need fancy technologies devised by companies that have to serve billions of users and yet a lot of people live there.

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.

I'm sure you serve them well with Elixir. All these technologies are good enough. You wouldn't be able to build stuff for them in PHP/Ruby/Java? You would, but you prefer Elixir because you think it's superior and thats fine. But even if its superior you have to agree equivalent stuff is being built in 15 other stacks. Technology choice is a bit overrated imo.

Actually the customer chose Elixir. They found me because there weren't many Elixir developers in my country when the project started years ago. I prefer Ruby for my own stuff which of course is way smaller than customers projects.

It's mature.

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.

Nothing changed much in the last 5 years, if you like .Net better stick to .Net. The fact you miss Rails sometimes means it wasn't that bad though.

I avoid rails-style megaframeworks like the plague. I'm fine writing the glue code if it means I understand more of the stack, or it doesn't refuse to budge if I occasionally have to go "off the rails".

Same for Laravel, although it hasn't grown as much as Rails, the amount of batteries included is amazing. There's very little I've had to reinvent, unlike my Node JS projects, where there's too much time wasted in finding and learning 3rd party packages that are outdated in a year or two.

What are the primary characteristics that distinguish a web site from a web app?

number of pages

i'd say the dynamic of the content.

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

At a very superficial level, HN feels like a website and logging in to do my banking feels like a web application. But trying to drill down into specific definitions or draw a clear line between them seems to fall apart quickly. So I guess for me at least I really don't know the answer, but also don't think it's terribly useful to make a distinction either.

>But trying to drill down into specific definitions or draw a clear line between them seems to fall apart quickly.

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.

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

A bank should be a website (if only my bank would agree...). If you're making a Photoshop clone in the browser, that's web app territory.

For me it is reading vs doing.

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.

Possibly old fashioned view here but I think of it in two ways.

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.

I'd say there's is not a clear definition, but I think: low interaction intensity / no personalized experience = website, high interaction intensity / personalized experience = application.

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.

Why would an SPA do a "personalized experience" better than a traditional website?

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?

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

Facebook used to be server side PHP and it always was personalized. I think the distinction is more about the degree of interactivity. Highly interactive GUIs (the hell of jQuery developers) went to SPAs and are called webapps. Low interaction GUIs could be server side rendered with the technologies of 20 years ago even today. Most banking sites are low interaction and could be old style Java even if almost every one I see is a SPA now. The distinction is very fuzzy.

I would say interactivity. A spreadsheet for example, you are constantly modifying rows. You want that in memory in the browser, not on a server, where you need to constantly be making ajax calls.

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

If the Shopify ecosystem was the only example of rails in existence then rails would still definitely be a thing.

> You probably shouldn’t build websites as SPAs but you probably should build most apps as SPAs.

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.

People largely don’t think for themselves, every once in a while the firmware gets updated and they have a new opinion. All you can do is pick your battles, there is finite amount of credits to spend.

OS developer here. You’re all naive children playing in our sandbox, arguing over what color to paint your sandcastles.

Or more likely I’m just bitter and old.

Purity: https://xkcd.com/435/

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

It's almost like their small differences come with some narcissism.

App developer here. Your sand sucks and it's affecting our apps!

Make your own sand then.

https://youtube.com/watch?v=YSYFs7Y1fFI

… and then go pound it?

Speaking from personal experience, those aren't mutually exclusive.

We need a hardware dev to chime in

I liked to put the line between whether you're required to sign in to use it or not. If none of the data was necessarily publicly accessible anyway, that's more of a spa suited interface

Not sure that heuristic works. For many people, the major destinations that require a login are paywalled content sites.

Well, it would be one of many. Considering building an SPA for a paywalled content site would be a little surprising to me in the first place, but it would make a lot of sense to me for any of the behind-the-scenes or account management facilities you'd only ever see once you've logged in. I wouldn't expect the content view to either be sufficiently interactive on its own, or sufficiently interactive when coupled with other aspects of the UI, to require the complexity of an SPA at all.

What do you think the full set looks like?

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

The full set would be something like who the target market is, whether it's a completely internal or completely standalone thing that just happens to be built with web tech, whether it's intended to be offline-capable and whether there's a lot of state involved in the interactive capabilities of most views, should there be the capability to do any kind of concurrent UI things like picture-in-picture video while someone navigates the rest of the screens and changes data frequently, and then the importance/complexity of maintaining a high-level of accessibility.

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

If you feel old you should try Next.js. I dove into it recently and joined the Discord channel, sometimes I answer questions. It is really interesting helping people who are creating complex apps by stitching together a bunch of npm modules while having absolutely no clue about the underlying implementations, or the basics of web dev and javascript.

And the meta-interesting thing is, once the abstractions get good enough, that is the correct direction for things to move in.

The abstractions are not, however, good enough yet.

I’m also surprised how people can’t see the benefit of have 1 way of doing things. 99% of the websites end up in app like features.

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.

We are bitter and old, but that doesn't make us wrong ;)

> Google

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.

Couldn't agree more, been saying this for years. There are moments when an "app-like" experience is what's required - and that's mostly (not always but mostly) when these SPAish approaches are relevant.

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

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

“It depends” never leads to thought leadership, though.

IMO the distinction is simple. You want Google to index your website. You don't want Google to index your webapp.

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.

Yes, sure. If you don't want Google to index your online service, one way to do it is to design the whole thing as an SPA, with all the added complexity and reinvention of the wheel that it involves.

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

It’s literally just headless evergreen chromium handling the rendering these days and has been for a while. It handles JS fine on the condition that you as a developer continue to think about accessibility.

It requires tremendous resources compared to html parser. It's possible, but very costly if you want to crawl the entire Internet.

I was expecting a discussion of native, cross-platform or hybrid apps. Single or multi-page application/site barely registers as a distinction to me like it once did with faster mobile networks and devices.

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.

The distinction is between websites as documents and websites as applications. Both are still websites.

Nah, you should build most apps using operating systems’ native toolkits, and stop trying to pretend web pages are applications.

But then you have to build it three times for desktop and another two times for mobile

Mobile users can just use the web. Clicking a link is much easier than installing yet another app.

The line between app and site is fuzzy IMO. Does cloudflare's documentation reader count as an app or a site? They certainly wrote it as an SPA.

The line between app and site is fuzzy IMO. Does cloudflare's documentation reader count as an app or a site? They certainly wrote it as an SPA. Hackernews seems more like something I would call an app etc.

>Apps, not sites. It’s even in the name, Single Page Application...you should probably build most apps as SPAs.

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?

We had that, remember flash and java applets? Well, it wasn't that great.

Sort of. But, was the problem the principle or the execution? Those "solutions" pre-dated the idea of building robust apps with native Web-idioms (e.g. SPAs). So, they tried to layer on an entirely different non-Web platform, including a completely new, non-browser native UI framework.

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.

Amen, I fondly recall the days when browsers went back to exactly the same page and data that I was on before when I click the back button.

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.

Your first paragraph is money and I don't want to get on a tangent, but I'm curious to know what you think rails is today, if not a thing?

I’m building an “app” using the low-JS approach with HTMX and Alpine (Django back-end) and it seems to give a more hybrid experience.

The problem is that it is not that easy to classify stuff as black or white. Most of the services we use are right in between. What's worse, what starts on one side might evolve to the other as new features are added.

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

What’s the method for determining what counts as a “website” versus a “web app”? For instance, what makes AirBnB or Amazon a “website” but Google an “app”? Are blogs which use SPA frameworks or dynamic routing necessarily “applications” because of the tools they use or can they be classified as a website in spite of them?

> I actually are annoyed by the new Reddit enough to switch to old.reddit.com most of the time when I end up on Reddit. Not sure why. But maybe it tells something,

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.

For people don't know how slow it is. This is a issue I opened 4 month ago and hasn't been answered.

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

I didn't know Firefox had the capability to post performance traces like this!

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.

The resolution is very small anyway, I don't think people would be able to see the title. Besides that, the screenshot (or other track) can be trimmed by just unselect the track when upload the profile. (The default does not contain track of other sites)

Even old.reddit.com is annoying enough that I head first to https://teddit.net/ Principle advantage being that Reddit URLs are rewritten such that once on the site, you stay there. This isn't the case for either old.reddit.com or the even lighter alternative i.reddit.com, for which reverts back to www keep occurring.

> This isn't the case for either old.reddit.com or the even lighter alternative i.reddit.com, for which reverts back to www keep occurring.

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

Trust me, I've tried that. It doesn't work.

Again: teddit.net solves that problem. RELIABLY

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

I'm not sure why it doesn't work for you, but it's been working reliably for me ever since the redesign was introduced.

My hack is to:

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.

YouTube, Facebook, Instagram, and Twitter are the obvious examples from among the top 10 or so most visited websites in the United States.

What is SPA about YouTube? It feels completely MPA to me.

It's an illusion. If you look carefully you'll see that all YT content is loaded dynamically, starting from a blank page with a blank video player.

The only distinction that matters is whether it has a client-side router. If it feels like an MPA, and doesn't feel slow, that can be easy to miss. But it’s still a SPA.

Minimize a video so it's playing in the corner of the browser; notice that the video continues to play seamlessly as you navigate around the site. You can't do that in an MPA right now.

You could in theory do that although the experience would be slightly odd. Either open the video in a new page and put in the bottom right, force focus it after the main window been active. Or wrap the entire websites in two iframes, one for main content and one for video player. Main content can change without interfering with the video player.

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

That s super annoying btw . Frankly video is best browsed like a traditional multi page listing, like how porn sites do it

But pages are difficult on mobile devices.

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

i dont get why they are difficult on mobile? inf scrolling is worse. Especially on android which has a back button everywhere. I think ppl should be more mindful of the megabytes of javascript that people have to download just to see a list of images

I have a redirect set up for shorts to redirect me onto a normal site. As youtube loads the content dynamically, then sets the URL it doesn't work unless I open the short in a new tab or do a f5.

Seems SPA to me.

If it feels completely MPA to you - then they pulled off their SPA implementation :)

When an SPA feels snappy enough/works well enough that you confuse it for an MPA, it means they are probably doing it right.

This is such an interesting inversion. IIRC, one of the original arguments for SPAs was that they would be so much quicker than MPAs because they don't reload the entire page on every action. Now it seems like we've come full circle and SPAs are considered to be done well when they can achieve the speed and feel of an MPA!

Also maintaining fullscreen play during video changes (playlists) is only possible in SPAs. In an MPA, every page re-render would require user interaction to go back into fullscreen again.

I think new Reddit is intentionally terrible, and incorporates SPA attributes, purely to make the experience unpleasant and drive app usage. They offer old.Reddit.com so that some core users don't leave, but those users might not be needed forever, if a different user base can be cultivated.

I've been developing SPAs as an independent contractor for over 8 years, and not a single of those SPAs is public facing - they are all enterprise line-of-business apps used internally. Sometimes I wondered how employing a team of 10-15 developers to develop an SPA for 1-2years (plus maintenance) is profitable, if your targeted user audience is 2,000-3,000 internal employees of that business.

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.

I have worked on similar projects in finance, where various regulatory requirements prevent using adhoc internal tools.

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.

GitHub is definitely not an MPA. Or at least most of the core functionality people use for work isn’t. It feels like one under ideal network conditions, but if your connection stalls you can see its routing stall before any attempt to load a new page.

Github is a Rails app, and leverages Turbolinks which does partial page renders (but still keeps routing server-side)

GitHub is an MPA Rails app that uses turbolinks to make page transitions quicker, which is what you’re seeing stall. No routing is done client side.

Navigations within the same repo are powered by client side routings (e.g. from "Code" tab to "Issue" tab).

No? I'm looking at the request in webinspector right now. GitHub is kicking back the full partial for the issues tab, and turbolinks JS is then swapping out the relevant DIVs -- it's a bog-standard Rails MPA server side routed setup, I think you're just letting the turbolinks animation convince you there's more happening on the frontend than really is.

You are right. It wasn't client side routing.

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

Ah, AFAIK that's not actually theirs but: https://github.com/defunkt/jquery-pjax (although I guess they rewrote it in TS, unless that's a different project floating around?), from which Turbolinks took its inspiration as a Rails-native built in solution. Presumably GitHub never saw any reason to rewrite for Turbolinks when the latter appeared.

> AFAIK that's not actually theirs but: https://github.com/defunkt/jquery-pjax

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

> "id": 2

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

huh, TIL

Github uses something called View Component to render 'partials' (aka components) which is a bit more sophisticated than just Turbolinks and IMO the future of complex web apps

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/

Eh, we use ViewComponents inhouse at work too, and they're great, but they're really just a better way of approaching partials instead of the normal "grab the Controller's ivars" free-for-all -- they don't move the needle any on the MPA front, and they change nothing w.r.t turbolinks (or any client side JS), since they're purely a server-side rendering time thing.

I'm more interested in the concept of ViewComponents than just the current library. It's really just starting with Rails adopting ActionCable and Phoenix using LiveView (which I see as both immature proto-concepts of the future of JS frontends).

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.

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

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.

The best apps seem to be fully MPA or SPA. The hybrids have UX problems. It's arbitrary some things require a hard page navigation, and others don't. I mean, it's probably an intersection between product/engineering teams, but as a user of an application, I have no real visibility into that nor concern for it; I just see the dichotomy.

Old.Reddit.com does some kind of page-reload every time you navigate back to the subreddit from a comments page. Incredibly annoying and makes Hacker News feel blazing fast by comparison.

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?

I do not know how to stop it and I hate it so much.

Replace the button you click with

    history.back()

with tampermonkey?

when you go to some page and it downloads 10MB of javascript for starters, proceeds to show you spinning wheels for 9 seconds (sometimes with original messages such as " time to take the world"), then when it loads it jumps around for 12 seconds while the images are absolutely destroying the layout of the page, then it beeps some chat asks you if you would like help, but the only help you need is to dismiss so many popups ? ... that one.

Was AirBnB not one of the first companies to champion server-side rendering of React apps? I think you’re listing apps that are actually a bunch of SPAs glued together (each page is super complex and an SPA of its own right).

On AirBnB, you search for a location on the homepage and then you go to a new page, the map page. Which is a bit SPAish because it reloads apartments when you move the map. Then when you click on an apartment, you go to a new page, the apartment page.

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.

Hum...

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

It wasn't React, but Spike Brehm gave a lot of talks about Airbnb moving to "isomorphic JavaScript" with a library he created. It was called Rendr and it basically let you stitch together Backbone and Node and share code between the client and the server.

I remember being pretty interested in it at the time.

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

Ah yes, before React even!

Lever was doing this in 2014 with DerbyJS.

AirBnB was doing it in 2013 (or earlier): https://news.ycombinator.com/item?id=31459699

For me it's not so much about the technical merits of SPA vs MPA its the annoyance of having all the stuff that used to be backend now part of frontend.

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.

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

What does TS have to do with SPA/MPA?

… and why is “learning” in quotes?

Airbnb is not a SPA in the sense that it's a _single_ page, but the main pages of the site contain a lot of interactivity, and IMO individually constitute at least mini-SPAs.

>Where are those SPAs everybody is talking about?

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.

I don't think the opposite of single-page app is multi-page app. The opposite is not an app at all, it is a "webpage". My viewpoint here: https://notan.app/

Monday.com, Google Docs, Trello.

6groups.com (PWA) is an SPA I am developing from scratch, no frameworks involved. It performs really well vs its native Android counterpart

Gmail

It's called "applications" because it's not "sites". Slack, Gmail, etc.

Airbnb is really a hybrid. For example, the property page is really an spa on its own.

Visual Studio Code, Spotify, Slack.

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

Well, Udacity is 90% SPA (React) and it's a content/page driven site.

Facebook, Twitter.

Reply on news.ycombinator.com