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.
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.
> 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.
I remember being pretty interested in it at the time.
https://techcrunch.com/2013/04/19/airbnb-open-sources-rendr-...
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()
Not saying you should do either of these, as the UX would be worse, but you could if you really want to :)
So are controls or useful UI or... :D
Seems SPA to me.
But GitHub doesn't use turbolink. They wrote their own implementations that lies at app/assets/modules/github/behaviors/pjax.ts.
Check out https://api.github.com/users/defunkt:
> "id": 2
pjax was written by a GitHub founder for use in github.com.
It's the right balance in-between React/SSR hydration and Railsy server-side apps, taking the best of both worlds.
This is a really good talk about how we got here from Jquery->Backbone.js->SPAs + React/Vue->Stimulus/ViewComponent/ActionCable
https://www.youtube.com/watch?v=sIxvxp7E0xg
There's another similar project called AnyCable which combines websockets with an ActionCable style approach:
This blog post (and my linked talk above) opened my eyes on the subject: https://evilmartians.com/chronicles/anycable-actioncable-on-...
Right now the complexity is a bit high on this approach^ and I personally just use a mix of Vue + Turbolinks/Rails at work for legacy/simplicity reasons. But I'm watching the space.
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.
Slack, Dropbox, Google, Notion, Spotify, superhuman, 1Password, Robinhood…
Basically most web tools/apps are SPAs if they have been built in the last ~10years. Github, Reddit and Airbnb were founded ~15 years ago when Rails was still a thing.
Slack, Dropbox, Google, Notion,
Spotify, superhuman, 1Password, Robinhood…
Thanks for letting us know everyone was waiting for you stating your personal preferences, so they can follow suit.
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.
I am just curious, why would I use Rails over something like .Net in today's time? I am no apologist for .Net or anything, I am just genuinely curious.
I mean, I solve most of my problems with the hammers I have at hand. But I try not to fall exclusively in this trap of “I will use tech X because that’s what I know.”
But I see a majority of my programming peers who will avoid moving “forward” because it’s easier to “stay behind.” At first, this works, because the difference between what’s new and evolving versus what’s established and a “core competency” is trivial and easy to marginalize. As it persists over time though, the investment can become a real millstone.
I am pretty comfortable with Python. We use it some pretty key areas in our product. It’s an established technology and competency for us. Last year, I needed to construct a service that was going to involve spinning up LOTS of little long lived threads. I was concerned about doing this in Python. Doing so would be easy and straightforward. “Because I know it” would definitely have said “do this in Python right now, deal with scaling issues later.” Instead I looked around and deemed this a good reason to take Elixir for a spin. I’m glad I did. It turned out to be a good fit for this problem. “Because I don’t know it” caused others around me to raise their eyebrows and question my approach initially. Was it the 100% best choice? Who knows for sure. But it’s worked out well. Ironically, just the other day, a data serialization library I have in both systems, the Python one needed to run faster (new use case for it suddenly needed speed that we didn’t hitherto care about). After some profiling, I rearchitected the python algorithm to be more similar to the Elixir one and gained about 50% speed up.
That would be a VERY interesting case study. Any chance you could write it up as a blog post or similar?
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.
You are not wrong though, and it's quite annoying when hopping between multiple .Net versions. I feel like I have a bit of insight into what it would have been like to be developing in Python during the 2.x to 3.x schism years back.
Then, they come up with The New Thing every few years, which is not backwards compatible and only handles 20% of what the old thing did + a few new things, but they promise this is the future and will eventually have all the features. The Old Thing is always there if you want it, so there's no reason to revolt when this happens.
The New Thing will eventually be replaced by a Newer Thing, get frozen in its current status, and the Newer Thing will be promised to be the future.
A nice example is Windows GUI. The Old Thing is GDI. Then they invented WinForms in .NET, then WinForms was abandonned in favor of WPF, then WPF was abandonned in favor of Metro/Modern/Universal apps, and last I checked they had some new HTML+JS-based stack available. All of these frameworks still work - you can take an app built with any of them and run it on the latest Windows, and you can even build a new App based on any of them and still find resources for it etc. But none of the old ones are getting new features, and MS will steer you to one of the newer ones instead.
The same kind of thing happened with communication frameworks (COM, then WCF, then???), with ORMs (ADO.NET, LINQ to SQL, Entity Framework, Entity Framework Core) and I'm sure others.
I detect a similar strategy with Apple and the app store: make it so that the long tail of small developers can't invest in more than one platform by moving goalposts so frequently you spend any spare cycles you have trying to keep up.
It's an engineering decision with tradeoffs, like every engineering decision.
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.
Actually the latter is a candidate to k8s because the team knows less and less of server management. I think they are going to replace complexity with complexity for something that fits well in a small VM. We will see.
About Elixir, I don't think it's an overkill. I find its pattern matching much better than anything similar in Python and Ruby. Running a background job without having to use Celery or Sidekiq is great. The deploy story is worse than Ruby's (IMHO) in part because it's compiled (I prefer to deploy with Capistrano than having to build and deploy.) Python's deploy story just doesn't exist. According to the project I'm using a self made Capistrano equivalent, git pull or sending git patches to the server.
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.
anything that can be done offline ought to be an SPA so that it can be made to actually still work without internet access.
The only clear line I've seen is javascript. If it uses javascript for anything nontrivial, people believe it's a web app. This comes up all the time in threads about "the old web" or "how you would fix the web," in the context of what seems to be a prevalent belief on HN that the web should be split up between the two paradigms, with purely static, noninteractive "sites" in one place, and "apps" in the other.
Problem is, as mentioned upthread, the vast majority of sites using javascript, including SPAs, are still meant to be read as documents. If you include any form of interactivity, including backend processing and rendering, even more sites become apps.
In practice, it seems to me to be more of a religious taxonomy than a technical one, based on the belief that the modern web has become tainted by complexity and needs to be made pure again.
I see it more being whether a page uses progressive enhancement. If I can disable JavaScript and at least be able to read a page's content, then its a web page rather than an app. If JavaScript is an absolute requirement for any functionality it's an app.
A page with some client-side form validation, AJAX submissions, or even just some dynamic content are awesome uses of JavaScript so long as the pages themselves don't hinge on me running the JavaScript. Posting a comment might be a POST and clicking an image thumbnail might load it in a new tab instead of a light box. The functionality is all still there if for any reason the JavaScript doesn't load.
One of my big problems with "apps" is they have zero provisions for JavaScript not running. Most "apps" don't even give an error page telling you explicitly JavaScript is required. Even when you have JavaScript enabled they tend to break in stupid ways if you've got an ad blocker.
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.
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.
Wikipedia and blogs are mostly for consuming content and it's the same content for everyone. Clearly a website. Instagram usually isn't super interactive, but it's extremely personalized, so it's much more like an app. Gmail also clearly a web app.
Amazon is highly personalized and fits well into the standard web page paradigm. What about Instagram's "personalization" wouldn't work as a standard web page?
Really nothing. But for most people Instagram is primarily a mobile application and comes with the usual experience of a mobile application. Transitions, fast reactions, no "whole page" reloads, etc.
Continuing this experience into the less frequently used browser version only makes sense, especially given the fact that Instagram's tooling allows for a relatively easy transfer (iirc large parts of the mobile apps are implemented using React Native)
How many micro-interactions do you want --- the more you have, the more likely you want an application rather than a site.
As a frontend dev this has always been my stance, but I’ve been consistently shunned for it.
How much of that was naïveté vs. misaligned incentives I’m not sure.
In any case, these thing always leave me with the feeling the industry is getting way too saturated with script kiddies. It just feels immature, and the culture that’s grown around web dev seems to reflect that. Or more likely I’m just bitter and old.
Or more likely I’m just bitter and old.
Farmville Devs <- Facebook Devs <- Chrome Devs <- OS Devs <- Chip Devs <- Factory Devs
Once you start adding conditions and context to the heuristic, it starts to look a lot like a Design Pattern.
What I was describing could maybe be conceptualized as multiple applications that serve one larger site. You have the public facing staticly rendered site, built in whichever way, but that ultimately has accessible rendered content on page load and as fast as possible. Then you also have interfaces to the data that is rendered there, which might be completely separate codebases for different purposes.
These could also take place in things like a reporting portal inside a company, where stakeholders need to regularly see static or filterable reports of pre-rendered data, and then you have other internally available apps that different departments can use to manipulate that data in ways that they can easily receive immediate feedback on whether or not it's valid or how it looks etc..
The abstractions are not, however, good enough yet.
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.
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.
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`.
I'd venture to guess that even an MPA comprising multiple SPA 'pages' is an unsurprising composition especially for captive audience apps like internal, or government etc.
The whole concept of Single Page Applications was misguided from the start, and the reason for that is even in the name. Pages and applications should never have been mashed together. The moment we decided we needed apps, we should have abandoned the static document-based "page" concept altogether.
We shoul've replaced it with a browser-hosted VM-based execution environment in which proper apps could be built.
It's never been a question of MPA vs SPA. The question has always been how do you build browser-based applications in a way that escapes the impedance mismatched document/html model?
And, we're now delivering entire frameworks to the browser to support, essentially, a kludgy VM-based approach that just shoehorns app concepts onto the HTML document model.
So, what I'm suggesting is more of an in-browser hybrid.
Assuming the only two approaches are Flash or React seems like an industry-wide failure of imagination.
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.
So the "It's even in the name" argument is not an easy decision point as you make it look like.
For me it's because the new design is hilariously slow in every way. And also it looks really, really bad. Meanwhile old.reddit.com loads instantly and doesn't burn my retinas.
https://www.reddit.com/r/bugs/comments/rj0u77/reddit_redesig...
Also... I wouldn't have thought that by default it would include screenshots of potentially private/sensitive information such as the the titles of other open tabs.
FWIW if you're logged in you can go to your profile and make it so www.reddit.com just shows old reddit
Again: teddit.net solves that problem. RELIABLY
There's the added bonus that I can't vote or comment. Yes, bonus.
1. Not log in to Reddit unless I must.
2. To use old.reddit.com exclusively. Or another which won't revert to www.reddit.com
The mechanism you describe fails on both counts.
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 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?
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.
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.
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.
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.
So might not be the best approach unless most of your users are at their desk
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.
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.
> 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.
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 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.
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.
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.
But why you’d do that instead of using 10 MB of React code, I don’t know.
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.
Everyone who down voted me is a total idiot.
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.
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.
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?
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 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.
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.
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.
If you can afford high risk (React at the beginning?) and it works, you’re in a sweet spot for a long time.
Most of them don’t pay out though, and most JS frameworks that got started around that time died long ago.
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.
How Hotmail changed Microsoft (and email) forever
https://seforum.se/2019/01/08/the-history-of-hotmail/
Names are important!
This had me in stitches. I'm also not a huge fan of obfuscatory jargon, irrespective of how cromulent such language may be.
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).
Other shops dont arrive at it naturally and it is just friction all the time trying to apply a practice without groking it.
Sorry, I'm actually just bluffing, what is DDD?
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.
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...
Have you considered adding a “business app” category? Thinking of things like CRMs and learning management systems. Maybe Salesforce would be the holotype?
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’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.
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 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.
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.
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.
this is most likely not true and drunken kruger syndrome
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?
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'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
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 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.
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.
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.
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?
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.
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?
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).
That's SPA fetching HTML instead of JSON or something. You are welcome.
> In a SPA, a page refresh never occurs
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 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.
> 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.
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?
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.
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.).
There is a full intro article in Java Magazine:
https://blogs.oracle.com/javamagazine/post/java-in-the-brows...
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.
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.
Instead of this:
def endpointAB:
a = db.getA()
b = db.getB()
return template('ab.html', {a=a, b=b})
def endpointAB:
a = db.getA()
b = db.getB()
return json({a=a, b=b})
That‘s the only SPA model I have seen which is a real productive approach.
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.
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.
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.
Saying KHTML wasn't viable/acceptable experience is more misleading to be honest.
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.
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.
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.
I find Rust more pleasant to use than C#. If you had said F#, I woud be like "maybe" but not C#.
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.
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.
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.
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.
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.