10 ms·
The myth that you can’t build interactive web apps except as single page app
- satyanash 2y agoFull title is "You Can't Build Interactive Web Apps Except as Single Page Applications... And Other Myths" Omission of trailing part changes the meaning and makes it clickbaity.
- gherkinnn 2y agoYou are right. The original title was too long for HN. I have since edited it to fit inside the requirements while keeping the spirit.
- notjoemama 2y agoIt’s fine. I don’t see the click-bait-ness of what the other person is talking about. Especially since I’ve run into the title length limit before. Some people have bad days and are more (overly?) critical.
- bbor 2y ago“You Can't Build Interactive Web Apps Except as Single Page Applications” is false, which would make that title clickbait, specifically of the “ragebait” family. You obviously shouldn't build interactive pure-HTML apps, but that’s a talk for another day ;)
- LeanderK 2y agoI am no frontend-guy, so I don't understand why in the age of node.js web-servers this ditchonomy exists between server-side and client side (SPA). Can't you initialise/pre-render most of your your stuff on the server, serialise it and push it through the client, which then acts as an SPA already initialised and then updates itself on its own. After all, both are JS? Why is the decision not more flexible where to run code, depending on latency, compute intensity etc. Maybe someone can enlighten me, as this is often left out, probably because it is obvious to someone working with these technologies.
- the__alchemist 2y agoI'm answering your initial question directly, but there is more going on that may be more informative. This is a distinction between computation that is performed on a server, using arbitrary tools, and computation run on a user's machine locally. The former is much more flexible, but comes at a cost of latency; all user input and output must be serialized, and transmitted a long distance. Front end code can result in much lower latency to the user due to ommitting this transmission. It makes sense to apply a suitable mix of these two tools that varies based on an application's details. For example, an immediate UI response that can be performed using only information already present on the client makes sense to be handled exclusively there, as computation time is minimal compared to transmission and serializtion. I believe that JS being able to be used on a server is not relevant to the core distinction.
- Terretta 2y agoThough, as most apps are built, only the code run on the server can be trusted, and only the response processing performed on the server can be trusted.
- do_not_redeem 2y agoYou can! The terms to search for are "isomorphic web apps" and "hydration". It's definitely not a panacea though. https://react.dev/reference/react-dom/client/hydrateRoot https://react.dev/reference/react-dom/client/hydrateRoot
- 2y ago
- nsonha 2y agoDo I have to point out that "you can do X without Y" is never an interesting nor insightful statement? No shit! so? Does that mean you should do X without Y?
- zdragnar 2y agoThis is largely code for "I used to slap shit together and nobody told me I did a bad job. Now I slap shit together and people tell me it's just shit slapped together and I don't like that." The real gradient is more like: 1) a SPA is needed because it might have to run offline 2) A SPA is extremely beneficial because the state of complex interactive are difficult to maintain on the server 3) A SPA helps because we have complex interactions and want to keep the server stateless 4) A SPA is used because we only have developers who haven't done it any other way and won't be fast enough trying something new 5) A SPA is strictly detrimental and ought not be used because there aren't any complex interactions and the added weight to processing / network traffic / etc overwhelm whatever justification we had. This is not really novel, newsworthy or even worth yet another rambling blog post.
- danaris 2y agoIt's interesting when the common wisdom is that you cannot do X without Y.
- nsonha 2y agoNo the common wisdom is that you should not...
- itronitron 2y agoDoing X without Y seems very one-dimensional though.
- flappyeagle 2y agoThis kind of stuff misses the entire point of frameworks like react or rails for that matter There might be some technical advantages you can argue but there’s an undeniable economic advantage to not needing to make a bunch of disparate choices and wire things up in a way that you hope will not bit you in the ass later.
- austin-cheney 2y agoTest automation.
- pier25 2y ago> I like to argue that some of the most productive days of the web were the PHP and JQuery spaghetti days I've wondered if going back to that paradigm would be more productive or not than using React et al. Plenty of big sites like Amazon or Steam still are made this way. Not exactly PHP + jQuery but rendering HTML on the server and sprinkling some JS on top of it. Has anyone gone back to working like that?
- the__alchemist 2y agoI use this general approach in most cased.
- WD-42 2y agoI just finished migrating a fairly large legacy vue2 app to server side rendering and HTMX. Its thousands of lines less code and also hundreds if not thousands less dependencies. Most importantly I’m not worried about the tech stack becoming abandoned and un updatable in 5 years like vue2 was. There are some pages that require more local state. Alpine.js has been great. It’s like Vuejs that you can initialize on your page and doesn’t require a build step.
- Jaygles 2y agoHow much of that code and dependency reduction is due to having the entire app to use as a spec? How can you be so sure this new stack won't be "abandoned"? (Vue has received regular updates for 11 years)
- WD-42 2y agoVue 2.x is NOT receiving updates. Not even security updates. Its abandonware. I had to ask myself if it was worth the hassle to update to 3.x and risk the same thing happening again. The answer was no. The new stack is Django (which the backend was already written in). Will it stop receiving updates? Extremely unlikely, conserving they have been preserving upgrade paths for the last 20 years and has a solid foundation supporting it. The supporting ui libraries like htmx and alpine could conceivably become abandoned. The big difference is that they can be vendored easily. I checked the vue project and it has 1500 transitive dependencies. The new “stack” has a whopping total of 7. On top of that there is no build step to maintain. Also it’s straight up way faster.
- mh-cx 2y agoI wonder why the article doesn't mention utilizing the browser cache for your static CSS and JS assets instead of introducing a service worker as first measure. Few years ago I built a shopping site MPA this way and the page transitions were almost not noticable.
- jdsleppy 2y agoSame (but not a shopping site). Bundle the JS and CSS into one file each and cache it forever (hash in the filename to bust the cache). Then with each page transition there's exactly one HTTP request to fetch a small amount of HTML and it's done. So fast and simple.
- mh-cx 2y agoExactly this. In our case we went so far to cache all static assets. Putting them into a directory with a hash in the name made them still easy to bust. # Cache static files location ~* \.(ico|css|js|gif|jpe?g|png|svg|woff|woff2)$ { expires 365d; add_header Pragma public; add_header Cache-Control "public"; proxy_pass http://127.0.0.1:9000; }
- wmfiv 2y agoThis has been the common/best practice for so long I don't understand why TFA is proposing something different.
- youngtaff 2y agoCache control directives indicate how long a browser, proxy etc can store a resource for… they don’t guarantee they will store it for that long though Control over Service Workers cache lifetime is more explicit I’d still specify ‘good’ cache lifetimes though
- wmfiv 2y agoMakes sense as a theoretical problem. Have you ever seen data that suggests it's a practical problem? Seems like one could identify "should be cached forever but wasn't" using etag data in logs.
- KronisLV 2y agoTo me it seems that if you have decent cache control headers, then SSR can be decent even without very specific optimizations. When choosing a tech stack, normally I’d also look for which one rots the slowest. Writing a SPA will typically mean that in the case of the libraries/frameworks there becoming untenable, at least you have an API that you can use when writing a new client. I have this PrimeFaces/JSF project at work - it’s unpleasant to work with and feels brittle (especially when you have to update components, in addition to nested table row updates being pretty difficult). I’ve also helped migrate an AngularJS project to Vue, the former was less pleasant to use than the latter but the migration itself was also unpleasant, especially when you wanted to get close to 1:1 the functionality. I like how Angular feels more batteries included than the other options, but I’ve seen some overabstracted codebases. React seems like it has the largest ecosystem but the codebases seem to rot pretty quickly (lots of separate libraries for the typical project, lots of updates, things sometimes break). The likes of Laravel and Rails let you be pretty productive but also have pretty tight coupling to the rest of the codebase, same as with PrimeFaces/JSF. I’ve also seen attempts at putting as much logic in the DB as possible and using the back end as more or less only the view layer, it was blazing fast but debugging was a nightmare. Honestly, just pick whatever technology you think will make the people working with the project in 5 years the least miserable. For me, often that is something for a SPA, a RESTful web API, some boring back end technology that connects to a relational database (sometimes SQLite, sometimes PostgreSQL, sometimes MariaDB; hopefully not Oracle). Whatever you do, try not to end up in circumstances where you can only run a front end with Node.js 10 or where you can't update your Spring or ASP.NET version due to there being breaking changes in your coupled front end technology.
- dnndev 2y agoThe only reason to use spa as far as I am concerned is that’s the way the industry was going 10 years ago… so the community and controls etc… were / are for spas.. any other reason to me was just chasing new tech. I made the switch and the community it stronger than ever for vuejs and react
- em-bee 2y agowhen i discovered angularjs i thought it was a revelation. finally i could write webapps without having to track UI state in the backend, only treat the backend like a database. all the UI logic was dramatically simplified. it went so far as making my backend so reusable that i don't have to do any backend coding at all anymore. creating a complex webapp is now as simple as writing a desktop client. sure, i could do the same thing with a traditional fullstack framework. with discipline i would be able to keep frontend and backend code separate. but i have yet to work on a project where that is the case. i don't build SPAs because the industry demands it. i build SPAs since before the industry even heard about it. and i build them because they make for a cleaner architecture and give me more flexibility than any fullstack framework would.
- recursivedoubts 2y agoThe HN headline is more combative than the actual headline: You Can't Build Interactive Web Apps Except as Single Page Applications... And Other Myths This is an essay contributed by Tony Alaribe, based on his talk at BigSkyDevCon this past year, discussing techniques to make a non-SPA based web application feel fast and slick. He mentioned some techniques that were new to me and I thought it was the best talk at the conference.
- justinko 2y agoThe most dangerous thing in programming is developer boredom with a dash of hubris and ignorance of the past.
- deleted 2y ago[deleted]
- pino82 2y agoMy feeling nowadays (i.e. since around a decade maybe) is that there is a lot of technical complexity going on which should imho be either an internal part of the browser itself, or should not be used that widely. It's probably all good for something... But I would love to just make my web app out of what the browser itself can do, without a tech stack as high as a skyscraper for me to handle. I know, this way the ecosystem can develop more rapidly (compared to waiting for improvements in the official web standards), and it's also fun to play with toys, and everyone can raise his/her value by learning more and more of these tools. On the other hand, the web was imho in a better shape before all that began. From user perspective and from developer perspective. I could be wrong... I'm not primarily a web developer at all...
- deleted 2y ago[deleted]
- throwaway984393 2y ago[dead]
- 0xbadcafebee 2y agoI dream of the day that we are finally free of the iron grip the web browser has on the minds of those that would create the future of technology.
- breckenedge 2y agoWell there was this idea about 16, 17 years ago called “Rich Internet Applications.” It flopped for many reasons. https://en.m.wikipedia.org/wiki/Rich_Internet_Application https://en.m.wikipedia.org/wiki/Rich_Internet_Application
- jonahx 2y agoCan someone explain what the service worker strategy accomplishes that plain old http Cache headers don't? It saves a (almost zero weight) network roundtrip, but feels like it's re-inventing the entire wheel for that small (I think) optimization? Am I missing something?
- ysofunny 2y agothat they can be used to compute stuff locally I imagine ideally we want user choice of where the computation is happening. if on a mobile device I'd save battery in exchange for network latency but in a desktop computer I'd rather do as most local computation as I can
- bathtub365 2y agoRadio is one of the biggest users of battery on mobile devices.
- jonahx 2y agoI'm not asking about web workers generally. I'm specifically asking about their use as a client side cache as described in the article.
- plorkyeran 2y agoFor the sort of thing that are fast enough that network latency is relevant, on a mobile device you save battery by doing them locally. The radio takes more power than the cpu.
- deleted 2y ago[deleted]
- alganet 2y agoIt was designed for apps, extensions and pages that behave like apps (stuff that might not have a server anywhere, just a manifest and some static HTML/JS). The cache is only one of the use cases. I think some pages still use them for running background stuff. My browser is setup to clear all of them upon closing the tab. This whole direction is being silently discontinued anyway. Running browser apps has become harder, not easier.
- easeout 2y agoThe final spaghetti point really takes the wind out of this article's sails. A lot of it is good information, but too many parts make me think "That's a stretch."
- ThalesX 2y agoI have some "internal" web apps that I use for myself, and while I do use Remix which is a framework that allows me to use React, I just use SSR and HTML default form controls as interpreted by the browsers, minimal client side processing and almost no styling. I love it so much compared to the "modern" cruft. It's responsive by default because I don't really style it. It has a high signal to noise ratio. I wouldn't change it for the world, but I've been told multiple times I'm very much in the minority.
- amelius 2y ago> The myth that you can’t build interactive web apps except as single page app You can do it, but you might paint yourself into a corner. For example, your manager might at some point say: please load X, while Y is animating; that will not work if the entire page is reloading. A SPA will give you more control and will also reduce the probability of having to rework entire parts of the code.
- tonetheman 2y ago[dead]
- peutetre 2y agoJust do it all in WebAssembly. WebAssembly is pretty great. Here's an example: https://bandysc.github.io/AvaloniaVisualBasic6/ https://bandysc.github.io/AvaloniaVisualBasic6/
- jiggawatts 2y agoThat's precisely what dotnet Blazor does: https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blazor https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...
- xnx 2y agoEven preceding the tech stack decision, many devs err when they misunderstand what they are writing. GMail, Google Sheets, Google Docs, etc. are apps, if you don't need that level of interactivity, it's probably just a crud app (AirBnB, Craigslist, ecommerce, etc.) and you'd be fine with more a mostly server-side framework.
- lmm 2y agoOk but what's the benefit? Yes, if you really want to, you can carve your validation logic in half, write two different kinds of JavaScript and CSS, so that you can change screens in two technically different ways. But the only thing it will accomplish is making your app harder to maintain, and probably slower to boot.
- pahbloo 2y agoPeople treat SPA and MPA as oposing teams, one is the right way and the other is garbage. But this is not how it must be seen. What we have is the natural way to do things with web stack (the way it's is mean to be used), and the "hacky way" (the way that let us do what we want to do, even when the web stack doesn't support it yet). SPA is the hacky way today, but before it we had CGI, Java applets, Flash... And the web purists were always very vocal against the hacky way. But the hacky way is what pushs the envelope of what the natural way can do. Every feature cited in the article that makes an MPA competitive with an SPA today only exists because of SPAs. I'm on the side of preferencially use the web the way it's meant to use whenever it's possible, but I love to see what can be done when we are a little hacky, and it's awesome to see the web stack adapting to do these things in a less hacky way.
- em-bee 2y agoi absolutely disagree that SPA should be considered hacky. as i already wrote here: https://news.ycombinator.com/item?id=42165046 https://news.ycombinator.com/item?id=42165046 i find SPAs a much cleaner way to write web applications.