> And, contra what Mr. Harris says, today the trend is not obviously in javascripts favor. Five years ago, we, as founding members of the javascript resistance, were despairing of any hope of stopping the Javascript juggernaut. But then something unexpected happened: Python took off and, at the same time, javascript flat lined:
Why yes... if you use Stack Overflow usage as your measurement.
The problem is that doesn't tell you anything about JavaScript or Python... except whom is using Stack Overflow.
As a JavaScript developer (primarily), I use Stack Overflow far less than I did in years past, not just because I need less help in general as a senior, but because SO is so littered with JS answers that are outdated, poor quality, and conflate JavaScript with jQuery, that it's simply not worth using 99% of the time because MDN provides excellent documentation.
It's been a while since I've used Python, so maybe things have changed, but I remember the documentation not being comparable. It's good documentation, but MDN is excellent.
I'm not saying that either one is better, but that to use Stack Overflow trends to prove a point seems very fallacious. By that point I couldn't finish the rest of the article.
The good news is that there wasn't much left in the article save a silly meme. Although perhaps this is worth pondering:
> We are fond of talking about the HOWL stack: Hypermedia On Whatever you'd Like. The idea is that, by returning to a (more powerful) Hypermedia Architecture, you can use whatever backend language you'd like: python, lisp, haskell, go, java, c#, whatever. Even javascript, if you like. There's no accounting for taste, after all. Since you are using hypermedia & HTML for your server interactions, you don't feel that pressure to adopt javascript on the backend that a huge javascript front end produces. You can still use javascript, of course, (perhaps in the form of alpine) but you use it in the manner it was originally intended: as a light, front end scripting language for enhancing your application. Or, if you are brave, perhaps you can try hyperscript for these needs.
> This is a world we would prefer live in: many programming language options, each with their own strengths, technical cultures and thriving communities, all able to participate in the web development world through the magic of more powerful hypermedia, rather than a monolith of SPAs-talking-to-Node-in-JSON. Diversity, after all, is our strength.
My SO experience lately has been the accepted answer is 12 years old and the correct, modern solution is down at the bottom with 1 point and I can't upvote it because they want me to jump through some hoops to get "reputation" before I can vote
> The problem is that doesn't tell you anything about JavaScript or Python... except whom is using Stack Overflow.
I'd also add that the author also failed to notice that all time series in that graph, with the exception of Python, either flatlined or are dropping. Thus that says more about SO and bad data analysis than real world trends in frontend development.
Even if we assume that Stack Overflow is a good proxy for overall language usage, OP does not account for the fact that Python is used more broadly than JavaScript in non-web use cases — e.g. the use of Python for machine learning.
Anyone who claims one language or tech stack is going to become the be-all, end-all of how we build things on the web is either naive or selling something.
I've gotten a lot of mileage out of ignoring grandstanders and focusing my time and energy on learning how browsers work. If you understand the DOM, CSS and core JavaScript fundamentals, you can apply your skills to virtually any front-end stack.
In the end, the thing that hurts the web the most is complexity in the name of DX. We are tricked into thinking that the simple thing is too hard to learn on the one hand, while being asked to juggle multiple layers of "sophisticated" abstraction on the other. These days there are entire businesses rising on the need to reduce the cognitive load created by our layers of sophisticated abstraction. But, I bring you the good word: you can still build incredible experiences without pulling in most of the complexity (and without sacrificing as much DX as you think).
Ironically this is why I prefer angular to react - people say angular is more complex, but IMHO it removes complexity by being "batteries included": reduced cognitive load because and angular project is an angular project so you only need to learn angular itself, and not a zillion extra libraries or frameworks.
Angular and React were a response to the problem of abstraction-less frontends: spaghetti jQuery, piled ten miles high. I appreciate the concern for over-abstraction introducing unnecessary complexity, but there's got to be a point on the continuum of spaghetti-jquery to react+redux+node_modules that's the sweet spot. If you're choiceful in what tools you use, you can have that in 2021. It doesn't have to be overly complex (though you certainly can make it that way).
By building apps using 100% client-side rendering with GraphQL and Rest APIs, I can use tools like Storybook to build a user interface that are easy to automate testing and ultimately, and consistently, ship enterprise-grade UIs. All my apps are behind auth walls. If need SSR, there's tools like Next.js.
Agree. The other thing I'd add is that we're long overdue for a more fundamental paradigm shift in webdev.
That is, we've changed our goal from the original page request/response model to one of delivering native-like SPA experiences. But, the frameworks that win don't fundamentally reconsider the old technology. Instead, they stop at the DOM layer, speak heavy HTML/CSS, make us manage browser mechanics like URLs, history and back buttons, and help us to better manage those old Web constructs while keeping them in focus.
So, they've added these abstraction layers that just keep piling up.
At some point we have to ask whether this is fundamentally the right approach.
in the article I show how a hypermedia-oriented (rather than javascript-oriented) library like htmx can address many of the usability concerns that Mr. Harris raises with MPAs, without abandoning the fundamental REST-ful architecture of the web for a more RPC-like javascript architecture.
As someone who has been developing websites for 15+ years and who stumbled across HTMX a year or two ago, I want to add a couple things here:
One really really nice thing about HTMX is how easy it is to "spruce up" a UI. You say "this part of my website could really do with some active content" and you start thinking about xmlHttpRequest and callbacks and and JSON and all that and you think "does it really need sprucing?". But with HTMX it's usually just adding a couple hx- attributes and maybe a couple serverside lines and you're done.
Another really really nice thing about HTMX is how easy it makes it to make things degrade gracefully. Javascript enabled? Get your beautiful ajax. No Javascript? Get a good experience in the "traditional" model. In anything else I've ever seen, if you want that experience, you need to write your UI twice (and usually in two different languages / models).
So basically it drastically lowers the bar for making nicer experiences on top of a solid MPA. Especially if you're a solo developer, this basically means that you end up producing better UIs "for free".
I don't think a lot of the points in the article hit home for me.
On one hand you suggest the culture of complexity is overwhelming, when just a few paragraphs earlier you suggest that sql-tuning and redis caching are how to deal with some of htmlx's problems with latency. That seems highly complex. You have to make deep changes to the back-end and data persistence systems to solve a front end issue.
It feels like the article is trying to say you shouldn't use javascript frameworks in a lot of cases, but then it advocates for using htmx, which is a javascript framework, in those cases?
In my experience the issues people have in front-end come from using tools and frameworks incorrectly, because they don't understand the tradeoffs being made -- so they don't account for those tradeoffs in a reasonable way that eventually comes back to bite the team. Handing people a new JS library that is seeming to intend we completely avoid javascript and therefore the library itself, creating an incentive not to learn how it works.
I've changed the title above to try to say what the article is about, using your wording here (but edited to fit HN's 80-char limit). In cases like this we try to avoid references to personalities. (We also try to avoid acronyms where possible, which is why I said 'multi-page apps' instead of 'MPAs'.) If there's a better title, i.e. a more accurate and neutral one, we can change it again.
It seems like there are broadly 2 concerns: having rich interaction inside of a single "page", and smooth transitions between "pages". You seem to dismiss the latter in your article, but HTMX seems to support Turbolinks style functionality, correct? Can animations be layered onto that?
I did some experiments around on how to do animated shared element transitions (as well as reactive functionality) within a REST mindset here, if anyone's curious: https://dev.to/eshan/toward-the-postmodern-web-38h (you can just scroll to the embeds)
Ultimately, maybe the browser vendors will do something here, like Google's portal elements, for example. A lot of effort is being spent on that flash during page loads.
One misconception about Hypermedia-driven applications is the belief that you can't / shouldn't use JS or other new technologies. You can create a Cloudflare Worker returning HTML[0], which you can call using HTMX in the frontend.
Using HTML to drive an app's interface has nothing to do with the tech stack, in fact, I think it opens the door to a more diverse tech stack. Optimistic UI updates, state management, and other "modern" JS techniques are cool, but often, the complexity is not worth it.
Also, let's not forget that web browsers are already good at taking HTML/CSS and showing it in your screen. Somehow, we decided it was better to make all your users waste CPU cycles to do the same with Javascript and a Virtual DOM (but only after 10MB of JS files have finished downloading)
From another POV, browsers are pretty bad at displaying HTML and CSS.
The layout mechanics are complicated. DOM is slow and non-transactional which means jumpy redraws and jank during partial updates, and you just can't render it at 60 fps, or even 30 fps, like you would with a direct-mode game-style UI; at best you can peg several CPU cores to 100%.
And this can never be fixed because backwards compatibility. It can only be replaced in some indefinite future.
This is why the virtual DOM was invented. And yes, if you know how to cook it, it's faster than jQuery.
OTOH great many web pages are not apps, and should not be treated as SPAs. But this happens, and it will until server-side rendering is made ridiculously easy to set up, and also becomes the fashion.
This is absolutely the right approach for building web sites IMO. It's the best mix of whatever-server-you-want-to-use and minimal JS on the client.
I built my own (proprietary for my employer) general-purpose AJAX etc framework that uses minimal javascript to produce flexible, interactive web sites with 1/100 the bulk of React. It even degrades gracefully for clients that don't run JS. But I'm tired of maintaining it. HTMLX looks like an even better approach because it doesn't seem to require me to add explicit event handlers all over the place and it's open source so I won't be the sole maintainer.
Looking forward to evaluating HTMLX as a replacement for my stuff.
htmx (no L) is pretty great. Maybe I’m old school, but I’ve used it in my last two projects and it’s a breath of fresh air. My projects were Go and PHP. htmx didn’t care, worked the same in both. I also added it late in one of them, so it has a traditional MPA feel and then I tacked on htmx instead of writing a bunch of js.
Anywayz, I’m loving htmx and I’m pretty sure it is making my development faster. I don’t know, yet, if it will degrade for larger applications.
contrary to most of the comments I'm in full agreement with the hypermedia approach.
This is an exciting development, especially with hyperscript!
I actually attempted to make a "simplified" "js" framework (where you just had some html tags and it did things for you) for tasks congruent to alpine (since I found alpine rather complex, or that it comes with so much but you still have to do a good amount of work to get things working) but I'm not as savvy; using the DSL you all have in hyperscript is real smart, simple.
Not too long ago I looked into using Svelte for a one-off project (since it was the highest rated framework at the time) which then prompted me to look into the current state of web development.
It's absurd, and left such a sour taste that I just shelved the project for another time.
Great stuff you guys got going here, it makes me excited to see what'll turn into in the future!
Looking forward to trying this out later.
SPAs might be the right approach for specific applications that are actually applications (e.g. text editors, Jupyter notebooks, chat and other web apps) but more generally the web is designed from the ground up to work well with separate pages representing separate resources.
I'm surprised you chose to shelve the project after looking at Svelte, as it's by far the simplest framework compared to its contemporaries (React, Vue et al.)
For example, here is a fully functional Svelte component:
God, I am so tired of these arguments. We need to stop bike-shedding web technology. You will never, ever convince me to go back to server-side rendering for the type of work I do. Are there other domains where that would be the wrong choice? Absolutely.
The web is a platform and we should not treat these tools as one-size-fits-all. Use the tools that fit your use case; there's no use in talking about the how without the why.
I'm not sure these are actual problems (other than JS tooling, which I find opaque.) Instagram works just fine for the vast majority of people. It's taken as gospel that Javascript frameworks are "bloated" but 1) is this really true; and 2) if true does this really matter if the page loads fast enough? React is only 5.3kB and gives a very simple model for reasoning about code. Making code smaller or faster has a cost.
I'll also note that htmx is making a programming language, but they don't seem to understand they are making a programming language, and that usually ends up a disaster. See all the YAML stuff in the devops world.
React is not only 5.3kb because that’s not the only piece you will need to actually use it. Check out the bundle of CRA for a real-world example.
I agree with the general sentiment though. I think the issue is that it’s easy to just import the whole npm registry in a bundle and ship it — and it’s too hard to trim it down.
For you a 2MB bundle is ok, but for me it’s taking 30 seconds to open this site and I’m standing here. That’s not ok.
Frameworks like Next.js provide a sane base for this; Most others don’t.
Having written SPAs in multiple frameworks over the years, I am finally starting to favour the author's perspective.
That said, the one criticism I can lob is toward the assumption that JavaScript / TypeScript will be the only path for SPAs, creating a full-stack monoculture. Web Assembly is on its way to negating this point long term.
I don't think this affects the position on MPAs, but weakens that one particular argument against SPAs.
We also have to accept that some dynamic page problems are completely unsolvable or have horrible solutions.
For instance, with infinite scroll - I spend 10 minutes scrolling down through 7000 rows, with all but the first few loaded dynamically.
I now want to send what I'm looking at to a friend. Or I want to bookmark it. Sure, I can have my app put the scrollposition in an anchor tag in the URL, but what happens when that URI is navigated to? Whatever solution you pick, it is horrid.
I like the potential for sending minimal document elements/objects, though it seems like HTMX/Intercooler/Unpoly features should be built into the browser. Unpoly, for example, has its own entire reimplementation of fetch():
I'm sorry but what's the point here? Rich's talk was not even remotely aimed at HTMX yet this article is nothing but a shameless list of HTMX features.
I dont think it has to be all or nothing. I think the best answer is to use both technologies as appropriate even in the same app.
I was writing something like htmx without intercooler with Angular with Django (which I fondly called Djangular) in 2013.
It just needed yet another framework type abstraction to reduce the boiler plate.
Send json with the html on initial page load, use the json api to load addition data, hard navigate between "sections" of the app but tabs and such were SPA pattern.
I think a middle ground combo of svelte and htmx is a killer idea (similar to all the "live view" stuff people are loving).
Indeed that is what Mr. Harris calls a "transitional" app, and, with him, I can recommend that approach.
The difference between us on that matter would be that I would recommend leaning hypermedia, whereas, at the risk of putting words into his mouth, he would appear to lean SPA/RPC as the default approach.
SPAs are fundamentally flawed. I am making a webapp with lots of images and media resources to download, when the user click to another page, the media on the previous page are being still downloading in the background and choked the 6 connection limit. To avoid this I have to encapsulate the download queue to each "page" manually.
Another issue is how browser cache 404, for SPA app, the "known" routes are stored in main.js rendered in browser, the nginx doesn't know which page is not defined, so every page is 200 and then rendered 404 in browser only, the browser would still cache the "wrong" 404 page because nginx has to serve index.html with main.js as 200 first.
I watched the Jamstack talk and I dont think Rich quite grasp why some people are against SPA.
The first thing being, 95% of what I do on the web doesn't need to be an SPA. Most of what I do is content consumption. HN doesn't need to be SPA. NewsReading doesn't need to be an SPA.
The second thing being once you allowed developers of SPA, and break free of the browser default usage pattern, there are very few SPA I have used that I even considered to be decent. Actually there is only one, Feedly. And yes, as pointed out in the video, even instagram cant do the basic right. Not Facebook web, and not Twitter. Look at new Reddit.
The problem with SPA is once you try to make a Web App, aka Reddit, I will instantly try to compare it with a Native App. And I have yet to see a single decent Web App that compares to "average" native app. It is far easier to make a very decent MPA with added magic like HTMX or Hotwire than a decent SPA.
The third being transitional design. Which is a compromise or taking best of both worlds. Interestingly HTMX or Hotwire are also considered as Transitional, since they try to make the those web page that needs a little more interactively without switching to SPA.
There are some things that are better for SPA, so far most them for me tends to be financial tools and graph based.
One argument for SPA is that your backend is just an API, your front end could now work not only in browser but even compiled natively into Apps. But so far none of them worked flawlessly across all platform without a team of expert.
And for simplicity, PHP is still by far the best in modern web backend tool kit. I am not advocating for PHP, I hate the syntax but other than that it is dead simple to use and set up. Considering both Hotwire / HTMX with Django and SPA camp with Svelte just shows how little the vocal web developer community value simplicity.
HOWl is a good idea.. either it will catch on and make web development fun again, or it will at least force the JS ecosystem to wake up and fix its terrible tooling and bloat.
Alpine is a lot closer to jquery than htmx IMHO--I think of it in a very similar way as what people used to use jquery for all the time (adding event handlers and logic to DOM elements).
I think they're overlooking a very big issue which is trying to do any sort of business logic in a markup language is terrible. HTML is good for presentation, trying to embed logic like retrying requests in it can lead to weird code. The reason people like Javascript is having a fully C-style language for things makes logic easier to read and maintain.
Agreed. Judging from this example: https://github.com/rajasegar/htmx-trello which uses htmx in pug templates combined with hyperscript the results are... dubious and hardly scalable.
I don't understand how you could do complex logic using this way. Is it possible and easy to say have multiple form elements share validation logic? It definitely looks great in many ways but I'm unsure how I wouldn't need to use a more complex framework like Svelte eventually anyway.
[+] [-] ravenstine|4 years ago|reply
Why yes... if you use Stack Overflow usage as your measurement.
The problem is that doesn't tell you anything about JavaScript or Python... except whom is using Stack Overflow.
As a JavaScript developer (primarily), I use Stack Overflow far less than I did in years past, not just because I need less help in general as a senior, but because SO is so littered with JS answers that are outdated, poor quality, and conflate JavaScript with jQuery, that it's simply not worth using 99% of the time because MDN provides excellent documentation.
It's been a while since I've used Python, so maybe things have changed, but I remember the documentation not being comparable. It's good documentation, but MDN is excellent.
I'm not saying that either one is better, but that to use Stack Overflow trends to prove a point seems very fallacious. By that point I couldn't finish the rest of the article.
[+] [-] recursivedoubts|4 years ago|reply
> We are fond of talking about the HOWL stack: Hypermedia On Whatever you'd Like. The idea is that, by returning to a (more powerful) Hypermedia Architecture, you can use whatever backend language you'd like: python, lisp, haskell, go, java, c#, whatever. Even javascript, if you like. There's no accounting for taste, after all. Since you are using hypermedia & HTML for your server interactions, you don't feel that pressure to adopt javascript on the backend that a huge javascript front end produces. You can still use javascript, of course, (perhaps in the form of alpine) but you use it in the manner it was originally intended: as a light, front end scripting language for enhancing your application. Or, if you are brave, perhaps you can try hyperscript for these needs.
> This is a world we would prefer live in: many programming language options, each with their own strengths, technical cultures and thriving communities, all able to participate in the web development world through the magic of more powerful hypermedia, rather than a monolith of SPAs-talking-to-Node-in-JSON. Diversity, after all, is our strength.
[+] [-] mwattsun|4 years ago|reply
[+] [-] fivea|4 years ago|reply
I'd also add that the author also failed to notice that all time series in that graph, with the exception of Python, either flatlined or are dropping. Thus that says more about SO and bad data analysis than real world trends in frontend development.
[+] [-] davidmurdoch|4 years ago|reply
[+] [-] divbzero|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] cdata|4 years ago|reply
I've gotten a lot of mileage out of ignoring grandstanders and focusing my time and energy on learning how browsers work. If you understand the DOM, CSS and core JavaScript fundamentals, you can apply your skills to virtually any front-end stack.
In the end, the thing that hurts the web the most is complexity in the name of DX. We are tricked into thinking that the simple thing is too hard to learn on the one hand, while being asked to juggle multiple layers of "sophisticated" abstraction on the other. These days there are entire businesses rising on the need to reduce the cognitive load created by our layers of sophisticated abstraction. But, I bring you the good word: you can still build incredible experiences without pulling in most of the complexity (and without sacrificing as much DX as you think).
[+] [-] mattlondon|4 years ago|reply
[+] [-] 88913527|4 years ago|reply
By building apps using 100% client-side rendering with GraphQL and Rest APIs, I can use tools like Storybook to build a user interface that are easy to automate testing and ultimately, and consistently, ship enterprise-grade UIs. All my apps are behind auth walls. If need SSR, there's tools like Next.js.
[+] [-] unclebucknasty|4 years ago|reply
That is, we've changed our goal from the original page request/response model to one of delivering native-like SPA experiences. But, the frameworks that win don't fundamentally reconsider the old technology. Instead, they stop at the DOM layer, speak heavy HTML/CSS, make us manage browser mechanics like URLs, history and back buttons, and help us to better manage those old Web constructs while keeping them in focus.
So, they've added these abstraction layers that just keep piling up.
At some point we have to ask whether this is fundamentally the right approach.
[+] [-] recursivedoubts|4 years ago|reply
it is a response to a talk that Mr. Harris gave at JamStack entitled "Have Single-Page Applications Ruined the Web?":
https://www.youtube.com/watch?v=860d8usGC0o
in the article I show how a hypermedia-oriented (rather than javascript-oriented) library like htmx can address many of the usability concerns that Mr. Harris raises with MPAs, without abandoning the fundamental REST-ful architecture of the web for a more RPC-like javascript architecture.
[+] [-] chias|4 years ago|reply
One really really nice thing about HTMX is how easy it is to "spruce up" a UI. You say "this part of my website could really do with some active content" and you start thinking about xmlHttpRequest and callbacks and and JSON and all that and you think "does it really need sprucing?". But with HTMX it's usually just adding a couple hx- attributes and maybe a couple serverside lines and you're done.
Another really really nice thing about HTMX is how easy it makes it to make things degrade gracefully. Javascript enabled? Get your beautiful ajax. No Javascript? Get a good experience in the "traditional" model. In anything else I've ever seen, if you want that experience, you need to write your UI twice (and usually in two different languages / models).
So basically it drastically lowers the bar for making nicer experiences on top of a solid MPA. Especially if you're a solo developer, this basically means that you end up producing better UIs "for free".
[+] [-] flapjackfritz|4 years ago|reply
On one hand you suggest the culture of complexity is overwhelming, when just a few paragraphs earlier you suggest that sql-tuning and redis caching are how to deal with some of htmlx's problems with latency. That seems highly complex. You have to make deep changes to the back-end and data persistence systems to solve a front end issue.
It feels like the article is trying to say you shouldn't use javascript frameworks in a lot of cases, but then it advocates for using htmx, which is a javascript framework, in those cases?
In my experience the issues people have in front-end come from using tools and frameworks incorrectly, because they don't understand the tradeoffs being made -- so they don't account for those tradeoffs in a reasonable way that eventually comes back to bite the team. Handing people a new JS library that is seeming to intend we completely avoid javascript and therefore the library itself, creating an incentive not to learn how it works.
[+] [-] dang|4 years ago|reply
[+] [-] satyrnein|4 years ago|reply
I did some experiments around on how to do animated shared element transitions (as well as reactive functionality) within a REST mindset here, if anyone's curious: https://dev.to/eshan/toward-the-postmodern-web-38h (you can just scroll to the embeds)
Ultimately, maybe the browser vendors will do something here, like Google's portal elements, for example. A lot of effort is being spent on that flash during page loads.
[+] [-] polyrand|4 years ago|reply
Using HTML to drive an app's interface has nothing to do with the tech stack, in fact, I think it opens the door to a more diverse tech stack. Optimistic UI updates, state management, and other "modern" JS techniques are cool, but often, the complexity is not worth it.
Also, let's not forget that web browsers are already good at taking HTML/CSS and showing it in your screen. Somehow, we decided it was better to make all your users waste CPU cycles to do the same with Javascript and a Virtual DOM (but only after 10MB of JS files have finished downloading)
[0] https://developers.cloudflare.com/workers/examples/return-ht...
[+] [-] nine_k|4 years ago|reply
The layout mechanics are complicated. DOM is slow and non-transactional which means jumpy redraws and jank during partial updates, and you just can't render it at 60 fps, or even 30 fps, like you would with a direct-mode game-style UI; at best you can peg several CPU cores to 100%.
And this can never be fixed because backwards compatibility. It can only be replaced in some indefinite future.
This is why the virtual DOM was invented. And yes, if you know how to cook it, it's faster than jQuery.
OTOH great many web pages are not apps, and should not be treated as SPAs. But this happens, and it will until server-side rendering is made ridiculously easy to set up, and also becomes the fashion.
[+] [-] dreamcompiler|4 years ago|reply
I built my own (proprietary for my employer) general-purpose AJAX etc framework that uses minimal javascript to produce flexible, interactive web sites with 1/100 the bulk of React. It even degrades gracefully for clients that don't run JS. But I'm tired of maintaining it. HTMLX looks like an even better approach because it doesn't seem to require me to add explicit event handlers all over the place and it's open source so I won't be the sole maintainer.
Looking forward to evaluating HTMLX as a replacement for my stuff.
[+] [-] codazoda|4 years ago|reply
Anywayz, I’m loving htmx and I’m pretty sure it is making my development faster. I don’t know, yet, if it will degrade for larger applications.
[+] [-] clownworldclown|4 years ago|reply
I actually attempted to make a "simplified" "js" framework (where you just had some html tags and it did things for you) for tasks congruent to alpine (since I found alpine rather complex, or that it comes with so much but you still have to do a good amount of work to get things working) but I'm not as savvy; using the DSL you all have in hyperscript is real smart, simple.
Not too long ago I looked into using Svelte for a one-off project (since it was the highest rated framework at the time) which then prompted me to look into the current state of web development.
It's absurd, and left such a sour taste that I just shelved the project for another time.
Great stuff you guys got going here, it makes me excited to see what'll turn into in the future! Looking forward to trying this out later.
[+] [-] divbzero|4 years ago|reply
SPAs might be the right approach for specific applications that are actually applications (e.g. text editors, Jupyter notebooks, chat and other web apps) but more generally the web is designed from the ground up to work well with separate pages representing separate resources.
[+] [-] zapt02|4 years ago|reply
For example, here is a fully functional Svelte component:
``` <h1>Hello world!</h1> ```
And here's another one that adds a bit of design:
``` <h1>Hello world!</h1>
<style> h1 { color: red; } </style> ```
I wouldn't call it particularly hard!
[+] [-] ng12|4 years ago|reply
The web is a platform and we should not treat these tools as one-size-fits-all. Use the tools that fit your use case; there's no use in talking about the how without the why.
[+] [-] peanut_worm|4 years ago|reply
[+] [-] noelwelsh|4 years ago|reply
I'll also note that htmx is making a programming language, but they don't seem to understand they are making a programming language, and that usually ends up a disaster. See all the YAML stuff in the devops world.
[+] [-] recursivedoubts|4 years ago|reply
Rather, we are making two programming languages:
https://hyperscript.org/
[+] [-] feupan|4 years ago|reply
I agree with the general sentiment though. I think the issue is that it’s easy to just import the whole npm registry in a bundle and ship it — and it’s too hard to trim it down.
For you a 2MB bundle is ok, but for me it’s taking 30 seconds to open this site and I’m standing here. That’s not ok.
Frameworks like Next.js provide a sane base for this; Most others don’t.
[+] [-] lucasyvas|4 years ago|reply
That said, the one criticism I can lob is toward the assumption that JavaScript / TypeScript will be the only path for SPAs, creating a full-stack monoculture. Web Assembly is on its way to negating this point long term.
I don't think this affects the position on MPAs, but weakens that one particular argument against SPAs.
[+] [-] jacobobryant|4 years ago|reply
[+] [-] kingcharles|4 years ago|reply
For instance, with infinite scroll - I spend 10 minutes scrolling down through 7000 rows, with all but the first few loaded dynamically.
I now want to send what I'm looking at to a friend. Or I want to bookmark it. Sure, I can have my app put the scrollposition in an anchor tag in the URL, but what happens when that URI is navigated to? Whatever solution you pick, it is horrid.
[+] [-] mitchtbaum|4 years ago|reply
https://github.com/unpoly/unpoly/blob/4854c7ccb268890a9522c6...
and it uses several X-HTTP-Headers, which could be standardized.
Do any browsers have the early workings of a "native web application sdk"?
[+] [-] seumars|4 years ago|reply
[+] [-] leetrout|4 years ago|reply
I was writing something like htmx without intercooler with Angular with Django (which I fondly called Djangular) in 2013.
It just needed yet another framework type abstraction to reduce the boiler plate.
Send json with the html on initial page load, use the json api to load addition data, hard navigate between "sections" of the app but tabs and such were SPA pattern.
I think a middle ground combo of svelte and htmx is a killer idea (similar to all the "live view" stuff people are loving).
[+] [-] recursivedoubts|4 years ago|reply
The difference between us on that matter would be that I would recommend leaning hypermedia, whereas, at the risk of putting words into his mouth, he would appear to lean SPA/RPC as the default approach.
[+] [-] est|4 years ago|reply
Another issue is how browser cache 404, for SPA app, the "known" routes are stored in main.js rendered in browser, the nginx doesn't know which page is not defined, so every page is 200 and then rendered 404 in browser only, the browser would still cache the "wrong" 404 page because nginx has to serve index.html with main.js as 200 first.
[+] [-] ksec|4 years ago|reply
The first thing being, 95% of what I do on the web doesn't need to be an SPA. Most of what I do is content consumption. HN doesn't need to be SPA. NewsReading doesn't need to be an SPA.
The second thing being once you allowed developers of SPA, and break free of the browser default usage pattern, there are very few SPA I have used that I even considered to be decent. Actually there is only one, Feedly. And yes, as pointed out in the video, even instagram cant do the basic right. Not Facebook web, and not Twitter. Look at new Reddit.
The problem with SPA is once you try to make a Web App, aka Reddit, I will instantly try to compare it with a Native App. And I have yet to see a single decent Web App that compares to "average" native app. It is far easier to make a very decent MPA with added magic like HTMX or Hotwire than a decent SPA.
The third being transitional design. Which is a compromise or taking best of both worlds. Interestingly HTMX or Hotwire are also considered as Transitional, since they try to make the those web page that needs a little more interactively without switching to SPA.
There are some things that are better for SPA, so far most them for me tends to be financial tools and graph based.
One argument for SPA is that your backend is just an API, your front end could now work not only in browser but even compiled natively into Apps. But so far none of them worked flawlessly across all platform without a team of expert.
And for simplicity, PHP is still by far the best in modern web backend tool kit. I am not advocating for PHP, I hate the syntax but other than that it is dead simple to use and set up. Considering both Hotwire / HTMX with Django and SPA camp with Svelte just shows how little the vocal web developer community value simplicity.
[+] [-] jonathan-adly|4 years ago|reply
[+] [-] Kiro|4 years ago|reply
[+] [-] qbasic_forever|4 years ago|reply
[+] [-] deniska|4 years ago|reply
[+] [-] hstaab|4 years ago|reply
[+] [-] recursivedoubts|4 years ago|reply
hyperscript, our other project, is a more direct competitor w/ alpine:
https://hyperscript.org
[+] [-] qbasic_forever|4 years ago|reply
[+] [-] toastking|4 years ago|reply
[+] [-] seumars|4 years ago|reply
[+] [-] xrd|4 years ago|reply