An SPA Alternative

https://htmx.org/essays/spa-alternative/

by vimota • 4 years ago

278 118 4 years ago

htmx.org

vladstudio• 4 years ago

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)

MrWiffles• 4 years ago

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.)

RobbieGM• 4 years ago

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.

traverseda• 4 years ago

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• 4 years ago

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/

edmcnulty101• 4 years ago

I think the article kind of explains it pretty well.

It kind of returns to the original intention of the web.

Starlevel0012• 4 years ago

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• 4 years ago

Why stop there? They should get their own end users as well.

n0us• 4 years ago

If you hate it so much just turn off JavaScript and enjoy waiting for the page to reload every time you click on anything

tshaddox• 4 years ago

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?

simonw• 4 years ago

It's faster. React apps often load hundreds of KBs - if not MBs - of code before they start to work. HTMX loads 10KB (gzipped).

threatofrain• 4 years ago

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.

tomnipotent• 4 years ago

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.

recursivedoubts10• 4 years ago

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• 4 years ago

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 ...

noidexe2• 4 years ago

The idea is that the js is used to implement the functionality that the author believes should be built-in. In theory you could have a browser plugin/extension for handling htmx and it would work across every site using htmx. You app-specific "code" is all declarative, just extra properties in your html tags. With most frontend frameworks, even if the browser came with built in support for Vue, React or whatever, you'd still tons of imperative js for each single webapp to define how it uses the framework.

Imagine not having html at all. You'd have to create pages from scratch imperatively by doing things like let element = createElement("p"); element.setContent("my paragraph"); parent.addChild(element); It'd be really ugly, a PITA to change stuff and error-prone. htmx is the opposite of that. It tries to make web development declarative again, among other things.

felipeccastro2• 4 years ago

The main advantage I see of traditional server side rendering (like in Rails/Django) is that you develop a single project, not two (SPA + API).

Instead of api models and client models, you just have models.

Instead of api routes and client routes, you just have routes.

Instead of unit testing api and client, you test one project.

Instead of having the client making N requests to load all the data it needs from the server (and being careful not to return more data than you need for performance reasons), you return an html with all the data it needs in a single request, and nothing more.

In the case of client stacks using SSR (like Next/Nuxt):

Instead of running the SPA on the server so the server returns the html rendered, you just make the server return the html rendered.

The benefit to the developer is higher productivity. The benefit to the end user should follow from that.

jeeep• 4 years ago

The tight coupling removes a lot of scalability possibilities though. I understand the higher productivity argument, but wouldn't it be time consuming on the long run to lock yourself in an environment where you would have to go back and build an API if you want to extend your web app to mobile for example?

drchaim• 4 years ago

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.

Scarbutt• 4 years ago

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.

S34RZrXNZoeemHj• 4 years ago

Why would you need JS at all for a date picker?!

sergiotapia• 4 years ago

I am totally with you. Unfortunately firefox as usual cocks it up for the rest of us.

phil-martin2• 4 years ago

Because the built in date pickers (and other editors) don't always fit the requirements?

A couple of things I had to handle in the last couple of weeks: - Handling different separators for input - having a clear button to indicate "no date" - display the date in a different format

dham• 4 years ago

Yea, would have been nice if the W3C actually gave us usable components, but hey you can connect your MIDI keyboard to the browser.

jaredcwhite2• 4 years ago

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.

vindarel2• 4 years ago

Same here, I would love an example on how to use a customizable asynchronous typeahead with HTMX (think Twitter Typeahead, not <datalist>). Couldn't find one or wrap my head around it. (We can hook HTMX into the library events, maybe?).

megaman821• 4 years ago

I have been using web components for those things. They actually pair great with htmx. Once you import a my-datepicker or my-modal web component it automatically works anytime it appears in the DOM. So htmx can ajax in some HTML and you don't have to wire up an JavaScript to it to get rich interactions. Check out Shoelace (https://shoelace.style/) for a good set of components.

daotoad• 4 years ago

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).

geenat• 4 years ago

It's a similar concept to Google's SPF.

htmx is more light weight, and very actively maintained.

no_wizard2• 4 years ago

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!

