The balance has shifted away from SPAs
nolanlawson.com
nolanlawson.com
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.
"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.
All sites I use regularly are MPAs:
Hackernews, Amazon, AirBnB, Booking.com, Wikipedia, GithHub ...
Reddits new design is kind of a hybrid. It is MPA when you hop between subreddits and other pages. But it shows a post on the same page when you click on it in a subreddit feed. I actually are annoyed by the new Reddit enough to switch to old.reddit.com most of the time when I end up on Reddit. Not sure why. But maybe it tells something, that the only "somewhat SPA" I know makes me switch to its MPA version regularly.
Slack, Dropbox, Google, Notion, Spotify, superhuman, 1Password, Robinhood…
Basically most web tools/apps are SPAs if they have been built in the last ~10years. Github, Reddit and Airbnb were founded ~15 years ago when Rails was still a thing.
As a frontend dev this has always been my stance, but I’ve been consistently shunned for it.
How much of that was naïveté vs. misaligned incentives I’m not sure.
In any case, these thing always leave me with the feeling the industry is getting way too saturated with script kiddies. It just feels immature, and the culture that’s grown around web dev seems to reflect that. Or more likely I’m just bitter and old.
Or more likely I’m just bitter and old.
Maybe we don’t talk about the same thing, but isomorphic code with react is great for websites too: server side render, instant page change on client side. Reuse of exact code. Huge benefits.
I am just curious, why would I use Rails over something like .Net in today's time? I am no apologist for .Net or anything, I am just genuinely curious.
Database driven sites and apps have experienced great performance and functional gains since the marketing teams pushed SPAs onto everything and it's tragic that billions of dollars will be thrown off a cliff (once again) to refactor everything back to prior methods... Hubris always wins until it fails massively.
That being said, SPAs do work well for certain things, but people just keep losing track of the right shoe for the right foot.
On big, sprawling, multipage content-rich websites, not so much if at all.
It depends. Web people should have this tattooed on their foreheads.
I'm aware that Google can run JS, but its support is limited compared to server rendering and there are other crawlers behind Google which probably will never be as sophisticated.
The other way is to add a few lines to your `robots.txt`.
If you mean "google" as "google properties as a whole", then yeah (the fusion of google maps and google earth is something absolutely _mind blowing_ to see in a web browser, for example).
If you mean "google" as "the search engine", then I was perfectly fine with a server side rendered, non-so-much-semantic search it was until last decade. Advanced search worked well, fast as hell already. Hell, there were two search text boxes if you wanted to search for something else once you scrolled down to the bottom of the page.
The whole concept of Single Page Applications was misguided from the start, and the reason for that is even in the name. Pages and applications should never have been mashed together. The moment we decided we needed apps, we should have abandoned the static document-based "page" concept altogether.
We shoul've replaced it with a browser-hosted VM-based execution environment in which proper apps could be built.
It's never been a question of MPA vs SPA. The question has always been how do you build browser-based applications in a way that escapes the impedance mismatched document/html model?
I'd venture to guess that even an MPA comprising multiple SPA 'pages' is an unsurprising composition especially for captive audience apps like internal, or government etc.
How many micro-interactions do you want --- the more you have, the more likely you want an application rather than a site.
When you first go to aws.amazon.com, you get a website with content about AWS.
Once you log in, you’re in the AWS web application, and it’s time to start doing things.
Forums like HN, I would consider websites because there is a lot of reading and not much doing.
Wikipedia and blogs are mostly for consuming content and it's the same content for everyone. Clearly a website. Instagram usually isn't super interactive, but it's extremely personalized, so it's much more like an app. Gmail also clearly a web app.
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.
anything that can be done offline ought to be an SPA so that it can be made to actually still work without internet access.
So the "It's even in the name" argument is not an easy decision point as you make it look like.
Slack, Dropbox, Google, Notion,
Spotify, superhuman, 1Password, Robinhood…
Thanks for letting us know everyone was waiting for you stating your personal preferences, so they can follow suit.
For me it's because the new design is hilariously slow in every way. And also it looks really, really bad. Meanwhile old.reddit.com loads instantly and doesn't burn my retinas.
https://www.reddit.com/r/bugs/comments/rj0u77/reddit_redesig...
My current gig for a smaller corp (<50 employees) I am with 3 other developers (1 FE, 2 BE) and all that team has been doing for almost 1.5 years is to develop a SPA webapp that is exclusively used by the on-call phone support staff, which are no more than 4 actively working supporters at the same time. Admittedly, the business customers deal in huge amounts of money so having qualified phone support is a must here, and upselling/sales also happens on those calls.
It's either use an application provided by an authorised third party (who take a cut of every transaction) or become directly authorised to run solo with your own application that meets legislative requirements.
Does anyone know how to block that page reload and associated movement of stories and scroll position on the page you're returning back to?
history.back()
I remember being pretty interested in it at the time.
https://techcrunch.com/2013/04/19/airbnb-open-sources-rendr-...
> Hackernews, Amazon, AirBnB, Booking.com, Wikipedia, GithHub
I don't know about AirBnB. Booking has a little bit of interactivity that is more annoying than helpful¹, like the GP's example for Reddit. None of the others can be described as "applications".
1 - The map is good. The stuff on the map is very good. The map itself is an SPA. For all the rest of the site, if they removed all the Javascript it wold be an improvement.
Overall, I would count that as MPA?
The apartment pages seem to be client side rendered. When I CTRL+u and look a the source code, I see a lot of JSON and not much HTML.
I resisted "learning" typescript for like 5 years or more and I hope it's been validated somewhat.
Being a web dev is hard enough dealing with myriad devices and ever changing trends without consolidating every aspect of web/app into that role because Facebook wanted to cut down on their server costs.
And I don't enjoy using those bloated electron apps either, the difference between native and JS is stark.
What does TS have to do with SPA/MPA?
I can't speak for others but my company (of 50k) has dozens of internal facing SPAs each with their own dev teams. Each of these apps are used by at least hundreds of not thousands of people on a weekly basis.
Sometimes SPAs are literally apps that you install on your computer.
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.
The way I see it, the state of an application resides in the server, more specifically, the database. Let's keep it there.
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.
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.
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.
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.
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.
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.
I would have said "Reading HN you'd think 99% of web sites are web apps". Most of the web is content with a light smattering of interactivity
> They love the interactivity and quickness of a SPA.
It's very easy to avoid the full page load without needing to go full-on SPA.
> I have no idea why I'd go back to having to maintain a JS entry point per page
I'm not sure what you mean here. "Progressive enhancement" was an excellent idea that didn't stick around for long enough.
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.)
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.
Unfortunately they are. People are using React for things that aren't apps.
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.
Absolutely right. But is that what most people here are working on? Aren't content sites like this largely a solved problem?
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.
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.
That's really long.
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.
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.
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?
Billion dollars companies rarely delivers high quality software, especially in the UI area.
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.
How Hotmail changed Microsoft (and email) forever
https://seforum.se/2019/01/08/the-history-of-hotmail/
This had me in stitches. I'm also not a huge fan of obfuscatory jargon, irrespective of how cromulent such language may be.
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.
Names are important!
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.
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.
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).
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.
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 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!
[2] https://www.usability.gov/what-and-why/information-architect...
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.
Have you considered adding a “business app” category? Thinking of things like CRMs and learning management systems. Maybe Salesforce would be the holotype?
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.
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.)
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.
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.
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.
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
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.
That feels like creative accounting of code to me. Is the rendering really simpler, or does it merely happen in a different place?
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.
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’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.
Rendering on the server-side requires transfer of state, so you know the context. For example did you expand the 3rd expander or not?
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
my browser is using 5GB of ram on three tabs.
> and the networks are fast
yeah, if you work next to the data center.
For consumer facing websites, where search engine viz is a concern and less is known about the clients browser, maybe it is different.
If the author states this, I would be on board - we're shifting to shipping HTML chunks.
Any civilians coming across this can't even find out what it is by searching unless they tack "software" after the word.
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.
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.
That‘s the only SPA model I have seen which is a real productive approach.
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.
antithesis: web 2.0 SPAs using JSON Data APIs (slick, but complex and & web-native)
synthesis: web 1.5 apps using hypermedia-oriented libraries like htmx or unpoly (slick, web native)
I wish the unpoly creator also did similar! Both great frameworks. Hotwire also!
I wish there was deeper comparisons on the big three
Hotwire probably doesn't need my help, I think dhh has a big enough mic. :)
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.
Not writing a bloody wrapper over express.js...
Edit: After some research I think SvelteKit is going to be the best new thing.
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.
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.
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.
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.
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.
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.
There is no other way around it.
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.
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.
Overall. Awesome.
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.
Ok, sure, but what you're saying is that the code and rendering is still on the client, same as SPAs.
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
Sites built in Next, Remix, or whatever work perfectly well as MPA. Astro merely goes a step further.
Pure SPA (as in a literal single route, maybe with horrible # based routing) is exceedingly rare and mainly found in legacy Angular code bases.
Just ask yourself who your users are and what workflow makes sense for them, and build something accordingly.
A „website“ like HN shouldn’t be a SPA
But an „app“ like Gmail probably should be.
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.
If this is the future, then no wonder everyone is running back to just shipping HTML over the wire. All this has gotten too complicated.
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.
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.
I find Rust more pleasant to use than C#. If you had said F#, I woud be like "maybe" but not C#.
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.
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 is. I can finally have value types which let me access properties without incurring the overhead of a JIT.
> and it generally has pretty bad bundle size
For now. So do websites btw.
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.
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.
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.
Maybe true but in the wild the vast majority of websites manage to fall down on one or both of these.
So either it's hard to "properly write" an SPA or something else is going wrong.
SPAs should offer better UX (by reducing full page loads), but at the expensive of developer hours.
Curious to hear what the difference in development time is from anyone who made the same app as a MPA and later as a SPA.
I'd guess to make the same app as a SPA would take around 2-3 times as long.
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.
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.
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.
Not that the industry is invested in accessibility out of benevolence.
I feel like we're holding up the hard/firmware side of things here.