Hello folks and welcome to round 678 of the Least Interesting Conversation on the internet. SPAs are great when they're necessary and MPAs are great at what they do too. Thanks for tuning in, the series stands at 678 ties, see you again tomorrow for rounds 679, 680, and 681.
The post wasn't about "which is better, SPAs or MPAs". It was specifically "what has changed in the last few years that now make MPAs able to handle things that they couldn't before". I for one learned from this post since I don't keep up with the current state of browser implementations of various features, nor with the consequences of these features.
I disagree, the post is itself a waste of time and energy because this is a problem that basically nobody cares about or is even aware of. It's not a real problem.
> this is a problem that basically nobody cares about or is even aware of
"Basically nobody" as a percentage of the global population? That's fine and as it should be. "Basically nobody" as a percentage of web developers? I strongly doubt that this is the case; but if it is, it is damnatory of our profession.
Because it is a useless answer. You don't answer "what is the best tool for the job at hand that matches my team and budget" by "use the best tool for the job at hand that matches your team and budget".
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.
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.
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.
> 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.
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.
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.
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
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.
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..
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.
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".
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
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`.
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.
>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?
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.
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.
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.
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.
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.
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)
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.
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.
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?
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.
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.
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.
> 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.
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.
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.
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
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 :)
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.
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.
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.
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.
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
> 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.
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).
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.
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.
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?
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).
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.
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.
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.
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.
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.
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/
Author of Elder.js (mentioned in the article) and avid lover of both MPA and SPA.
Daily I am writing MPAs for SEO assets and SPAs for internal dashboards used to manage the huge amount if data collection our teams do.
It really boils down to what you are building.
Google is decidedly terrible about indexing JS for sites with a low crawl budget. Why make your life harder. That is why I wrote Elder.js. Statically generate everything, sprinkle in interactivity where needed.
But for internal dashboards I developed a internal framework to spit out crud apps based on nothing more than a couple graphql queries and a couple yupjs validations. It is a breeze and adding new data collection fields takes minutes so I and my team can focus on stuff that drives business value… instead of crud.
As with everything picking the right tool for the job makes the job a lot easier. Don’t give into the hype one way or another.
They touch on it at the end but I think it is under-appreciated ... the big benefit of a SPA is continuity of client side state. I don't actually care whether it's one page or ten but it does simplify things enormously that I can maintain a single model object and not have to persist it in and out of local storage or even worse have all the complex UI state replicated on the server side to maintain continuity, just because the user clicked a button or something. Especially with reactive frameworks where updating the model automatically triggers re-rendering of the UI everywhere it needs to, a whole piece of complexity in your architecture just goes away.
I actually see having to manage client side state as one of SPAs' greatest downsides. You're literally doubling the complexity of your application. Now you have to maintain state on both the server and the client and it becomes a great effort to make sure they don't get out of sync.
The way I see it, the state of an application resides in the server, more specifically, the database. Let's keep it there.
If your UI is rendered on the server, then your UI state remains on the server. It just ferries that state to the client. There's no synchronization involved because it's synchronized by default.
The new way is html over the wire e.g. Hotwire, Liveview, htmx. So instead of the page being reloaded, the section of the UI that needs to updated is rendered on the server and sent over via websocket.
Not in my experience. I've worked on several react apps. Currently doing a Hotwire project and it's just so much simpler to keep all state on the server side.
Liveview: it sends event to server and the server handle the event, then send "diff" to client (and automatically patch the dom) .. all of these via websocket, it's fast.
No they don’t, they use web forms, which are a local UI state that gets bundled up and sent when the user presses a submit button. They do not refresh on every single UI change
Well, ok, if you're thinking of UI state in that way, you're right. I was thinking of UI state in terms of how it's stored and manipulated in client-side JS.
To your original question, my proposal is that html over the wire provides a good solution without the need for state to reside and change in client JS.
But the application is embedded in a browser. Are you saying it's fine to bin all that UI state the moment the user performs a totally normal interaction with their browser? Accidentally hitting back or refresh in a complex SPA and losing the state of the application is one of the most frustrating experiences on the web, right behind trying to hit back or refresh intentionally and being blocked because the SPA overrides those functions.
No? I simply clarified which state op was referring to. The state of the browser is separate to what's being discussed. SPA's can be good at some state and not others.
I build internal apps for my clients and this ship has sailed. They love the interactivity and quickness of a SPA. For a while I was doing application per page type of apps and it worked fine. But honestly maintenance has become a lot easier just making it a SPA. I have no idea why I'd go back to having to maintain a JS entry point per page instead of just one for no benefit whatsoever.
Reading HN you'd think 99% of development is landing pages and blogs. Maybe it is? lol. But I have a feeling many here develop a lot more sophisticated applications including but definitely not limited to data analysis, charting, workflows and business processes, statistical analysis, optimization, and having a reload on every little operation makes things significantly slower from a user experience perspective.
You should take a look at the frameworks mentioned in the article. They each address some or all of your concerns. The distinction here isn’t going back to “old school” MPA development, but a trend in component frameworks towards shipping more truly static HTML and less unnecessary JS.
For the landing page/blog type experience, Astro is a great fit. Qwik is probably a better fit for your use cases as it’s intended for more interactive apps. But both can span that interactivity spectrum. I can’t speak to where Elder fits on that spectrum, not having used it and having little experience with Svelte.
I’m disappointed not to see Marko mentioned, as it’s been in this category for years and used at scale at eBay. It fits very well in the middle of the interactivity spectrum.
Anyway, it’s worth checking all of them out just to even see what’s happening in the ecosystem. I’m personally very interested in Qwik‘s familiar React-like DX with what they call “resumability”: their alternative to hydration; components compile to fine grained chunks and resume from state serialized to HTML, rather than re-running the original component on load.
No, they shouldn't look at some of the frameworks. They're all more complex than just making a bog standard SPA, which seems to be working fine for them. People need to stop bringing in that complexity when they don't need server rendering.
This is basic software engineering shit, and it boggles me that the industry can't get it right. Same kind of code goes in the same place and runs in the same context unless you specifically need to do otherwise. No reason not to route and render on either the client or the server unless you absolutely need both.
Trying to get fancy is how you end up with a truckload of bugs you wouldn't have otherwise had. I've been on like 5 projects that have spent months dicking around with Next or Nuxt or Gatsby or whatever rubbish, lighting client money on fire, for a portal behind a login that doesn't need to be indexed and would work totally fine as an SPA.
> No, they shouldn't look at some of the frameworks. They're all more complex than just making a bog standard SPA, which seems to be working fine for them.
Should was probably too strongly phrased, shouldn’t definitely is. The suggestion wasn’t “hey go learn a new framework, your current solution isn’t up to date” or whatever. It was really, very sincerely, “the frameworks discussed in article agree with you, you oughta keep an open mind”. Encouraging both a general, and clear area of interest, spirit of curiosity.
I don’t get the sense that you have or want that curiosity on the topic, by all means stick with what’s working and carry on.
If your comment was paired with downvote, I do want to thank you for the comment. It’s refreshing to get a perspective on why someone didn’t like something I said, when I wouldn’t have that insight otherwise.
I've been mixing React with static exports from WordPress. It's unbelievable to say that I actually like this solution after spending years and years with PHP, custom JS front ends, then jQuery and the backend frameworks.
React continues to get better and is great for highly interactive and customized experiences. Browsers are also making it more usable so it's just up to the front end devs to make sure history state and other stuff is accounted for.
WordPress continues to be terrible but accessible to the masses for your landing page and blog stuff. That means your design and content team don't get bogged down in the app dev process and you don't have React slinging fixed/static content. They can just bash stuff around in WordPress and export the static pages for a quick deploy.
The Simply Static[0] plug-in exports all of your WordPress pages and assets into a directory that you can deploy. It basically renders the entire site and takes a snapshot of the rendered HTML.
You'll lose dynamic features (but ideally you'll be doing that stuff in your React app) but the static site is very quick and you'll avoid some of the security headaches of a public WordPress instance.
This is where I think the confusion lies. When I think of the tools that my teams build, they effectively are internal and external tools that happen to use the browser as a platform because nobody was able to converge on a universally-installed tool like java web start. Web applications proliferate because it entirely circumvented the problems of installing software.
The places people are most enamored with SPAs are tools that effectively replace desktop applications. Consider Jira or Trello. These are effectively applications that happen to live in the browser. If you built progressive enhancement on trello, it would effectively mean building a parallel application.
Multiple page applications do not have the ecosystem to make these tools easier to build. I have built these applications before SPAs became the dominant modality and after. The MPA has a long way to go to make this a good experience.
Now I think it's great that content apps are moving away from SPAs. I think the only reason that people did this was to avoid the white flash, frankly, and I'm glad that chrome has solved this. I hope nobody is using react to build their content in 2022.
However, we have a long way to go before MPAs could replace SPAs in web applications. (And frankly, that time would have been better spent in building a tool that is truly fit for purpose rather than overloading the browser DOM, but I fear that ship has sailed.)
I think there is a mismatch between the types of web content that the general public most interacts with and the types of web content which tend to have lots of development resources devoted to them. The ratio of SWEs to users is much, much higher for niche (typically B2B or internal business line) applications, which often require a fair amount of interactivity and custom logic. Whereas the vast majority of random web content used by the general public probably can just be hosted as static sites or server-side rendered apps with better performance and lower cost. HN then just reflects the underlying demographics of the industry and has a disproportionate number of people who work on niche applications where SPAs are still the more appropriate tool.
Which makes sense given the economics. Consumer facing content is generally free to users and funded by ads so the dev costs need to be amortized across more content, which tends toward a lower touch, more scalable approach like static pages where there isn’t much if any custom logic on any given page of content. Businesses on the other hand are willing to fork over cash directly to solve their problems so you get higher touch, more custom solutions where SPAs are relatively more useful.
Also software engineering by its very nature automates routine tasks, reducing their costs and manual complexity dramatically over time to the point that a SWE isn’t needed to carry them out. So none of us work on static sites because at this point it doesn’t take a highly skilled engineer to set up, host, and scale one. One day SPAs and cloud native and k8s and all the latest fads may reach the same level of simplicity, and we will all be working on tuning hyper parameters on ML models or whatever else becomes the de facto cutting edge for the field.
I mean why wouldn’t you? Degenerate React — a mostly static content “chrome” replacing the “layout.html.erb” and a component to render content from an API based entirely on the route replacing “article.html.erb” still is way faster than your average site. Slower then the equivalent SSR but ehh.
The grand parent comment is likely referring to ‘deep web’ apps that you or I will never see, which probably replace a series of excel spreadsheets and email conversations.
Most of the web is content, but websites rarely are SPAs. If you only consume content you would hardly know about the concept of SPAs.
I think it's weird to compare websites with web apps. Instead web apps should be compared to desktop applications. So many applications in the corporates have been replaced by web apps. In the company I work for there are 0 "desktop" applications other than Office, and even those applications you can use using a web browser. Then you see a massive shift and that balance is not shifting away at all.
If your non-spa app requires a page load per an operation, my opinion is someone built it wrong. You can do a lot with < 200 lines of JS to make a page interactive.
Legacy apps were rebuilt as SPAs and rebuilding them made them faster.
"Spinning wheel of doom" is used by users now to describe delays in both SPA and non-spa web applications. Same tricks to make a SPA feel responsive work for both styles.
In 200 lines of JS, you can add maybe an interactive file uploader, or a tooltip implementation, and some form validation. But good luck doing anything of "business-tool" complexity in 200 lines that constitutes an application.
Not really. IMO, people are using large dependencies for things that can be implemented with a few lines of JS or even no JS at all. Doing things for the sake of complexity. The whole point is that X, Y and Z aren't needed.
What is the point? Optimizing for lines of code is a wasteful target. I thought we all knew that by now? Great that you can demonstrate that you can do something without React where others are using React, but that's not the point at all.
If you do more than a few asynchronous calls you will quickly find yourself developing your own DOM abstraction. That's a waste of time because React and Vue already exist, and have existed for years, and are battle tested.
SPA frameworks also give you the ability to write your applications in a declarative way, which is _far_ easier and way less error prone, thus easier to test, than imperative DOM modifications.
Its more like the time to become interactive. Even if internet and smarphones are fast. Sometimes it's pretty annoying to click an unresponsive page... just because it's loading-starting a lot of js
I relate to this so hard. It's hard to know what other people work on, but I haven't worked on a web site in over a decade, and it's just honestly hard for me to relate to people who can't understand the user experience benefits of within-page interactivity.
Are you sure that something like PJAX wouldn't bring you like 80% along the way from MPAs to SPAs, as far as "interactivity and quickness" is concerned? Or did you already try that?
Accessibility has nothing to do whether your page is cut up in one way or another. You can build accessible pages that are SPA and unaccessible pages in any other way all the same. Most if not all accessibility issues stem from lack of education on the matter, rather than technical limitations.
Agreed. One of our employees is visually impaired, and it is shocking how many Spas are entirely incompatible with a screen reader and standard keyboard nav. With a MPA, most of the things that a screenreader needs come for 'free' just by being standard components. When everything is wrapped in JS and is slightly different for each page, it's frustrating.
We have changed quite a bit of our software systems in the past 1.5 years, and I have dropped multiple vendors from consideration over accessibility. Many B2B SaaS salespeople just give you a blank look if you ask about usability for a blind user.
SPAs reimplement accessibility features in JavaScript to the best of their ability. This has created an arms race where screen readers need to execute JavaScript and use heuristics to determine what's on the a page.
I worked at a large tech company replacing an internal MPA website with a SPA replacement. The MPA website was built in the 2000s, it was unmaintainable, and it was generally duct-taped together. The SPA website was new, shiny, and build on the hottest technologies at the time. But screen readers had a hard time understanding the SPA. Where the MPA favored simplicity and used <select> elements for its dropdowns, the SPA used a custom component that consisted of <div> soup with some JS. It took considerable effort to make the SPA friendly to screen readers.
I'm not convinced that the SPA architecture was the source of the problem. A MPA with <div> soup everywhere would have had the same problem. However, these sorts of issues seem to be more common in SPA than MPA. There might be some correlation between using SPA architecture and reckless overindulgence.
Every mainstream desktop ui framework out there has standard, evolving out-of-box set of controls and layout widgets that do not suck. Guess what, you can build Gtk, Qt or Wx app without wrapping inputs into stacks of divs, which aren’t there for layout. People even barely know how to create new controls or containers. The deepest container depth for a regular app is like 5-7 there, and that’s a complex layout already with bells and whistles. Web does suck a lot in this regard, so people reimplement this functionality in javascript and div soup, as the other commenter mentioned. While your statement is true, the idiots here are the web standards which stuck in 1990s and never realized that this “apps” thing everyone’s running around with for a decade or soon two is something more than a printable document with font sizes and empty fields split into sections and paragraphs. If web did care, it would at least add accessibility-only tags (or a separate structure like css does) denoting what’s where and how to interact with it or how to dumb it down to whatever plain set of controls would be there, if the web ui model didn’t suck. The stockholm syndrome it induced in software development is truly tremendous.
I've spent the last 2 years building B2B SPAs and, like everything in software, they can be fast or slow depending on how you build the app and what tools you use. I usually leverage lit-html, esmodules, and the dynamic import syntax. If you only fetch the business logic and views when you need them you can have an app that renders in seconds with an initial payload of ~15kb.
I usually also set up a service worker to prefetch and cache the rest of the site while cache busting specific files on subsequent visits.
Personally I use SPAs for offline support and MPAs for "portals" and brochure/marketing websites or blogs.
Oh geese, I didn't realize that I forgot to add "on slow-3g". We usually aim for <1s FCP & <2s LCP. If it's ever above 5s on slow-3g we set aside time to optimize/refactor. Since our SPAs are offline-first the return visits (usually 3-5 times a day based on the customer) is on the scale of milliseconds.
I feel like we're just spinning in circles trying to define "fast" and what speeds are "acceptable" when the main point was:
> SPAs for offline support and MPAs for everything else
You could build MPAs that offer offline support (and I have) but I find that you spend a lot of time writing the same render logic twice. Things might be different now with Next/Nuxt but when you're using PHP or C# it sucks to write the view render logic twice.
Prefetching content means you can literally load a new page instantly without rendering anything but the new content. It is inherently faster once the initial page has loaded, and the JS no longer needs to be all that large to accomplish it.
Like any technology, using it in the right place helps. This is great for documentation where the template and content slots are super consistent, for example.
There are places it’s not a great choice. It isn’t inherently worse, though.
This is the theory, and yet in practice my experience is almost always the opposite: MPAs load and render quickly and are responsive during use, SPAs are slow to load and render and often chug substantially. Some of the better SPA manage to beat mediocre MPA implementations, but it's not super common. I don't know how it so frequently gets screwed up so badly, but it's a really consistent trend (and this is across fast desktops with a good internet connection to mobile devices with not-so-great signal). For example, hacker news is way, way more usable to me than new reddit (which actually renders my browser unusable on a high end machine after some use).
The impedance mismatch always seems to boil down to the fact that we have been told umpteen million times that most people end up on your website with a nearly completely evicted cache, and we (or at least, the people who resist) don't seem to believe it.
This is pretty much the default and a given for everyone who visits your site... except you. As the author, you likely use your application more than most users, you use it on a work machine (which has a smaller, more niche browser history), and you use it with the sort of network connection that software developers demand: you know, excessive.
We see what we expect to see, what we want to see, and most of us don't challenge that, or only do it perfunctorily. And if someone else does? Well that's just crazy talk. See? Everything is fine.
Our B2B SaaS apps are SPA and preload static assets in the background on the login screen, including the top 90% of used js, templates, and icons (simple to find via http log analysis). This improves the end-user perception of performance dramatically.
Accessibility with said SPAs is still a pain though. Even when you use correct semantic elements instead of DIV soup, the DOM usable by screen readers changes “out-of-order” frequently in SPAs, requiring lots of extra work to ensure an accessible experience.
> Blog posts are making the rounds listing all the challenges with SPAs: history, focus management, scroll restoration, Cmd/Ctrl-click, memory leaks, etc.
I guess? Like, who is implementing all this BS themselves? Every time I've written a SPA, my framework and/or routing library handled all this crap for me. None of these "challenges" were ever problems for me, and this sounds like another case of programmers creating an issue where there actually isn't one.
If you use a proper framework or routing library that changes the history state of the URL, it's pretty much impossible for users to tell whether something is a SPA or an "MPA". So who cares?
And yet, a large portion of big websites using SPAs don't seem to have functioning back buttons. If a billion dollar company can't get it to work properly I doubt anyone else can.
Back buttons in web apps are hard regardless of SPA or MPA.
I've seen many MPAs fail, for example after checkouts or form submissions.
The problem is just more prominent with SPAs because they usually feature more complicated navigation.
Perhaps for privacy reasons, you don't get much control over the built in history: you can push, replace and pop.
Maybe you could implement your own history, but then you need to somehow keep that in sync with the browser.
If someone knows a good approach, I'd be interested.
Discussions about website architecture become a lot more productive when you use Jason Miller's holotypes idea [1] as your starting point. "Holotypes" is kinda just a fancy word for the common top-level uses of the web. E-commerce, search, media player, etc. With that foundation it becomes obvious that SPAs make a lot of sense for some holotypes and a lot less sense for others. We waste time when we talk as if MPA or SPA is appropriate for all website architectures because neither are and never will be. The uses of the web are just too broad at this point.
I'm generally opposed to jargon in tech writing so the use of 'holotype' caused me to look it up. I'm not sure it works. For example, by the definition Hotmail should be the holotype instead of GMail, which would be the paratype. (if I'm reading it right, I am not a zoologist.)
Something rubs me the wrong way about unnecessarily obfuscated jargon for relatively simple concepts in web development. The term "isomorphic code" has been living rent free in my head for like a decade and it still drives me nuts.
I've always felt that DDD is more of a meta-paradigm than a paradigm per-se, and shops that "arrive" at it have actually always been themselves examples of the practice in itself, as opposed to being instances of itself.
The goofy thing is how quickly that term fell out of the vernacular, and how few people (other than you) even stop to be amazed at the ridiculousness of it all in hindsight.
At the time, it seemed rather earth-shattering to be programming in the same language on both the front-end and the back-end without a browser plug-in or applet. The possibilities such an arrangement opened up seemed potentially vast.
Up until that point, it had been a basic assumption that the front-end and back-end had to be done in different languages if you wanted a site/app above a certain quality threshold (though Java applets and Silverlight (C#) had previously provided a way to run the same language on the front and back ends).
I didn't find it ridiculous. There were real, tangible benefits, like sharing the same validation code on the frontend and backend. Would I make it the sole reason to choose a given language? No, but there was demonstrable efficiency to it.
> by the definition Hotmail should be the holotype instead of GMail, which would be the paratype
I think in this particular case the term "holotype" is being overloaded; it means both "general category of applications" and "what this author takes to be the canonical application in that category". I don't think an exact parallel to the zoological usage is intended.
For sure it's a terrible name (sorry, Jason ;P). In my other comment I talk about my experiences pitching this idea when I was https://web.dev content lead. There's something about this word that is an immediate turnoff and prevents people from really looking deeply at it. Which is a shame because it's such a useful mental model.
Could archetype/al/ical (or possibly prototypal) have been used instead? Both have associations with artefacts (usually authored and manufactured, respectively) rather than gathered specimens.
Sometimes when going deep into a subject I have to pause and explain that it’s a very specific name for what we are talking about and while it may seem pedantic, Naming Things Is Actually Incredibly Important. IMO naming things properly is at least 25% of a good system design.
I’d recommend anyone who’s posted for/against some web practice to read it.
Maybe one day we could all collectively acknowledge that people work on different stuff, with different goals and under different constraints, and there isn’t actually one right way to build for the web. It’s such a tiresome part of HN.
I don't believe that (all of) the people who get frustrated by these things don't understand that different problems require different solutions, it's when the majority of the industry (or more likely an influential minority) starts to say, "Hey! Let's build EVERYTHING this way" that that people start to complain. And I say this is warranted as it affects the job market. SPAs have their place (highly interactive applications that more closely mirror traditional desktops apps, I would say, the main one) but so many companies out there are developing their apps as SPAs that have no business being such and some of us would rather not have to deal with that (I've experienced this first hand).
The other side (or one other side) of the coin, of course, is that our industry is super new and we're all still figuring it out. I always liken out industry to thinking about how long it took to standardize the hammer design we have to day. I don't have the exact stats, but I'm thinking it was probably 100s of years and our ancestors had many a fight over a big rock vs a plank with a bit small bit of steel on the end of it being the better choice.
Yes, just like _____ written in [Go|Rust|flavoflav].
However, at the beginning of every project, this conversation should be had. What are the needs of the project, what gets us there fast while still allowing to grow after scopecreep, what is going to allow for maintanence and future needs?
Picking the latest tech just because it's a new project and you want to use the NEW on it just for the sake of it will probably mean finding yourself painted in a corner in the future (or maybe not the original dev, but those that are forced to follow).
Of course, a discussion should be had, choices should be weighed.
But since you mentioned “new just for the sake of it” I’ll mention that I think that’s overplayed, too. If you picked React when it was new, or GraphQL, or NextJS, then you probably made a pretty good choice. Backbone was the first of the modern MVC frameworks to get traction (someone will correct me on this) and if you’d chosen that when it was new it would also have been a pretty good decision. Kafka’s still around and going strong, wouldn’t have been a bad choice early-on.
Thanks for the link, it is an interesting and obvious way to have clearer conversations.
Multiple types have a recommendation to use "turbolinks-style transitions", which was new to me. So I did some research, and it's basically another take on "just render html server-side, and let a framework take care of AJAX-ifying it". I've seen some attempts at this before, like the UpdatePanel's from ASP.Net Web Forms back in the 2000's.
It looks like Turbolinks itself is defunct, but has been superseded by Turbo (https://github.com/hotwired/turbo), and I only see chatter in Rails communities. It also looks like there are some other alternatives.
Are people actually using "turbolinks-style transitions"? And if so, what are you using how is it working out for you?
I think it's also relevant to mention that I spent a lot of time thinking about whether web developers at large should use SPAs or MPAs. It'll take a bit of my history to explain.
I was content lead for https://web.dev from 2019 to 2021. My job was to create and execute the content strategy of the site. The mission of that site was [1] to provide actionable insights on how to build better websites. But the big challenge is how do you provide guidance for the web at large?? We know through MDN surveys, HN discussions, Twitter, etc. that many web developers are drowning in uncertainty around how to architect their website. Which framework to use is a key uncertainty. MPA or SPA is another one. So to me this was the obvious opportunity for https://web.dev. Help web developers make better architecture decisions and the overall web experience is bound to get better. But if you've seen web developers talk on Twitter you know that these are landmine topics. If you don't handle it extremely delicately and respectfully and fairly you are setting yourself up for a tsunami of vitriol. This is 10x true for anything that the browser vendors do or say (a lot of Googlers work on https://web.dev).
So here's where holotypes comes in. When I read holotypes I see a very useful framework for understanding website architecture. And it provides a way to logically/fairly recommend SPAs or MPAs. The answer is that it depends on your use case. If you're building a content-heavy, interaction-minimal site like Wikipedia then no duh an MPA is probably the right call. If you're building a media player like Spotify though then a SPA makes a lot more sense. You can use the same logic to figure out which framework is probably best for you.
So going back to my personal history. I pitched holotypes as the overarching information architecture [2] for https://web.dev. It didn't really go anywhere. The main reason was that I was just too green as a leader/manager to push through a big change like this (or I'm just not a very effective leader/manager in general). I still think holotypes is a phenomenal way to think about website architecture and I'm honestly sharing all this to encourage someone to carry the torch and create a website that guides you through which website architecture (and framework) to use based on your holotype. Happy to chat with anyone about it further just poke around on my HN profile page to figure out how to contact me.
Also hopefully it goes without saying that this is all just my personal opinion/experience and doesn't represent Google. I'm not even working on the web anymore. Working on Web DevRel for Google or any of the other browser vendors is very delicate work and to all my former colleagues I hope I shared the history respectfully/accurately. My intention here is to share a key idea on how to make the web better (help web developers make better architecture decisions) that I'm never going to personally pursue. If you do this "guiding architecture decisions based on holotypes" idea right it doesn't really matter who "owns" this because all of the decision weighting logic/data will have to be rigorously fair/balanced/open or else it will never take off because one of the vested interests in the web developer ecosystem will mount a campaign to discredit it.
[1] It probably still has the same mission. I'm only saying "was" because I'm no longer on the project. I quit Google in June 2021 for a sabbatical and returned last week working on something very different, Fuchsia!
> It probably still has the same mission. I'm only saying "was" because I'm no longer on the project. I quit Google in June 2021 for a sabbatical and returned last week working on something very different, Fuchsia!
I don't know your background, but this sort of discussion predates the web by quite a bit, though the labels, affordances, and other factors change considerably due to spatial versus temporal constraints.
In HCI (and later on, usability) circles, these were the Multi Document Interface, Single Document Interface, Tabbed Document Interface, and (largely informally) IDE interface debates: https://en.m.wikipedia.org/wiki/Multiple-document_interface
In fact during the days of the early web, quite a lot of experimentation and development was done on making browser windows (especially chromeless ones) participate more fully in the desktop environment as objects such as floating toolbars and widgets. Other efforts were focused on expanding the browser to displace the desktop OS (eg. the Netscape "webtop", or more recently, Chrome Apps).
The details of the pro vs con arguments aren't exactly repeated, but like history, they certainly rhyme, and are similarly affected quite deeply by the capabilities and defaults of the underlying platform, like whether the desktop environment has a global menu bar.
I also think that with today’s choices of web technology, separating solutions by “holotypes” is the correct thing to do. But on non-web platforms there is no such choice, yet every holotype has a place. Sure, other platforms has sometimes different requirements, but I do believe that ideally there should be a single unifying way for both kind of webpages/applications.
Have you considered adding a “business app” category? Thinking of things like CRMs and learning management systems. Maybe Salesforce would be the holotype?
the balance should come from the business requirement, not something as top-down as if the frontend development works like physics that it has some intrinsic principles to drive into a destined more advanced stage.
this is most likely not true and drunken kruger syndrome
Running it on the desktop is far inferior, because a great advantage of QBO is the ability for several people, distributed worldwide, to work on the same account at the same time.
> Running it on the desktop is far inferior, because a great advantage of QBO is the ability for several people, distributed worldwide, to work on the same account at the same time.
Is there any reason the desktop version couldn’t do that if Intuit wanted it to?
(I imagine they just artificially limit it to encourage customers to ditch indefinite license purchases in favor of monthly SaaSS subscriptions, ie. it has little to do with technical advantages of the web and much to do with the profit advantages of software that stays on Intuit’s servers.)
Neither the users or the providers want or care about some desktop p2p/self hosted accounting software. It’s an advantage of offload the risk and accountability.
I think there is also some circular logic when looking at the pricing models for SaaS products. Customers use them because they are the best, but they are very likely the best because they have constant revenue from subscriptions.
So maybe you paid $100 for photoshop and used it for 3 years but now you pay $10/month for photoshop which is more expensive but that’s all more money going in to the product. And with a business tool, the better it is, the more money users make using it. So it’s worth paying more for a better product.
Though I must say, for my small non-profit, the $650/yr for QBO is rather stiff. I only stay with it because I know I’ll be able to find a replacement accountant who understands it. As opposed to, say, gnucash or ledger.
>Is there any reason the desktop version couldn’t do that
There is no reason any experience cannot be replicated on any computing device, barring hardware limitations.
There may however be reasons why things are easier done with one architecture than another, and there may be business reasons (not necessarily of benefit to the consumer) why a particular way of doing things will be preferred, and sometimes it will just be because the people who have been tasked with making something are comfortable making it one way and that is the way they will start because - as we are often told on sites like HN - when making something go with what you know if your purpose is to ship.
What would you suggest? Would it be like Valheim (any many other games) where if you want to collaborate, one person needs to be the host and run their copy of the app and if they aren't running it no one can work?
Or are you suggesting the average user would some how spin up a server and run some software and maintain that server so that all the collaborators can access the thing 24/7?
Me, I love that from any of my 7 machines I can access my docs, spreadsheets, tax info, etc. If I have to use a native app then I can only access it on machines that have that app installed. The app might not even exist on some of the machines I use but a web browser does.
As far as I could ever tell the desktop version of QuickBooks was only some sort of Electron or WebView wrapper around the site. Not knocking it - it worked fine. But that was the main reason I was surprised when they End of Life’d the desktop version.
Yup same with Google Docs. And there are plenty of other SPAs like Google Maps that just work so well that way, that it's hard to see the argument for banning them.
100% agree, and people are have been slowly figuring that out. The front runners were the mobile App folks. But it’s going to take awhile for the tide to turn fully again.
I’m curious if Java desktop is going to make a resurgence, or something else will. Platform native Windows dev never really died, but the market definitely shrunk.
Our web product went from AngularJS to React to Angular to Angular + Spring. The addition of Spring helped us introduce a useful constraint: if you can build it as an old-school page with Spring, don't put it into the SPA. Angular is reserved for deep core business logic and UI which would be impractical to build anywhere else. One of the biggest benefits is reducing our Angular project complexity, making it easier to keep current with Angular updates. I am happy to hear that SPAs are no longer sexy because this sounds like the landscape has matured. For example, Angular started doing LTS releases.
You invented a problem. SPA team and Spring team have separate responsibilities. Our customers don’t care how it looks beyond ergonomics and functionality. It took us a long time to shift away from “SPA all the things” mentality.
As someone who works on design systems, I struggle with the concept of consistency in MPA's. If every team has their own tech stack, you'll inevitably end up with multiple ways of rendering HTML: Java/JSP, Ruby/ERB, etc. It's only easy to SSR React in NodeJS.
If all the teams use client-side rendering, I can ship the design system as an NPM package of React components, and you can use tools like Storybook to run visual regression tests without standing up your full environment.
I know I'm speaking tactically here, but a shift away from SPAs seems like a loss for shared UI components and design consistency. I can't just give a CSS file (which is portable across tech stacks) and leave it to engineers to write accessible HTML; there's huge value-add in isolating a11y in something like a React component abstraction.
> I struggle with the concept of consistency in MPA's. If every team has their own tech stack, you'll inevitably end up with multiple ways of rendering HTML: Java/JSP, Ruby/ERB, etc. It's only easy to SSR React in NodeJS. If all the teams use client-side rendering, I can ship the design system as an NPM package of React components
That's true, but if your various teams are allowed to use various server-side programming languages and frameworks, what's to say they're not allowed to use various client-side frameworks as well? E.g. one team uses Angular, the other React, the other Vue, etc. Then you're back to having the same problem.
I get it, there's a sort of lowest-common-denominator argument going on here, but it is still an enforced consistency which ignores the benefits of giving teams the freedom to choose the best tool for their specific job.
You end up with a Frankenstein application where different product areas feel like they were built by entirely different companies. There's a real price to giving that much autonomy to each development team. You want teams to be empowered, but there has to be ground rules. Having to unwind the "every team had all the freedoms" and having dozens of databases and hundreds of microservices makes implementing anything cross-cutting (auditing, analytics) a slow-as-molasses multi-quarter initiative.
My issue with design systems is that inevitably the team using the internal companies design system has to implement custom components (usually early on) and try to match the feel of the design system already in place.
I'd rather go custom for a project and semi match the already in place feel of the company's UI standards. Then we're only bottle necked by our internal team and not an external team.
Thinking more on this, I'd love the https://tailwindcomponents.com setup for internal design components? Seems like the best of both worlds but does move the base from React/Angular components to Tailwindcss
SPA makes the backend much more simpler as all the HTML rendering is not its concern anymore. The client devices are very capable and the networks are fast, it's very logical to offload the rendering to the client.
I doubt that MPA is coming back but for things that don't need to be SPA in first place, going back to being MPA is reasonable.
Happening in a different place makes it simpler because the backend no longer needs to take into consideration the various clients. For example, the same API can serve a SPA and a Mobile app and some other interactions with other systems(integrations with multiple services becomes so easy).
Also makes it possible to separate the people who build the API and the people who build the UI which can have many advantages such as hiring more specialised people and decouple the releases. For example, you no longer need someone who knows PHP/SQL/Linux and JS/HTML/CSS. You also have less vendor lock-ins because the front end and the back end are agnostic to each other, which means you can much easily ditch something from the one side without doing any work on the other side.
> the backend no longer needs to take into consideration the various clients. For example, the same API can serve a SPA and a Mobile app and some other interactions with other systems(integrations with multiple services becomes so easy).
Drawing a circle artificially around a portion of your code and saying "look, now the circled part doesn't need to change!" feels like creative accounting to me as well. If you have multiple clients, the code for multiple clients still has to live somewhere, so it's not like the whole system that you need to build is getting simpler.
Pretty much the only actual difference I can see here is the ability to use more of client's CPU time to run your applications. I'm sure there's applications that could profit from that.
> For example, you no longer need someone who knows PHP/SQL/Linux and JS/HTML/CSS.
But if you don't do your logic in JS but do it in PHP on the server, you don't need a JS person. And if you were using Seaside, you wouldn't need an HTML/CSS person since everything would be just Smalltalk at that point. It's again just moving stuff around, but someone still has to do that.
I guess one situation where this argument might apply would be if one of the two language options was difficult to hire for.
> You also have less vendor lock-ins because the front end and the back end are agnostic to each other, which means you can much easily ditch something from the one side without doing any work on the other side.
Not even this argument seems any less artificial to me, since if you're ditching something, I'm not quite sure why it matters where you ditch it from -- unless you have no control over one of the sides. In that particular case, I could see this as an argument. If you're forced to do a client for an already existing server, you're obviously justified in doing a pure client-side solution for anything that doesn't exist on the server yet. If you're building your own server, this limitation is removed.
I don't know why it feels like creative accounting to you(I actually do, see next paragraph). Indeed, by drawing a circle around a code you change the architecture through separation of concerns and break down larger problem into smaller parts. As a result of this, your system acquires new properties.
It all matters because the code is written by people and people specialise. Maybe from computational perspective you are just moving the computation from one place to another but from development perspective you are breaking down code into pieces that specialised people can work on. Instead of having a linux wiz coding CSS or front-end guy creating security holes in your PHP code you have a front-end dev who can talk to backend-dev and all do their parts and the mobile-app-dev can join the party later and simply use the existing work done by the back-end dev.
All that when having some of your computations offloaded to the client devices. It's pretty neat.
> Indeed, by drawing a circle around a code you change the architecture through separation of concerns and break down larger problem into smaller parts.
I'm not saying "don't have cleanly separated components". I just fail to see why it matters that the network communication has to happen between very specific modules and not some other ones. Ideally your system wouldn't even notice at all if you moved the "network border" within your system. Some systems would notice that, mainly performance-wise (for example moving a database engine (which uses random access to a large amount of data) across the border could be a problem), but I imagine that many would not.
> or front-end guy creating security holes in your PHP code
You do realize that this falls under the "hiring difficulties" qualification I've added in my previous comment?
> you have a front-end dev who can talk to backend-dev and all do their parts and the mobile-app-dev can join the party later and simply use the existing work done by the back-end dev
People can communicate with each other and collaborate regardless of whether their code runs on the same machine or not. For example, now with Microsoft's Blazor, just because the user interface is going to be programmed in the same address space and process as the backend doesn't mean that two different people with different strengths can't work on two different parts of the same large program. You can still have the guy who's better at dealing with UI design do the UI, and the guy who's good at writing fast database code write the backend. Not sure what prevents you from doing that.
It's not hiring difficulties, people have limited time and energy to specialise - you can't simply try harder and hire someone who is the best front end and the best backend developer at the same time. Sure, you can still have clean separation of concerns and send rendered page to the user instead having the user run the UI on their device and fetch data as needed but that's just extra work and higher data transfers(in fact, it's a common practice to send the initial page as a full HTML for SEO purposes). If that's your thing, sure go ahead.
But you are keeping dismissing the interoperability part. Since you are now sending fully rendered browser specific output you loose your chance to use the same backend for different type of clients, such as mobile apps or other tools that can work with your system. You instantly need to create client specific output for each and every client type. If you want to do it, go ahead.
Certainly things can be achieved in worse ways at higher costs, maybe some people have reasons to want that? I wouldn't know why though. An art form? A protest? A way to inflate the budget to bill more work for each type of client?
> But you are keeping dismissing the interoperability part. Since you are now sending fully rendered browser specific output you loose your chance to use the same backend for different type of clients, such as mobile apps or other tools that can work with your system.
It really depends on what you are building and if the interoperability is a requirement vs costs and simplicity.
I was part of a 4 person engineering team, all who are full stack, that built an app in Rails, started with server side rendering and later on moved to React, but much of what we had were still serverside rendered html. But our mobile app was done in Cordova and we didnt have to pay for mobile engineers (who usually are exclusively mobile) and to build out APIs for the mobile client. As a result our team was able to move multiple times faster than another team that had 4 frontend 6 backend and 8 mobile devs.
There are inherent costs when you have multiple teams/components or even specializations, especially around coordination and communication.
> It's not hiring difficulties, people have limited time and energy to specialise.
I never claimed otherwise.
> but that's just extra work and higher data transfers
Not necessarily. For example, when compression is being employed, I doubt that something like Rails' Turbo will transfer measurably more data in a page update than sending a JSON or XML representation of the very same data.
> But you are keeping dismissing the interoperability part. Since you are now sending fully rendered browser specific output you loose your chance to use the same backend for different type of clients
No, I'm not! In a single address space, you can generate outputs for multiple clients just as easily as for one client. Literally nothing prevents you from doing that.
A JSON containing the data to update a piece in the page will always be measurably smaller than the full UI, no matter how you compress it because you can compress the JSON too. If you use something that loads HTML or something like that from the server instead of reloading the whole page, congratulations you made a funny SPA.
Sure you can make outputs for multiple clients just as easily. On the traditional SPA though, you don't need to make those at all.
I think the advantages are clear at this point.
> I never claimed otherwise.
You literally called it "hiring difficulties". What's the point to argue after this?
> A JSON containing the data to update a piece in the page will always be measurably smaller than the full UI
There's no need to compress the full UI again. Rails' Turbo for example transfers only the minimum fragment required.
> Sure you can make outputs for multiple clients just as easily. On the traditional SPA though, you don't need to make those at all.
Neither do you have to do that in a traditional MPA. One client = one frontend, surely?
> You literally called it "hiring difficulties". What's the point to argue after this?
Did I misunderstand the comment I was responding? You wrote "people have limited time and energy to specialise". The way I interpreted it was that different people have different strengths, so it's difficult to hire someone who has many different strengths at once (and for example wouldn't poke a hole in your PHP code, to use your own example).
This is not true with something like Turbo: the partial transfer may or may not take place depending on whether it's useful to do that. The point is that you don't have to even care about that (and I'm not even sure you even any control over that). From the perspective of a Rails programmer, you're generating whole pages. How they get to the client is immaterial to you. Think of it as compression (which is actually is, basically using the previously tranferred data as a dictionary).
It's alright, Rails programmers can do that. Nice little trick for building SPAs. There are other systems that use the technique, it has some advantages and disadvantages. If it works for you, great. What's the point to argue against the advantages of SPA?
The point of the person you are replying to is very clear so I am not sure why you insist on arguing.
> Not sure what prevents you from doing that.
The technology stacks used on the back-end, front-end, mobile apps, and their associated tooling are most of the time very different. Most developers aren't polyglot, or at the very least have a preferred ecosystem in which they are the most productive. By introducing physical boundaries, specialization is easier.
For example instead of having a team only composed of Java developer, and having a development workflow and build process requiring Java knowledge, the back-end team may be composed of Java specialists, while the front-end is composed of nodejs + typescript folks, and the mobile app is composed of iOS or Kotlin experts.
Is there a technical limitation preventing people from using typescript in a Java project and separating concerns using the java module system or basic folder hierarchy? No. However this rarely happens in practice unless there is clear physical boundary such as the one enabled by SPAs, because people specialize themselves.
It lets you code in Java, compile to a native SPA, and gain all the benefits you'd expect from a single, strongly-typed language top to bottom (refactoring, POJO reuse on the front end, etc.).
> The technology stacks used on the back-end, front-end, mobile apps, and their associated tooling are most of the time very different.
Which feels like a major mistake to me. My house doesn't use different construction technologies for different rooms. It was built all at once, why would it have one room built of bricks and another one from glass and steel? (Other than for some artistic reason, I imagine...)
> Most developers aren't polyglot, or at the very least have a preferred ecosystem in which they are the most productive.
Yeah, sure. But you don't need to artificially exclude the situation where for example everyone on the team speaks C# (like with the emerging Blazor projects). To say that different developers on a project often have different preferred ecosystems does not mean that different developers on a project must have different preferred ecosystems, even if they're working on different parts of the same project. That feels like a very weird form of segregation to me. "You're a girl, you'll learn cooking!" "You're a C# developer, you'll write the database interface!". Why couldn't the girl weld a bike frame and the C# developer write a Blazor UI?
The house analogy is wrong, we are not talking about using different tech for different apps but different tech for different parts of the system.
Therefore, the house analogy would be using different materials for the floors, for the roof, for plumbing and electricity. Then you will notice that different experts install all these parts. The plumber wouldn't do the electricity. It's not that it's impossible to know plumbing and electrical systems at the same time but it's much easier when you are plumber or electrician instead of trying to be a jack of all trades.
> Happening in a different place makes it simpler because the backend no longer needs to take into consideration the various clients
I’d argue it makes it more flexible, but not easier. It’s so much easier rendering html serverside than having it all done separately in React.
> Also makes it possible to separate the people who build the API and the people who build the UI which can have many advantages such as hiring more specialised people and decouple the releases
You now also have to worry about versioning and/or coordinating releases. Mobile clients demanding a different set of APIs than web client. use graphql? Rest?
> front end and the back end are agnostic to each other
This is good in theory but in practice when you have to replatform the backend for example, it is often for reasons such as separating out concerns, refactoring, rewrites, or moving the frontend over to a new system etc and that usually ends up with the frontend needing to change as well. The frontend is coupled with the API contract that the backend provides and is not entirely agnostic to each other.
This is pretty similar in nature to monoliths vs microservices where monoliths are by far a simpler architecture.
Was HTML rendering ever a concern in terms of complexity? No backend engineers at my company do any frontend because JS is a large hurdle. Sending data to the frontend requires serializing and deserializing which duplicates logic and tightly couples two components we’re trying to separate by technology. You need to deal with a slew of new failure modes when your backend can die at any time - particularly if you are lazily fetching like most apps do.
Personally I think the only reason to ever use an SPA should be performance when sending data over the wire is significantly cheaper than sending new templates or when your frontend code needs to handle very complex states. An SPA can also be a good option if you want to dog food your API layer
So can we really claim these as MPAs? This is all using the same architecture of SPAs but it moves it to the backend. Technically that's still an SPA that moved the rendering to the server and instead of shipping JSON and telling the browser to update with the new JSON it's the server sending HTML that the browser is told to replace a part of the screen. It's really just the same thing but with a twist. This is not "MPA" tech, it's SPA tech with new bells and whistles. MPA tech (PHP, CGIBIN, etc..) is dead and not coming back.
If the author states this, I would be on board - we're shifting to shipping HTML chunks.
Imagine if a kde, qt or other native desktop application had to contact a remote server for the actual styled content to render to page. An SPA is the same concept of desktop applications, only get the data, and render it locally. It doesn't make sense for some things and makes sense for others.
So I don't think this pendulum backswing is all that surprising or interesting on its own - it's been a journey to discover the edges of the SPA paradigm's capabilities and strengths and a retreat to pragmatism mostly.
What I do find quite fascinating is that React actually started out pushing this kind of server rendered, pragmatic pieced-together approach from its very first days. Indeed, because that's exactly what the facebook website required - dynamic additions to a php-like fundamentally server-rendered site.
I am not sure if I'm always interpreting this correctly but a lot of blogs I read about server rendering (the buzz TLA for which is now SSR) and the general per-page approach for React apps seem to be attributing the idea of the approach to a few of the newer frameworks that have appeared. Those frameworks are great and package up a load of this goodness, but ironically you don't and have never needed any such wrapping, nor any of the learnings of the SPA era, for any of this. It came out of the box in React before it even hit major version numbers. Somehow, the idea just never seemed to catch.
This is not a binary choice - SPA's remain a valid pattern for the right use case. The point is knowing when to apply the pattern. Aside from that they have some great features, including security; ;they largely reduce the attack surface to supply/dep chain, and an API interface - which is a great pinchpoint at which to apply mitigations, monitoring etc.
Just taking a guess: supply chain attacks may occur the same (or even more) but they’re less impactful client side. Makes it easier to have more trusted server-side code and less validated client-side JS.
That was my assertion, I said the surface for attack included supply chain. As another poster pointers out, that is in fact reduced under some circumstances, since the runtime context is browser side.
Can anyone point me in the direction of any SPA framework well integrated with a backend framework that can make me as productive as Django, Laravel or Rails?
I think remix (remix.run) is really close. You can use it to easily build a site that fully functions with JavaScript disabled (seriously, at one point while building the demo app I disabled JavaScript and there was no observable difference in functionality), or one that just does SSR with hydration and client-side navigation. The framework is built and maintained by the people who did react-router and you can tell that it's very well thought out. It seems to fill a similar niche to Next.js but it has some clear "second system" advantages, IMO.
I find myself very productive in it, especially compared to trying to build a highly interactive frontend on top of a Django app. The tutorial app on their website does a great job of demonstrating the capabilities of it and the patterns you'll expect to use, and you should be able to follow along in one long coding session.
It doesn't have built in auth, admin, or ORM, but it heavily advocates for the use of Prisma which is probably your best option for ORM in js. So far, no node ORM really comes close to Django's in terms of capabilities. They don't really even try on the production-ready migrations system. However, you could always use Django to get auth (change your hashing to bcrypt and get a bcrypt lib from npm) and admin for free and use `prisma db pull` to keep your Prisma schema definitions (and corresponding type modules) in sync.
It’s hard to know hot productive you are in those frameworks, but I’ll take your question at face value: if you were an expert with NextJS, Typescript, and Prisma or Hasura then you’d be pretty dang productive.
This is not really what you had been asking for but inertia.js is doing a spectacular approach of combining Laravel and a SPA. All the benefits you have with MPAs and no need to build APIs for the SPA view part.
That‘s the only SPA model I have seen which is a real productive approach.
The problem is that you now need to either make resource-oriented APIs for every model in your DB that your frontend may need to access (even if just for internal business logic) or make RPC-style endpoints that do the business logic.
That's significantly more work than just doing whatever logic you want on the server to begin with where you have access to all tables directly (they're an ORM call away) and not have to worry about access control because all of this still happens within the trusted environment of the server.
Perhaps you could elaborate on what you mean, but from my viewpoint there isn't much daylight between DB-queries in most server-rendered apps vs. SPAs.
Instead of this:
def endpointAB:
a = db.getA()
b = db.getB()
return template('ab.html', {a=a, b=b})
You tend to have this:
def endpointAB:
a = db.getA()
b = db.getB()
return json({a=a, b=b})
When I think of ways you may want to generalize over arbitrary queries on the server, I run into the same challenges you'd have in a SPA rather than fewer.
I mean, SPAs were overkill for half the shit they were being developed for. Your average web app is a CRUD app and works better as an SSR app. But there's still use cases for them, they're still a great way to build highly interactive cross platform apps.
In my experience, one of the biggest benefits of SPAs is that the front-end tends to be a bit more decoupled from the back-end when compared to SSR apps. Now, of course MPAs could be built this way, and plenty probably are, but again, it's not something I have personally seen often.
i always try to mention unpoly unless the discussion is specific to htmx because I agree: it is a wonderful library and henning is a great guy in general.
Hotwire probably doesn't need my help, I think dhh has a big enough mic. :)
My dude... I made those in like a day, when I was first getting started with htmx. Accessibility has nothing to do with the language or framework you use. It's about the thing you build with it. If you can build it with Javascript, you can build it with htmx.
Give this a try, and see if it's any more accessible -- https://benpate.github.io/hyperscript-widgets/modal/ -- I've learned a bit since those first demos, and have followed every W3C guideline I can find on accessibility to make them.
One more thing, I'm nowhere near being an accessibility expert, so I'm positive someone who knows more will have suggestions on how to improve this, too. But it has nothing to do with htmx/hyperscript, and everything to do with me being new at accessibility.
Bugs/Suggestions/Pull Requests are always welcome. That's what makes htmx fit for "serious projects."
Edited to add: Htmx is a JS-based extension of the natural hypermedia patterns your browser already uses, not a widget library. All of the demos on the site are just that -- demos that show you the kinds of things you can build, and not plug-and-play, ready-for-npm widgets you can just drop into your application without a second thought.
SPAs themselves have come increasingly towards this with SSR. The next step of web is merging both trends into a framwork that can combine the positives of both, which the libraries in OP seem to be. I'd like to see some comparisons.
Edit: After some research I think SvelteKit is going to be the best new thing.
Doesn't vue.js allow for this in some form with it's low barrier to commitment? I thought it could be implemented via a CDN alone without installing anything.
Regardless, I have read one of the biggest benefits to vue's low commitment is that you can use it or forgo it whenever a developer wants, can add it to existing projects, etc..
I will admit that I am far from well-versed in vue, so I could be mistaken.
>"There’s a feeling in the air. A zeitgeist. SPAs are no longer the cool kids they once were 10 years ago.
Hip new frameworks like"
I have my own company developing products. Some for our own, some for clients. I count my money. Why would I give a flying fuck about what is "hip"?
The only thing that matters is how much it costs me to develop solution assuming it satisfies all the constrains imposed by client's specs. The difference makes a profit and this is what I am after.
I use SPA when I need real business application and it needs to be delivered in a browser. If SPA becomes too big I make it dynamically load a pieces of needed functionality upon request. By nature is is still SPA and dynamically loaded parts tend to stay in browser's cache anyways. When I need a website I make plain website. I do not turn one into the other.
> I have my own company developing products. Some for our own, some for clients. I count my money. Why would I give a flying fuck about what is "hip"?
You are a minority in a sea of crap whose only goal is to extract more money from investors by dazzling them with buzzwords, "growth & engagement" and engineering playgrounds where complexity is a feature to justify hiring more engineers and make an engineering blog to brag about solving (self-inflicted) problems in order to help hire more engineers.
When your objective is to make money by solving clients' problems as opposed to dazzling investors to then beg for their money, the "bill of materials" changes significantly.
I believe there are countless companies like mine, serving needs of various businesses. We just do not make much noise and hence are not written about.
I love how this credits the back/forward cache to chrome when it was a webkit feature chrome inherited. Much like almost every other "chrome" feature other than the process architecture (which was also the actual real engineering work they should have got credit for).
The back/forward cache is from apple era webkit, as is a large amount of the basic compat work in webkit.
KHTML did a lot of work, but they did not do all of the stuff that made WebKit actually practical as a browser engine - webkit had massive rewrites to get compatibility and performance to anything approaching acceptable.
That said the problem I had here in this article was that this article is explicitly crediting a specific feature that predates Chrome to Chrome. The bf-cache is one of the vast amounts of work webkit had done to make khtml a practical engine for real browsing.
WebKit at the point chrome forked it had already largely rewritten the DOM, JS engine, Rendering engine, and layout engine.
Or you can continue searching HN to make glib questionably accurate and definitely misleading comments in response to things I say because you’re unhappy that someone suggested opencl failed because it was a crappy spec.
Konqueror/KHTML was more than "acceptable". It was a fine web browsing experience. You'd barely notice anything wrong with it and it was the first browser to pass ACID 2 tests I think.
Saying KHTML wasn't viable/acceptable experience is more misleading to be honest.
It looks like KDE is still to this day a primary contributor. Isn't giving Apple credit for the work of a large team, the same thing OP was doing with Chrome?
Regarding your accusation, I'll make sure to check who I am replying to and not reply to you anymore. I guess you have interesting counter arguments that encourage discourse. Anyways, keep posting, you're doing a great job.
I do agree alot with the article. One of the major use case SPAs was optimization hack that service worker can do easily. Service worker are like proxy middleware and are capable of some nifty tricks. Since I am not in web dev that much so I never actually managed to develop a project using it, but I felt that the templating could done fully in service worker. It will be faster as long the templating/transcompiling is not a bottleneck as the on wire format will be smaller. The main issue will be bootstrapping as you need to load a page first to install the service worker. I wonder if there is a good solution to that? (One idea is a service worker middleware on node so you can the service worker in the server side on first time use).
(Author here.) I totally agree and feel that Service Workers are still underexplored in this area. If your main reason for writing an SPA is speeding up navigation (e.g. the Turbolinks approach), then you may be better served by just moving the rendering logic into a Service Worker.
It should be possible to build an "MPA" where all the rendering logic lives in the Service Worker. Then you'd get fast navigations without needing to worry about a client-side router and managing focus/scroll/etc. I'm not sure I've seen a great implementation of this though.
Thank you! This is exactly what I had in mind. The streaming aspect of MPA pages is a great example of something you can't really do in an SPA. (Although there are hacks: https://jakearchibald.com/2016/fun-hacks-faster-content/)
These are interesting developments in the browser! Still, I don’t think this headline conclusion is supported by the facts in the article.
Of course “balance” in this context is basically meaningless but if you replace it with “consensus” it does mean something, and it’s clearly not correct: the article makes clear we are still adding critical support at the browser level. Possibly, this will result in a renaissance of multi page apps, but we have to wait and see.
Even if you want to have a SPA like behavior it's easy to render everything on server and keep it interactive by re-rendering just small parts of the page using HTMX, Alpine.js or handwritten JS. It's trivial to add HTML templating and rendering logic to a WebApp.
I'd argue that for somebody equally skilled in backend and frontend frameworks, using server side rendering would be faster than writing a backend and a fronted.
I've been using SPAs to handle lots of complex interactions, and react makes a lot of things quite pleasant that I had to fight with in the past.
Having said that, I am very very happy to see technology move forward and give us more options. I am excited about the possibilities. Having many options to solve complex problems in simple ways is a great thing, and old down sides of each are disappearing.
From my point of view, SPA is really good when you need to use one API for different kinds of clients: web, mobile apps, cli etc. Second benefit is predicted relative routing: in case you're serving your web app (with hash router) as one page, you may don't worry about subpaths (ex: page served as /webapp will work properly under /foo/bar)
"Headless CMS" is simultaneously all the rage (API first content management).
If I had to generalize in broad strokes, decoupling the front-end from back-end using SPAs will be far more practical in B2B use cases. While consumer apps will benefit from MPA/SSR (server side render) where one page per product is easier to manage and bookmark.
I don't remember which hotel website(Marriott?),I was using that migrated to MPA and their dev team had no clue that it broke their in-app chat feature. Agent asks me for registration details, I click on the page to get details... Poof, my chat gets disconnected and now I have to wait another 30 minutes for next agent.
> Service Workers – once experimental, now effectively 100% available for those of us targeting modern browsers – allow for offline navigation without needing to implement a client-side router (and all the complexity therein).
Ok, sure, but what you're saying is that the code and rendering is still on the client, same as SPAs.
I understand that SPAs were being overused in many places. But the pendulum seems to be swinging back way too hard, and people are bashing SPAs as if it's the worst thing in the world.
SPAs are cheap to host, as you just need a reverse proxy and with increasing internet speeds, bundle splitting can be almost imperceptible from MPAs
SPA movement has given us nice frameworks to build mobile apps in Ionic. I wouldn't build a website with Angular but combine Angular framework and the million libraries in npm gives a pretty powerful ecosystem to quickly build very high functioning apps.
Speaking of Rich Harris, is SvelteKit a good framework to build MPAs? If not, what is? I'm planning to learn SvelteKit in my next side-project. As for "Astro, Qwik, and Elder.js" mentioned in the blogpost, I haven't heard about them.
Pour one out for all the junior engineers on teams with senior engineers who read this and argue to go back to poorly implemented MPA’s without the engineering talent to drive sensible abstractions.
Different architectures make sense in different contexts. Whether one is used more than another doesn’t matter one bit. It is not a popularity context.
I think nearly every spa I've ever used was a piece of crap. There is just something off about them. It's almost like it's missing tactile feedback or something. And there's always goofy stuff that just doesn't work half the time. Like middle click to open a link in a new tab. So anyway. Good riddance
SPAs are like visual effects. You don't notice the good ones, because they just work. It's when they're poorly implemented that you notice they're SPAs. It's just a form of survivorship bias.
I have been reading articles like this for the last 10 years. I'm not sure why people complain about SPAs.
Guess what, in the mean time as some MPA frameworks have been made, the whole web has been moving towards webassembly. Say goodbye to MPA HTML, say hello to Rust with custom UI based on WebGPU transpiled to webassembly.
I think Web Development has been trending towards being obnoxious no matter how you spin it for many many years now.
All these frameworks, doing too much magic under the hood, were supposed to make things easier, in some form or fashion, but I feel like each one always come with their own problems. Are things actually easier when developing with them?
While I understand nothing is perfect, it doesn't help but add so much complexity into many applications for no reason. If over half of all websites when back to plain HTML/CSS/JS, I do not think the world would suddenly stop.
I feel like a majority of people building web applications are using a development methodology I read on here years ago that was jokingly called, "Resume-Driven Development." I've still not really ever heard a convincing argument for SPAs for websites (web applications could be a different debate, but it also could be a false dichotomy).
However, I find myself getting urges to learn one of these SPA frameworks, not because I think it will benefit much of what I do, but because that is obligatory in staying competitive in my market.
Wait we have to support older browsers? IME if you're not on the latest Chrome release, or one prior, then you're on your own. Any other browser or older release is rarely a serious concern.
I disagree with calling C# "easy to use". But Rust is such a bad fit for wasm that any other language will probably displace it once it's viable.
The DOM has it's own lifetime decisions, but lifetimes are the most central concern for Rust. I don't think both can be conciliated without a major rewrite of one of those parts.
So rebuild everything a browser does on canvas to make things easier? On what planet is that sensible?
These ideas must come from people who have no intention to learn the languages required to build frontends, but want to stick to their systems language of choice. Not realising of course, that the problem space remains pixels and users and all the irritations that come with it.
As a JS developer, I think this is correct and kind of fear for my future. Time for this old dawg to learn something new again. Thing is, I think I am not good enough for system level programming. I've only done rust to the extend of going just a step beyond "hello world". I've also read good things about Go. Decisions, decisions.
> think I am not good enough for system level programming
I think that this is the wrong way to think about it, the languages and tools for systems programming suck. I would recommend you check out Rust, it make systems programming really pleasant. Like I have been programming C++ for 25 years and somehow I'm a lot more comfortable with writing Rust even though I have seriously written Rust for only like 1.5 years.
It really hasn’t been moving towards web assembly. Web assembly is not magic performance pixie dust and it generally has pretty bad bundle size. You need pretty specific scenarios to get genuine improvements with web assembly over JavaScript.
something still annoying between navigatng pages normally Vs SPA history API is in first case you lose devtools network/console data from previous page (while developing at least)
In the early days of the web, pages were static, and changing content required navigation to a new page (url). Then JavaScript took off and you could dynamically change content on a given page, even reload data without navigating/refreshing. In the extreme, frameworks like react were developed, where you no longer have pages at all. The entire website is rendered on the same page using JavaScript to load all the content on the fly.
As a Web user, I urge Web site developers to return to "keep it simple". In particular, multi-page applications are better, easier to understand, than single page applications which tend to be confusing. Treat the pages of the site more like the pages of a book -- those pages don't change as I'm trying to read the book.
Net, a single page application looks to me like it has no pages at all, just a lot of confusion where I don't know where I stand, what is the state of my visit, something I can't meaningfully copy or save.
Use big 100% black fonts on a white background. In particular, note that about 25% of men are partially red-green color blind. So, if insist on using colors, avoid using both red and green on the same page.
Have both vertical and horizontal scroll bars. Never omit either the vertical or the horizontal scroll bars. Accept no substitutes.
Similarly, never have a row of images or other blocks of content that scroll off and on the screen left or right via little arrows. With that scrolling, there's no real page I can have in mind.
Don't have parts of the page moving or coming and going without explicit user requests. Such Web pages are a good reason just to leave the site. Or, maybe I DO want to look at some of that content -- nope, soon it's jerked from me and gone. Bummer.
Don't assume that the user will display the pages at full screen -- often can't have that because need other windows open for the purpose of visiting the Web site at all.
Don't cover up what I'm trying to read: So, cut way back on popups, pull-downs, overlays, etc.
Design the Web page HTML so that I can save the page and later, without an Internet connection, still have my Web browser display the page correctly. Such saving can be crucial for pages where I've done something important, say, pages summarizing a purchase I just made.
Conserve the crucial, vertical space: So, get rid of banners that overlay the content, take up a lot of the vertical space, and come and go as I scroll the page up and down. Apparently as people saw how to do that, doing it became popular as if it were a good idea -- it was a fad and a bad idea. Don't do it. Quanta magazine has done a lot with such banners, and it has seriously hurt the usability of their site.
Now commonly a lot of Web pages have been done with some fancy work with JavaScript and require me to take several actions just to get to the content. I've had more than enough: When I see such a page, with nearly no exceptions, I just leave the Web site. I'm gone, out'a there.
I commonly have the mouse pointer on the content of the page as I scroll the page, and some sites track the mouse pointer and, then, generate lots of popups that cover up the content I'm trying to scroll and read. No matter what, almost certainly, I regard any popup I have not explicitly requested as a big interruption in my work, a big waste of my time, a big frustration, something I really HATE, and a good reason just to leave the site. Tracking my mouse pointer and responding with a popup I didn't request is doing me a favor based on some assumptions: To me, it's not a favor. In general, just do not make assumptions and then do me automatic, unrequested favors by interrupting my effort to read the content of the site. Cut way back on unrequested favors. Wikipedia and Disqus both do a lot of mouse tracking and popup favors, and I hate both of them for it.
Just keep it simple, e.g., so I can see the real content the site does have and I came to see. Just because it is possible to insult, interrupt, irritate, infuriate, and frustrate me does not make it a good idea.
So much whining about SPAs. A properly written SPA is very performant and really doesn't have huge differences compared to MPA.
If anything the only thing that's changed is people understand how to properly write a SPA and JavaScript web development is finally reaching a period of some level of stability.
It really depends on what you're trying to do. Want a fully offline app? Good luck without SPA.
My experience is the opposite. I say that from a career that is dominated by backend experience.
In any application, you have to have a good front end. To most users the app/page is the UI.
Having the majority of your concerns in one place will help you develop with smaller teams. Certain SPA architectures can bring nearly ALL of the concerns into the front end. Particularly with databases that are simply port open to the world like say couchdb. Your backend needs almost effectively disappear. If this is a reasonable data model, SPA looks and feels much faster to use and develop.
When you attach a backend, you often attach other specialists, languages, techs (python, ruby, Java). Have to deal with separate teams, which often means a formal API and all the handshaking between. This pretty much triples the required work with development and the communication overhead.
Stop griping about SPAs. Local compute is powerful and lower latency than the data center across the country or world.
Page weight isn't that big of a deal, a 2 MB ball of js is nothing compared to the multi megabyte pictures and videos people routinely add to pages.
For some use cases MPA is fine, but in many cases it's actively worse and higher dev costs to boot.
Service workers are an interesting middle ground I think should see more attention and development. I like to combine service workers with SPAs for fully offline capable web apps.
> Page weight isn't that big of a deal, a 2 MB ball of js is nothing compared to the multi megabyte pictures and videos people routinely add to pages.
That's a good argument if you're one of the people adding multi megabyte pictures and videos to your pages, but I'd bet that if page size is of concern to you, you're not one of them, so "a 2 MB ball of js" would suddenly become your weakest link.
You say "weakest link" like there is an optimum. People are regularly downloading 4k video. By choice, they want to be doing this.
Amazon is one of the most successful websites ever created and last I checked came in at over 12MB page weight. Mostly highly optimized images. I'm sure they wrangle and agonize what shows up there.
There's a limit somewhere, but pointing the finger at a ball of js that compresses to less than 500k isn't particularly reasonable.
User experience is more about latency. Be it from local compute or remote compute+network.
If your visitors are one and done you must SSR at a minimum. Because that will drive the average latency of the majority of user experience.
If they are long term users, you should seriously look at user local data and potentially full offline functionality that can mask even poor 3g performance and spotty networks. Making users suffer long term through an MPA architecture is silly.
And you end up saving that 2MB at some point since every page load is just some JSON instead of waiting for the server to render a whole new page that is mostly a duplicate of the current page.
Page 2 definitely has big wins, not only for the user but in reduced server load and thus cost. That is really the key bit of information in answering the question, to SPA or not to SPA.