sodapopcan• 4 years ago

To nitpick, Figma is not a good example as it’s essentially all Canvas.

recursivedoubts10• 4 years ago

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.

vindarel2• 4 years ago

Sheets

Interestingly, I have seen a new app that provides a sheet with HTMX: https://www.licenseprompt.com/ (gif: https://twitter.com/WimpieNortje/status/1520419150245638144)

henning• 4 years ago

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!

no_wizard2• 4 years ago

No, I'm simply positing that HTMX doesn't fill the void of heavy web apps, like Figma, or Salesforce. At least not naturally. React does scale well in this way. So does Angular (though I don't care for it, which is another discussion entirely). Especially when you want maximal code sharing in your dependency chain.

I never done it with Vue (largest Vue app I ever worked on had roughly 200K lines of deployed code, all in, for the application, very thick client type stuff), but maybe with Vue 3 and the composition API this isn't an issue (I don't think Vue 2 would ever scale well developer experience wise this way)

I'm not throwing shade on HTMX, but there tends to be this energy around it that would make someone who, perhaps trying to weigh some options, stumbles across HN, sees threads like this and thinks oh gee! This sounds great without knowing exactly what that means. And it is true, that perhaps, that person is building app that needs scalable reactivity and fine-grained control, or something along those lines. I at least want to give a fair take on purpose for people thinking about it.

HTMX is great for its target audience, much superior to jQuery in this day and age, but you have to understand what its for.

jdthedisciple4• 4 years ago

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

listenallyall3• 4 years ago

Usually, the server returns plain HTML tags with Tailwind-enabled 'class' attributes.

jaredcwhite2• 4 years ago

I don't understand why you mentioned Tailwind. Nothing about htmx requires a utility class framework AFAIK.

recursivedoubts10• 4 years ago

The normal way: via a CSS file included in your head.

jdthedisciple4• 4 years ago

Yea I figure but I meant actually like layouting and overall decision-making when it comes to how much data should be shown in this or that place, why should the API make those decisions for the client rather than just sending data?

lawtalkinghuman• 4 years ago

Exciting new technology for styling web pages.

https://www.w3.org/Style/CSS/

quickthrower27• 4 years ago

The question makes me think someone is teaching new developers wrong in a complex-thing-first way.

Instead of HTML, CSS, JS in that order maybe they got chucked right into a NextJS / Tailwind twitter clone course as their intro to web dev.

jdthedisciple4• 4 years ago

Haha ok let me expand, I didn't actually mean only styling but layouting as well. Consider this example from htmx.org:

<html> <body> <div>Account number: 12345</div> <div>Balance: $100.00 USD</div> <div>Links: <a href="/accounts/12345/deposits">deposits</a> <a href="/accounts/12345/withdrawals">withdrawals</a> <a href="/accounts/12345/transfers">transfers</a> <a href="/accounts/12345/close-requests">close-requests</a> </div> <body> </html>

What I don't get is who says I want to have all of that html displayed in this exact form anywhere I make a request for account info? Say I want to only display the Account balance - are you telling me client has to cut and parse the html response for that? How much html parsing is that gonna be all over a web page?

Also the example I gave below about setting the css classes and ids inside the returned html elements...

recursivedoubts10• 4 years ago

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.

mtlynch2• 4 years ago

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

recursivedoubts10• 4 years ago

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.

BeefySwain3• 4 years ago

Can you be specific about what exactly an exploit taking advantage of this in HTMX would look like?

60secs• 4 years ago

Why the use of the article 'An' instead of 'A' ?

detaro2• 4 years ago

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)

jrockway2• 4 years ago

They must pronounce it S P A, not "spa". In which case, it's "an" because S sounds like "ess", which starts with a vowel-like sound, so you use "an".

I also pronounce it S P A, so "an" seemed immediately correct to me.

recursivedoubts10• 4 years ago

You have no idea how many times I went back and forth on this.

zagrebian2• 4 years ago

Could you put publication dates below blog post titles on that website?

kulor• 4 years ago

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

rlawson• 4 years ago

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.

likortera• 4 years ago

Same here, except I use Unpoly for all my side projects.

quickthrower27• 4 years ago

