by j4mie on 12/26/21, 4:12 PM with 128 comments
by ravenstine on 12/26/21, 6:05 PM
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.
by cdata on 12/26/21, 7:28 PM
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).
by recursivedoubts on 12/26/21, 6:26 PM
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.
by polyrand on 12/26/21, 11:36 PM
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...
by dreamcompiler on 12/26/21, 7:08 PM
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.
by clownworldclown on 12/26/21, 6:24 PM
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.
by ng12 on 12/26/21, 8:17 PM
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.
by noelwelsh on 12/26/21, 6:33 PM
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.
by lucasyvas on 12/26/21, 7:48 PM
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.
by kingcharles on 12/26/21, 8:44 PM
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.
by mitchtbaum on 12/26/21, 10:25 PM
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"?
by seumars on 12/26/21, 6:09 PM
by leetrout on 12/26/21, 5:54 PM
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).
by est on 12/27/21, 2:31 AM
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.
by ksec on 12/27/21, 11:57 PM
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.
by jonathan-adly on 12/26/21, 7:28 PM
by Kiro on 12/26/21, 7:12 PM
by hstaab on 12/26/21, 7:35 PM
by toastking on 12/26/21, 6:26 PM
by xrd on 12/27/21, 1:33 AM
by gorgoiler on 12/26/21, 6:51 PM
What about an SPA that made internal requests to a server backend, running in the browser?
by bryik on 12/26/21, 6:17 PM
Is CPU cheap? I can literally host a static site or SPA on GitHub Pages for free. Where can I get free CPU time for an htmlx application?
by phekunde on 12/27/21, 1:51 AM
by feupan on 12/26/21, 6:21 PM
The core behavior of a SPA is that it loads pages via ajax and just replaces content in the current “document”. The difference between a simple SSR React site and this is that React will only fetch JSON and templates after the first load, whereas this one fetches whole chunks of HTML.
An htmx site still has to deal with all the pitfalls of SPAs, namely non-native navigation and history, and memory leaks.
Just like htmx may have solved some of these issues, a (other framework) SPA can do too.
by pictur on 12/26/21, 6:15 PM
by inwardsword on 12/26/21, 6:01 PM
by coding123 on 12/27/21, 12:54 AM
I'm not saying that all sites need to migrate to SPAs but there is a HUGE market segment that has been replaced with a React SPA over custom apps that had to be downloaded. And now those same SPAs work in your phone and your computer.
HTML POST REDIRECT HTML is dead, get over it.