13 ms·

The refrain against the "we should go back to MPA apps with server rendered HTML" is often "well what about Figma and Photoshop", which of course, yes those don

The refrain against the "we should go back to MPA apps with server rendered HTML" is often "well what about Figma and Photoshop", which of course, yes those don't really work in the MPA, server rendered HTML model. The problem isn't so much those but how most developers lump themselves in with the incredibly interactive sites because it sounds sexier and cooler to work on something complex than something simple. The phrase becomes "well, what about Figma and Photoshop (and my mostly CRUD SaaS)?" I think a valuable insight that the MPA / minimal JS crowd is bringing to the table is the idea is that you shouldn't strive for cool and complicated tools, you should strive for the simplest tool possible, and even further, you should strive to make solutions that require the simplest tools possible whenever you can.

endisneigh 3y ago
> you should strive for the simplest tool possible, and even further, you should strive to make solutions that require the simplest tools possible whenever you can. Why do you believe this? I couldn’t disagree more. People should strive for the most effective tool, and most of the time that’s what they already know, unless some new tools’ efficacy outweighs cost to learn it
- ryanbrunner 3y ago
  Fair point that my point was overly reductive. But given you understand multiple tools, you should reach for the simplest tool possible to solve the problem. And in some cases you should still reach for the simplest tool possible even if you don't understand it yet. If you've only ever used Kubernetes but someone asks you to host a static HTML file at an address, you should learn how to use a simpler solution for that.
- Xeamek 3y ago
  >most of the time that’s what they already know, unless some new tools effficacy outweighs cost to learn it ....which any proponent of the new tool will argue it does
  - endisneigh 3y ago
    Yes which is why you should generally stick with what you know until you have an actual problem that needs solving… SPA, MPA, who cares. Ship.
    - Xeamek 3y ago
      That's not how anything in the world works though
      - endisneigh 3y ago
        Most professions do work like that, actually.
        ryanbrunner 3y ago
        - Hammer, screwdriver, who cares, fix it. - Scalpel, forceps, who cares, do surgery. - Reinforced concrete, 2x4s, who cares, build a bridge. No, pretty much every profession that uses tools cares about using the correct tools for the job.
        endisneigh 3y ago
        Yea, tools and processes they’ve decided on decades ago. You don’t see these people writing blog posts about new tools and wasting time evaluating them yearly like in tech. If there’s an actual issue like there was with deaths in the medical profession due to not washing hands, then they evaluate.
        Xeamek 3y ago
        ...except those field are literally a thousands years old, while software industry is about 70? Them being more mature doesn't change the fact that processes and tools are crucial
        3y ago
- deleted 3y ago
  [deleted]