Has anyone got battle stories from using HTMX it similar? I there a time you regretted it a little and wished you had chosen React? Or is it pretty rosy?

phil-martin2• 4 years ago

I've used it a fair bit in a equipment finance app I have built for a small company.

In the system I've used a mix of regular django templates, some Django unicorn, some HTMX, and some HTMX+Alpinejs

I pick the tool based on the the amount of interactivity I need on the page.

It's.... interesting. If you start out knowing you will do HTMX, then I found everything is much easier. Splitting off small small views to return just the right html after a hx-post is more labor intenstive than i would like, bit overall it's nice.

The hardest part I found was being able to have a fine level of control around the user experience, and solving that required adding a lot of javascript, which made me wonder if it was worth the effort and should have instead just used Vue to handle it.

I've ended up using a lot of HX-Refresh in responses (causes a page refresh) because it was easier to do that than to ensure all the different parts of the page updated at the right time.

The way it cascades htmx values down the tree is really handy, and lends itself to consise attributes on the html.

Overall I'd give it a silver-coated bullet rating. Certainly not a solid silver bullet. :)

infamia• 4 years ago

It's.... interesting. If you start out knowing you will do HTMX, then I found everything is much easier. Splitting off small small views to return just the right html after a hx-post is more labor intenstive than i would like, bit overall it's nice.

This was almost exactly my first impression of HTMX as well. It's a huge step forward! However, for my tastes it demands too many tiny views and micromanaging, which somewhat felt like a drag on my productivity. For an alternative, take a look at Unpoly [1] which has more batteries included (i.e. create layers of interactivity that update lower layers automatically) and is centered around full page requests/diffs and less focused on injecting small page fragments everywhere. For my small apps, I could do everything in one view that took three or more views with HTMX. I can only imagine the views exploding for a modestly complex site. The biggest penalty for Unpoly is that it is quite a bit (~2X) slower than HTMX, which needs to be kept in mind and managed for larger pages with a lot of interactivity. I suspect this is because Unpoly loads the entire page and does a DOM diff to see what it needs to update, as opposed to injecting just a page fragment. In my tests, I was able to manage around this issue using layers. The big upside to Unpoly is that the full page refresh architecture aligns very neatly with Django's request/response cycle, which gives you pretty seamless interactivity and form validation. It also has a lot of batteries included that HTMX lacks. I think HTMX is terrific and revolutionary, but Unpoly fits my brain better while doing Django development.

[1] https://unpoly.com/tutorial

mejutoco• 4 years ago

I have used it for my website [1] and liked it a lot. I found the attributes `hx-swap` and `hx-swap-oob` [2] important to allow multiple updates. For instance, after liking a post the like button updates in several places, in the aforementioned website.

I found out putting the ids for the htmx snippets in a typed datastructure (in my case Python with type annotations, since I use django in the backend) to be easier to find the corresponding templates, see all usages, etc. I think otherwise it gets a bit confusing.

[1] https://fromzerotofullstack.com/

[2] https://htmx.org/attributes/hx-swap-oob/

noidexe2• 4 years ago

For me this feels like finally jumping back to the good timeline.

From the user point of view, I think there are two main types of experiences on the Web:

a ) Interactive documents. Basically web 1.0 but today we want fancier transitions and interactions. This can be provided by htmx and should always have been developed declaratively. It should ideally be provided by the browser and htmx shouldn't need to exist. Examples of this are Gmail and most social networks and forums including this one.

b) Desktop apps-but-I-don't-want-to-have-to-install-them. This would be things like Google Docs, Photopea and most real-time games. To deliver this, right now we have a browser that has become almost an OS inside an OS, to the point only Google can keep up with the complexity. On top of that, we pretend apps are documents and for all the imperative code we need we use a scripting language that was not meant for that, and we need a really complex VM just to keep it more or less performant. For this use case I think at some point we should move all the way into just delivering apps, if not native apps, something like wasm, where the browser tab would just be a vm player.

toddmorey• 4 years ago

I agree generally with the two types of experiences, but I'd also submit that there's no easy, clear deliniating line and it's much more of a spectrum between the two types. I really think some of the quirky magic of the web comes from this doc / app hybrid thing it supports and bifurcating them fully would be a mistake.

