[HN Gopher] An SPA Alternative
___________________________________________________________________
An SPA Alternative
Author : vimota
Score : 181 points
Date : 2022-07-19 06:38 UTC (16 hours ago)
(HTM) web link (htmx.org)
(TXT) w3m dump (htmx.org)
| drchaim wrote:
| I've been trying htmx and the results are great. So much simpler
| to code than with SPA. My only concern is about those datetime
| pickers and other type of "components" that is easy to get from a
| react/vue ecosystem but much harder in a vanilla Javascript way.
| Not saying it's impossible, but a bit harder to find decent
| maintain libraries/components for those kind of web interactions.
| jaredcwhite wrote:
| I would focus less on "vanilla JavaScript" as the ecosystem
| from which good components will arise and focus more on web
| components (which, generally speaking, _are_ vanilla
| JavaScript). There is a thriving and growing sector of the
| frontend space where web components and WC-based design systems
| are coming to the forefront. Shoelace is a fantastic library in
| this vein. Libraries like htmx, Alpine, Turbo, etc. benefit
| greatly from web components.
| S34RZrXNZoeemHj wrote:
| sergiotapia wrote:
| I am totally with you. Unfortunately firefox as usual cocks
| it up for the rest of us.
| Scarbutt wrote:
| I haven't use it but my understanding is that htmx is normally
| paired with something like alpinejs for which there existes
| date picker components.
| newbieuser wrote:
| andybak wrote:
| People post it and other people upvote it?
|
| I've seen this before but I enjoyed the other article and it
| was new to me
| bulatb wrote:
| Just answering the why, not granting or disputing that it's
| weird:
|
| A decent fraction of HN hates some or all of: JavaScript the
| language; SPAs; the modern JavaScript environment, tooling, and
| churn; the JavaScript community and/or its way of working; web
| frontend development in general; that JavaScript exists at all;
| what JavaScript is used for, and how it affects their use of
| the web. Different subgroups have their own positions, but this
| alternative approach is something they can mostly agree on.
| It's simple, easy to work with, and gets the job done with as
| little of that JavaScriptiness as possible.
|
| There's a lot (a lot, a _lot_ ) to say about the...sociology?
| of JavaScript. But I think that's the general reason.
| recursivedoubts wrote:
| I assure you, at this point, as much as you, I would like a
| break from the front page
| MrWiffles wrote:
| What's the actual advantage of HTMX over something like React or
| Vue? All 3 require some form of JavaScript library coupled with
| markup to build interfaces. While I'm all about killing
| JavaScript as much as possible (why should I let $MEGACORP
| execute code on my device all willy-nilly without any real
| restrictions?), I just don't see the tangible benefit to the end
| user here.
|
| (And don't start with "it's faster/more efficient", that
| comparison isn't terribly valid because the inefficiencies seen
| with React/Vue are largely an artifact of bad code/practices, not
| the libraries themselves.)
| edmcnulty101 wrote:
| I think the article kind of explains it pretty well.
|
| It kind of returns to the original intention of the web.
| simonw wrote:
| It's faster. React apps often load hundreds of KBs - if not MBs
| - of code before they start to work. HTMX loads 10KB (gzipped).
| tomnipotent wrote:
| Doesn't really matter unless you're targeting low-bandwidth
| customers. The Amazon homepage is ~4MB, and an average user
| session is going to downloading many times that in additional
| images and markup while browsing. In that context, React or
| other JS files will be single-digit percentage of what was
| downloaded.
| threatofrain wrote:
| Then use Preact, Solid or its ilk. Then your bundle size is
| going to be a tiny fraction of the kinds of things users tend
| to like, such as images.
| [deleted]
| recursivedoubts wrote:
| One big advantage is simplicity: you eliminate the need for a
| lot of client side technology, such as routing, and push
| everything back to the server.
|
| Also, by eliminating application javascript, it allows you to
| spend more time in your preferred language on the back end.
|
| The downside is the same as regular HTML, although less
| pronounced: since you are driving application state through
| hypermedia (HATEOAS), the less coarse-grained your state or UI
| gets the more annoying things are going to be. There are some
| patterns that help but eventually, if you want to update 12
| different places in your UI at once on every keystroke, the
| hypermedia approach just isn't going to cut it.
| amelius wrote:
| > Also, by eliminating application javascript, it allows you
| to spend more time in your preferred language on the back
| end.
|
| But these days (using transpilers and/or WebAssembly) you can
| choose just about any language on the front-end ...
| recursivedoubts wrote:
| That's true and, in the case of pyscript in particular, may
| limit the appeal of something like htmx.
|
| On the other hand, the simplicity of the hypermedia
| approach, and the flexibility of ReST are still there.
|
| We'll see.
| Starlevel001 wrote:
| Web devs have zero right to run their javascript disasters on
| my computer. Htmx outsources 99% of the rendering and logic to
| the server, where it can use up their valuable time.
| ng12 wrote:
| Why stop there? They should get their own end users as well.
| n0us wrote:
| If you hate it so much just turn off JavaScript and enjoy
| waiting for the page to reload every time you click on
| anything
| andybak wrote:
| Which is often faster than the response time of a client
| side app.
| tshaddox wrote:
| Can you further explain your principles around the web? I'm
| curious to hear more. For instance, it sounds like you don't
| think web sites ought to be able to distribute JavaScript
| which executes on your computer in order to generate a user
| interface, but it seems you do think web devs have the right
| to utilize your internet bandwidth to download markup from a
| server in order to generate a user interface. Is that the
| case, and if so, why do you make that distinction?
| zakki wrote:
| Maybe GP wants to access the information and not the
| unnecessary local processing?
|
| Edit: wording
| Starlevel001 wrote:
| Theoretically my local computer is faster to render
| something than my network connection can download the pre-
| rendered content.
|
| However, 99% of javascript blobs of hatred end up slower
| than downloading the pre-rendered content.
| traverseda wrote:
| You can generate your HTML using a server-side template, and it
| is mostly just HTML.
|
| > All 3 require some form of JavaScript library coupled with
| markup to build interfaces.
|
| With HTMX you're typically including one static javascript file
| that you just download, you're not using any kind of javascript
| build system at all. Where it has very limited scope it's
| possible to imagine a browser that doesn't have javascript but
| that has HTMX built in.
|
| Calling it a javascript library might be a bit much, I mean
| you're not typically installing this with node/npm, or
| minifying it, or importing it. You're just including it in a
| script tag at the bottom of your site. While they both do
| technically run on javascript I think they have more
| differences than things they have in common, and saying "Well
| they're both just javascript libraries" is a very sophomoric
| take. I mean you might as well just say that all javascript
| libraries are the same, and it doesn't matter what you use. So
| why choose react/vue over jquery?
|
| > inefficiencies seen with React/Vue are largely an artifact of
| bad code/practices, not the libraries themselves.
|
| Ehh, I'm sure you can make a fast bug-free website in server-
| side assembly if you're so inclined but it's probably not the
| right tool for the job. The question is what kind of design
| patterns do the libraries/tools encourage, not "can I do X with
| Y".
| y2bd wrote:
| I want to note that Vue provides official instructions on how
| to use it without build tools [1], and lots of folks who have
| written posts on how to use React without tooling as well
| [2]. I agree that they're ultimately designed to be used with
| tooling, but it's not a blanket requirement.
|
| - [1] https://vuejs.org/guide/quick-start.html#without-build-
| tools
|
| - [2] https://blog.jim-nielsen.com/2020/react-without-build-
| tools/
| RobbieGM wrote:
| Without any real restrictions? JavaScript is very restricted in
| what it can do. Most APIs that you'd expect to be gated behind
| a permission are gated behind a permission.
| S34RZrXNZoeemHj wrote:
| tehbeard wrote:
| Then go back to an abacus?
| radus wrote:
| Unfortunately, abacus side-channel exploits are numerous
| as well
| rlawson wrote:
| I have used htmx (and it's predecessor intercooler) on several
| occasions now.
|
| The real sweet spot is it allows you to push server side
| frameworks like Django even further. You may find you can skip
| the SPA all together. And nothing beats the speed of development
| of a Django/Rails/Laravel.
|
| Htmx is part of my go to stack for solo/side projects and my
| preferred stack on the job for crud heavy line of business
| applications.
| jdthedisciple wrote:
| Naive question but how would styling be handled actually? If the
| server just returns plain html tags with content in it ... I
| mean, I don't quite get it
| lawtalkinghuman wrote:
| Exciting new technology for styling web pages.
|
| https://www.w3.org/Style/CSS/
| listenallyall wrote:
| Usually, the server returns plain HTML tags with Tailwind-
| enabled 'class' attributes.
| jaredcwhite wrote:
| I don't understand why you mentioned Tailwind. Nothing about
| htmx requires a utility class framework AFAIK.
| recursivedoubts wrote:
| The normal way: via a CSS file included in your head.
| recursivedoubts wrote:
| I am the author of this article. Happy to answer questions.
|
| I know my alternative approach, htmx-enhanced hypermedia, isn't
| right for every application, but it can be a much simpler
| approach for many applications, and, since it is so simple, can
| be used to conserve complexity in applications that have parts
| that are not amenable to the hypermedia approach.
| encryptluks2 wrote:
| It looks to me like you took the phrase SPA and then attached
| your own meaning to it, which to you meant React or a similar
| framework. Then, you created an alternative to react that still
| uses JavaScript and put the word HTML in it when you're still
| loading JavaScript. Is that about right?
| pier25 wrote:
| Technically correct but you will have to admit probably +90%
| of React apps are SPAs.
| encryptluks2 wrote:
| The issue is the title which is incorrect.
| recursivedoubts wrote:
| SPA means "Single Page Application", I don't spend much time
| defining it but defer to Tom Wright's definition, about which
| he says:
|
| _> The SPA pattern (Single-Page Apps), I tried to define,
| was about the React model, which also covers, to a large
| extent, the model of Vue, Angular, and other frontend
| frameworks._
|
| I created an alternative to AngularJS, Meteor, Knockout and
| Ember.js back in 2013 called intercooler.js. It used
| hypermedia as the communication mechanism with the server,
| rather than JSON. I wrote the library in JavaScript because
| that's what was there. In 2020 I rewrote the library to
| eliminate the jQuery dependency and clean it up and renamed
| it to htmx, since I had figured out that it was a
| generalization of HTML as a hypertext.
|
| I think that's a pretty good summary of what happened.
| woojoo666 wrote:
| This reads like more of an attack than a question. Even
| though I prefer React over HTMX, I think the difference is
| pretty clear, as well as the intention of this article. In
| particular, this quote from the article is most relevant
|
| > In HTML-Centric Development, rather than being an
| afterthought, HTML is embraced as the primary medium of
| application development. This is in contrast to most SPA
| frameworks, where a client-side model & the javascript that
| manipulates it is the central focus.
|
| If you read the authors other post about REST [1], they also
| talk about how most SPAs communicates with the server via
| JSON, whereas HTMX uses HTML. This is also part of the HTML
| centric design. You embed the fetching logic into the HTML,
| and the server returns HTML directly, so there's less work
| done on the client, in constrast to most SPA frameworks.
|
| [1]: https://htmx.org/essays/how-did-rest-come-to-mean-the-
| opposi...
| dragonwriter wrote:
| So, it's an HTML-Centric SPA framework. It is still a SPA
| framework.
| encryptluks2 wrote:
| The title is literally an SPA Alternative. Should the title
| then not be updated to an SPA framework, since it isn't an
| alternative. That is like saying Microsoft Word is an
| alternative to word processors.
| recursivedoubts wrote:
| But it isn't an SPA framework, it's a generalization of
| HTML as an alternative to SPA-style frameworks. It's very
| different conceptually, as different as mobile apps and
| web 1.0 apps at the network architecture level.
|
| I understand that this approach will not appeal to a lot
| of folks, but on the other hand that's because it is so
| different than what most of the industry is doing.
|
| I hope I understand your criticism correctly here.
| encryptluks2 wrote:
| The issue I have is that you're taking the idea of an
| SPA, which is pretty loose:
|
| > An SPA (Single-page application) is a web app
| implementation that loads only a single web document, and
| then updates the body content of that single document via
| JavaScript APIs...
|
| Looking at the examples at htmx.org, this is exactly what
| it does. Just because some car manufacturers decide to
| put an engine in the front of the car doesn't mean that a
| car with an engine in the back isn't still a car.
| jaredcwhite wrote:
| But htmx doesn't update the body content of the document
| via JavaScript APIs. It updates them via HTML APIs. That
| is, the content coming over the wire from the backend is
| HTML, not JSON.
|
| If you're trying to claim that literally any web page
| which uses JavaScript in any capacity to update any DOM
| on the page ever suddenly means it's an SPA, that seems
| like _quite a stretch_.
| dragonwriter wrote:
| > But htmx doesn't update the body content of the
| document via JavaScript APIs.
|
| Yes, it does.
|
| > It updates them via HTML APIs.
|
| It updates then by using JS code calling DOM APIs. Just
| like any other SPA.
|
| > the content coming over the wire from the backend is
| HTML, not JSON.
|
| The content coming over the wire being HTML, JSON, XML,
| or text/plain has no bearing on whether the JS framework
| inserting the result of processing it somewhere on a
| single pre-existing page is a SPA framework.
| 60secs wrote:
| Why the use of the article 'An' instead of 'A' ?
| detaro wrote:
| Because you use "An" if the following starts with a vowel
| sound, and "SPA" (spoken as the individual letters) does.
| (EDIT: fell for a false friend, fixed)
| tartoran wrote:
| Interesting. Do you generally pronunce it as Es-pea-ay? In
| that case it warrants the an in front
| sirshmooey wrote:
| Most wouldn't read an acronym phonetically if it happens to
| spell a commonly used word.
| mtlynch wrote:
| Thanks for sharing and for your work on intercooler.js and
| htmx!
|
| I share your sentiments about SPAs, and I've been trying to get
| back to a simpler web stack.
|
| One of the hurdles I keep running into with libraries like htmx
| and Alpine is that they don't play nicely with Content Security
| Policy. And I'm reluctant to forfeit CSP to use a JS library
| since CSP is the most robust solution I've found for preventing
| XSS.
|
| Alpine is working on a CSP-compatible build, but it hasn't been
| released[0] and doesn't seem to be a priority.
|
| htmx is compatible with CSP, but it effectively reverses the
| protection it offers. The attacker can inject JS through htmx
| directives.[1] I know there's hx-disable, but this degrades
| CSP's effect from "secure by default" to "secure when the
| developer remembers to mark the subtree as containing user-
| controlled data."
|
| Is there a way to use htmx without forfeiting the benefits of
| CSP?
|
| [0]
| https://github.com/alpinejs/alpine/issues/237#issuecomment-9...
|
| [1] https://htmx.org/docs/#security
| recursivedoubts wrote:
| unfortunately not one I can think of without htmx being baked
| in to HTML
|
| which, I think should be the case: I don't think htmx should
| have to exist, I think this is just how HTML should work.
| That could address a lot of accessibility and progressive
| enhancment issues as well.
| mtlynch wrote:
| Ah, bummer. Thanks for your answer!
| 88913527 wrote:
| What is the best way to use a React-based design system with
| concepts like HTMX? I need to enforce consistent look-and-feel
| across product development teams, and that means using the
| components that ship our standard look-and-feel (eg: our
| buttons, form inputs, etc are contained within the design
| system).
| kulor wrote:
| I've found this library a delight. Coupled with a sprinkling of
| Alpinejs to cover more advanced interactions and Django-
| livereload, I feel progressive enhancement has a renascence
| opportunity
| daotoad wrote:
| I'm pretty sure I've said this on previous mentions of htmx, but
| I'll say it again: this reminds me of the old SPF framework
| youtube published.
|
| http://youtube.github.io/spfjs/
|
| SPF was a bit more focused on being easy to merge into an
| existing server side app.
|
| I am glad to see this and hope it has some legs. It could help
| free us from the need to write every UI in JavaScript(ish).
| no_wizard wrote:
| this of course, is really meant for brochure or light
| interactivity sites. I don't think Figma should convert to htmx.
| I also don't think its meant for sites that may need to honestly
| scale as part of their product line heavy JavaScript
| interactivity. For instance, I've definitely worked at a place
| that deployed well over 10K components to production (I think we
| pushed over a million lines of deployed production code).
|
| React & Angular do scale this far, I have yet to encounter any
| who works with Vue that ships over a million lines of deployed
| code though I'd love to hear from you!
| henning wrote:
| No, it's meant for websites that don't require loading 8 MB of
| JavaScript. You've completely missed the point that "product
| line heavy JavaScript interactivity", whatever that means, is
| bullshit that doesn't solve any problems, it just creates new
| ones.
|
| You're saying "I have all this code, what do I do with all this
| code." The answer is: don't write it!
| sodapopcan wrote:
| To nitpick, Figma is not a good example as it's essentially all
| Canvas.
| recursivedoubts wrote:
| I don't think that "scale" is the right axis, but rather the
| amount of interdependence in your UI.
|
| htmx would probably work great for something like GMail, but
| would be a bad choice for something like Google Sheets. Both
| are big apps, but one is more amenable to coarse grain HTTP
| requests because the UI isn't as interdependent.
| vladstudio wrote:
| Every time I see an essay from Carson, author of HTMX, I upvote
| instantly!
|
| Make sure to check other essays at https://htmx.org/talk/ (scroll
| down for Essays)
___________________________________________________________________
(page generated 2022-07-19 23:00 UTC)