- christophilus 3y ago
  It also depends on your definition of simple. The architectural model of Preact is simple. You change state, your application renders correctly. The architectural model of an MPA with interactivity sprinkled in seems as simple, but quickly becomes more complex over time, and has ultimately not been as simple in my experience.
  - ryanbrunner 3y ago
    Preact / React is simple because it solves for a very small slice of what an application needs to do and willfully ignores the rest. For example, (P)React has no real opinion on how it interacts with a server, which is a fundamental requirement of 99% of web applications (the new server components stuff is a counterargment I guess, but even then it doesn't consider the complexities of what a backend needs to do and is essentially a "put backend stuff here" slot) MPA frameworks tend to present themselves as complete and batteries included. If you're using Rails, you can build a complete application without thinking about a single other library than what Rails ships with. Neither approach is correct, but comparing them is like saying that HTML is so much simpler than C++ so everyone should use HTML.
    - christophilus 3y ago
      But, that is a form of simplicity. It’s kind of the UNIX approach. I use Preact and a typed RPC client and a very simple router. The result is a reasonably small, easy-to-reason about program that I find very enjoyable to work on. If Preact shipped with their own communication layer and router, that would reduce the simplicity, and I’m not sure I’d actually like the choices they made for the part of the stack that is unrelated to rendering. Angular is an example of what you describe, and it’s not for me.
      - ryanbrunner 3y ago
        Sure, that's fine, I'm just saying they're not really directly comparable. A batteries included framework is an entirely different beast than a view library.
diggan 3y ago
Agree, too many believe in the silver-bullet that solves all their problems. Different problems require different solutions, it's kind of simple but hard to realize when you're deep into the woods. If you want to build a vector editor in the browser then yes, probably you want to leverage webassembly, canvas, webgl or whatever you fancy. But if you're building a more basic application (like most CRUD SaaS actually are) then probably you don't want to over-complicate it, as you instead want to be able to change and iterate quickly, so simplest tools and solutions gives you the most velocity for changes, until you've figured out the best way forward. Trouble is to recognize where on the scale of "Figma <> news.ycombinator.com" you should be, and it's hard to identify exactly where the line gets drawn where you can justify upfront technical innovation in favor of true-and-tested approaches.
- The_Colonel 3y ago
  I think there's a similar dynamic as behind "nobody got fired for choosing Oracle" - it's safer to choose a more complex, but also more flexible technology. If you're a tech lead, your worst nightmare is when you have to say - "this is very difficult to do with the current stack. When we were choosing this stack, we assumed you'll never want these things". You're not going to extract a binding promise from product/business that they will never want a certain class of things - you can only guess, and then hope, that the product will remain a dumb CRUD.
  - rezonant 3y ago
    This exactly. And with modern approaches (not that it's not without a fair amount of effort), you can achieve both an MPA style with SPA features via "isomorphic" JS (SSR).
    - ryanbrunner 3y ago
      The converse is also true, you can add a lot more interactivity than you used to in a server rendered HTML world with stuff like LiveView in Phoenix or Hotwire in the Rails world. I think a good heuristic is looking at whether the UX of your app feels more multi-page or single page, that should be a pretty big factor in your decision.
toasted-subs 3y ago
The core of what differentiates applications isn't what happens on the front end. Putting all the focus on the client which gets delivered seems like a misappropriation of funds. Especially as one man teams it just doesn't make sense. Any on teams with multiple people having relatively static HTML is a really effective abstraction.
ko27 3y ago
It's funny that you, and probably a lot of HN folk, consider MPA simpler than SPA. It's opposite in my experience. The name itself is actually telling you that it has more complexity (multi page vs single page). In practice, you can make both as complicated as you want, but SPA seems like a simpler starting point.
- rileymat2 3y ago
  The complications are not coming from the M or S part of the acronym, it comes from the words “Page” and “App” being intertwined. Or in other words 18 years of trying to hammer the web browser (conceived for “pages”) into an app platform.
- ryanbrunner 3y ago
  It can definitely seem this way if you only consider the front end. But a challenge that many SPA apps run into is that for the vast majority of SPA apps you end up in a situation where the front end and back end need to share business logic, and this can be a very complex thing to model and maintain, with either duplicated effort (and the potential of drift) or complicated solutions to keep them in sync, particularly if your front end and back end technologies aren't identical. Most MPA apps treat the browser and front end as dumb clients basically - strictly responsible for putting stuff on a screen
- sidlls 3y ago
  How is SPA a simpler starting point? It requires more code and more abstractions in the client from the onset. One might argue that that complexity would just exist in the backend in an MPA, but that's not true: there is some additional backend complexity, but not nearly as much as required to support the multitude of clients that exist for the baseline in an MPA.
  - lacerrr 3y ago
    Because in most web apps you still need to have client-side logic anyways, like form validation and such, so familiarizing yourself with a SPA framework is simpler than learning to implement this in addition to the MPA framework you'll probably end up using anyway.
dustingetz 3y ago
"the problem" "you should" – this is the language of special interests developers are salarymaxxing first, second virtue signaling to support their case in their employers' selection process, third work-minimization and pain-minimization. Even the Simplicity Paladins are min/maxxing the same three priorities, perhaps weighing pain-minimization above salarymaxxing, yet still subject to the same invisible macro forces that shape our lives. and I postulate that this is a complete explanation of developer behavior at scale.
- diggan 3y ago
  I feel like I understand 50% of your comment, is this some DSL from a different ecosystem being used to explain developer behavior, or something like that?
  - lacerrr 3y ago
    Lol, this is written in very game-like language where you often need to prioritize certain aspects (to max something) above others. This is often because you get a limited number of "ability points" when you level up, so "maxing" strength means you prioritize using those points to gain strength.
- JackMorgan 3y ago
  A great mental framework that holds up to my experience as well.
- seszett 3y ago
  I feel like we live in completely different worlds.
  - pi-e-sigma 3y ago
    You have never seen the resume-driven development? Lucky you, because it's the vast majority of development out there
    - 3y ago
traverseda 3y ago
For stuff like figma and photoshop I can't help but suspect that the creators would be better of writing their program in CPP with the GUI toolkit of their choice, and compiling it for the web with emscripten.
- diggan 3y ago
  I don't think that workflow was even a realistic option when Figma development was initiated, or even when it first launched.
  - traverseda 3y ago
    (300MB download warning) Here's an example of libreoffice running entirely in the browser: https://lab.allotropia.de/wasm/ https://lab.allotropia.de/wasm/ Once it does it's painfully long download and bootstrap it works pretty nicely. This is a big complicated legacy app, but I'm sure if reasonable file sizes and graceful loading was an actual goal you could get some pretty good results. Sure, it's not going to be as easy to hire for right now, but I think for complicated programs that general kind of workflow is likely to be better than the big pile of JS scripts. Google seems to think the same if flutter is any indication.
    - diggan 3y ago
      Are you saying that that was built back in 2016/2017?
- chilli_axe 3y ago
  The existing C++ Photoshop codebase was largely ported to WASM with Emscripten https://web.dev/articles/ps-on-the-web https://web.dev/articles/ps-on-the-web
- grose 3y ago
  I believe Figma is indeed written in C++ and uses emscripten. It's pretty much the polar opposite of your standard CRUD app. Old article: https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/ https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
christophilus 3y ago
That’s not why. In my experience, applications accumulate interactivity over time. At some point, they hit a threshold where you (as a developer— not an end user) wish you had gone with an interactive development model. Also, for me, the statically typed, component-based approach to UI development that I get with Preact is my favorite way to build UIs. I’ve used Rails, PHP, ASP (the og), ASP.NET, ASP.NET MVC, along with old-school native windows development in VB6, C# Winforms, whatever garbage Microsoft came up with after Winforms (I forget what it was called), and probably other stacks I’m forgetting. VB6 and C# Winforms were the peak of my productivity. But for the web, the UI model of Preact is my favorite.
- davidmurdoch 3y ago
  Styling with WPF (the thing after winforms) was so confusing, at least from someone coming from CSS.
  - christophilus 3y ago
    WPF. That was it. Yeah. It was terrible.
- zelphirkalt 3y ago
  I don't see why you cannot add interactivity later on. Frameworks like VueJS provide an easy way to deliver interactive widgets on a subset of rendered pages of a traditional website. If you need an API on the backend, you need to write that API one way or another anyway. This way people who are just looking for some information on a website can go visit, get, and leave, without having to enable intrusive JS blobs, while those in for the interative things on the website can get their preferred experience as well. Instead many websites are developed with only the second group in mind, often intentionally forcing you to run their code on your computer, or not delivering useful information at all.
jayceedenton 3y ago
This is motte-and-bailey argumentation in my opinion. The motte: SPAs are a good way to write highly complex applications in the browser, like Photoshop and Figma, to compete with desktop apps. The bailey: SPAs are a good way to write most web applications. If you attack the bailey, proponents retreat to the motte, which is hard to disagree with. With the motte successfully defended, proponents return to the bailey, beneficial for those enthusiastic about SPAs but much harder to defend. The only way to tease this issue apart is to stick to specifics and avoid casting SPAs or MPAs as universally good or bad. Show me the use-case and we can decide which route is best.
- danielvaughn 3y ago
  Or even avoid discussing SPAs or MPAs entirely. At the end of the day, we're talking about whether a specific interaction (or a set of interactions) can be handled over the network or not. If you need the interaction to fully resolve (as in the state is updated and the success or failure of the interaction is visible to the user) within 800ms or so, then it shouldn't be performed over the network. For interactive editors like Figma, you often have interactions based on key repeats, which usually fire at 50-200ms intervals. So client-side rendering is really the only feasible option.
  - zozbot234 3y ago
    > If you need the interaction to fully resolve (as in the state is updated and the success or failure of the interaction is visible to the user) within 800ms or so, then it shouldn't be performed over the network. Most real-world SPA sites perform a lot more roundtrips over the network than the MPA equivalent, not less. And every roundtrip adds yet another 800ms to your update latency, plus the risk that some random network failure will break the SPA state update and force you to reload it from scratch.
    - inopinatus 3y ago
      Those who do not remember Lotus Notes are doomed to reinvent it.
blackoil 3y ago
> The problem isn't so much those but how most developers lump themselves in with the incredibly interactive sites It is not only Figma or Photoshop. Any site with multiple steps of interactions or complex filters over search result etc. benefit from SPA and declarative code. The experience is smoother and development of anything, but simple forms is much faster. People disabling JS or working on satellite internet from a remote island are fringe cases and are not relevant for the business.
- xigoi 3y ago
  > People disabling JS or working on satellite internet from a remote island are fringe cases and are not relevant for the business. How about people working on a train?
  - christophilus 3y ago
    Their experience shouldn’t be much different on an SPA vs an MPA. If they can do an MPA round trip involving a medium-size image, then they should be able to load an SPA.
    - xigoi 3y ago
      SPAs often require an uninterrupted internet connection even if it’s not technically necessary.
      - worthless-trash 3y ago
        Many of them use 'websockets', which break when you have interrupted connectivity.
      - christophilus 3y ago
        That’s not been my experience, but you may be right. Why do they require an uninterrupted internet connection?
        3y ago
ksec 3y ago
From my brief look at my log and history usage and generally my estimate, 95%, or dare I say 99% in terms of my traffic could be a MPA. Currently the only site I go regularly that are JS SPAs are Feedly, Youtube, Discourse Forums and Twitter. And apart from Twitter the others could have been MPAs and still be perfectly fine. ( Although Youtube is debatable ) I did like to think 80-90% of the web population browsing usage dont deviate from mine that much. The thing about JS SPA is that they are hard to make it 100% right. Even the simplest thing. And this goes back to the topic about Web Development and computing. Modern day web is designed by Google for Google. Making things easier for 98% of the web simply isn't their thing. And that is not just on the Web but everything else they do as well. And since no one gets fired for using what Google uses, we then end up with additional tools to solve the complexity of what Google uses. Depending on how you count it we are now fast coming close to 20 years of Google dominance on the web. And there hasn't been a single day I didn't wish for an alternative to compete with them. I know this sounds stupid. But may be I should start another Yahoo.
- troupo 3y ago
  > Although Youtube is debatable It can definitely be an MPA. The only somewhat dynamic part it has is the comments. And now it's so egregiously bad that it's the single source of bad scores in Google's own metrics: https://twitter.com/dmitriid/status/1742669322487533801 https://twitter.com/dmitriid/status/1742669322487533801 and https://twitter.com/dmitriid/status/1742670032113402049 https://twitter.com/dmitriid/status/1742670032113402049 (yes, it loads 47KB of CSS/2.7 MB on desktop among other things)
  - ryanbrunner 3y ago
    There's the picture in picture stuff when you navigate away too. I recently did that with a MPA, and it was a not straightforward experience to get right.
    - bluefirebrand 3y ago
      It's kind of an awful experience though? Do people actually want their videos to follow them? If I'm navigating away it's because I'm done, it actually makes me kind of angry that the video chases me.
Yaina 3y ago
I think it's (increasingly) not as binary as either MPA or SPA. Although it has been for quite some time now. A lot of web developers strive for some amount of templating and client-side interactivity on their websites. And when frameworks like React came up they solved interactivity issues but made it hard to integrate into existing server-side templating systems, which were mostly using different programming languages. So because integrating the frameworks for client-side interactivity was hard, the frameworks also took on the job of templating the entire site and suddenly SPAs were popular. I think a big draw here was that the entire tooling became JavaScript. But the drawbacks were apparent, I guess a big one was that search engines could not index these sites and of course performance, so the frameworks got SSR support. The site was still written in the framework, rendered to HTML on the server and then hydrated back to a SPA on the client. Now, even more recently we got stuff like islands, where you still use the handy web framework but can choose which parts of your site should actually be interactive (i.e. hydrated) on the client. And I believe this is the capability that has just long been missing. Some sites require no JS on the client (could even be SSGs), others require a little interactivity, and some make most sense as full blown SPAs. We're finally entering the era where the developer has that choice even though they use the same underlying framework.
kgdiem 3y ago
> you should strive to make solutions that require the simplest tools possible whenever you can I’ve gone back to making MPA apps with minimal JS. It helps me actually ship my projects rather than tinkering and having an over complicated setup for mostly CRUD tasks. In one project that is a bit more data intensive and interactive I’m using Laravel Breeze / Laravel + inertajs (SSR react pages). I’m also a big fan of Jekyll lately, I made my own theme on Thursday with only 2 tiny scripts for the mobile menu and submission of the contact form. Using DOM APIs and managing a little bit of state is fine for many, many projects. OTOH when you don’t control the requirements and the business asks for a ton of stateful widgets progressive enhancement can become a mess of spaghetti in the UI and API unless very carefully managed and well thought out. At that point you might as well go all in on React/Angular/Vue, especially when you have to account for a mix of skill levels and turnover.
- jwells89 3y ago
  A big factor in that “tinkeriness” of SPAs is how nearly every part of making an SPA well-behaved and pleasant to use falls almost entirely on the shoulders of the developer. Due to how little browsers provide on that front, well-behaved polished SPAs are very much not on the happy path or default. Even if you use the big popular libraries, special care must be taken to not build a product that’s a frustrating mess for users. In comparison a server-side MPA will probably be at least decent to use unless the dev has been entirely careless, because that model better matches what browsers have been built for. The takeaway is that for SPAs to be consistently good for both devs and users, browsers need to do the bulk of the heavy lifting and provide a “happy path”, largely eliminating the need for overwrought JS libraries that try to paper over browser inadequacies.
  - kgdiem 3y ago
    Yes, can’t argue with that. Making apps for iOS and usually Android is often way more pleasant. Have you seen any serious proposals on this front?
    - jwells89 3y ago
palata 3y ago
> well what about Figma and Photoshop I, for one, don't want them rendered in my browser. I have an OS that can run apps, and I want my browser to be an app that renders simple HTML pages. If you want an app, make a damn Desktop app that can run on my OS.
- dstroot 3y ago
  Well… if you have ever supported a desktop app you know how difficult “version dispersion”, users that never update their OS, users that always update their OS, different hardware, other hostile software, etc. can be. If you know, you know.
  - palata 3y ago
    Sure, I'm not saying it's easier. It would be completely stupid to go down the webapps road if the desktop apps one was both better and easier. I kind of find it ironic, though: why not write one desktop app that only supports the latest version of Windows, and tell your users to use that? If you're big enough, surely you can force them to use the OS you want, right? I am convinced that most people who love webapps kind of hate the idea of being forced to use the latest version of Windows. But somehow they find it okay to force everyone to use Chromium? What's the difference?
  - skydhash 3y ago
    What I remember was mostly minimum and standard requirements listed on the product pages.
- throwitaway1123 3y ago
  I couldn't disagree more. Desktop apps are often so invasive that they almost feel like malware. Every time I install a desktop app I have to ensure that it isn't reading random files from my filesystem, snooping on my clipboard, or making itself persistent so that it restarts automatically every time I reboot my computer. Adobe apps like Photoshop are some of the worst offenders. Sometimes I'll kill an Adobe process running in the background, only to realize that there's an additional background process ready to restart the first one. It's like playing whack a mole trying to stop all of the creative cloud junk processes. I would much rather sandbox software like that in the browser where I can close a tab and be done with it (and where I'll be prompted before an app tries to read passwords from my clipboard or access files from my filesystem).
acdha 3y ago
> The problem isn't so much those but how most developers lump themselves in with the incredibly interactive sites because it sounds sexier and cooler to work on something complex than something simple. This is very similar to the NoSQL arc. Some people at prestigious places posted about some cool problems they had, and a generation of inexperienced developers started that they needed MongoDB and Cassandra to build a CRUD app with several orders of magnitude fewer users, transactions, or developers. One of the biggest things our field needs to mature on is the idea of focusing on the problem our users have rather than what would look cool when applying for a new job. The SPA obsession has been frustrating that way for me because I work with public-focused information-heavy sites where the benefits are usually negative and there’s a cost to users on older hardware – e.g. the median American user has JavaScript performance on par with an iPhone 6S so not requiring 4MB of JS to display text and pictures has real value – but that conflicts with hiring since every contractor is thinking about what’ll sound “modern” on their CV.
jauntywundrkind 3y ago
Simplest feels like a folly. No project of significance stays in a simple phase. They all grow and expand. Having a stable reliable generally applicable decision/toolset you can apply beats this hunt for optimization to smithereens. Don't optimize case by case. Optimize for your org, for your life, lean into good tools you can use universally and stop special casing your stuff. There's nearly no reason to complicate things by hounding for "simplicity." Other people won't be happier if you keep doing side quests for simple, and you won't be either. (Do learn to get good with a front-end router, so you can avoid >50% of the practical downsides of SPAs. And I hope over time I can recommend WebComponents as a good-for-all un-framework.)
amadeuspagel 3y ago
When you vote on a HN comment while writing a reply, it reloads and you lose your reply. That's the kind of problem you have with MPAs, even if you aren't building the next Figma.
yetanother12345 3y ago
> " ... is bringing to the table is the idea ..." Wikipedia states that "Keep it simple, stupid!", is a design principle first noted by the U.S. Navy in 1960 [0] ... but some coders, including yours truly, has been brought up with that principle as a keystone of programming from day one (which was decades ago). It is related to the more modern DRY principle. If this is brought to the table now it is only seemingly so, caused by the fact that those at the table must have forgot it, or never learned it. Of course, there are also commercial interests in keeping things as complicated as possible - it could just be that these have had too much influence for too long. [0] https://en.wikipedia.org/wiki/KISS_principle https://en.wikipedia.org/wiki/KISS_principle

endisneigh 3y ago

> you should strive for the simplest tool possible, and even further, you should strive to make solutions that require the simplest tools possible whenever you can. Why do you believe this? I couldn’t disagree more. People should strive for the most effective tool, and most of the time that’s what they already know, unless some new tools’ efficacy outweighs cost to learn it

ryanbrunner 3y ago
Fair point that my point was overly reductive. But given you understand multiple tools, you should reach for the simplest tool possible to solve the problem. And in some cases you should still reach for the simplest tool possible even if you don't understand it yet. If you've only ever used Kubernetes but someone asks you to host a static HTML file at an address, you should learn how to use a simpler solution for that.
Xeamek 3y ago
>most of the time that’s what they already know, unless some new tools effficacy outweighs cost to learn it ....which any proponent of the new tool will argue it does
- endisneigh 3y ago
  Yes which is why you should generally stick with what you know until you have an actual problem that needs solving… SPA, MPA, who cares. Ship.
  - Xeamek 3y ago
    That's not how anything in the world works though
    - endisneigh 3y ago
      Most professions do work like that, actually.
      - ryanbrunner 3y ago
        - Hammer, screwdriver, who cares, fix it. - Scalpel, forceps, who cares, do surgery. - Reinforced concrete, 2x4s, who cares, build a bridge. No, pretty much every profession that uses tools cares about using the correct tools for the job.
        endisneigh 3y ago
        Yea, tools and processes they’ve decided on decades ago. You don’t see these people writing blog posts about new tools and wasting time evaluating them yearly like in tech. If there’s an actual issue like there was with deaths in the medical profession due to not washing hands, then they evaluate.
        Xeamek 3y ago
        ...except those field are literally a thousands years old, while software industry is about 70? Them being more mature doesn't change the fact that processes and tools are crucial
        3y ago
deleted 3y ago
[deleted]
christophilus 3y ago
It also depends on your definition of simple. The architectural model of Preact is simple. You change state, your application renders correctly. The architectural model of an MPA with interactivity sprinkled in seems as simple, but quickly becomes more complex over time, and has ultimately not been as simple in my experience.
- ryanbrunner 3y ago
  Preact / React is simple because it solves for a very small slice of what an application needs to do and willfully ignores the rest. For example, (P)React has no real opinion on how it interacts with a server, which is a fundamental requirement of 99% of web applications (the new server components stuff is a counterargment I guess, but even then it doesn't consider the complexities of what a backend needs to do and is essentially a "put backend stuff here" slot) MPA frameworks tend to present themselves as complete and batteries included. If you're using Rails, you can build a complete application without thinking about a single other library than what Rails ships with. Neither approach is correct, but comparing them is like saying that HTML is so much simpler than C++ so everyone should use HTML.
  - christophilus 3y ago
    But, that is a form of simplicity. It’s kind of the UNIX approach. I use Preact and a typed RPC client and a very simple router. The result is a reasonably small, easy-to-reason about program that I find very enjoyable to work on. If Preact shipped with their own communication layer and router, that would reduce the simplicity, and I’m not sure I’d actually like the choices they made for the part of the stack that is unrelated to rendering. Angular is an example of what you describe, and it’s not for me.
    - ryanbrunner 3y ago
      Sure, that's fine, I'm just saying they're not really directly comparable. A batteries included framework is an entirely different beast than a view library.

diggan 3y ago

Agree, too many believe in the silver-bullet that solves all their problems. Different problems require different solutions, it's kind of simple but hard to realize when you're deep into the woods. If you want to build a vector editor in the browser then yes, probably you want to leverage webassembly, canvas, webgl or whatever you fancy. But if you're building a more basic application (like most CRUD SaaS actually are) then probably you don't want to over-complicate it, as you instead want to be able to change and iterate quickly, so simplest tools and solutions gives you the most velocity for changes, until you've figured out the best way forward. Trouble is to recognize where on the scale of "Figma <> news.ycombinator.com" you should be, and it's hard to identify exactly where the line gets drawn where you can justify upfront technical innovation in favor of true-and-tested approaches.

The_Colonel 3y ago
I think there's a similar dynamic as behind "nobody got fired for choosing Oracle" - it's safer to choose a more complex, but also more flexible technology. If you're a tech lead, your worst nightmare is when you have to say - "this is very difficult to do with the current stack. When we were choosing this stack, we assumed you'll never want these things". You're not going to extract a binding promise from product/business that they will never want a certain class of things - you can only guess, and then hope, that the product will remain a dumb CRUD.
- rezonant 3y ago
  This exactly. And with modern approaches (not that it's not without a fair amount of effort), you can achieve both an MPA style with SPA features via "isomorphic" JS (SSR).
  - ryanbrunner 3y ago
    The converse is also true, you can add a lot more interactivity than you used to in a server rendered HTML world with stuff like LiveView in Phoenix or Hotwire in the Rails world. I think a good heuristic is looking at whether the UX of your app feels more multi-page or single page, that should be a pretty big factor in your decision.

toasted-subs 3y ago

The core of what differentiates applications isn't what happens on the front end. Putting all the focus on the client which gets delivered seems like a misappropriation of funds. Especially as one man teams it just doesn't make sense. Any on teams with multiple people having relatively static HTML is a really effective abstraction.

ko27 3y ago

It's funny that you, and probably a lot of HN folk, consider MPA simpler than SPA. It's opposite in my experience. The name itself is actually telling you that it has more complexity (multi page vs single page). In practice, you can make both as complicated as you want, but SPA seems like a simpler starting point.

rileymat2 3y ago
The complications are not coming from the M or S part of the acronym, it comes from the words “Page” and “App” being intertwined. Or in other words 18 years of trying to hammer the web browser (conceived for “pages”) into an app platform.
ryanbrunner 3y ago
It can definitely seem this way if you only consider the front end. But a challenge that many SPA apps run into is that for the vast majority of SPA apps you end up in a situation where the front end and back end need to share business logic, and this can be a very complex thing to model and maintain, with either duplicated effort (and the potential of drift) or complicated solutions to keep them in sync, particularly if your front end and back end technologies aren't identical. Most MPA apps treat the browser and front end as dumb clients basically - strictly responsible for putting stuff on a screen
sidlls 3y ago
How is SPA a simpler starting point? It requires more code and more abstractions in the client from the onset. One might argue that that complexity would just exist in the backend in an MPA, but that's not true: there is some additional backend complexity, but not nearly as much as required to support the multitude of clients that exist for the baseline in an MPA.
- lacerrr 3y ago
  Because in most web apps you still need to have client-side logic anyways, like form validation and such, so familiarizing yourself with a SPA framework is simpler than learning to implement this in addition to the MPA framework you'll probably end up using anyway.

dustingetz 3y ago

"the problem" "you should" – this is the language of special interests developers are salarymaxxing first, second virtue signaling to support their case in their employers' selection process, third work-minimization and pain-minimization. Even the Simplicity Paladins are min/maxxing the same three priorities, perhaps weighing pain-minimization above salarymaxxing, yet still subject to the same invisible macro forces that shape our lives. and I postulate that this is a complete explanation of developer behavior at scale.

diggan 3y ago
I feel like I understand 50% of your comment, is this some DSL from a different ecosystem being used to explain developer behavior, or something like that?
- lacerrr 3y ago
  Lol, this is written in very game-like language where you often need to prioritize certain aspects (to max something) above others. This is often because you get a limited number of "ability points" when you level up, so "maxing" strength means you prioritize using those points to gain strength.
JackMorgan 3y ago
A great mental framework that holds up to my experience as well.
seszett 3y ago
I feel like we live in completely different worlds.
- pi-e-sigma 3y ago
  You have never seen the resume-driven development? Lucky you, because it's the vast majority of development out there
  - 3y ago

traverseda 3y ago

For stuff like figma and photoshop I can't help but suspect that the creators would be better of writing their program in CPP with the GUI toolkit of their choice, and compiling it for the web with emscripten.

diggan 3y ago
I don't think that workflow was even a realistic option when Figma development was initiated, or even when it first launched.
- traverseda 3y ago
  (300MB download warning) Here's an example of libreoffice running entirely in the browser: https://lab.allotropia.de/wasm/ https://lab.allotropia.de/wasm/ Once it does it's painfully long download and bootstrap it works pretty nicely. This is a big complicated legacy app, but I'm sure if reasonable file sizes and graceful loading was an actual goal you could get some pretty good results. Sure, it's not going to be as easy to hire for right now, but I think for complicated programs that general kind of workflow is likely to be better than the big pile of JS scripts. Google seems to think the same if flutter is any indication.
  - diggan 3y ago
    Are you saying that that was built back in 2016/2017?
chilli_axe 3y ago
The existing C++ Photoshop codebase was largely ported to WASM with Emscripten https://web.dev/articles/ps-on-the-web https://web.dev/articles/ps-on-the-web
grose 3y ago
I believe Figma is indeed written in C++ and uses emscripten. It's pretty much the polar opposite of your standard CRUD app. Old article: https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/ https://www.figma.com/blog/webassembly-cut-figmas-load-time-...

christophilus 3y ago

That’s not why. In my experience, applications accumulate interactivity over time. At some point, they hit a threshold where you (as a developer— not an end user) wish you had gone with an interactive development model. Also, for me, the statically typed, component-based approach to UI development that I get with Preact is my favorite way to build UIs. I’ve used Rails, PHP, ASP (the og), ASP.NET, ASP.NET MVC, along with old-school native windows development in VB6, C# Winforms, whatever garbage Microsoft came up with after Winforms (I forget what it was called), and probably other stacks I’m forgetting. VB6 and C# Winforms were the peak of my productivity. But for the web, the UI model of Preact is my favorite.

davidmurdoch 3y ago
Styling with WPF (the thing after winforms) was so confusing, at least from someone coming from CSS.
- christophilus 3y ago
  WPF. That was it. Yeah. It was terrible.
zelphirkalt 3y ago
I don't see why you cannot add interactivity later on. Frameworks like VueJS provide an easy way to deliver interactive widgets on a subset of rendered pages of a traditional website. If you need an API on the backend, you need to write that API one way or another anyway. This way people who are just looking for some information on a website can go visit, get, and leave, without having to enable intrusive JS blobs, while those in for the interative things on the website can get their preferred experience as well. Instead many websites are developed with only the second group in mind, often intentionally forcing you to run their code on your computer, or not delivering useful information at all.

jayceedenton 3y ago

This is motte-and-bailey argumentation in my opinion. The motte: SPAs are a good way to write highly complex applications in the browser, like Photoshop and Figma, to compete with desktop apps. The bailey: SPAs are a good way to write most web applications. If you attack the bailey, proponents retreat to the motte, which is hard to disagree with. With the motte successfully defended, proponents return to the bailey, beneficial for those enthusiastic about SPAs but much harder to defend. The only way to tease this issue apart is to stick to specifics and avoid casting SPAs or MPAs as universally good or bad. Show me the use-case and we can decide which route is best.

danielvaughn 3y ago
Or even avoid discussing SPAs or MPAs entirely. At the end of the day, we're talking about whether a specific interaction (or a set of interactions) can be handled over the network or not. If you need the interaction to fully resolve (as in the state is updated and the success or failure of the interaction is visible to the user) within 800ms or so, then it shouldn't be performed over the network. For interactive editors like Figma, you often have interactions based on key repeats, which usually fire at 50-200ms intervals. So client-side rendering is really the only feasible option.
- zozbot234 3y ago
  > If you need the interaction to fully resolve (as in the state is updated and the success or failure of the interaction is visible to the user) within 800ms or so, then it shouldn't be performed over the network. Most real-world SPA sites perform a lot more roundtrips over the network than the MPA equivalent, not less. And every roundtrip adds yet another 800ms to your update latency, plus the risk that some random network failure will break the SPA state update and force you to reload it from scratch.
  - inopinatus 3y ago
    Those who do not remember Lotus Notes are doomed to reinvent it.

blackoil 3y ago

> The problem isn't so much those but how most developers lump themselves in with the incredibly interactive sites It is not only Figma or Photoshop. Any site with multiple steps of interactions or complex filters over search result etc. benefit from SPA and declarative code. The experience is smoother and development of anything, but simple forms is much faster. People disabling JS or working on satellite internet from a remote island are fringe cases and are not relevant for the business.

xigoi 3y ago
> People disabling JS or working on satellite internet from a remote island are fringe cases and are not relevant for the business. How about people working on a train?
- christophilus 3y ago
  Their experience shouldn’t be much different on an SPA vs an MPA. If they can do an MPA round trip involving a medium-size image, then they should be able to load an SPA.
  - xigoi 3y ago
    SPAs often require an uninterrupted internet connection even if it’s not technically necessary.
    - worthless-trash 3y ago
      Many of them use 'websockets', which break when you have interrupted connectivity.
    - christophilus 3y ago
      That’s not been my experience, but you may be right. Why do they require an uninterrupted internet connection?
      - 3y ago

ksec 3y ago

From my brief look at my log and history usage and generally my estimate, 95%, or dare I say 99% in terms of my traffic could be a MPA. Currently the only site I go regularly that are JS SPAs are Feedly, Youtube, Discourse Forums and Twitter. And apart from Twitter the others could have been MPAs and still be perfectly fine. ( Although Youtube is debatable ) I did like to think 80-90% of the web population browsing usage dont deviate from mine that much. The thing about JS SPA is that they are hard to make it 100% right. Even the simplest thing. And this goes back to the topic about Web Development and computing. Modern day web is designed by Google for Google. Making things easier for 98% of the web simply isn't their thing. And that is not just on the Web but everything else they do as well. And since no one gets fired for using what Google uses, we then end up with additional tools to solve the complexity of what Google uses. Depending on how you count it we are now fast coming close to 20 years of Google dominance on the web. And there hasn't been a single day I didn't wish for an alternative to compete with them. I know this sounds stupid. But may be I should start another Yahoo.

troupo 3y ago
> Although Youtube is debatable It can definitely be an MPA. The only somewhat dynamic part it has is the comments. And now it's so egregiously bad that it's the single source of bad scores in Google's own metrics: https://twitter.com/dmitriid/status/1742669322487533801 https://twitter.com/dmitriid/status/1742669322487533801 and https://twitter.com/dmitriid/status/1742670032113402049 https://twitter.com/dmitriid/status/1742670032113402049 (yes, it loads 47KB of CSS/2.7 MB on desktop among other things)
- ryanbrunner 3y ago
  There's the picture in picture stuff when you navigate away too. I recently did that with a MPA, and it was a not straightforward experience to get right.
  - bluefirebrand 3y ago
    It's kind of an awful experience though? Do people actually want their videos to follow them? If I'm navigating away it's because I'm done, it actually makes me kind of angry that the video chases me.

Yaina 3y ago

I think it's (increasingly) not as binary as either MPA or SPA. Although it has been for quite some time now. A lot of web developers strive for some amount of templating and client-side interactivity on their websites. And when frameworks like React came up they solved interactivity issues but made it hard to integrate into existing server-side templating systems, which were mostly using different programming languages. So because integrating the frameworks for client-side interactivity was hard, the frameworks also took on the job of templating the entire site and suddenly SPAs were popular. I think a big draw here was that the entire tooling became JavaScript. But the drawbacks were apparent, I guess a big one was that search engines could not index these sites and of course performance, so the frameworks got SSR support. The site was still written in the framework, rendered to HTML on the server and then hydrated back to a SPA on the client. Now, even more recently we got stuff like islands, where you still use the handy web framework but can choose which parts of your site should actually be interactive (i.e. hydrated) on the client. And I believe this is the capability that has just long been missing. Some sites require no JS on the client (could even be SSGs), others require a little interactivity, and some make most sense as full blown SPAs. We're finally entering the era where the developer has that choice even though they use the same underlying framework.

kgdiem 3y ago

> you should strive to make solutions that require the simplest tools possible whenever you can I’ve gone back to making MPA apps with minimal JS. It helps me actually ship my projects rather than tinkering and having an over complicated setup for mostly CRUD tasks. In one project that is a bit more data intensive and interactive I’m using Laravel Breeze / Laravel + inertajs (SSR react pages). I’m also a big fan of Jekyll lately, I made my own theme on Thursday with only 2 tiny scripts for the mobile menu and submission of the contact form. Using DOM APIs and managing a little bit of state is fine for many, many projects. OTOH when you don’t control the requirements and the business asks for a ton of stateful widgets progressive enhancement can become a mess of spaghetti in the UI and API unless very carefully managed and well thought out. At that point you might as well go all in on React/Angular/Vue, especially when you have to account for a mix of skill levels and turnover.

jwells89 3y ago
A big factor in that “tinkeriness” of SPAs is how nearly every part of making an SPA well-behaved and pleasant to use falls almost entirely on the shoulders of the developer. Due to how little browsers provide on that front, well-behaved polished SPAs are very much not on the happy path or default. Even if you use the big popular libraries, special care must be taken to not build a product that’s a frustrating mess for users. In comparison a server-side MPA will probably be at least decent to use unless the dev has been entirely careless, because that model better matches what browsers have been built for. The takeaway is that for SPAs to be consistently good for both devs and users, browsers need to do the bulk of the heavy lifting and provide a “happy path”, largely eliminating the need for overwrought JS libraries that try to paper over browser inadequacies.
- kgdiem 3y ago
  Yes, can’t argue with that. Making apps for iOS and usually Android is often way more pleasant. Have you seen any serious proposals on this front?
  - jwells89 3y ago

palata 3y ago

> well what about Figma and Photoshop I, for one, don't want them rendered in my browser. I have an OS that can run apps, and I want my browser to be an app that renders simple HTML pages. If you want an app, make a damn Desktop app that can run on my OS.

dstroot 3y ago
Well… if you have ever supported a desktop app you know how difficult “version dispersion”, users that never update their OS, users that always update their OS, different hardware, other hostile software, etc. can be. If you know, you know.
- palata 3y ago
  Sure, I'm not saying it's easier. It would be completely stupid to go down the webapps road if the desktop apps one was both better and easier. I kind of find it ironic, though: why not write one desktop app that only supports the latest version of Windows, and tell your users to use that? If you're big enough, surely you can force them to use the OS you want, right? I am convinced that most people who love webapps kind of hate the idea of being forced to use the latest version of Windows. But somehow they find it okay to force everyone to use Chromium? What's the difference?
- skydhash 3y ago
  What I remember was mostly minimum and standard requirements listed on the product pages.
throwitaway1123 3y ago
I couldn't disagree more. Desktop apps are often so invasive that they almost feel like malware. Every time I install a desktop app I have to ensure that it isn't reading random files from my filesystem, snooping on my clipboard, or making itself persistent so that it restarts automatically every time I reboot my computer. Adobe apps like Photoshop are some of the worst offenders. Sometimes I'll kill an Adobe process running in the background, only to realize that there's an additional background process ready to restart the first one. It's like playing whack a mole trying to stop all of the creative cloud junk processes. I would much rather sandbox software like that in the browser where I can close a tab and be done with it (and where I'll be prompted before an app tries to read passwords from my clipboard or access files from my filesystem).

acdha 3y ago

> The problem isn't so much those but how most developers lump themselves in with the incredibly interactive sites because it sounds sexier and cooler to work on something complex than something simple. This is very similar to the NoSQL arc. Some people at prestigious places posted about some cool problems they had, and a generation of inexperienced developers started that they needed MongoDB and Cassandra to build a CRUD app with several orders of magnitude fewer users, transactions, or developers. One of the biggest things our field needs to mature on is the idea of focusing on the problem our users have rather than what would look cool when applying for a new job. The SPA obsession has been frustrating that way for me because I work with public-focused information-heavy sites where the benefits are usually negative and there’s a cost to users on older hardware – e.g. the median American user has JavaScript performance on par with an iPhone 6S so not requiring 4MB of JS to display text and pictures has real value – but that conflicts with hiring since every contractor is thinking about what’ll sound “modern” on their CV.

jauntywundrkind 3y ago

Simplest feels like a folly. No project of significance stays in a simple phase. They all grow and expand. Having a stable reliable generally applicable decision/toolset you can apply beats this hunt for optimization to smithereens. Don't optimize case by case. Optimize for your org, for your life, lean into good tools you can use universally and stop special casing your stuff. There's nearly no reason to complicate things by hounding for "simplicity." Other people won't be happier if you keep doing side quests for simple, and you won't be either. (Do learn to get good with a front-end router, so you can avoid >50% of the practical downsides of SPAs. And I hope over time I can recommend WebComponents as a good-for-all un-framework.)

amadeuspagel 3y ago

When you vote on a HN comment while writing a reply, it reloads and you lose your reply. That's the kind of problem you have with MPAs, even if you aren't building the next Figma.

yetanother12345 3y ago

> " ... is bringing to the table is the idea ..." Wikipedia states that "Keep it simple, stupid!", is a design principle first noted by the U.S. Navy in 1960 [0] ... but some coders, including yours truly, has been brought up with that principle as a keystone of programming from day one (which was decades ago). It is related to the more modern DRY principle. If this is brought to the table now it is only seemingly so, caused by the fact that those at the table must have forgot it, or never learned it. Of course, there are also commercial interests in keeping things as complicated as possible - it could just be that these have had too much influence for too long. [0] https://en.wikipedia.org/wiki/KISS_principle https://en.wikipedia.org/wiki/KISS_principle