Rich Harris speaks towards that here: https://www.youtube.com/watch?v=860d8usGC0o

ordinaryradical• 4 years ago

I think the spectrum is the right mental model, too.

E-commerce stores have different interactivity needs than blogs, which have different needs than documentation, which has different needs than dashboards, which have different needs than real-time collaboration tools, and on and on and on.

Much of the framework angst is around the assumption of a singular tool for all these varieties of interaction and the annoyance that comes with not acknowledging the trade-offs.

Plus the web itself is changing, so the breadth of this spectrum is increasing. Years ago, the ends might not have been very far apart but they are diverging more with each new use-case and app idea.

fendy3002• 4 years ago

CMIIW for a), chrome is prototyping `shared element transition` for that case.

soruly2• 4 years ago

This reminds me of the <meta> tag page transitions in Internet Explorer 20 year ago! http://www.simplehtmlguide.com/pagetransitions.php

hencq• 4 years ago

I really love the idea of htmx and will definitely use it for my next hobby project. Out of curiosity, does htmx only work for always online apps or could you build a PWA with offline capability with it as well?

mixmastamyk4• 4 years ago

Seems focused on a backend service, but you may be able to fake it.

jasongi2• 4 years ago

I have noticed that there is a dogmatic element to a lot proponents of these libraries which leaves a sour taste in my mouth.

Occasionally you get a head nod in the direction that “sometimes, React is the best tool” but most of the time it’s Simpsons memes stoking a culture war.

If you’ve worked in an org where someone with decision making power has drunk the “progressive enhancement not SPA” koolaid, then it’s just as bad as someone who has drunken the SPA always koolaid - at least you’ll find it easy to hire and find support/libraries with the latter.

wrnr• 4 years ago

This happens a lot mathematicians might have their favourite object they study like Category theory and then get hung up on categories of categories but might forget that many simple things aren't categories like the prime numbers under addition because 2 + 2 = 4 and that is not prime.

Not just programming or math, in physiology you have entire research groups worked up about a molecule that causes dementia and after decades of research realise that the story was a lot more complicated than that.

You can almost recognise a healthy mind by the lack of such dogma, just don't make it a rule that would defeat its purpose.

silviogutierrez• 4 years ago

I'm the creator of Reactivated[1] and fully agree with a lot of the aversion to SPAs [2] and REST [3][4]

But to me, writing my markup in JSX (really, TSX with TypeScript) and using scoped CSS solutions was too good to pass up. I just couldn't bear writing text-based templates.

That's why I built Reactivated: combining the best of both worlds. Server-rendered, simple markup — albeit still in TypeScript — but you can add interactivity as needed.

Of course, HTMX is far less opinionated and framework-agnostic. So it can be used with any number of libraries / stacks.

[1] https://www.reactivated.io

[2] https://www.reactivated.io/documentation/philosophy-goals/#t...

[3] https://www.reactivated.io/documentation/philosophy-goals/#r...

[4] https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...

zagrebian2• 4 years ago

When was this published?

NorwegianDude• 4 years ago

I have been doing something similar where a js file takes over links and forms and uses fetch to get content and some other data on navigation.

Great TTFB as I don't need to send it to node to render js, faster navigation for many users with slow plugins and easy to implement.

This seems to do the same thing, and much more. I really need to try htmx, looks cool!

jmull• 4 years ago

Here's the "motivation" for htmx, from it's main page:

  Why should only <a> and <form> be able to make HTTP requests?
  Why should only click & submit events trigger them?
  Why should only GET & POST methods be available?
  Why should you only be able to replace the entire screen?
  By removing these arbitrary constraints, htmx completes HTML as a hypertext

I think the first three items are minor issues, at best, which in no way justify yet another DSL.

The fourth is a reasonable point -- it's quite common that you only want to update a portion of a page.

But it's very unclear that HTTP requests are the way to do it.

For one thing, using HTTP requests as the transport for app event handling adds nothing conceptually. It seems nice to use something that people are widely familiar with to build an event model on top of, but HTTP isn't a good fit for everything. So you either need something else (javascript or another language/api/framework) or you awkwardly fit everything into this model anyway.

But more importantly, it implies a strongly hierarchical structure to your app UI, which I think is overly rigid and unrealistic. Content tends to be largely hierarchical, but frequently important cross-cutting concerns pop up... maybe not on day one, but maybe on day 100 or 1000. Now you're swimming upstream.

Also, it's not like there aren't a very high number of HTML-centric options available. It has an interesting low-level approach, but in the end we're developing apps and UIs. It's very unclear to me whether htmx really offers advantages that other approaches don't meet or exceed.

mamcx• 4 years ago

It's very unclear to me whether htmx really offers advantages that other approaches don't meet or exceed.

You say what is the advantage before :) :

... maybe not on day one, but maybe on day 100 or 1000.

That is the thing. Is Wonderfull when you actually wait and see if you truly need the extra complexity of things.

Go nuts when is time to go nuts.

But is nuts to do it now.

soruly2• 4 years ago

I think Turbolinks is a nice balace bewteen traditional webpage and SPA. https://github.com/turbolinks/turbolinks

It provides a smooth UX by fetching next page's HTML in background, then replace the DOM by compareing the diff in HTML. So you won't see a blank page while navigating between pages.

jasongi2• 4 years ago

Turbolinks is one of those things that seems revolutionary to begin with, until you need to start implementing hacks in your server in order to deal with edge cases.

Things I remember from the last time I had to deal with these libraries were redirects and hard-to-debug JavaScript issues due to so much JavaScript relying on document ready/onload events.

barking_biscuit• 4 years ago

https://hotwired.dev/

They turned Turbolinks and extended it into a complete framework. I really want to give it a try.

danbulant• 4 years ago

Kind of reminds me of sveltekit. For example, I hate writing the same HTML repeatedly, so I just used svelte for it's components and made a fully static, JS-less page. That later evolved and left out the JS-less (some fancy effects, dialogs, cross-page transitions etc), but even for building static pages seems far better than writing normal HTML, when those pages become a bit complex.

calderwoodra• 4 years ago

What are the pain points developers have with SPAs? I've been working on a nextjs/react/tailwindcss project for 5 months full-time now and I honestly love it. It's been very intuitive and straightforward to get things done.

ravenstine• 4 years ago

There are no pain points with SPAs that can't be had in any other kind of web app architecture. Most of the problems we run into are ones we create for ourselves. Writing jQuery splatter got tiring, so we moved everything to the frontend. Then we got tired of our 300+ line Webpack configs, so now the old days of server rendered HTML is where the grass looks green. Inevitably, we will get tired of all the hacks we have to do to work around the shortcomings of HTMX/LiveView/Hotwire and move on to something else.

What tires me is the groupthink around web development. SPAs and server rendered content aren't better than one another. It's annoying and unreasonable that the current trend is that SPAs are bad. They are not. Everything bad with SPAs I've seen is caused by developers not getting their priorities straight and by bandwagoning. Stop making webpages complicated and you'll find that many problems disappear.

tr1ll10nb1ll• 4 years ago

One of my apps built on the Django+HTMX stack got traction and no matter how much I loved using HTMX, I found it’s not feasible to keep a clean codebase (facilitating new developers on the team as well) with this stack.

[Tetra](https://www.tetraframework.com/) might be an alternative if you’re hell-bent on not using React.

But, if you want to ship quick, have a maintainable codebase in a technology a lot of devs are familiar with and have the power to instantly ship for mobile (and buy yourself some time to build one in React Native; code is going to be similar to React.js), I’d recommend using React.

You can use Capacitor.js for instantly shipping a mobile app with your codebase that “just works”. Use Capgo for affordable codepush and you’re set!

HTMX all the way if you’re not building an app cause not everything is an “app”.

At the same time, if you’re building an app with a framework unlike Phoenix, I don’t see why one would not go ahead and use a decent JS framework. Using frontend framework seems to be facing a lot of aversion and I don’t understand if it’s because of the inability to learn these frameworks or what.

Point is, your users just need a snappy app that works. That’s it! And using a robust frontend framework makes it easier.

An SPA Alternative

Related Stories