[HN Gopher] Htmx Is the Future
___________________________________________________________________
Htmx Is the Future
Author : quii
Score : 537 points
Date : 2023-05-05 14:32 UTC (8 hours ago)
(HTM) web link (quii.dev)
(TXT) w3m dump (quii.dev)
| chrsjxn wrote:
| I love articles like these, because the narrative of "JS
| framework peddlers have hoodwinked you!" is fun, in an old-timey
| snake oil salesman kind of way.
|
| But I'll be honest. I'll believe it when I see it. It's not that
| htmx is bad, but given the complexity of client-side interactions
| on the modern web, I can't see it ever becoming really popular.
|
| Some of the specifics in the comparisons are always weird, too.
|
| > Instead of one universal client, scores of developers create
| bespoke clients, which have to understand the raw data they fetch
| from web servers and then render controls according to the data.
|
| This is about client side apps fetching arbitrary JSON payloads,
| but your htmx backend needs to do the same work, right? You have
| to work with the raw data you get from your DB (or another
| service) and then render based on that data.
|
| You're still coupled to the data, and your htmx endpoint is just
| as "bespoke" as the client code which uses it. It's not wrong to
| prefer that work be done on the server instead of the client, or
| vice versa, but we're really just shuffling complexity around.
| phpnode wrote:
| Title needs (2011). Not because that's when it was written but
| because that's when this technique was the future.
| recursivedoubts wrote:
| we are going to go back
|
| back to the future
| robertoandred wrote:
| This really comes down to backend devs thinking frontend must be
| simple, and when they realize it's not they blame the tools. So
| they come up with new tools and pretend they're better because
| they cater to backend devs and not those silly frontenders who
| just don't know anything.
| aigoochamna wrote:
| I somewhat get where htmx is coming from. It's not bad per-say..
| I actually like the general idea behind it (it's sorta like
| Turbolinks, but a bit more optimal using fragments instead of the
| entire page, though Turbolinks requires zero additional work on
| the markup side and works with JavaScript disabled out of the
| box).
|
| With that being said, I imagine it would become unmaintainable
| very quickly. The problems htmx is solving are better solved with
| other solutions in my opinion, but I do think there's something
| that can be learned or leveraged with the way htmx goes about the
| solution.
| jmull wrote:
| > HTMX is the Future
|
| I'm not seeing it. SPAs can be overly complex and have other
| issues, but I'm not seeing HTMX as a particular improvement.
|
| Also, a bunch of this article doesn't make sense to me.
|
| E.g, one of the listed costs of SPAs is managing state on the
| client and server... but (1) you don't have to -- isn't it rather
| common to keep your app server stateless? -- and (2) HTMX
| certainly allows for client-side and server-side state, so I'm
| not sure how it's improving things. That is, if you want to
| carefully manage app state, you're going to need a mechanism to
| do that, and HTMX isn't going to help you.
|
| It also doesn't somehow prevent a rats nest of tooling or
| dependencies. It isn't an application framework, so this all
| depends on how to solve that.
|
| SPA's also aren't inherently "very easy to make [...]
| incorrectly".
|
| Also, the suggested HTMX approach to no browser-side javascript
| is very crappy. Your app would have to be very specifically
| designed to not be utterly horrible w/o JS with such an approach
| and instead be just pretty horrible. There are just so much more
| straightforward ways to make apps that work well without JS.
| Also, this isn't exactly a mainstream requirement in my
| experience.
|
| I could go on and on. "caching" - htmx doesn't address the hard
| part caching. "seo-friendliness" - Like all the benefits here
| attributed to htmx, htmx doesn't particularly help with this and
| there are many other available way to achieve it.
|
| IDK. These kinds of over-promising hyped up articles give me the
| feeling the thing being hyped up probably doesn't have a lot of
| real merit to be explored or else they'd talk about that instead.
| It also feels dishonest to me, or at least incompetent, so make
| all of these claims and assertions that aren't really true or
| aren't really especially a benefit of htmx vs many numerous other
| options.
| vp8989 wrote:
| 1) "Web application development" doesn't happen in a vacuum.
| Often it happens in contexts where the "backend" is also consumed
| by various non-web applications. In those contexts, collapsing
| the frontend and backend back into 1 component is less of the
| slam dunk than it's made out to be in this post.
|
| 2) The missing piece is how you can achieve this "collapsing"
| back of functionality into single SSR deployable(s) while still
| preserving the ability to scale out a large web application
| across many teams. Microfrontends + microservices could be
| collapsed into SSR "microapplications" that are embedded into
| their hosting app using iframes?
| quest88 wrote:
| This is a weak argument. The article is demoing a TODO app
| talking to localhost. Almost any library, framework, or language
| is the future if this is how we're judging the future.
|
| > Working with HTMX has allowed me to leverage things I learned
| 15-20 years ago that still work, like my website.
|
| Yes, a website is different than a webapp and has different
| requirements.
| BeefySwain wrote:
| > Yes, a website is different than a webapp and has different
| requirements.
|
| The piece missing here is that most people do not stop to think
| which they are building before they reach for a JS heavy SPA
| framework and start spinning up microservices in whatever AWS
| calls their Kube implimentation.
| brushfoot wrote:
| I use tech like HTMX because, as a team of one, I have no other
| choice.
|
| I tried using Angular in 2019, and it nearly sank me. The
| dependency graph was so convoluted that updates were basically
| impossible. Having a separate API meant that I had to write
| everything twice. My productivity plummeted.
|
| After that experience, I realized that what works for a front-end
| team may not work for me, and I went back to MPAs with JavaScript
| sprinkled in.
|
| This year, I've looked at Node again now that frameworks like
| Next offer a middle ground with server-side rendering, but I'm
| still put off by the dependency graphs and tooling, which seems
| to be in a constant state of flux. It seems to offer great
| benefits for front-end teams that have the time to deal with it,
| but that's not me.
|
| All this to say pick the right tool for the job. For me, and for
| teams going fuller stack as shops tighten their belts, that's
| tech like HTMX, sprinkled JavaScript, and sometimes lightweight
| frameworks like Alpine.
| willio58 wrote:
| Angular is falling off hard in the frontend frameworks race.
| And I totally agree about how the boilerplate and other things
| about Angular feels bad to work with. Other frameworks are far
| easier to build with, to the point where a 1-person team can
| easily handle them. React is being challenged but still has the
| biggest community, it's a much better place to start than
| Angular when evaluating frameworks like this.
|
| All that being said, I'm glad HTMX worked out for you!
| fridgemaster wrote:
| Angular 2 works fine out of the box, and already provides a
| good architecture that noobs struggle to come up with in
| "freestyle" solutions like React. Angular's bi-directional
| binding is way superior and simpler to use vs React's mono-
| directional binding: you can just use bound variables, no
| need to do complicated setState or use abominations like
| Redux. Vue also has bi-directional binding. Essentially there
| are many alternatives that are superior to React, which is
| where it is mostly because of fame and popularity.
| agrippanux wrote:
| You may of not used React in the past few years, but
| setState fell out of favor a while ago with the release of
| the useState hook and Redux (which I agree is an
| abomination) isn't necessary for 95% (imo) cases, again
| thanks to hooks.
|
| For bound variables you can use MobX or signals in Preact.
| hirako2000 wrote:
| I have no love for unnecessarily bloated dependency graphs, but
| we can't have the cake and eat the cake too.
|
| Next.js for example, comes packed with anything and everything
| one might need to build an app. Sitting on the promise of
| hyperproductivity with "simplicity". Plus, is made of single
| responsability principles set of modules, kind of necessary to
| build a solve-all needs framework.
|
| And it does that.
|
| A bit like Angular, set to solve everything front-side. With
| modules not entirely tightly coupled but sort of to get the
| full solution.
|
| And it did that.
|
| Then we have outliers like React, which stayed away from trying
| to solve too many things. But the developers have spoken, and
| soon enough it became packed in with other frameworks. Gatsby
| etc. And community "plug-ins" to do that thing that dev think
| should be part of the framework.
|
| And they did that, solved most problems from authentication to
| animation, free and open source sir, so that developers can
| write 12 lines of code and ship 3 features per day in some non
| innovative way, but it works, deployed in the next 36 seconds,
| making the manager happy as he was wondering how to justify
| over 100k in compensation going to a young adult who dressed
| cool and seemed to type fast.
|
| Oh no! dependency hell. I have to keep things maintained, I
| have to actually upgrade now, LTS expired, security audits on
| my back, got to even change my code that worked perfectly well
| and deal with "errors", I can't ship 3 features by the end of
| today.
|
| We need a new framework!
| marcosdumay wrote:
| Back in the late 90's and early 00's, armed with the
| experience of C, C++, Bash, and Perl, everybody knew it very
| clearly that "batteries included" is the correct way to
| create development tools.
|
| I don't know about the current fashion of minimalism comes
| from. It doesn't bring simplicity.
| hdjjhhvvhga wrote:
| > C, C++, Bash, and Perl
|
| While I agree with your comment, lumping these together
| somehow doesn't seem fair. As for C and C++, it took
| decades to develop package managers, and we can't still say
| we have standard ones (but I feel Conan is a de facto
| standard PM for C++).
|
| Bash, on the other hand, should never have 'batteries
| included' because in this case the batteries are the rest
| of the system - coreutils and the rest. An Perl had CPAN
| quite early on, in the early nineties iirc.
| marcosdumay wrote:
| C is completely without batteries, the stdlib for C++ was
| a great change and a big force towards people adopting
| it. The same happened with Bash and Perl (and people did
| migrate a lot of things into the later).
| justeleblanc wrote:
| So Next.js did everything right, but is built upon React that
| does too much. Okay?
| BiteCode_dev wrote:
| Django comes with a lot: auth, caching, csrf protection, an
| orm, the admin, form workflow, templating, migrations, i18n,
| and yet doesn't come with thousands of deps.
| minusf wrote:
| it comes exactly with 2 on latest python versions
| courgette wrote:
| I maintains a side project in Django since 5+ years now.
|
| The scope has been reduce to almost nothing. I have spend
| like 20h on it in 2022. But it still being used.
|
| Django helps by how boring and solid it feels.
|
| A similar project in node would probably not build anymore
| BiteCode_dev wrote:
| I know of a 15 years django project that runs on 2.7 that
| is still making money. It got reinstalled this month on
| brand new Ubuntu servers out of a rubbish
| requirements.txt, and it worked.
|
| So much for saying python packaging sucks.
| stanmancan wrote:
| Have you taken a look at Elixir/Phoenix? I've recently made the
| switch and I find it incredibly productive as a solo developer.
| jasfi wrote:
| I'm using React, and I feel like I can manage as a team of one.
| But React has a huge community, which means lots of libraries
| for just about anything you need.
|
| I previously used HTMX for another project of mine, and it
| worked fine too. I did, however, feel limited compared to React
| because of what's available.
| [deleted]
| fridgemaster wrote:
| Just pick a lightweight web framework, and freeze the
| dependencies. I don't see the problem.
| scoofy wrote:
| I use htmx on my current project, and it's like a dream. I'm
| happy to sacrifice a bit of bandwidth to be able to do all the
| heavy lifting in python. On top of that, it makes testing _much
| much easier_ since it turns everything is GET and POST
| requests.
|
| I'd add a couple features if I were working there (making css
| changes and multiple requests to multiple targets standard),
| but as it stands, it's a pleasure to work in.
| elliottinvent wrote:
| Hop on the Discord, a very active and collaborative
| community: https://htmx.org/discord
| MisterSandman wrote:
| Angular is nototiously bad for single developers. React is much
| better, and things like Remix and Gatsby are even better.
| Bellend wrote:
| I'm a single developer and its fine. (5 years in).
| ChikkaChiChi wrote:
| I've felt the same way and it's good to hear I'm not alone. I
| feel like log4j should have been enough of a jolt to push back
| on dependency hell enough that devs would start writing
| directly against codebases they can trace and understand. Maybe
| this is just a byproduct of larger teams not having to do their
| own DevOps.
| ademup wrote:
| Your story sounds similar to mine, and your choice to use HTMX
| has me motivated to check it out. The sum total of my software
| supports 5 families' lifestyles entirely on LAMP MPAs with no
| frameworks at all. Thanks for posting.
| tudorw wrote:
| Xanadu.
| pwpw wrote:
| What is the simplest way to host a website closer to barebones
| HTML, CSS, and a bit of JS with reusable components like nav
| bars? My experiences handling those manually leads to too much
| overhead as I add more pages. SvelteKit makes things fairly easy
| to organize, but I dislike how the user isn't served simple HTML,
| CSS, and JS files. Ideally, I don't want to use any framework.
| optymizer wrote:
| It's called PHP and you can host it anywhere, or if there's
| nothing dynamic going on, run it on the files on your computer
| and upload the generated HTML/CSS/JS files to an S3 bucket.
| src/index.php --------- <!DOCTYPE html>
| <html> <head><title>Hey look ma, we're back to
| PHP</title></head> <body> <? include
| "navbar.php" ?> <p>Don't forget about PHP -
| a hypertext preprocessor!</p> <? include
| footer.php ?> </body> </html>
| src/navbar.php ---------- <div>
| <ul> <li>Home</li> <li>About</li>
| </ul> </div> Makefile to generate a
| static site: -----------------------------------
| dist/index.html: src/index.php dist/about.html:
| src/about.php dist/%.html: src/%.php
| @mkdir -p ${dir $@} php $< > $@
| doodlesdev wrote:
| No it's not. Honestly, the fact that this website displays like
| shit without JavaScript enabled is ironic considering it uses
| HTMX.
|
| Please just use the damn full-stack JS frameworks, they make life
| simpler, just wait for WebAssembly to allow us to have full-stack
| Rust/Go/whatever frameworks, and then you can abandon JavaScript,
| otherwise you get the mess of websites like this one where the
| developer has not written JavaScript, but the website still needs
| it for me to be able to read a _damn blog post_.
|
| Otherwise, stick with RoR, Django, Laravel, or whatever ticks
| your fancies, but HTMX just ain't for everyone and everything,
| it's supposed to be used for hypermedia, not for web apps or
| anything else, just that: hypermedia.
|
| And no, JavaScript libraries aren't all "complicated" and "full
| of churn", React is. Stop using React, or otherwise accept the
| nature of its development, and stop complaining. There are
| hundreds of different JavaScript libraries and yet every single
| time I see people bashing on full stack JavaScript they just keep
| repeating "React" like it's the only library in the world and the
| only way developers have written code for the last decade.
|
| Also, tangentially related, can we as an industry stop acting
| like kids and stop following these "trends"? The author talks
| about a "SPA-craze" but what I've been seeing more and more now
| is the contrary movement, however it's based on the same idea of
| a hype cycle, with developers adopting technology because it's
| cool or whatever and not really considering what are their actual
| needs and which tools will provide them with that.
|
| Rant over.
| tsuujin wrote:
| > Please just use the damn fullstack JS frameworks, they make
| life simpler
|
| Strongest possible disagree. I've been doing web dev for a long
| time, and the last 10 years has seen a massive, ridiculous
| increase in complexity across the board.
|
| I personally took my company back to good old server rendered
| apps with a turbolinks overlay because I was sick of dealing
| with the full stack frameworks, and we saw a huge increase in
| productivity and developer happiness.
| doodlesdev wrote:
| Hotwire is appropriate (I imagine you're not using actual
| Turbolinks which has been deprecated) with RoR or whatever
| stack you want, I agree it's great developer experience
| (despite Ruby and Rails being painfully slow haha).
|
| I wonder which full-stack JS framework you used that you
| thought made life harder? One of the things that gets me mad
| is the idea of putting it all in one single box, as React is
| indeed very (needlessly) complex and so can be other
| libraries, but that doesn't mean the paradigm of JavaScript
| front-to-back is fundamentally flawed.
|
| edit: Something else I should've added to my comment is that
| the HTMX approach is terrible if you ever need more than just
| the web-client (i.e. a mobile app, native or otherwise) since
| you will now have to implement an API anyway, which you
| could've done in the first place by taking the usual approach
| to development.
| tsuujin wrote:
| > I wonder which full-stack JS framework you used that you
| thought made life harder?
|
| I've used Angular, Dart, Backbone, Ember, Elm, React, Vue,
| Svelte, and a few others I can't remember anymore. All in
| production systems, not demo projects. Also some of the
| "build it once" platforms like Meteor.
|
| They're all cool until you have to actually maintain them.
| My favorite part is having to build my data models twice,
| one for the producer and one for the consumer. That's
| totally never caused any headaches or slowed anyone down at
| all.
| doodlesdev wrote:
| > I've used Angular, Dart, Backbone, Ember, Elm, React,
| Vue, Svelte, and a few others I can't remember anymore.
| All in production systems, not demo projects. Also some
| of the "build it once" platforms like Meteor.
|
| That's quite a lot of libraries lol, I guess no one can
| say you just haven't found the right library
|
| I must admit I've used Hotwire much less than I
| should've, but I still feel comfortable with full-stack
| JavaScript (or rather, TypeScript).
|
| You said you migrated back to Turbo, what backend
| framework do you use? RoR with Hotwire is so nice, but I
| personally avoid it because of Ruby (not personally a
| fan), to be fair the same is true for most full-stack
| frameworks I avoid (such as Django/Python).
| jdthedisciple wrote:
| Well which JS framework(s)/librar[y|ies] are _you_ then
| using /advocating for, if you agree that React is
| needlessly complex?
| doodlesdev wrote:
| I personally enjoy Svelte.
| PaulHoule wrote:
| I worked for a startup that built a React + Scala system for
| building training sets for machine learning models. At the time I
| was involved this had a strong research component, particularly
| we frequently had to roll out new tasks, and in fact we were
| working actively with new customers to adapt to their needs all
| the time.
|
| The build for the system took about 20 minutes, and part of the
| complexity was that every new task (form where somebody had to
| make a judgement) had to be built twice since both a front end
| and back end component had to be built so React was part of the
| problem and not part of the solution. Even in a production
| environment this split would have been a problem because a busy
| system with many users might still need a new task added from
| time to time (think AMZN's MTurk) and forcing people to reload
| the front end to work on a new task defies the whole reason for
| using React.
|
| It all was a formula for getting a 20 person team to be spinning
| its wheels, struggling to meet customer requirements and keeping
| our recruiters busy replacing developers that were getting burnt
| out.
|
| I've built several generations of my own train-and-filter system
| since then and the latest one is HTMX powered. Each task is
| written once on the back end. My "build" process is click the
| green button on the IDE and the server boots in a second or two.
| I can add a new task and be collecting data in 5-10 minutes in
| some cases, contrasted to the "several people struggling for 5
| days" that was common with the old system. There certainly are
| UIs that would be hard to implement with HTMX, but for me HTMX
| makes it possible to replace the buttons a user can choose from
| when they click a button (implement decision trees), make a
| button get "clicked" when a user presses a keyboard button and
| many other UI refinements.
|
| I can take advantage of all the widgets available in HTML 5 and
| also add data visualizations based on d3.js. As for speed, I'd
| say contemporary web frameworks are very much "blub"
|
| http://www.paulgraham.com/avg.html
|
| On my tablet via tailscale with my server on the wrong end of an
| ADSL connection I just made a judgement and timed the page reload
| in _less than a second_ with my stopwatch. On the LAN the
| responsiveness is basically immediate, like using a desktop
| application (if the desktop application wasn 't always going out
| to lunch and showing a spinner all the time.)
| redonkulus wrote:
| We've been using similar architecture at Yahoo for many years
| now. We tried to go all in on a React framework that worked on
| the server and client, but the client was extremely slow to
| bootstrap due to downloading/parsing lots of React components,
| then React needing to rehydrate all the data and re-render the
| client. Not to mention rendering an entire React app on the
| server is a huge bottleneck for performance (can't wait for
| Server Components / Suspense which are supposed to make this
| better ... aside: we had to make this architecture ourselves to
| split up one giant React render tree into multiple separate ones
| that we can then rehydrate and attach to on the client)
|
| We've moved back to an MPA structure with decorated markup to add
| interactivity like scroll views, fetching data, tabs and other
| common UX use cases. If you view the source on yahoo.com and look
| for "wafer," you can see some examples of how this works. It
| helps to avoid bundle size bloat from having to download and
| compile tons of JS for functionality to work.
|
| For a more complex, data-driven site, I still think the SPA
| architecture or "islands" approach is ideal instead of MPA. For
| our largely static site, going full MPA with a simple client-side
| library based on HTML decorations has worked really well for us.
| vosper wrote:
| > We've been using similar architecture at Yahoo for many years
| now.
|
| At all of Yahoo? I imagined such a big company would have a
| variety of front-end frameworks and patterns.
| redonkulus wrote:
| Nope, not all. Yahoo homepage, News, Entertainment, Weather
| all use this architecture. Yahoo Mail uses a React/Reduct
| architecture on the client. Other Yahoo properties with more
| complex client-side UX requirements are using things like
| Svelte or React. It's not a one size fits all architecture at
| Yahoo, we let teams determine the right tools for the job.
| anyonecancode wrote:
| The tricky part of an SPA is that as a developer, you're taking
| on a lot of the burden of managing location state that in an MPA
| is handled by the browser. And location state often is a
| significant component of application state.
|
| Certainly it's possible to take on that burden and execute it
| well, but I think a lot of teams and businesses don't fully
| account for the fact that they are doing so and properly deciding
| if that extra burden is really necessary. The baseline for
| nailing performance and correctness is higher with an SPA.
| yellowapple wrote:
| Using an HTTP header to decide between "just return a snippet for
| this specific list element" v. "return the whole page with the
| updated content for this list element" is an interesting choice
| that I hadn't really considered before; normally I would've opted
| for two entirely separate routes (one for the full page, one for
| the specific hypermedia snippet), which HTMX also seems to
| support. I guess it ain't fundamentally different from using e.g.
| Accept-* headers for content negotiation.
| quii wrote:
| I think both are valid, as i mentioned in the article, for this
| particular case, the psuedo content-negotiation felt right
| pkelly wrote:
| Thank you for writing this article! I've had similar thoughts for
| the past 5 years or so.
|
| A lot of the comments here seem to have the approach that there
| is a single best stack for building web applications. I believe
| this comes from the fact that as web engineers we have to choose
| which tech to invest our careers in which is inherently risky.
| Spend a couples years on something that becomes defunct and it
| feels like a waste. Also, startup recruiters are always looking
| for the tech experience that matches the choice of their
| companies. VCs want to strike while the iron is hot.
|
| Something that doesn't get talked about enough (which the author
| does mention near the end of article) is that different web apps
| have different needs. There is 100% a need for SPAs for certain
| use cases. Messaging, video players, etc. But there are many
| cases where it is overkill, like the many many CRUD resource apps
| I've built over the years. Say you have a couple hundred users
| that need to manage the state of a dozen interconnected
| resources. The benefits of an MPA are great here. Routing is
| free, no duplication of FE / BE code. Small teams of devs can
| ship code and fix bugs very fast which keeps the user feedback
| loop tight.
| quii wrote:
| Thanks for taking the time to read the article :) A lot of the
| comments here seem to implying that I claim "htmx is the one
| hammer to solve all website needs", even when I explicitly say
| SPAs have their place in the article.
|
| A hypermedia approach is the nice happy medium between a very
| static website and an SPA, not sure why so many people are
| close-minded about this possibility.
| iamsaitam wrote:
| "If you wish to use something other than JavaScript or
| TypeScript, you must traverse the treacherous road of
| transpilation." -- this is the crux of the article.
|
| These kind of takes fall in the bullseye of "I don't want to
| program with Javascript". The subtext is all about this.
|
| Perhaps.. maybe.. Htmx won't be the future because there are a
| lot of people that like programming in Javascript?
| aidenn0 wrote:
| > Managing state on both the client and server
|
| This is a necessity as long as latencies between the client and
| server are large enough to be perceptible to a human (i.e. almost
| always in a non-LAN environment).
|
| [edit]
|
| I also just noticed:
|
| > ...these applications will be unusable & slow for those on
| older hardware or in locations with slow and unreliable internet
| connections.
|
| The part about "slow and unreliable internet connections" is not
| specific to SPAs If anything a thick client provides
| opportunities to improve the experience for locations with slow
| and unreliable internet connections.
|
| [edit2]
|
| > If you wish to use something other than JavaScript or
| TypeScript, you must traverse the treacherous road of
| transpilation.
|
| This is silly; I almost exclusively use compiled languages, so
| compilation is happening no matter what; targeting JS (or WASM)
| isn't _that_ different from targeting a byte-code interpreter or
| hardware...
|
| --
|
| I like the idea of HTMX, but the first half of the article is a
| silly argument against SPAs. Was the author "cheating" in the
| second half by transpiling clojure to the JVM? Have they tested
| their TODO example on old hardware with an unreliable internet
| connection?
| ivan_gammel wrote:
| Fully agree with this comment. Also, client and server state
| are different: on the client you need only session state
| relevant to user journey, on server you keep only persistent
| state and use REST level 3 for the rest.
| lolinder wrote:
| > This is silly; I almost exclusively use compiled languages,
| so compilation is happening no matter what; targeting JS (or
| WASM) isn't that different from targeting a byte-code
| interpreter or hardware...
|
| I agree with everything else you said, but having followed the
| development of Kotlin/JS and WASM closely I have to disagree
| with this statement.
|
| JavaScript is a _very_ bad compilation target for any language
| that wasn 't designed with JavaScript's semantics in mind. It
| can be made to work, but the result is _enormous_ bundle sizes
| (even by JS standards), difficult sourcemaps, and terrible
| performance.
|
| WASM has the potential to be great, but to get useful results
| it's not just a matter of changing the compilation target,
| there's a lot of work that has to be done to make the
| experience worthwhile. Rust's wasm_bindgen is a good example: a
| _ton_ of work has gone into smooth JS interop and DOM
| manipulation, and all of that has to be done for each language
| you want to port.
|
| Also, GC'd languages still have a pretty hard time with WASM.
| hu3 wrote:
| meta: I love when htmx is highlighted in HN because the
| discussions branch into alternatives and different ways of doing
| web dev. It's very enriching to think outside the box!
| mikeg8 wrote:
| Agree. I always find some interesting and new FE
| approaches/methodologies in these random HTMX threads and it's
| awesome.
| obpe wrote:
| It's kinda funny to me that many of the "pros" of this approach
| are the exact reasons so many abandoned MPAs in the first place.
|
| For instance, a major selling point of Node was running JS on
| both the client and server so you can write the code once. It's a
| pretty shitty client experience if you have to do a network
| request for each and every validation of user input.
|
| Also, there was a push to move the shitty code from the server to
| the client to free up server resources and prevent your servers
| from ruining the experience for everyone.
|
| We moved away for MPAs because they were bloated, slow and
| difficult to work with. SPAs have definitely become what they
| sought to replace.
|
| But that isn't because of the technology, it's because all the
| devs writing shitty MPAs are now writing shitty SPAs. If this
| becomes popular, they will start writing shitty MPAs again.
| Nothing about this technology will stop that.
| MetaWhirledPeas wrote:
| > all the devs writing shitty MPAs are now writing shitty SPAs
|
| This pretty much sums it up. There is no right technology for
| the wrong developer.
|
| It's not about what _can_ get the job done, it 's about the
| ergonomics. Which approach encourages good habits? Which
| approach causes the least amount of pain? Which approach makes
| sense for your application? It requires a brain, and all the
| stuff that makes up a good developer. You'll never get good
| output from a brainless developer.
| duxup wrote:
| I often work on an old ColdFusion application.
|
| It's amusing that for a long time the response was "oh man that
| sounds terrible".
|
| Now it is "oh hey that's server side rendered ... is it a new
| framework?".
|
| The cycle continues. I end up writing all sorts of things and
| there are times when I'm working on one and think "this would
| be better as Y" and then on Y "oh man this should be Z". There
| are days where I just opt for using old ColdFusion... it is
| faster for somethings.
|
| Really though there's so many advantages to different
| approaches, the important thing is to do the thing
| thoughtfully.
| giraffe_lady wrote:
| I also switch back and forth between two large projects
| written in different decades and it definitely gives an
| interesting perspective on this. Basically every time I'm in
| php I go "oh yeah I see why we do react now" and every time
| I'm in react I go "oh right I see why php still exists."
| tempest_ wrote:
| To be fair to PHP there have been quite a few improvements
| to the language in recent years.
|
| I even hear Laravel is pretty nice to use.
|
| I'll never know that stuff though because the PHP I
| generally encounter is 15 years old spaghetti.
| cutler wrote:
| PHP lost its identity with the release of PHP5 since when
| it is nothing more than an interpreted version of Java.
| giraffe_lady wrote:
| Yeah I also hear that and also have no idea because I'm
| permanently in that 5.6 shit.
| pengaru wrote:
| > there are times when I'm working on one and think "this
| would be better as Y" and then on Y "oh man this should be
| Z".
|
| How much of that is just a garden variety "grass is always
| greener on the other side" effect?
|
| > the important thing is to do the thing thoughtfully.
|
| And finish! Total losses are still total losses no matter how
| thoughtfully done.
| duxup wrote:
| >How much of that is just a garden variety "grass is always
| greener on the other side" effect?
|
| In my example not so much. I'm working in a number of
| frameworks, use them regularly, sometimes ColdFusion is
| just faster / better suited, sometimes some other system.
| no_wizard wrote:
| ActionScript is basically ES6 too isn't it?
| phpnode wrote:
| No, it's more like ES4 which was eventually abandoned and
| never became part of ecmascript
| courgette wrote:
| Older than that, flash already received the apple coup de
| grace a little while ago when ES6 was release.
| mock-possum wrote:
| AS3 was typed though, so maybe closer to Typescript.
| mixmastamyk wrote:
| > have to do a network request for each and every validation of
| user input.
|
| HTML5 solved that to a first approximation client-side. Often
| later you'll need to reconcile with the database and security,
| so that will necessarily happen there. I don't see that being a
| big trade-off today.
| marcosdumay wrote:
| > But that isn't because of the technology
|
| Technically, the technology support doing any of them right. On
| practice, doing good MPAs require offloading as much as you can
| into the mature and well developed platforms that handle them;
| while doing good SPAs require overriding the behavior of your
| immature and not thoroughly designed platforms on nearly every
| point and handling it right.
|
| Technically, it's just a difference on platform maturity.
| Technically those things tend to correct themselves given some
| time.
|
| On practice, almost no SPA has worked minimally well in more
| than a decade.
| wrenky wrote:
| > , it's because all the devs writing shitty MPAs are now
| writing shitty SPAs. If this becomes popular, they will start
| writing shitty MPAs again
|
| It brings a tear of joy to my eye honestly. The circle of life
| continues, and people always forget people are bad at
| programming (myself included).
| onion2k wrote:
| _But that isn 't because of the technology, it's because all
| the devs writing shitty MPAs are now writing shitty SPAs. If
| this becomes popular, they will start writing shitty MPAs
| again. Nothing about this technology will stop that._
|
| This is only _sort of_ true. The problem can be mitigated to a
| large extent by frameworks; as the framework introduces more
| and more 'magic' the work that the developer has to do
| decreases, which in turn reduces the surface area of things
| that they can get wrong. A perfect framework would give the
| developer all the resources they need to build an app but
| wouldn't expose anything that they can screw up. I don't think
| that can exist, but it is definitely possible to reduce places
| where devs can go astray to a minimum.
|
| And, obviously, that can be done on both the server and the
| client.
|
| I strongly suspect that as serverside frameworks (including
| things that sit in the middle like Next) improve we will see
| people return to focusing on the wire transfer time as an area
| to optimize for, which will lead apps back to being more
| frontend than backend again. Web dev will probably oscillate
| back and forth forever. It's quite interesting how things
| change like that.
| tomca32 wrote:
| Unfortunately, developers often write code in a framework
| they don't know well so they end up fighting the framework
| instead of using the niceties it provides. The end result
| being that the surface area of things that can go wrong
| actually increases.
| CSSer wrote:
| Most companies unfortunately don't let developers
| adequately explore solutions or problem spaces before
| committing to them either. The ones that dominate do, but
| that's also because they often have the resources to build
| it from the ground up anyway.
|
| The average mid-sized business seems to have internalized
| that code is _always_ a liability, but they respond by
| cutting short discovery and get their just deserts.
| runlaszlorun wrote:
| True. But I also find that a lot of frameworks are narrowly
| optimized for solving specific problems, at the expense of
| generality, and those problems often aren't the ones I
| have.
|
| Supposedly declarative approaches especially are my pet
| peeve. "Tell it what you want done, not how you want it
| done" is nice sounding but generally disappointing when I
| soon need it to do something not envisioned by its creator
| yet solved in a line or two of general purpose/imperative
| code.
| CSSer wrote:
| That oscillation probably wouldn't happen if it were possible
| to be more humble about the scope of the solution and
| connection to commercial incentives. It's gotten to the point
| where a rite of passage for becoming a senior developer is
| waking up to the commercialization and misdirection.
|
| You can see the cracks in Next.js. Vercel, Netlify et. al,
| are interested in capitalizing on the murkiness (the middle,
| as you put it) in this space. They promise static performance
| but then push you into server(less) compute so they can bill
| for it. This has a real toll on the average developer. In
| order for a feature to be a progressive enhancement, it must
| be optional. This is orthogonal to what is required for a
| PaaS to build a moat.
|
| All many people need is a pure, incrementally deployed SSG
| with a robust CMS. That could exist as a separate commodity,
| and at some points in the history of this
| JAMStack/Headless/Decoupled saga it has come close (excluding
| very expensive solutions). It's most likely that we need web
| standards for this, even if it means ultimately being driven
| by commercial interests.
| pier25 wrote:
| I agree but one important point to consider is the dev effort
| of making a proper SPA which is not a very common occurrence.
|
| "The best SPA is better than the best MPA. The average SPA is
| worse than the average MPA."
|
| https://nolanlawson.com/2022/06/27/spas-theory-versus-practi...
| 0cf8612b2e1e wrote:
| Can we even weight that statement? The average SPA is
| significantly worse than the average MPA. There is so much
| browser functionality that needs to be replicated in a SPA
| that few teams have the resources or talent to do a decent
| job.
| pier25 wrote:
| Yeah it's so easy to fuck it all up with an SPA.
|
| Recently I was using Circle (like a paid social media
| platform for communities) and pressing back not only loses
| the scroll position, it loses everything. It basically
| reloads the whole home page.
| seti0Cha wrote:
| The nice thing about htmx is it gives a middle ground between
| the two. Build with the simplicity of an MPA while getting a
| lot of the nice user experience of an SPA. Sure, you don't
| get all the power of having a full data model on the client
| side, but you really don't need that for most use cases.
| pier25 wrote:
| OTOH if you need to go back to the server after every
| interaction the UX can get pretty bad for distant users.
| lenkite wrote:
| Extend that statement with "Only True Web Gods can create the
| Best SPA".
| pier25 wrote:
| You joke but even Google with all its resources struggles
| to create proper SPAs.
|
| I dread using the Google Cloud console for example.
| Spivak wrote:
| > prevent your servers from ruining the experience for
| everyone.
|
| This never panned out because people are too afraid to store
| meaningful state on the client. And you really can't because
| (reasonable) user expectations. Unlike a Word document people
| expect to be able to open word.com and have all their stuff and
| have n simultaneous clients open that don't step on one
| another.
|
| So to actually _do_ anything you need a network request but now
| it 's disposable-stateful where the client kinda holds state
| but you can't really trust it and have to constantly refresh.
| bcrosby95 wrote:
| A pro can be a con, and vice versa. The reason why you move to
| a SPA might be the reason why you move away from it. The reason
| why you use sqlite early on might be the reason you move away
| from it later.
|
| A black & white view of development and technology is easy but
| not quite correct. Technology decisions aren't "one size fits
| all".
| com2kid wrote:
| > Also, there was a push to move the shitty code from the
| server to the client to free up server resources and prevent
| your servers from ruining the experience for everyone.
|
| People forget how bad MPAs were, and how expensive/complicated
| they were to run.
|
| Front end frameworks like svelte let you write nearly pure HTML
| and JS, and then the backend just supplies data.
|
| Having the backend write HTML seems bonkers to me, instead of
| writing HTML on the client and debugging it, you get to write
| code that writes code that you then get to debug. Lovely!
|
| Even more complex frameworks, like React, you have tools like
| JSX that map pretty directly to HTML, and in my experience a
| lot of the hard to debug problems come up with the framework
| tries to get smart and doesn't just stupidly pop out HTML.
| foobarbecue wrote:
| welcome to City Web Design, can a take a order
| chubot wrote:
| Well at least the shitty MPAs will run on other people's
| servers, rather than shitty SPAs running on my phone and iPad
|
| FWIW I turned off JavaScript on my iPad a couple years ago ...
| what a relief!
|
| I have nothing against JS, but the sites just became unusably
| slow
| pphysch wrote:
| Client side validation is for UX.
|
| Server side validation is for security, correctness, etc.
|
| They are different features that require different code.
| Blending the two is asking for bugs and vulnerabilities and
| unnecessary toil.
|
| The real reason that SPAs arose is user analytics.
| emodendroket wrote:
| I don't understand why that should be the case. There are a
| lot of checks that end up needing to be repeated twice with
| no change in logic (e.g., username length needs to be
| validated on both ends).
| ZephyrBlu wrote:
| You shouldn't have to wait until you submit something to
| get feedback on it. It's poor UX.
|
| Frontend and backend validations are also different.
| Frontend is more about shape and type. Backend is content
| and constraints.
| emodendroket wrote:
| Right, you shouldn't, but that means writing them twice.
| One of the selling points of backend JavaScript is the
| same validation code can run on both ends (obviously any
| validator that needs to check, e.g., uniqueness in a
| database won't work).
| ZephyrBlu wrote:
| Frontend and backend validation are usually not the same
| though. You won't be writing the same thing twice, you'll
| be writing different validations for each.
| emodendroket wrote:
| I think the frontend validations will, most of the time,
| be a subset of the backend ones, with many shared
| validation points.
| petepete wrote:
| > It's poor UX.
|
| It's not as easy as that. Showing validation while people
| are editing can be even worse, especially for less-
| technically able users or people using assistive
| technology.
|
| Having an announcement tell you your password isn't
| sufficiently complex when you're typing in the second
| letter might not be bad for us, but how does that work
| for a screen reader?
| emodendroket wrote:
| That seems like it's resolved by waiting for a focus
| change event.
| kokanee wrote:
| There are two things that engineers tend to neglect about
| validation experiences:
|
| 1) When you run the validation has a huge impact on UX. A
| field should not be marked as invalid until a blur event,
| and after that it should be revalidated on every keystroke.
| It drives people crazy when we show them a red input with
| an error message simply because they haven't finished
| typing their email address yet, or when we continue to show
| the error after the problem has been fixed because they
| haven't resubmitted the form yet.
|
| 2) Client side validation rules do occasionally diverge
| from server side validation rules. Requiring a phone number
| can be A/B tested, for example.
| emodendroket wrote:
| Even if you're not A/B testing you're going to have some
| validations that only happen server-side because they
| require access to resources the client doesn't have, but
| I don't see either of these points as arguments against
| sharing the validators that can be.
| kokanee wrote:
| I agree. These points are arguments against the
| philosophy of HTMX which asserts that you can get
| everything you need without client-side logic.
|
| To be fair, I'm also not a fan of bloated libraries like
| React and Angular. I think we had it right 15-20 years
| ago: use the server for everything you can, and use the
| smallest amount of JS necessary to service your client-
| side needs.
| pphysch wrote:
| > HTMX which asserts that you can get everything you need
| without client-side logic.
|
| That's not true at all. HTMX _extends_ the logical
| capabilities of HTML, and _hyperscript goes even further.
| emodendroket wrote:
| It's been a while since I did much frontend work but I
| actually found Angular revelatory. It makes it so easy
| and it's really batteries-included.
| pphysch wrote:
| Username length does not "need" to be validated on the
| client. However, it is nice for UX to enforce it there.
| emodendroket wrote:
| I think a charitable reader could infer that this is
| often made a requirement out of UX concerns and therefore
| it "needs" to be done. Do you have a substantive
| objection to what I said?
| gpapilion wrote:
| I actually tend to think of it to add feature degradation and
| handle micro service issues. It always seemed better to have
| the client manage that, and more graceful.
| withinboredom wrote:
| The number of SPAs that implement their own timeouts when
| I'm stuck on 2G networks is non-zero and incredibly
| annoying. The network socket has a timeout function, just
| because you 'time out' doesn't mean the network timed out,
| that data is still being transferred and retrying just
| makes it worse.
| blowski wrote:
| > The real reason that SPAs arose is user analytics.
|
| Can you go into that a bit? I don't really understand what
| you mean.
| pphysch wrote:
| HTML gives very limited tools for _tracking_ what a
| (potentially JS-less) user is doing. There are various
| tricks, like "link shorteners" and "magic pixels" that
| allow some tracking.
|
| But if you want advanced tracking, like tracking what a
| user is focusing on at a particular instant, you need to
| wrap the whole document in a lot of JS.
|
| SPA frameworks came out of AdTech companies like Meta, and
| I assure you it wasn't because they had limited engineering
| resources.
| blowski wrote:
| I can imagine that Facebook and Google liked the way
| Angular and React allowed for more advanced tracking. But
| it seems like you're giving too much weight to that as a
| primary cause.
|
| From my memory of working through this time, it was
| driven more by UX designers wanting to have ever more
| "AJAXy" interfaces. I did a lot of freelancing for design
| agencies 2006 - 2016, and they all wanted these
| "reactive" interfaces, but building these with jQuery or
| vanilla JS was a nightmare. So frameworks like JavaScript
| MVC, Backbone.js, SproutCore, Ember.js were all popping
| up offering better ways of achieving it. React, Vue and
| Angular all evolved out of that ecosystem.
| [deleted]
| dtagames wrote:
| This is not correct. SPAs and web components were
| pioneered by Google with the introduction of Angular.
| Later, Vue was invented by a previous Google employee who
| had worked on Angular. Finally, Facebook came up with
| React (it's a "reaction" to Angular) because they could
| not be seen using a Google product.
|
| If anything, SPAs make metrics harder because they hide
| the real behavior of the page in local JS/TS code and
| don't surface as much or any information in the URL.
| Also, fewer server interactions means fewer opportunities
| to capture user behavior or affect it at the server
| level.
| jannes wrote:
| React was significantly better than Angular (version 1).
|
| Please don't pretend it was merely NIH syndrome that led
| to its creation.
| withinboredom wrote:
| I mean, they also came out with 'flow' after MS came out
| with TypeScript... I def don't want to think it was NIH
| syndrome, but it smells fishy.
| dtagames wrote:
| But that would suffice! Facebook does not use any
| platforms from people who might compete with them. Why
| would they?
| pphysch wrote:
| A lot of misconceptions here.
|
| Google is an AdTech company par excellence.
|
| You don't need to do hacky URL tracking with SPAs. That's
| the point.
|
| >Also, fewer server interactions means fewer
| opportunities to capture user behavior or affect it at
| the server level.
|
| SPAs certainly do not have "fewer server interactions".
| What do you think an API call is?
|
| "React" comes from "reactive web app", not "reaction to a
| competitor's product".
| dtagames wrote:
| I work with SPAs with API calls every day. It definitely
| reduces the server interactions over computing everything
| on that side, and it gives fewer points of contact with
| the server about the user's behavior. For example, many
| clicks and other actions will not result in any server
| contact at all.
|
| I'm aware that they call it "reactive" but I'll stick
| with my rationale. There is no way they would use a
| Google product like that.
| pphysch wrote:
| An enterprise React app I am currently working with takes
| about 50 requests to fully render the app post-login.
| Switching to another view (no reload) takes another few
| dozen. That's a lot of "server interactions", pretty
| standard for SPAs, but YMMV.
| traverseda wrote:
| I... don't believe you? Like looking at the network
| request of any SPA I've ever seen there's just tons of
| requests for even simple page loads. One for main
| content, one for profiles, one for comments, etc.
|
| In theory stuff like graphql helps but in the reality I'm
| living in SPA's hit multiple endpoints to get render even
| simple pages.
| dtagames wrote:
| Definitely true, and mine do also. It's a side effect of
| the migration to microservices and away from monolithic
| endpoints.
| replygirl wrote:
| your timeline is a bit off. facebook had react in
| production (mid-late 11) less than a year after angularjs
| went public, open-sourced it 18-24 months later (early
| 13), then evan started working on vue a few months after
| that (mid 13) and released early the following year
| dtagames wrote:
| Thank you. I stand corrected.
| obpe wrote:
| I have never heard this before. Can you elaborate on the
| differences? What do you validate on the client side that you
| don't on the server and vice versa?
| pphysch wrote:
| Some validations require capabilities that you don't
| want/need the client to have.
|
| There are also validations that can improve UX but aren't
| meaningful on the server. Like a "password strength meter",
| or "caps lock is on".
|
| Religiously deploying the same validations to client and
| server can be done, but it misses the point that the former
| is untrusted and just for UX. And will involve a lot of
| extra engineering and unnecessary coupling.
| obpe wrote:
| I see, I have never implemented those types of
| validations. We do religiously deploy the same validation
| on client and server to explicitly avoid the mismatch of
| client/server validation. Having the client submit
| "valid" input only to have server reject it is something
| we have run into. Having only client side validation is
| something I have never run into.
|
| Also, in my opinion things like you suggest you shouldn't
| do. A password strength metre is only going to give
| attackers hints at the passwords you have in your system.
| And I have not see a caps lock on warning in forever. The
| only password validation we do is the length which is
| pretty easy to validate on client and server.
| yawaramin wrote:
| > A password strength metre is only going to give
| attackers hints at the passwords you have in your system
|
| No, it's not. A password strength meter just shows you
| the randomness of an input password, it doesn't have
| anything to do with passwords already in the system.
| zamadatix wrote:
| I'd agree with both takes on that it depends on the
| meter. Ones which truly approximate password entropy work
| like you say, however, for some reason, the most common
| use of such meters is to show how many dartboard
| requirements you've met while ignoring the actual
| complexity. When this common approach is used you combine
| "password must be 8 characters or more" with things like
| "password must have a number, symbol of ${group}, and
| capital letter" and the average password complexity is
| actually made worse for a given length due to
| pigeonholing.
|
| In the full picture though, in terms of UI/UX, the meter
| seems like only a downside. In the dartboard use case
| it's great because it displays what's still needed in
| terms users work and think with signalling e.g. "you
| still need a number, otherwise you're all set". People
| don't really think in bits of entropy though so ll that
| really is being signaled by either a meter or a normal
| failed validation hint is "more complexity and/or length
| needed".
|
| There may be good cases for using a meter while
| simultaneously implementing good password requirement
| policy I'm not thinking of though.
| yawaramin wrote:
| If you Google 'password strength' the first result is
| https://www.passwordmonster.com/
|
| This works like I described, it don't show 'dartboard
| requirements', only entropy. I think you've misunderstood
| what a password strength checker is. It's definitionally
| not a checklist like 'You need an uppercase letter, a
| lowercase letter, a number, a special character'. It's a
| tool which measures the _strength_ i.e. the _randomness_
| or entropy of the password.
| zamadatix wrote:
| I'm not sure adding a meter value output to the server
| side check to use it in both places is really more
| engineering work. Writing separate checks on the client
| and server side seems much more likely to create headache
| and extra work.
|
| That said, I could definitely see additional checks being
| done server side. One example would be actually checking
| the address database to see if service is available in
| the entered address. On the other hand, there really
| isn't any waste here either. I.e. just because you write
| the validation in server side JS doesn't mean you MUST
| therefore deploy and use it in the client side JS as
| well, it just means you never need to worry about writing
| the same check twice.
| pphysch wrote:
| You misunderstand: the server only cares if your password
| is valid (boolean), not if it is "almost valid (0.7
| strength)".
| zamadatix wrote:
| I understand the argument I just disagree that having a
| separate "bool isPasswordValid()" and "float
| isPasswordValid()" (really probably something that
| returns what's not valid with the score) function is in
| any way simpler than a single function used on both
| sides. Sure, the server may not care about the strength
| level but if you need to write that calculation for the
| client side anyways then how are you saving any
| engineering work by writing a 2nd validation function on
| the server side instead of just ignoring the extra info
| in the one that already exists?
| Dylan16807 wrote:
| In this situation code for a good strength meter is going
| to be an order of magnitude or two more complicated than
| the boolean validity check. Porting 50x as much code to
| the server is significantly worse than having two
| versions or having one shared function and one non-shared
| function.
| politician wrote:
| Client side validations predominately drive user
| experiences.
|
| Server side validations predominately enforce business
| constraints.
|
| If you mix the concerns, either your UX suffers (latency)
| or the data suffers (consistency, correctness).
| nagyf wrote:
| Everything has to be validated on the server side simply
| for security reasons. Even if you do all validation on the
| client side, which prevents the users submitting a form
| with invalid data, an attacker can work around that. e.g.
| submitting the form with valid data, but intercepting the
| request and modifying the values there. Or simply just
| using curl with malicious/invalid data.
|
| You still need the client side validation for UX. The
| regular users needs to know if they messed up someting in
| the form. Also it's a much better UX if it's done on the
| client side, without the need to send an async request for
| validations.
| emodendroket wrote:
| Yeah but that doesn't answer why you can't share
| validators between the backend and the frontend if both
| are written in the same language.
| yawaramin wrote:
| Because HTML form validation is a built-in native feature
| of HTML, and it's integrated in the browser:
| <input type="email" required placeholder="Please enter
| your email address">
|
| Constantly reinventing the wheel in every app is silly.
| emodendroket wrote:
| These validators are rather limited and you'll end up
| needing JavaScript for any Web app with anything beyond
| the simplest requirements.
| yawaramin wrote:
| They're limited in some ways but they're just about
| powerful enough to do almost everything you'd need or
| want to do client-side without making a network request.
| In my opinion it doesn't make sense to try to fit in tons
| of complex validation logic in the frontend.
| emodendroket wrote:
| Why make a round trip if you don't have to?
| PaulHoule wrote:
| Some kinds of validation really _do_ need the round trip.
| If somebody is choosing a user name on a sign up for you
| do need to do a database lookup.
|
| If your back end is fast and your HTML is lean, backend
| requests to validate can complete in less time than any
| of the 300 javascript, CSS, tracker, font, and other
| requests that a fashionable modern webapp does for no
| good reason...
|
| It's true though that many back ends are run on the cheap
| with slow programming languages and single-thread
| runtimes like node.js that compete with slow javascript
| build systems to make people think slow is the new
| normal.
| emodendroket wrote:
| Yeah, obviously if it requires I/O you can't write it
| client side, but the argument here seems to be in favor
| of doing validation only server-side even when it could
| also be done client-side.
| yawaramin wrote:
| Why be on the internet at all? Why not distribute a
| desktop app that doesn't need any connectivity at all?
| emodendroket wrote:
| Presumably there are some features of the app that won't
| work that way. Surely you're not saying you prefer a Web
| app just for the sake of making calls.
| austinthetaco wrote:
| because many people wouldn't use the product or you would
| have to maintain multiple codebases for the various
| operating systems and devices (including mobile).
| adrr wrote:
| I don't understand how spa is different than vanilla web app
| in terms of user analytics? A beacon is a beacon. Whether its
| img tag with a 1x1 transparent gif or an ajax call.
|
| Also validation is usually built on both client and server
| for the same things. Like if you have a password complexity
| validation. Its both on UX and the server otherwise it will
| be a very terrible UX experience.
| ragall wrote:
| A SPA can track the mouse cursor, as well as stealing form
| content that was left unsubmitted.
| detaro wrote:
| an MPA can use javascript that does exactly the same.
| lucasyvas wrote:
| You're on the money with this assessment. It's all bandwagon
| hopping without any consideration for reality.
|
| Also, all these things the author complains about are realities
| of native apps, which still exist in massive numbers especially
| on mobile! I appreciate that some folks only need to care about
| the web, but declaring an architectural pattern as superior -
| in what appears to be a total vacuum - is how we all
| collectively arrive at shitty architecture choices time and
| time again.
|
| Unfortunately, you have to understand all the patterns and
| choose when each one is optimal. It's all trade-offs - HTMX is
| compelling, but basing your entire architectural mindset around
| a library/pattern tailored to _one_ very specific type of
| client is frankly stupid.
| megalord wrote:
| > to one very specific type of client is frankly stupid
|
| However, I see this specific type of clients that need just
| basic web functionalities, e.g CRUD operations and build
| something basic more prevalent than those that need very
| instant in-app reactivity and animations and so on (React,
| and SPA ecosystem).
|
| Nowadays that's exactly the opposite, every web developer
| assumes SPA as default option, even on these simple CRUD
| examples.
| recursivedoubts wrote:
| agreed:
|
| https://htmx.org/essays/when-to-use-hypermedia/
| amiga-workbench wrote:
| >For instance, a major selling point of Node was running JS on
| both the client and server so you can write the code once
|
| I mean, I'm using Laravel Livewire quite heavily for forms,
| modals and search. So effectively I've eliminated the need for
| writing much front-end code. Everything that matters is handled
| on the server. This means the little Javascript I'm writing is
| relegated to frilly carousels and other trivial guff.
| halfcat wrote:
| > a major selling point of Node was running JS on both the
| client and server so you can write the code once
|
| But we don't have JS devs.
|
| We have a team of Python/PHP/Elixir/Ruby/whatever devs and are
| incredibly productive with our productivity stacks of
| Django/Laravel/Phoenix/Rails/whatever.
| kitsunesoba wrote:
| > But that isn't because of the technology, it's because all
| the devs writing shitty MPAs are now writing shitty SPAs. If
| this becomes popular, they will start writing shitty MPAs
| again.
|
| I think the root cause of this is lack of will/desire to spend
| time on the finer details, either on the part of management who
| wants it out the door the second it's technically functional or
| on the part of devs who completely lose interest the second
| that there's no "fun" work left.
| jonahx wrote:
| > But that isn't because of the technology, it's because all
| the devs writing shitty MPAs are now writing shitty SPAs. If
| this becomes popular, they will start writing shitty MPAs
| again. Nothing about this technology will stop that.
|
| While I am a fan of MPAs and htmx, and personally find the dev
| experience simpler, I cannot argue with this.
|
| The high-order bit is always the dev's skill at managing
| complexity. We want so badly for this to be a technology
| problem, but it's fundamentally not. Which isn't to say that
| specific tech can't matter at all -- only that its effect is
| secondary to the human using the tech.
| PaulHoule wrote:
| I remember that all the web shops in my town that did Ruby on
| Rails sites efficiently felt they had to switch to Angular
| about the same time and they never regained their footing in
| the Angular age although it seems they can finally get things
| sorta kinda done with React.
|
| Client-side validation is used as an excuse for React but we
| were doing client-side validation in 1999 with plain ordinary
| Javascript. If the real problem was "not write the validation
| code twice" surely the answer would have been some kind of DSL
| that code-generated or interpreted the validation rules for the
| back end and front end, not the fantastically complex Rube
| Goldberg machine of the modern Javascript wait wait wait wait
| and wait some more to build machine and then users wait wait
| wait wait wait for React and 60,000 files worth of library code
| to load and then wait wait wait wait even more for completely
| inscrutable reasons later on. (e.g. amazing how long you have
| to wait for Windows to delete the files in your node_modules
| directory)
| cutler wrote:
| Wasn't Ember the idiomatic choice before React? I don't
| remember Angular being that popular with Rails devs
| generally.
| Glyptodon wrote:
| I definitely associate it (Angular) with Python BE devs for
| some reason.
| berkes wrote:
| Even worse: Client-side validation and server-side validation
| (and database integrity validation) are all their own
| domains! I call all of these "domain logic" or domain
| validation just to be sure.
|
| Yes, they overlap. Sure, you'll need some repetition and
| maybe, indeed, some DSL or tooling to share some of the
| overlapping ones across the boundaries.
|
| But no! They are not the same. A "this email is already in
| use" is serverside, (it depends on the case). A "this doesn't
| look like an email-address, did you mean gmail.com instead of
| gamil.com" is client side and a "unique-key-constraint:
| contactemail already used" is even more down.
|
| My point is, that the more you sit down (with customers!
| domain experts!) and talk or think all this through, the less
| it's a technical problem that has to be solved with DSLs,
| SPAs, MPAs or "same language for backend and UI". And the
| more you (I) realize it really often hardly matters.
|
| You quite probably don't even need that email-uniqueness
| validation at all. In any layer. If you just care to speak to
| the business.
| dsego wrote:
| I think the main concern for frontend validation was before
| HTML5 came along with validation attributes. You can easily
| produce HTML input validation attributes from a Yup schema
| for example by using its serialization feature
| (https://github.com/jquense/yup#schemadescribeoptions-
| resolve...). Here is an example from some silly code I
| wrote a while back testing htmx with deno
| https://github.com/dsego/ssr-playground/
| ratorx wrote:
| Or even skip the DSL and use JS for both client and server,
| just independently. Validation functions can/should be
| simple, pure JS that can be imported from both.
| v0idzer0 wrote:
| It really wasnt about client side validation or UX at all.
| You can have great UX with an MPA or SPA. Although I do think
| it's slightly easier in an SPA if you have a complex client
| like a customizable dashboard.
|
| Ultimately it's about splitting your app into a server and
| client with a clear API bounday. Decoupling the client and
| server means they can be separate teams with clearly definied
| roles and responsibilities. This may be worse for small teams
| but is significantly better for large teams (like Facebook
| and Google who started these trends).
|
| One example is your iOS app can hit the same API as your web
| app, since your server is no longer tightly coupled to html
| views. You can version your backend and upgrade your clients
| on their own timelines.
| myth2018 wrote:
| > Decoupling the client and server means they can be
| separate teams with clearly definied roles and
| responsibilities
|
| How desirable this is depends on the UI complexity.
|
| Complex UIs as the ones built by google and facebook will
| most likely benefit from that.
|
| Small shops building CRUD applications probably won't. On
| the contrary: the user requirements often cross-cut client
| and server-side code, and separating these in two teams
| adds communication overhead, at the best of the hypotheses.
|
| Moreover, experience shows that such
| separation/specialization leads to bloated UIs in what
| would otherwise be simple applications -- too many
| solutions looking for problems in the client-side space.
| tored wrote:
| Generally you don't want to reuse the same API for
| different types of clients, you want backends for frontends
| (BFF) that are specialized for each use and can be moved
| forward in their own pace. The needs and the requirements
| differs a lot between a browser, app and server-to-server
| call.
|
| And just because you serve HTML doesn't necessary mean that
| you backend code is tightly coupled with the view code,
| HTML is just one adapter of many.
|
| A boundary doesn't get better just because you slip a HTTP
| barrier in between, this is the same type of misconception
| that has driven the microservice hysteria.
| scns wrote:
| When a company gets to the stage where they actually need a
| mobile app, it is pretty easy to add API endpoints in
| many/most/all? major web frameworks. Starting out with the
| FE/BE split slows you down immensely.
| towawy wrote:
| This development style might be a better DX for the teams.
| But Facebook on the web is an absolute dumpster fire if you
| use it in a professional capacity.
|
| You can't trust it to actually save changes you've made, it
| might just fail without an error message or sometimes it
| soft-locks until you reload the page. Even on a reliable
| connection. Error handling in SPAs is just lacking in
| general, and a big part of that is that they can't
| automatically fall back to simple browser error pages.
|
| Google seems to be one of the few that do pretty good on
| that front, but they also seem to be more deliberate for
| which products they build SPAs.
| [deleted]
| goodSteveramos wrote:
| There is no reason other than poorly thought out
| convenience to make the webbrowser/webserver interface the
| location of the frontend/backend interface. You can have a
| backend service that the web server and mobile apps all get
| their data from.
| PaulHoule wrote:
| Ouch!
|
| I've worked in two kinds of organizations. In one of them
| when there is a 'small' ticket from the viewpoint of
| management, one programmer is responsible for
| implementation but might get some help from a specialist
| (DBA, CSS god, ...)
|
| In the other a small ticket gets partitioned to two, three
| or more sub teams and productivity is usually reduced by a
| factor more than the concurrency you might get because of
| overhead with meetings, documentation, tickets that take 3
| sprints to finish because subtasks that were one day late
| caused the team to lose a whole sprint, etc.
|
| People will defend #2 by saying thar's how Google does it
| or that's how Facebook does it, but those monopolists get
| monopoly rents that subsidize wasteful practices and if
| wall street ever asks for "M0R M0NEY!" they can just jack
| up the ad load. People think they want to work there but
| you'll just get a masterclass in "How to kill your
| startup."
| wahnfrieden wrote:
| Speaks some truth to Graber's Bullshit Jobs thesis
| treeman79 wrote:
| Yep. I was in a type 1 startup. Stuff got done fast.
|
| Company forced us to type 2 using Angular. projects thar
| used to take a couple of days for one person became multi
| month efforts for a dozen developers across three teams.
| dial9-1 wrote:
| it's called resume-driven development
| hdjjhhvvhga wrote:
| > felt they had to switch to Angular about the same time and
| they never regained their footing in the Angular age
|
| And in this case what actually happened is exactly what we
| had expected would happen: tons of badly-written Angular apps
| than need to be maintained for foreseeable future because at
| this point nobody wants to rewrite them so they become
| Frankensteins nobody wants to deal with.
| simplotek wrote:
| > For instance, a major selling point of Node was running JS on
| both the client and server so you can write the code once.
|
| What? No.
|
| The whole point of Node was a) being able to leverage
| javascript's concurrency model to write async code in a trivial
| way, and b) the promise that developers would not be forced to
| onboard to entirely different tech stacks on frontend, backend,
| and even tooling.
|
| There was no promise to write code once, anywhere. The promise
| was to write JavaScript anywhere.
| callahad wrote:
| That's the reasoned take, and yet I have strong and distinct
| memories of Node being sold on the basis of shared code as
| early as 2011. Much of the interest (and investment) in
| Meteor was fueled by its promise of "isomorphic JavaScript."
| imbnwa wrote:
| I mean...[0]
|
| [0]https://hn.algolia.com/?dateRange=all&page=0&prefix=true
| &que...
| danielvaughn wrote:
| 100%. Saying that [technology x] will remove complexity is like
| saying that you've designed a house that can't get messy. All
| houses can be messy, all houses can be clean. It depends on the
| inhabitants.
| elliottinvent wrote:
| True, but well designed houses that have natural places for
| the things a well functioning home needs, are far easier to
| keep clean and tidy.
| withinboredom wrote:
| natural to whom?
| randomNumber7 wrote:
| Yes, but some technologies make it easier (or harder) to keep
| everything clean.
|
| Like in my opinion you can write clean code in C, but since
| you dont even have a string type it shepherds you into doing
| nasty stuff with char*... etc.
| foul wrote:
| That demonstration as per OP is dumb or targeted to React-ists.
| You can, with HTMX, do the classic AJAX submit with offline
| validation.
|
| In the last years, for every layer of web development, what I
| saw was that a big smelly pile of problems with bad websites
| and webapps, be it MPA or SPA, was not a matter of bad
| developers on the product, but more a problem of bad, sometimes
| plain evil, developers on systems sold to developers to build
| their product upon. Boilerplate for apps, themes, ready-made
| app templates are largely garbage, bloat, and prone to supply
| chain attacks of any sort.
| croes wrote:
| >For instance, a major selling point of Node was running JS on
| both the client and server so you can write the code once.
|
| You did write it once before too. With NodeJS you have
| Javascript on both sides, that's the selling point. You still
| have server and client code and you can write a MPA with NodeJS
| guggle wrote:
| > a major selling point of Node was running JS on both the
| client and server so you can write the code once
|
| Yes... but some people like me just don't like JS so for us
| that was actually a rebutal.
| RHSeeger wrote:
| > We moved away for MPAs because they were bloated, slow and
| difficult to work with. SPAs have definitely become what they
| sought to replace.
|
| Plus we now get the benefit of people trying to "replace" built
| in browser functionality with custom code, either
|
| The SPA broke it... Back button broken and a buggy custom
| implementation is there instead? Check.
|
| or
|
| They're changing things because they're already so far from
| default browser behavior, why not? ... Scrolling broken or
| janky because the developer decided it would be cool to replace
| it? Check.
|
| There is a time and place for SPA (mail is a great example).
| But using them in places where the page reload would load in
| completely new content for most of the page anyways? That's
| paying a large cost for no practical benefit; and your users
| are paying some of that cost.
| jfvinueza wrote:
| Mail is not a good example. Why would you like to read a
| collection of documents through A Single Page interface?
| Gmail was a fantastic improvement over Hotmail and Yahoo, and
| it provided UX innovations we still haven't caught up with,
| yes, but MPAs are naturally more suited for reading and
| composing them. Overriding perfectly clear HTML structure
| with javascript should be reserved for web experiences that
| are not documents: that is, videogames, editors, etc (Google
| *Maps* is a good example). The quality of the product usually
| depends on how it was implemented more than the underlying
| technology, but as I see it is: if it's a Document, if the
| solution has a clear paper-like analogue, HTML is usually the
| best way to code it, structure it, express it. Let a web page
| be a web page and let the user browse through it with a web
| browser. If it's not, well, alright, let's import OpenGL.
| kbenson wrote:
| Mail is good for a SPA because the main central view which
| shows the different items (emails) to view or take an
| action on is based on a resource intensive back-end
| request, so keeping that state present and not having to
| refresh it on many of the different navigation actions
| yields a tremendous benefit.
|
| You could do some client side caching with local page data,
| but just keeping it present and requesting updates to it
| only is vastly superior.
|
| Thats honestly one place SPAs shine, where there's a
| relatively expensive request that provides data and then a
| lot of actions that function on some or all of that data
| transiently.
| taeric wrote:
| I'm willing to wager that I get far more data loading
| Gmail than just an email or list of titles/senders.
|
| That is, it may seem a fine optimization, but has led to
| a fairly bloated experience.
| kbenson wrote:
| You're thinking just of the amount of data sent, not the
| amount of work that's done on the back end. Just because
| it's only showing you the most recent 40 messages or
| something doesn't mean it isn't doing a significant
| amount of work on the back end to determine what those
| messages are. Not having to scan through all your email
| and sort by date nearly as often is a significant win.
| alethiophile wrote:
| What exactly is the resource-intensive request here?
| Loading an E-mail, or list of E-mails? I don't see why
| that should be any more resource-intensive than any other
| CRUD app.
| kbenson wrote:
| A list of emails. That's essentialls a database query
| that is taking X items and sorting by the date field,
| most commonly, except that the average user can have
| thousands, or even tens or hundreds of thousands of items
| that are unique to them in that dataset that need to be
| sorted and returned.
|
| Sure, gmail optimizes for this heavily so it's fast, but
| it's still one of the most intensive things you can do
| for an app like that, so reducing the amount of times you
| need to do that is a _huge_ win for any webmail. If you
| 've ever used a webmail client that's essentially just an
| IMAP client for a regular IMAP account, you'll note that
| if you open a large inbox or folder it's WAY slower than
| trying to view an individual message, most times, for
| what are obvious reasons of you just think of a mailbox
| as a database of email and the operations that need to
| happen on that database (which it is).
|
| If clicking on an individual message is a new page,
| that's fine, but if going back to the main view is
| another full IMAP inbox query, that's incredibly resource
| intensive compared to having it cached in the client
| already (even if the second request is cached in the
| server, it's still far more wasteful than not having to
| request it again).
| robertoandred wrote:
| JavaScript doesn't override perfectly clear HTML structure,
| it generates it.
| yellowapple wrote:
| > There is a time and place for SPA (mail is a great
| example). But using them in places where the page reload
| would load in completely new content for most of the page
| anyways? That's paying a large cost for no practical benefit;
| and your users are paying some of that cost.
|
| Yep. It's bonkers to me that a page consisting mostly of text
| (say, a Twitter feed or a news article) takes even so much as
| _a_ second (let alone multiple!) to load on any PC
| /tablet/smartphone manufactured within the last decade. That
| latency is squarely the fault of heavyweight SPA-enabling
| frameworks and their encouragement of replacing the browser's
| features with custom JS-driven versions.
|
| On the other hand, having to navigate a needlessly-elongated
| history due to every little action producing a page load (and
| a new entry in my browser's history, meaning one more thing
| to click "Back" to skip over) is no less frustrating. Neither
| is wanting to reload a page only for the browser to throw up
| scary warnings about resending information simply because
| that page happened to result from some POST'd form
| submission.
|
| Everything I've seen of HTMX makes it seem to be a nice
| middle-ground between full-MPA v. full-SPA: each "screen" is
| its own page (like an MPA), but said page is rich enough to
| avoid full-blown reloads (with all the history-mangling that
| entails) for every little action within that page (like an
| SPA). That it's able to gracefully downgrade back to an
| ordinary MPA should the backend support it and the client
| require it is icing on the cake.
|
| I'm pretty averse to frontend development, especially when it
| involves anything beyond HTML and CSS, but HTMX makes it
| _very_ tempting to shift that stance from absolute to
| conditional.
| PaulHoule wrote:
| I remember writing high complexity rich internet
| applications (knowledge graph editors, tools to align sales
| territories for companies with 1000+ salespeople, etc.)
| circa 2005. It was challenging to do because I had to
| figure out how to update the whole UI when data came in
| from asynchronous requests, I had to write frameworks a bit
| like MobX or redux to handle the situation.
|
| Even before that I was making Java applets to do things you
| couldn't do with HTML, like draw a finite element model and
| send it to a FORTRAN back end to see what it does under
| stress, or replace Apple's Quicktime VR plugin, or simulate
| the Ising model with the Monte Carlo methods.)
|
| What happened around 2015 is that people gave up writing
| HTML forms and felt that they had to use React to make very
| simple things like newsletter signups so now you see many
| SPAs that don't need to be SPAs.
|
| Today we have things like Figma that approach the complex
| UI you'd expect from a high-end desktop app, but in many
| ways our horizons have shrunk thanks to "phoneishness" and
| the idea that everything should be done with a very
| "simple" (in terms of what the user sees) mobile app that
| is actually very hard to develop -- who cares about how
| fast your build cycle is if the app store can hang up your
| releases as long they like?
| detaro wrote:
| my favorite example is dev.to. A (web-)developer-centric
| site, open-source nowadays. In a similar discussion years ago
| it was praised as well-done SPA. Everytime the topic comes
| back up again I spend 5 minutes clicking around, it every
| time I find some breakage of a page being critically broken
| during a transition, not being the page the URL-bar says it
| is, ... because having a blogging site just be pages
| navigated by the browser was too easy.
| fridgemaster wrote:
| I fail to see how HTMX could be the "future". It could have
| been something useful in the 2000s, back when browsers had
| trouble processing the many MBs of JS of a SPA. Nowadays
| SPA's run just fine, the average network bandwidth of a user
| is full-HD video tier, and even mobile microprocessors can
| crunch JS decently fast. There is no use case for HTMX.
| Fragmented state floating around in requests is also a big
| big problem.
|
| The return of the "backend frontender" is also a non
| happening. The bar is now much higher in terms of UX and
| design, and for that you really need frontend specialists.
| Gone are the days when the backend guys could craft a few
| html templates and call it a day, knowing the design won't
| change much, and so they would be able to go back to DB work.
| robertoandred wrote:
| Neither broken back buttons nor messy scrolling are unique to
| SPAs. You're just talking about bad websites.
| com2kid wrote:
| > The SPA broke it... Back button broken and a buggy custom
| implementation is there instead? Check.
|
| MPAs break back buttons all the damn time, I'd say more often
| than SPAs do.
|
| Remember the bad old days when websites would have giant text
| "DO NOT USE YOUR BROWSER BACK BUTTON"? That is because the
| server had lots of session state on it, and hitting the
| browser back button would make the browser and server be out
| of sync.
|
| Or the old online purchase flows where going back to change
| the order details would completely break the world and you'd
| have to re-enter all your shipping info. SPAs solve that
| problem _very_ well.
|
| Let's think about it a different way.
|
| If you are making a phone app, would you EVER design it so
| that the app downloads UI screens on demand as the user
| explores the app? That'd be insane.
| wwweston wrote:
| > "DO NOT USE YOUR BROWSER BACK BUTTON"?
|
| Yeah, state mutation triggered by GET requests is going to
| make for a bad time, SPA or MPA. Fortunately enough of the
| web application world picked up enough of the concepts
| behind REST (which is at the heart of _all_ web
| interaction, not just APIs) by the mid /late 00s that this
| already-rare problem became vanishingly rare well before
| SPAs became cancerous.
|
| > going back to change the order details would completely
| break the world and you'd have to re-enter all your
| shipping info. SPAs solve that problem very well.
|
| The problem is entirely orthogonal to SPA vs MPA.
|
| > If you are making a phone app, would you EVER design it
| so that the app downloads UI screens on demand as the user
| explores the app?
|
| It's not only EVER done, it's _regularly_ done. Perhaps you
| should interrogate some of the reasons why.
|
| But more to the point, if it's bad, SPAs seem to frequently
| manage to bring the worst of both worlds, a giant payload
| of application shell and THEN also screen-specific
| application/UI/data payload, all for reasons like
| developer's unfortunately common inability to understand
| that both JSON and HTML are perfectly serviceable data
| exchange formats (let alone that the latter sometimes has
| advantages).
| com2kid wrote:
| > It's not only EVER done, it's regularly done. Perhaps
| you should interrogate some of the reasons why.
|
| Content in the app is reloaded, sure, but the actual
| layout and business logic? Code that generally changes
| almost never, regenerated on every page load?
|
| I know of technologies that are basically web wrappers
| that allow for doing that to bypass app store review
| processes, but I'd be pissed if an alarm clock app
| decided to reload its layout from a server every time I
| loaded it up!
|
| The SPA model of "here is an HTML skeleton, fill in the
| content spaces with stuff fetched from an API" makes a
| ton more sense.
|
| The application model, that has been in use for even
| longer, of "here is an application, fetch whatever data
| you need from whatever sources you need" is, well, a fair
| bit simpler.
|
| Everyone is stuck with this web mindset for dealing with
| applications and I get the feeling that a lot of
| developers now days have never written an actual phone or
| desktop application.
|
| > But more to the point, if it's bad, SPAs seem to
| frequently manage to bring the worst of both worlds, a
| giant payload of application shell and THEN also screen-
| specific info, all for reasons like developer's
| unfortunately common inability to understand that both
| JSON and HTML are perfectly serviceable data exchange
| formats (let alone that the latter sometimes has
| advantages).
|
| I've seen plenty of MPAs that consist of multiple large
| giant mini-apps duct taped together.
|
| Shitty code is shitty code!
| ebiester wrote:
| It wasn't GET mutation... it was POSTs with multi-page
| forms that was the problem. It was such a pain to
| subdivide a form and create server and session state and
| intuit the return state. And what happens if you needed a
| modal with dynamic data? Did you pop open a new window
| and create a javascript call for the result? There was no
| great progressive answer to them.
|
| Oh, and then request scope wasn't good enough because you
| needed to do a post-redirect-get? I will say that I do
| not think MPAs for web applications were the good old
| days.
| pier25 wrote:
| > _If you are making a phone app, would you EVER design it
| so that the app downloads UI screens on demand as the user
| explores the app? That 'd be insane._
|
| Good luck forcing users to download 50MB before they can
| use your web app.
|
| The web and mobile/desktop apps are two totally different
| paradigms with different constraints.
| PaulHoule wrote:
| It is totally possible to make MPAs where reloads are never
| a problem.
|
| As for phone apps these are undeniably a step backwards
| from desktop apps, web apps and every other kind of app. On
| the web you can deploy 100 times a day, waiting for the app
| store to approve changes to your app is like building a
| nuclear reactor in comparison.
|
| All the time you get harassed in a physical store or a web
| site to "download our mobile app" and you know there ought
| to be a steaming pile of poop emoji because the mobile app
| almost always sucks.
|
| One of the great answers to the app store problem is to
| move functionality away from the front end into the back,
| for instance people were looking to do this with chat bots
| and super apps back in 2017 and now that chatbots are the
| rage again people will see them as a way to get mobile apps
| back on internet time.
| ebiester wrote:
| Sure. You maintain the entire application state in
| session scope or some sort of internal state. It was
| possible, but it was hell.
| codeflo wrote:
| I mean, there's nothing about an SPA that forces you to break
| the back button, to the contrary, it's possible to have a
| very good navigation experience and working bookmarks. But it
| takes some thinking to get it right.
| afavour wrote:
| I don't think "forces" is the right way to think about it.
| _By default_ a SPA breaks navigation history etc (it's
| right in the name). It's not onerous to reimplement it
| correctly but reimplement you must.
| RHSeeger wrote:
| And it's very common for it to be re-implemented
| incorrectly.
| robertoandred wrote:
| No it doesn't and no you don't. Every modern SPA
| framework has solved that problem long ago.
| afavour wrote:
| Right, so you agree: you have to reimplement it. You can
| just use a framework to do so.
|
| It might be news to folks to learn that every single SPA
| framework has solved the problem entirely because it's
| really not an uncommon experience to have your browser
| history broken by a SPA. I believe that most frameworks
| implement the API correctly. I also believe a good number
| of developers use the framework incorrectly.
| Joker_vD wrote:
| Or simply unaware about the whole "back button" debacle.
| Which is yet another stone to throw at the SPA camp: if
| using technology A requires a programmer to learn about
| more stuff (and do more work) than technology B for
| achieving pretty much the same end results, then
| technology A is _inferior_ to B (for achieving those
| particular end results, of course).
| robertoandred wrote:
| That's like saying you have to reimplement assembly
| arithmetic, you can just use the Calculator app to do so.
|
| Bad websites are the results of bad developers, not the
| tool. You can have your history messed up by any kind of
| website.
| afavour wrote:
| No, it's like saying you've been provided with a
| calculator but may, if you wish, create your own
| calculator with some parts provided. No guarantee it adds
| numbers together correctly.
| robertoandred wrote:
| Why would anyone choose to create and use their own
| unreliable calculator instead of what came installed?
| afavour wrote:
| ...that's the point being made
| robertoandred wrote:
| The point that bad websites are the result of bad
| developers, not the tools?
| afavour wrote:
| I don't understand why this point is so complicated. Yes,
| bad SPA developers mess it up all the time. Bad MPA
| developers do not mess it up because it doesn't require
| reimplementation by said bad developer, it works out of
| the box.
| robertoandred wrote:
| It works out of the box on SPAs too. It doesn't require
| reimplementation by said bad developer.
| afavour wrote:
| We're way too far into a thread for me to have to restate
| the original point I made in the first post. If what
| you're saying is true we'd never see bad implementations
| of history in SPAs yet we do all the time.
|
| But look, whatever. It's Friday afternoon, I'm out of
| here. Have a good weekend.
| zelphirkalt wrote:
| > For instance, a major selling point of Node was running JS on
| both the client and server so you can write the code once. It's
| a pretty shitty client experience if you have to do a network
| request for each and every validation of user input.
|
| Node does not absolve from this. Any important verification
| still needs to be done on the server side, since any JS on the
| client side cannot be trusted to not be manipulated. JS on the
| client side was of course possible before NodeJS. NodeJS did
| not add anything there regarding where one must verify inputs.
| Relying on things being checked in the frontend/client-side is
| just writing insecure websites/apps.
|
| > We moved away for MPAs because they were bloated, slow and
| difficult to work with. SPAs have definitely become what they
| sought to replace.
|
| I would claim they became even more so than the thing they
| replaced. Basically most of any progress in bandwidth or
| ressources is eaten by more bloat.
| obpe wrote:
| >Node does not absolve from this. Any important verification
| still needs to be done on the server side, since any JS on
| the client side cannot be trusted to not be manipulated. JS
| on the client side was of course possible before NodeJS.
| NodeJS did not add anything there regarding where one must
| verify inputs. Relying on things being checked in the
| frontend/client-side is just writing insecure websites/apps.
|
| Yeah, that was my point. With Node you can write JS to
| validate on both the client and server. In the article, they
| suggest you can just do a server request whenever you need to
| validate user input.
|
| >Basically most of any progress in bandwidth or ressources is
| eaten by more bloat.
|
| In my experience, the bloat comes from Analytics and binary
| data (image/video) not functional code for the SPA.
| Unfortunately, the business keeps claiming it's "important"
| to them to have analytics... I don't see it but they pay my
| salary.
| zelphirkalt wrote:
| > In my experience, the bloat comes from Analytics and
| binary data (image/video) not functional code for the SPA.
| Unfortunately, the business keeps claiming it's "important"
| to them to have analytics... I don't see it but they pay my
| salary.
|
| Similar to my experience. So glad I uBlock Origin a lot of
| unnecessary traffic. At some point it is not longer good
| taste, when the 5th CDN is requested, the 10th tracker
| script from random untrusted 3rd parties loaded ... All
| while neglecting good design of a website, making it
| implode, when you block their unwanted stuff. Not rare to
| save more than half the traffic, when blocking stuff.
| aidenn0 wrote:
| The first SPA I wrote, I wrote in React for my use and for
| the use of friends. I spent about 3 days getting it working
| and then 3 months getting it to usable performance on my
| phone. There were no analytics, no binary data (100% text),
| just a bunch of editable values and such. I ended up having
| to split it up into a bunch of tabs just to reduce the size
| of the vdom.
| austinthetaco wrote:
| I would think you have something else wrong with the
| design. I've worked on some pretty complex and large
| react apps that worked flawlessly on some low-end mobile
| browsers. Maybe you're accidentally duplicating a LOT of
| dom nodes?
| robertoandred wrote:
| "The size of the vdom" would not destroy performance like
| you're saying.
| aidenn0 wrote:
| I've been told that before. Maybe it was something else;
| I don't know.
|
| All I know is that I was unable to figure out what it
| was, and I bounced it off a few people online, and the
| performance scaled inversely with the number of DOM
| nodes.
| tored wrote:
| SPAs transfers large amounts of data to the frontend to be
| able to do HTTP JOIN and then tosses most of it away.
| ladberg wrote:
| I feel like you misunderstood the OP, they are claiming that
| Node allows you to reuse the same code to do validation on
| both the client and the server. By definition that means they
| are also doing server-side validation, and they are not
| relying on it being checked on the frontend.
| PaulHoule wrote:
| As I see it though, node.js on the backend is not
| mainstream, most sites are still using JVM or other back
| ends. Using the same code for the front end and the back
| end is a dream that has been pursued in various forms but
| it isn't mainstream.
| austinthetaco wrote:
| according to the latest stackoverflow developer survey,
| NodeJS is extremely common and used quite a bit more than
| things like ASP.net
| (https://survey.stackoverflow.co/2022/#most-popular-
| technolog...)
| emodendroket wrote:
| Man... if you don't think node.js on the backend is
| mainstream at this point I don't know what to tell you.
| It's not even the hyped-up new thing anymore.
| sidlls wrote:
| Being not hyped up doesn't mean it's mainstream. Most
| backends are in Java, Go, or PHP. Python and Ruby take up
| most of those that aren't. It's _rare_ to find node on
| the backend in comparison.
| cutler wrote:
| Go more ubiquitous than Node.js? In your dreams.
| emodendroket wrote:
| I don't agree that Go is more common than node (or other
| options you did not mention like .NET).
| SoftTalker wrote:
| Well by definition the "average" team is not capable of writing
| a "great" app. So it doesn't matter so much what the
| _technology stack_ is -- most of what is produced is pretty
| shitty regardless.
| mattgreenrocks wrote:
| This is the real problem, and why I'd argue we've made little
| real progress in tooling despite huge investment in it.
|
| The web still requires too much code and concepts to be an
| enjoyable dev experience, much less one that you can hold in
| your head. Web frameworks don't really fix this, they just
| pile leaky abstractions on that require users to know the
| abstractions as well as the things they're supposed to
| abstract.
|
| It seems like it is difficult to truly move webdev forward
| because you have to sell to people who have already bought
| into the inessential complexity of the web fully. The second
| you try to take part of that away from them, they get
| incensed and it triggers loss aversion.
| chasd00 wrote:
| I remember the hype about javascript on the server (node) being
| front-end devs didn't have to know/learn a different language
| to write backend code. Not so much writing code once but not
| having to write Javascript for client-side and then switch to
| something else to write the server-side.
| erikerikson wrote:
| I remember it being both and then some...
|
| [edit: both comprising shared code between client and server,
| as well as, reduced barrier to server-side contribution, and
| then some including but not limited to the value of the
| concurrency model, expansive (albeit noisy) library
| availability, ...]
| [deleted]
| nawgz wrote:
| I'm sorry, but these arguments are so tired.
|
| > SPAs have allowed engineers to create some great web
| applications, but they come with a cost:
|
| > Hugely increased complexity both in terms of architecture and
| developer experience. You have to spend considerable time
| learning about frameworks.
|
| Yes, better quality software usually packages a bit more
| complexity.
|
| SPAs are popular, just like native apps, because people don't
| like jarring reloads. Webviews in native apps are panned for a
| reason; turning your whole app into a series of webviews would be
| stupid, right?
|
| > Tooling is an ever-shifting landscape in terms of building and
| packaging code.
|
| I've used these 4 libraries to build apps since 2015:
|
| * React * MobX * D3 * Webpack
|
| The only one I have had pain with is react-router-dom, which has
| had 2 or 3 "fuck our last approach" refactors in this time. And I
| added TypeScript in 2018.
|
| PEBCAK
|
| > Managing state on both the client and server
|
| It's a lie that a thin client isn't managing state; it's just
| doing a static, dumb job of it.
|
| Imagine some cool feature like... collaborative editing.
|
| How would you pull that off in HTMX?
|
| > Frameworks, on top of libraries, on top of other libraries, on
| top of polyfills. React even recommend using a framework on top
| of their tech:
|
| Yes, React is famously not a batteries-included library, while
| Angular is. But, as addressed, you need about 3 other libraries.
|
| Besides, did you know: HTMX is also a framework. Did you know:
| HTMX also has a learning curve. Did you know: HTMX forces you to
| be able to manipulate and assemble HTMLstrings in a language that
| might not have any typing or tooling for that?
|
| Anyways, I've said enough. I should've just said what I really
| think: someone who can't even get their nested HTML lists to
| actually indent the nesting shouldn't give advice on building
| UIs.
| traverseda wrote:
| >Imagine some cool feature like... collaborative editing.
|
| What are you gaining by writing something like that in
| java/type-script rather than like rust and webassembly?
|
| To me javascript is in a sort of uncanny valley where you
| probably want to be either making a real app and compiling it
| to wasm or using something like htmx.
| nawgz wrote:
| > rather than like rust and webassembly
|
| WASM can't even interact with the DOM, how exactly are these
| languages positioned better to give me access to a ton of UI
| primitives?
|
| The backend can be a fast language, certainly, but the
| browser is a premier UI platform... and it's powered by JS...
|
| To me, Rust developers thinking they know how to build UIs is
| the real uncanny valley. What they produce looks like it
| should work, but the more you look at it, the more you
| realize they don't know what UX stands for
| vb-8448 wrote:
| > Imagine some cool feature like... collaborative editing.
|
| In my opinion, the whole point of the article and for everyone
| who is backing htmx is that SPA frameworks are too complex (and
| a liability) for solo/small teams or projects that don't need
| `collaborative editing`(or other advanced stuff).
| nawgz wrote:
| > In my opinion, the whole point of the article
|
| Well, in my opinion, the article claims "HTMX is the future"
| as its title, and so it's impossible to interpret the
| arguments in any other way than "the user experience benefits
| of the SPA might matter to the users, but I think it's stupid
| because I dislike JS"
| rmbyrro wrote:
| > _Yes, better quality software usually packages a bit more
| complexity._
|
| That view (+quality = +complexity) is actually flip sided,
| isn't it? [1]
|
| [1] https://www.infoq.com/news/2014/10/complexity-software-
| quali...
| nologic01 wrote:
| htmx got a lot of good press (deservedly) but I think somehow it
| needs to get to the next step beyond the basic hypermedia
| evangelism. I don't know exactly what that step needs to be,
| because I don't know what a fully "htmx-ed" web would look like.
| It is promising, but that promise must be made more concrete.
|
| A conceptual roadmap of where this journey could take us and,
| ideally, some production quality examples of solving important
| problems in a productive and fun way would increase the fan base
| and mindshare. Even better if it show how to solve problems we
| didn't know we had :-). I mean the last decade has been pretty
| boring in terms of opening new dimensions.
|
| Just my two cents.
| loxs wrote:
| Am I the only one who actually thinks that a SPA is simpler than
| server rendered UI? I always go for a SPA when I can sacrifice
| indexability and never seem to regret it.
| janosdebugs wrote:
| I can still remember the horrors of page state. The server would
| keep track of what the client has and only send HTML fragments to
| the client. Early-days ASP, Prado and the likes did this and it
| was a terrible idea. HTMX sounds very much like that, but the
| packaging is nicer. Ultimately, the problem is that sometimes you
| need to update more than just the tiny, well-defined part that is
| the todo list and several parts of the UI need to change when a
| request is made. By which I mean this happens all the time. The
| road to hell is paved with todo list implementations as a proof
| that a system works and is good. Please show me a moderately
| complex login system with interlinking interfaces implemented in
| this.
| hamilyon2 wrote:
| I am not going to be serious here, because, honestly, this is
| kind of ridiculous.
|
| Two years ago I distinctly remember server side rendering piped
| thru websocket was future.
|
| I also like how demo is visibly ugly, jQuery-style ugly. It's
| nostalgic in a way. And I swear to gods this approach will break
| back button. And resending form after network error. And expired
| cookie will of course result in your input being lost.
| tedunangst wrote:
| How does this differ from what we called rehydration a decade
| ago?
| lucidguppy wrote:
| HTMX brings new life to tech like django which can catapult MVPs
| into production asap.
|
| Backend engineers are now able to write management tools and
| experimental products faster - and then pass the winning products
| off to a fluttr team to code for all environments. The backend
| could be converted into a django rest api if the code is properly
| refactored.
| chrislan815 wrote:
| Yeah HTMX is nice; I'm still learning about it. I'm building a
| django app for https://host.upcyclebikes.co/listings/allll and
| i'm slowly introducing htmx into it.
| CodeCompost wrote:
| I'm beginning to realise that AI assistance is now resulting in
| long and verbose articles like this one. The bullet points are
| especially off-putting.
| rmorey wrote:
| then the problem begets its own solution - just use an
| assistant to summarize for you! \s
|
| (i don't actually think this article is largely AI-generated)
| divan wrote:
| Why people concentrating on creating more hacks on top of
| fundamentally ill-suited stack for app development, rather then
| rethink the whole stack from the first principles?
|
| Luckily, after 3 decades, there is some sobering realization that
| typesetting engine is not a good foundation for modern apps.
| https://news.ycombinator.com/item?id=34612696
|
| Web development without HTML/CSS/JS is the future.
| mike503 wrote:
| Reminds me of Drupal's AHAH implementation.
| [deleted]
| nine_k wrote:
| I think it's the wrong article (pun semi-intended), HTMX is _a_
| future. React is _a_ future. Svelte is _a_ future. Even Angular
| is _a_ future. They all have their specific strengths which
| define where they are more applicable.
|
| There's no " _the_ future " in this area, because demands are
| very different; a heavily interactive SPA like GMail or Jira has
| requirements unlike an info page that needs a few bits of
| interactivity, etc.
| rglover wrote:
| Or: just use plain HTML [1] and keep separation of concerns
| intact.
|
| In a quote:
|
| > "So much complexity in software comes from trying to make one
| thing do two things." - Ryan Singer (Basecamp/37Signals)
|
| [1] https://github.com/cheatcode/joystick
| kokizzu5 wrote:
| meh, Svelte is the future, just plain Svelte, not SvelteKit
| recursivedoubts wrote:
| i am the creator of htmx, this is a great article that touches on
| a lot of the advantages of the hypermedia approach (two big ones:
| simplicity & it eliminates the two-codebase problem, which puts
| pressure on teams to adopt js on the backend even if it isn't the
| best server side option)
|
| hypermedia isn't ideal for everything[1], but it is an
| interesting & useful technology and libraries like htmx make it
| much more relevant for modern development
|
| we have a free book on practical hypermedia (a review of
| concepts, old web 1.0 style apps, modernized htmx-based apps, and
| mobile hypermedia based on hyperview[2]) available here:
|
| https://hypermedia.systems
|
| [1] - https://htmx.org/essays/when-to-use-hypermedia/
|
| [2] - https://hyperview.org/
| pdonis wrote:
| The article under discussion here appears to be saying that
| HTMX can work without Javascript enabled. But HTMX itself is a
| Javascript library, correct? So how can it work without
| Javascript enabled?
| the_gastropod wrote:
| HTMX embraces the idea of progressive enhancement [1]. You
| start with a functional, javascript-free, web application.
| HTMX layers on top of this to make the experience better, but
| it's effectively optional.
|
| [1] https://developer.mozilla.org/en-
| US/docs/Glossary/Progressiv...
|
| Whoa... I was very slow apparently
| mixmastamyk wrote:
| Adding the form element allows it to post to the server
| without javascript, just like olden times. Since the htmx
| header is not included, the backend was instructed to return
| a full page instead of a fragment.
| recursivedoubts wrote:
| the article says it is possible to build web applications
| that use htmx for a smoother experience if javascript is
| enabled, but that properly falls back to vanilla HTML if js
| is not enabled
|
| this is called progressive enhancement[1], and yes, htmx can
| be used in this manner although it requires some effort by
| the developer
|
| unpoly, another hypermedia-oriented front end library, is
| more seamless in this regard and worth looking at
|
| [1] - https://developer.mozilla.org/en-
| US/docs/Glossary/Progressiv...
| elliottinvent wrote:
| I think the point is that by using HTMX your site can degrade
| gracefully for non-JS users.
|
| A site for a project of mine [1] is built with HTMX and
| operates more or less the same for JS and no-JS users.
|
| I'm aiming to add some bells and whistles for JS users but
| the version you see there is more or less the experience non-
| JS users gets too:
|
| 1. https://www.compactdata.org
| jonahx wrote:
| Out of curiosity, have you used hyperview? Do you consider it
| production ready?
| runlaszlorun wrote:
| Just started using HTMX on a new project and have been a big
| fan. I'd go so far as to say that it's the best practical case
| for the theory of hypermedia in general. Like others have
| mentioned, this is the sort of thing that prob _should_ be in
| the HTML spec but, given what I've personally seen about the
| standards process, I have little expectation of seeing that.
| Thx again!
| rmbyrro wrote:
| How would this be in HTML standard if it requires JS to work?
| account-5 wrote:
| Complete novice here; what are the advantages of hyperview over
| something like flutter?
|
| I looked at a bunch of frameworks before settling on
| dart/flutter for my own cross platform projects. I did look at
| htmx but since I wasn't really wanted to create a web app I
| moved on. But I like the idea of a true rest style of app.
| recursivedoubts wrote:
| hyperview uses the hypermedia approach, which means the
| client and server are decoupled via the uniform interface
|
| so you can, for example, deploy a new version of your mobile
| app without updating the client, a big advantage over needing
| users to update their mobile apps
| fridgemaster wrote:
| >simplicity
|
| Can be achieved in MPAs and SPAs alike. I'd also argue that
| having state floating around in HTTP requests is harder to
| reason about than having it contained in a single piece in the
| browser or in a server session. Granted this is not a problem
| of HTMX, but of hypermedia. There is a reason why HATEOAS is
| almost never observed in REST setups.
|
| > two-codebase problem
|
| This is a non-problem. In every part of a system, you want to
| use the right tool for the job. Web technologies are better for
| building UIs, if only by the sheer ammount of libraries and
| templates that already exist. The same splitting happens in the
| server side: you would have a DB server, and a web service,
| maybe a load balancer. You naturally have many parts in a
| system, each one being specialized in one thing, and you would
| pick the technologies that make the most sense for every one of
| them. I'd also argue that backend developers would have a hard
| time dealing with the never ending CSS re-styling and constant
| UI change requests of today. This is not 2004 where the backend
| guys could craft a quick html template in a few hours and went
| back to work in the DB unmolested. The design and UX bar is way
| higher now, and specialists are naturally required.
| benatkin wrote:
| It doesn't feel like hypermedia to me. It just feels like a
| vue-like language that is an internal DSL for HTML instead of
| an external DSL for HTML like svelte and handlebars.
|
| Hypermedia advances would be microformats and RDF and the like.
| http://microformats.org/wiki/faqs-for-rdf
| recursivedoubts wrote:
| it absolutely is hypermedia
|
| we generalize HTML's hypermedia controls in the following
| way:
|
| - any HTML element can become a hypermedia control
|
| - any event can drive a hypermedia interaction
|
| - any element can be the target of a hypermedia interaction
| (transclusion, a concept in hypermedia not implemented by
| HTML)
|
| all server interactions are done in terms of hypermedia, just
| like w/links and forms
|
| it also makes PUT, PATCH and DELETE available, which allows
| HTML to take advantage of the full range of HTTP actions
|
| htmx is a completion of HTML _as a hypermedia_ , this is its
| design goal
| benatkin wrote:
| Links and forms are the bread and butter of many
| frameworks.
|
| Like with HTMX, SvelteKit and Remix forms won't function
| properly without the framework.
| renerick wrote:
| HTML forms absolutely do function without htmx since it's
| a part of browser standard. By default, htmx sends forms
| using same content type as browser does
| (application/x-www-form-urlencoded). The server will
| receive same requests, as if the browser sent them and
| can differentiate by presence of HX-Request HTTP header.
| benatkin wrote:
| That's the _properly_ part. If you make a form and the
| output is supposed to go in a particular place and it
| doesn 't (hx-swap), then it isn't functioning properly.
| The degree to which it is improperly functioning depends
| on the UI and the user. In many cases it's improperly
| enough that it may as well either work or not work.
| renerick wrote:
| As mentioned, htmx will attach a `HX-Request: true`
| header to the request[1]. The server can check this
| header and either return a partial for swapping, or a
| full page/redirect like in good old days. Same with any
| request. This is one way of how htmx provides
| "progressive enhancement". Sure, this may not be as
| transparent, as other JS-first frameworks implement it,
| but it's not complex at all.
|
| The only thing that might cause trouble is non-standard
| (as in HTML standard) HTTP methods, which basically means
| any method other than GET and POST, I admit that.
| However, the fact that these methods are not supported
| even in HTML5 is a huge miss.
|
| [1]: https://htmx.org/reference/#request_headers
| csjh wrote:
| SvelteKit forms work fine with Javascript disabled --
| Rich Harris is a big proponent of progressive
| enhancement.
| recursivedoubts wrote:
| if you read the article, you will see that you can use
| htmx as progressive enhancement quite easily since it is
| consonant with the vanilla HTML approach.
|
| what makes htmx a hypermedia framework is the exchange of
| hypermedia with the server, this satisfies the hypermedia
| constraint (HATEOAS) of REST. there are other libraries
| that are also hypermedia oriented, such as unpoly.
|
| it is a different approach to building web applications
| than the JSON/RPC style that is popular today
|
| i encourage you to read the linked article, and, if it is
| interesting to you, the essays at
| https://htmx.org/essays, and then potentially
| https://hypermedia.systems
| dlisboa wrote:
| I don't really see how progressive enhancement works if
| every element is a hypermedia control. Without JS/HTMX
| you just have a page that does nothing:
| <div hx-get="/example">Get Some HTML</div>
|
| This will never do anything without HTMX because the
| semantic of that markup is wrong. You'd really have to
| write everything in a vanilla HTML approach to begin
| with, and never make use of the idea of adding hypermedia
| to other elements.
| recursivedoubts wrote:
| you do have to structure things properly to make
| progressive enhancement work with htmx
|
| for your example, you wouldn't have a div, you'd use an
| anchor: <a hx-get="/example"
| href="/example">Get Some HTML</a>
|
| or, more likely, just boost it: <a
| hx-boost="true" href="/example">Get Some HTML</a>
|
| and then on the server side you'd need to check the `HX-
| Request` header to determine if you were going to render
| an entire page or just some partial bit of HTML
|
| if you go down the progressive enhancement route you need
| to think carefully about each feature you implement and
| how to make it compatible w/ no-js. Some patterns (e.g.
| active search) work well. Others (drag and drop) don't
| and you'll have to forgo them in the name of supporting
| noJS
|
| nb: unpoly is a more seamless progressive enhancement
| experience due to its design goals
| tomhallett wrote:
| have you seen any interest by the browsers to build htmx
| features as experimental browser features, with the goal of
| htmx features becoming browser standards?
|
| When looking at the various options, I always enjoyed your
| architectural choice of htmx being an extension of html,
| for that very reason. Similar to "phonegap" hoping that the
| phonegap code base would get smaller and smaller as mobile
| browsers built more of those features natively. :)
| recursivedoubts wrote:
| i haven't heard of any browsers implementing these
| features, but that's the right thing: they would be far
| more effectively implemented by the hypermedia client and
| it wouldn't be too much work technically
|
| my sense is that HTML is constrained by
| social/organizational issues rather than technical ones
| at this point
|
| hopefully someone on the chrome team notices htmx at some
| point and HTML starts making progress again
| tomhallett wrote:
| question - which parts of htmx would be better from an
| end-user-perspective if they were built into the browser?
| i assume "all features" might be a bit faster, but is
| there anything which would be night and day better if it
| wasn't a js library?
|
| the browser vendors have been more than happy to use
| experimental features to chart their own course, which I
| think can be a good thing to spawn innovation and healthy
| competition. (given the standards bodies will be slower
| and more prudent - similar to how python doesn't want
| "pedantic" to be part of python core, because that would
| hurt pedantic's innovation, not improve it)
|
| Maybe the way someone from the chrome team could tap into
| "business value" of "let's build these htmx features in
| chrome" would be that it allows developers to write
| "internal/developer/crud apps" where a "only supported in
| chrome" is acceptable.....
| recursivedoubts wrote:
| maybe I'm too close to it, but htmx feels like a hack to
| address things that really should be part of the HTML
| spec
|
| if browsers got into the game I would assume they could
| do things much faster and integrate things like preload
| (https://htmx.org/extensions/preload/) and idiomorph
| (https://github.com/bigskysoftware/idiomorph/) much more
| cleanly w/ the rest of the browser infrastructure
| booleandilemma wrote:
| I use htmx on my personal site and I love it so much. Thank
| you!
| cogman10 wrote:
| It's not clear to me, but how and where is state managed?
|
| In the OPs article, it looks like the only thing going over the
| line is UUIDs. How does the server know "this uuid refers to
| this element"? Does this require a sticky session between the
| browser and the backend? Are you pushing the state into a
| database or something? What does the multi-server backend end
| up looking like?
| recursivedoubts wrote:
| https://htmx.org/essays/hateoas/
| mal-2 wrote:
| I like some concepts from HTMX but I don't understand how it
| tracks the relationship between these addresses and the
| identifiers in the markup. It seems to be just that the
| identifier strings match - the markup identifies the
| targets/swaps and it just refers to itself.
|
| When I compare this to Phoenix LiveView I much prefer LiveView,
| because it both provides the markup templating engine and tracks
| the meaning of the relationship, with server-side tokens and
| methods.
| diegof79 wrote:
| While HTMLX makes some interactions easier for developers without
| JS experience, the primary issue in web development is that the
| browser was not designed for apps. It evolved unevenly from a
| document navigation platform, and many things we do in web
| development today are hacks due to the lack of a better solution.
|
| In my opinion, the future of the web as a platform is about
| viewing the web browser as an operating system with basic
| composable primitives.
|
| HTMLX adds attributes to HTML using JS, and the argument about
| "no-JavaScript" is misleading: with HTMLX you can write
| interactions without JS, but HTMX uses JS. But, as it forces you
| to use HTML constructs that will work without scripts (such as
| forms), the page will fall back. It doesn't means that the
| fallback is usable.
|
| The custom HTMLX attributes work because the browser supports
| extensions of its behavior using JS. If we add those attributes
| to the standard HTML, the result is more fragmentation and an
| endless race. The best standard is one that eliminates the need
| for creating more high-level standards. In my view, a possible
| evolution of WASM could achieve that goal. It means going in the
| opposite direction of the article, as clients will do more
| computing work. In a future like that, you can use HTMLX,
| SwiftUI, Flutter, or React to develop web apps. The biggest
| challenge is to balance a powerful OS-like browser like that with
| attributes like searchability, accessibility, and learnability
| (the devtools inspect and console is the closest thing to
| Smalltalk we have today)...even desktop OSs struggle today to
| provide that.
| [deleted]
| themodelplumber wrote:
| Thanks for the reminder, I've been meaning to try it out. Just to
| get started, I asked ChatGPT to write an htmx app to show a
| 10-day weather forecast.
|
| It described the general steps and seemed to be able to describe
| how htmx works pretty well, including hx-get and hx-target, etc.,
| but then said "As an AI language model, I am not able to write
| full applications with code".
|
| I replied "do the same thing in bash" (which I knew would be
| different in significant ways, but just to check) and it provided
| the code.
|
| I wonder, is this a function of recency of htmx or something
| else? Do other htmx developers encounter this? I imagine it's at
| least a little bit of a pain for these boilerplate cases, if it's
| consistent vs. access to the same GPT tooling for other
| languages.
| yawaramin wrote:
| You can write an htmx app in bash:
| https://www.youtube.com/watch?v=Jzcu4JheCtY
| themodelplumber wrote:
| So are you saying that ChatGPT will probably offer to write
| an htmx app in bash?
|
| > I'm sorry, but it's not possible to write a weather
| forecast app using bash and htmx as htmx is a client-side
| technology and bash is a command-line shell. htmx is
| typically used in conjunction with HTML and JavaScript to
| create dynamic web applications.
|
| Cuz that didn't work. It straight up forged ahead and wrote a
| bash script to show the weather though.
|
| I really wonder today if ChatGPT is going to cause a bash
| renaissance
|
| (If you are telling me I can do this myself plz reread posts
| thx)
| nirav72 wrote:
| Was it with gpt 3.5 or 4?
| themodelplumber wrote:
| 3.5. I actually just tried the same prompt in playground >
| text-davinci-003 and it wrote the front end in htmx without
| any endpoint code, then when prompted it provided endpoint
| code.
|
| Still looks to be missing something aside from just the api
| key... <script> htmx.on('load',
| () => { const apiKey = '<your-api-key>';
| }); </script>
|
| ...maybe 4 is way better. I thought I had a Plus account but
| it looks like API only.
|
| Edit: Just tried 4 and it is better in the sense that it
| writes a more complete app for you, but it strangely
| separates the sections of the front end into discrete
| textareas w/ code, so if you are new to front end it'll be
| confusing for sure. "Where do I put all this" "oh actually it
| all gets run together; specifically these two sections of
| code are concatenated and placed in the body area of the
| first code section."
|
| It also writes the endpoint code in Python and Flask by
| default, but with one more prompt it seems to have fixed all
| that.
|
| I really wonder why 3.5, the common public interface, did
| what it did, when "actually writes code for more languages by
| default" isn't exactly on the Plus features list.
| listenallyall wrote:
| HTMX is quite easy to code. Your prompt sounds rather generic,
| I mean, you can just serve 10 days of weather forecasts without
| any interaction whatsoever.
|
| https://www.wunderground.com/forecast/us/ak/north-pole
|
| It isn't clear what you were asking ChatGPT to provide,
| therefore not surprised it didn't come up with the exact answer
| you expected. I'd suggest learning HTMX by reading the docs,
| the majority is just a single page.
| themodelplumber wrote:
| ChatGPT made it very clear it understood exactly what I
| wanted, short of writing the code. The steps it offered were
| long, and far from generic. So. Why no code? It offers code
| for other langs all the time, even unprompted.
|
| It was like...if you've ever been mansplained before, when
| you know how to code something, but are asking a specific
| question that interests you, related to the process of having
| a service do that part for you--and someone comes along like,
| "well, it's easy to code that yourself!"
|
| Not sure if you've experienced that before but it's very
| similar.
| listenallyall wrote:
| I don't really use ChatGPT but regardless, it seems strange
| to evaluate the merits of a JS library based upon ChatGPT's
| prowess with it. Your time would be far better spent, I
| think, by reviewing the docs yourself and building a basic
| site.
| Animats wrote:
| It's sort of like client side PHP. Is that a good thing or a bad
| thing?
| eimrine wrote:
| > Some SPA implementations of SPA throw away progressive
| enhancement (a notable and noble exception is Remix). Therefore,
| you must have JavaScript turned on for most SPAs.
|
| Is this really the future?
| qgin wrote:
| As long as native apps live alongside web, then the architecture
| of web is going to trend towards that of native apps, managing
| display state on the client while managing business state on
| server.
| s1k3s wrote:
| Love articles like this because I know there's some manager
| somewhere who will read this and force it upon their team without
| having any idea if it's good or not. And in 3 years we'll have
| people from those teams complaining about HTMX because it's not
| suited for their projects.
|
| The future is whatever works best for your use-case.
| w10-1 wrote:
| What's the business case, for them or for developers?
|
| Ideas aside, the web app future belongs to those with the
| resources to sustain a response, or those who can restore the
| ability to capture/monetize developers and users in a closed
| system.
|
| The scope of web apps is broad enough that many technologies
| arguably have their place. The open javascript ecosystem reduced
| the cost of creating candidates, but has no real mechanism to
| declare winners for the purpose of consolidating users, i.e.,
| access to resources.
|
| Careers and companies are built on navigating this complexity,
| but no one really has the incentive to reduce it unless they can
| capture that value.
|
| I really appreciate Cloudflare because they are open about both
| their technology and their business model. They thus offer a
| reasonable guarantee that they can sustain their service and
| their technology, without basing that guarantee on the fact that
| they are a biggie like AWS, Microsoft, or Google (i.e., eating
| their own dog food, so we can join them at the trough).
|
| The biggest cost in IT is not development or operating fees but
| reliance and opportunity.
| jimmaswell wrote:
| I've made my personal website something of a hybrid SPA. WithJS
| enabled it only loads and replaces the relevant portions of the
| page, but a page renders fully from PHP going to it directly.
|
| Relevant code:
|
| https://github.com/ldyeax/jimm.horse/blob/master/j/j.php
|
| https://github.com/ldyeax/jimm.horse/blob/master/j/component...
|
| The JS would be a bit more elegant if script tags didn't need
| special handling to execute on insertion.
|
| The experience is very seamless this way - I'm very pleased with
| it. It's live at https://jimm.horse - the dynamic behavior can be
| found clicking on the cooking icon or N64 logo.
|
| On reading the article, I'll definitely make use of this if it
| becomes well-supported. It does exactly what I wanted here.
| 0xbadcafebee wrote:
| I just want Visual Basic for the web man. Screw writing lines of
| code. I want to point and click, drop complex automated objects
| onto a design, put in the inputs and outputs, and publish it. I
| don't care how you do it, I don't want to know any of the
| details. I just want to be able to make things quickly and
| easily. I don't care about programming, I just want to get work
| done and move on with my life.
|
| At this rate, when I'm 80 years old we will still be fucking
| around with these stupid lines of code, hunched over, ruining our
| eyesight, becoming ever more atrophied, all to make a fucking
| text box in a monitor pop some text into a screen on another
| monitor somewhere else in the world. It's absolutely absurd that
| we spend this much of our lives to do such a dumb thing, and
| we've been iterating on it for five decades, and it's still just
| popping some text in a screen, but we applaud ourselves that
| we're so advanced now because something you can't even see is
| doing something different in the background.
| otreblatercero wrote:
| I feel you. I'd love to have a tree that gives money, and I
| tried to, but somehow I had to implement many things, like
| invent a seed that can actually produce golden coins, I had to
| read about alchemy, seed hybridation... I just wanted to get
| money from a tree. But do not despair, while documenting my
| process, I found a revolutionary tool called Dreamweaver, I
| think it's the future, I think it would be terrific for your
| needs.
| neurostimulant wrote:
| So, do you want to run a winform app in a browser? Behold!
| https://github.com/roozbehid/WasmWinforms
|
| https://news.ycombinator.com/item?id=18981806
| revelio wrote:
| There's a lot of low-code platforms that do that.
| auct wrote:
| I tried htmx, but syntax is horrible, so 3 years ago I've created
| uajax universal Ajax forms and js-ajax-button. Add class to any
| form and it is ajaxed. I even released it on github
|
| The js-ajax-button has similar approach. Add class to button that
| have data-url and it will make request to it. This is small func
| I use, but with uajax is so powerful, I don't need react or htmx.
|
| But it is hard to sell something that eliminates using
| javascript.
| xutopia wrote:
| Wether it is Htmx or Phoenix/Liveview or Hotwire/Stimulus we're
| seeing a shift in the industry towards augmented HTML rather than
| throwing away all RESTFUL routes. REST is elegant and this
| approach is very powerful as well.
| iamgopal wrote:
| Basecamp ( or Hey or guys behind ror ) , the original SAAS guys
| really do understand software development from practical point of
| view, they did something similar with rails as well as native
| clients, now a days they are trying people to move away from
| cloud. Bare metal is the future.
| branko_d wrote:
| I'm afraid htmlx might be repeating the same mistake that CORBA
| and DCOM made decades ago: pretending that latency doesn't
| matter.
|
| Yes you could make a CORBA or DCOM object almost
| indistinguishable from a local object, except for the latency
| when it was actually remote. And since it looked like a normal
| object it encountered "chatty" interface which exacerbated the
| latency cost.
|
| Htmlx seems pretty chatty to me, which I'm sure works OK over the
| LAN, but what about the "real" internet?
| incrudible wrote:
| I take the opposite side of that bet. Always bet on (more)
| Javascript. Dealing with HTML sucks, and we want as little of it
| as possible, otherwise we would not have invented generations of
| frameworks to make it manageable. The lasting success of React
| shows that we have converged on how to do that. Moving back to
| MPAs is always something that bored engineers want to do. Users
| generally do not care.
|
| Moreover, REST APIs - and I mean the simple ones people actually
| want to use, none of that HATEOAS BS - are ubiquitous for all
| sorts of interactions between web and nonweb clients. Are you
| going to ship an MPA as your mobile apps, or are you going to
| just use REST plus whatever clients make sense?
|
| It also makes a lot of sense in terms of organization. Your
| backend developers probably suck at design, your frontend
| developers suck at databases.
| rektide wrote:
| Personally I believe strongly in thick clients but this is a
| pretty neat demo anyways.
|
| I see a lot of resemblance to http://catalyst.rocks with
| WebComponents that _target_ other components. I think there 's
| something unspoken here that's really powerful & interesting,
| which is the declarativization of the UI. We have stuff on the
| page, but making the actions & linkages of what does what to what
| has so far been trapped in code-land, away from the DOM. The
| exciting possibility is that we can nicely encode more of the
| behavior into the DOM, which creates a consistent
| learnable/visible/malleable pattern for wiring (and rewiring)
| stuff up. It pushes what hypermedia can capture into a much
| deeper zone of behaviors than just anchor-tag links (and
| listeners, which are jump points away from the medium into
| codespace).
| Alifatisk wrote:
| That looks alot like Stimulus!
| rektide wrote:
| Yeah it is! I meant to cite that too. It's mentioned by
| Catalyst as inspiration, somewhere.
| wwweston wrote:
| > the declarativization of the UI
|
| Yes! There's always going to be some range of client behavior
| that's difficult to reduce to declarations, but so much of what
| we do is common that if it isn't declarative we're repeating a
| lot of effort.
|
| And in general I think you're describing a big part of what
| made the web successful in the first place; the UI-as-document
| paradigm was declarative, accessible, readable, repeatable.
| haolez wrote:
| Catalyst looks nice! What's the downside? Is it dead?
| rektide wrote:
| Catalyst is great. Definitely active, actively used, last
| updates in main were late February.
|
| They have a big 2.0 branch that has a ton of internal
| changes. TypeScript 5.0 finally updated to support modern
| @decorator syntax & they're rewriting a bunch to support
| that, which is excellent.
| synergy20 wrote:
| htmx is ajax wrapped in html to me.
|
| it does not work for resource restricted (i.e. embedded) devices
| where you just can't do server-side rendering, CSR SPA is the
| future there as the device side just need return some json data
| for browser to render.
| thomasreggi wrote:
| I agree with this article, however I think that HTMX needs a
| strong server framework to support HTMX. I've thought about this
| alot and a couple months back created this deno / typescript
| framework https://github.com/reggi/htmx-components, would love
| for people to take a look at it and provide guidance and
| direction for a releasable version.
| triyambakam wrote:
| That's really nice!
| tkiolp4 wrote:
| Frontend developers don't want to write HTML nor augmented HTML.
| They want to write code, and these days that means JS. Frontend
| developers want to make good money (like those backend developers
| or even infrastructure developers who are working with data,
| servers, and cool programming languages), hence they need to work
| with complex libraries/frameworks (if you just write HTM?, you
| don't get to earn much money because anyone can write HTM?).
|
| Hell, the term "frontend developer" exists only because they are
| writing JS! Tell them it's better to write HTM?, and you are
| removing the "developer" from their titles!
|
| Same reason why backend developers use K8s. There's little money
| on wiring together bash scripts.
|
| Now, if you're working on your side project alone, then sure HTMX
| is nice.
| robertoandred wrote:
| Incorrect. You can't create a website without HTML. The term
| "frontend developer" exists because frontend is a complex mix
| of HTML, CSS, JS, browser functionality, screen sizes,
| accessibility requirements, privacy requirements, server
| interactions.
|
| Backend devs just lampoon it because they assume it must be
| simple.
| pier25 wrote:
| Good luck with latency though for anything slightly interactive.
| Veuxdo wrote:
| I like how the cons of SPA are "you have to manage state" and
| "clients have to execute code".
|
| I mean, aren't these baseline "get computers to do stuff" things?
| zerkten wrote:
| Why do things in two places when you can do it all in one
| place? This isn't limited to computers, but unless you are
| getting specific benefits, it isn't wise to continue with a SPA
| approach.
|
| We had the same and worse problems with "thick clients" that
| came before the web grew. With the right requirements, team,
| tools etc., you could sometimes build great apps. This was
| incredibly difficult and the number of great apps was
| relatively small. Building with earlier server-side web tech,
| like PHP, isolated everything on the server and it was easier
| to iterate well than with the "thick clients" model.
|
| SPA reinvents "thick clients" to some degree and brings back
| many of the complications. No one should claim you can't build
| a great SPA, or that they have few advantages, but the
| probability of achieving success is frequently lower.
| Frameworks try to mitigate these concerns, but you are still
| only moving a closing some of the gaps and the probability of
| failure remains higher. Depending on the app you can move the
| success metrics, but we often end up fudging on items like
| performance.
|
| We get to a point where there is current model is fraying and
| energy builds to replace it with something else. We end up
| going back to old techniques, but occasionally we learn from
| what was done before.
|
| I find that it's surprisingly rare for people with 1-2 years of
| experience to be able to give an accurate overview of the last
| 10 years of web development. A better understanding of this
| history can help with avoiding (or targeting) problems old
| timers have encountered and complain about in comments.
| chasd00 wrote:
| back in the olden days a web browser was largely considered
| just a program to read documents stored on other systems that
| can be linked to each other sent over a simple stateless
| protocol. Then we started to be able to collect user input,
| then a hack was invented to maintain state between
| requst/response pairs (cookies), then a scripting language etc
|
| There are many use cases out there where not treating a browser
| as a container to run an actual application is the right way to
| go. On the other hand, there's many use cases where you want
| the browser to be, basically, a desktop app container.
|
| The big bold letters at the top of the article declaring htmlx
| is the future is a bit much. It has its place and maybe people
| are re-discovering it but it's certainly not the future of web
| development IMO. The article gives me kind of web dev career
| whiplash.
| 0x445442 wrote:
| When do you want the browser to be anything more than a
| hypertext document viewer and why?
| dalmo3 wrote:
| Roughly every time I can use something by just typing some
| words instead of downloading a .exe.
| mdaniel wrote:
| Or its close friend: when I want to use the data or
| customize the UI via `document.querySelectorAll`
| kubota wrote:
| I don't know. The tabs example on the htmx page is perceptibly
| slow to me. Making a rest call every time I switch a tab, each
| time sending 90% of the same html skeleton data over the wire
| feels like a sin to me. Returning html from my api also feels
| like a sin.
| munbun wrote:
| The HATEOAS approach is viable for some applications but I
| wouldn't necessarily call it the future.
|
| Using custom html attributes as the base for complex client-side
| interactions is arguably a step backwards when considering the
| story around maintenance.
|
| Right now, if you are building a robust component library - it's
| much easier to maintain using a template language with strong
| Typescript / IDE support, like JSX or similar.
| hankchinaski wrote:
| everytime i see a custom new DSL i just bin the thing altogether,
| I dont want to learn a new DSL that will disappear in a year, it
| will be impossible to find documentation and community support
| for. just a big no for me. Apart from that seems like a good idea
|
| >Here we are getting a bit fancy and only allowing one row at a
| time to be edited, using hyperscript. https://hyperscript.org
| michaelchisari wrote:
| Everybody's arguing about whether Htmx can do this or that, or
| how it handles complex use case x, but Htmx can do 90% of what
| people need in an extremely simple and straight-forward way. That
| means it (or at least its approach) won't disappear.
|
| A highly complex stock-trading application should absolutely not
| be using Htmx.
|
| But a configuration page? A blog? Any basic app that doesn't
| require real-time updates? Htmx makes much more sense for those
| than React. And those simple needs are a much bigger part of the
| internet than the Hacker News crowd realizes or wants to admit.
|
| If I could make one argument against SPA's it's not that they
| don't have their use, they obviously do, it's that we're using
| them for too much and too often. At some point we decided
| everything had to be an SPA and it was only a matter of time
| before people sobered up and realized things went too far.
| ktosobcy wrote:
| This!
|
| It's like with static websites - we went from static to blogs
| rendered in php and then back to jekyll...
| bottlepalm wrote:
| I tried HTMX. The static typing just isn't there between the
| components you send down and the rest of the page. This makes
| maintenance of a large HTMX app pretty costly. For simple stuff,
| it's probably fine, but large complicated web apps, I'm not
| seeing it. Mixing HTML fragments from the server into the client
| is pretty messy. Keeping all the rendering in one place a la
| React seems much simpler to maintain. With Next for example you
| can pre-render on the server, and re-render on the client - the
| same code is doing the rendering in both places so a bit more
| easier to understand.
| quickthrower2 wrote:
| No. A hodgepodge of everyone's favourite way, is the future.
| Always has been!
|
| That said for my next hobby project I will probably go even
| simpler than HTMX, and use classic server side rendering. Then
| add some Vanilla JS where needed.
|
| I keep going around in circles, but I have tried NextJS and while
| pretty cool there are a class of problems you need to deal with
| that simply don't exist in simpler apps.
| wibblewobble124 wrote:
| we're using htmx at work, migrating away from react. the
| technique we're using is just rendering the whole page, e.g. we
| have a page where one side of the screen is a big form and the
| other side is a view on the same data but with a different UI,
| updating one updates the other. we're using the morphdom swapping
| mode so only the things that changed are updated in-place. as a
| colleague commented after implementing this page, it was pretty
| much like react as far as "pure function of state."
|
| our policy is that for widgets that are like browser components
| e.g. search as you type with keyboard shortcuts, we just use the
| off the shelf react component for that purpose and use it from
| htmx like it'a browser input element. for all other business
| logic (almost all of which has no low latency requirements and
| almost always involves a server requets), we use htmx in our
| server side language of choice.
|
| our designer who knows a bit of react is not happy, but the 12
| engineers on our team who are experts in $backend_lang and who
| are tired of debugging react race conditions, cache errors,
| TypeScript front end exceptions, js library churn, serialisation
| bugs, etc. are very happy indeed.
|
| it doesn't fit every app, but it fits our app like a glove and
| many others that I've considered writing that I didn't feel like
| bothering to do so before discovering htmx.
| robertoandred wrote:
| Sounds like your backend devs are just bad at frontend.
| jcmontx wrote:
| I am very fond of MPAs. Glad to see them make a comeback.
|
| The one single strong point of the front/back split is the famous
| Strangler Fig Pattern which takes away a lot of stress when
| making decisions.
| EGreg wrote:
| We spent 12 years on https://qbix.com/platform and along the way
| saw a lot of fads come and go.
|
| At one point we experimented with the server returning the stuff
| to replace the HTML with. We support that in our framework
| natively (through a mechanism called "slots").
|
| That said, I have come to believe that people this decade will
| (and should) invert the idea of progressive enhancement to be
| client-first.
|
| Imagine your site being composed of static files (eg served on
| Hypercore or IPFS via beaker browser). As more people use it, the
| swarm grows. No worries about being DDOSed. No having to trust a
| server to not send you the wrong interface one day. The software
| is yours. It just got delivered via a hypercore swarm or
| whatever, and your client checked the Merkle trees to prove it
| hasn't been tampered with.
|
| The you just interact eith a lot of headless web services. Rather
| than bearer tokens and cookies, you can use webauthn and web
| crypto to sign requests with private keys. You can do a lot more.
| And you store your data WHERE YOU WANT.
|
| Sure, htmx can be used there. But there, too, it's better to
| fetch JSON and interpret it on the client.
|
| Returning markup language like HTML actually mixes data with
| presentation. Consider what happens when you want to return a lot
| of rows. With JSON, you return just the structured content. With
| HTML, there is a lot of boilerplate <li class="foo"
| onclick="..."> mixed in there which is a lot of extra weight on
| the wire.
|
| If you are interested in learning more, I gave a whole talk about
| it:
|
| https://qbix.com/blog/2020/01/02/the-case-for-building-clien...
| Pet_Ant wrote:
| The problem is that these kind of approaches require more upfront
| thought, which produces less now, and pays off later... and only
| if maintained by people in tune with the original design.
|
| I've seen this architectures quickly ruined by 'can-do' people
| who butcher everything to get a feature done _and_ get a bonus
| from the management for quick delivery.
| 727564797069706 wrote:
| In my experience, these 'can-do' people can (and usually will)
| butcher anything, be it MPA, SPA or TUI.
|
| This seems like the real problem we need to solve, but not sure
| how?
| aidenn0 wrote:
| I suppose we could stop rewarding people for delivering
| features that customers want...
| Pet_Ant wrote:
| Or make them accountable for long term consequences. It's
| no different than CEOs cutting R&D and calling a profit.
| Deferred bonuses till a 3 year post mortem would help.
| poidos wrote:
| I've been using HTMX (from Clojure) for projects recently and I
| have to say I like it a lot. Full-stack web stuff is a hobby for
| me and I always had trouble really grokking all the parts of
| SPAs. HTMX fits neatly into my brain's model of how websites
| should work.
| xkcd1963 wrote:
| "The hypermedia approach of building websites led to the world-
| wide-web being an incredible success." This is wrong
| pictur wrote:
| If your project consists of a todo list, these tools will do the
| trick. but they are useless for projects with larger and more
| complex needs. and yes, there may be cases where it doesn't work
| in frameworks like nextjs and you need to apply hacky solutions.
| but I don't see even libraries like nextjs being so self-
| praising. Come on, folks, there's no point in praising a small
| package that can do some operations through the attribute. It is
| inevitable that the projects developed with this package will
| become garbage when the codebase grows. because that doesn't
| exist in the development logic. It's nothing more than a smug
| one-man's entertainment project. sorry but this is the truth.
| jcpst wrote:
| I don't understand how it's inevitable that projects using this
| package will become garbage when the codebase grows. It looks
| like reasonable patterns could be built around it. Am I missing
| something?
| infamia wrote:
| You can always incrementally add dynamic features using web
| components when HTMX and similar things aren't a good fit. It
| doesn't have to be either HTMX or JS-first frameworks. Our
| industry's fixed mindset of JS/React vs. Hypermedia (e.g.,
| HTMX/Hotwire/Unpoly) needs to change.
| pictur wrote:
| I am not for or against anything. I don't live in a fantasy
| world like in the article. I want to talk about real world
| problems, not dreams.
| infamia wrote:
| A Real World React -> htmx Port
|
| https://htmx.org/essays/a-real-world-react-to-htmx-port/
| optymizer wrote:
| I remember fetching HTML from the server with AJAX and updating
| innerHTML before it was called AJAX. Is HTMX repackaging that or
| am I missing some exciting breakthrough here?
| sourcecodeplz wrote:
| It is like that yes but more abstract because it uses some
| special HTML tags to make the JS calls.
|
| There is a big downside though: weak error handling. It just
| assumes that your call will get a response.
| mlboss wrote:
| It is doing the same. Just makes cleaner and easier.
| BeefySwain wrote:
| I recently put together https://github.com/PyHAT-stack/awesome-
| python-htmx at PyCon.
|
| If anyone is looking to discuss making Hypermedia Driven
| Applications with HTMX in Python, head over to the discussions
| there!
| klysm wrote:
| I'll stick to making SPAs for the apps I work on. This is just
| the pendulum of tradeoffs swinging back till people experience
| the pains of MPAs again
| sublinear wrote:
| > SPAs have allowed engineers to create some great web
| applications, but they come with a cost: ... Managing state on
| both the client and server
|
| Having a separation of concerns between server and client is the
| whole point, and replacing JSON APIs with data trapped in HTML
| fragments is a massive step backwards.
| recursivedoubts wrote:
| https://htmx.org/essays/splitting-your-apis/
| dalmo3 wrote:
| So, by your own words, in htmx:
|
| > the new API is simply reflected in the new HTML returned by
| the server
|
| Whereas with SPAs (my words)
|
| > the new API is simply reflected in the new json returned by
| the server
|
| I think I prefer the mental model of the api serving data and
| client rendering it.
| Alifatisk wrote:
| Can we count in Hotwire, inertiajs, Alpinejs, unpolyjs aswell?
| jksmith wrote:
| You know, nobody likes this argument, but desktop is still just
| better. Yeah, yeah, the updates, security issues, I get it, but
| the tools are simple better, render faster, better
| functionality/complexity ratio, less gnashing of teeth.
| lolinder wrote:
| Desktop on which OS? Using what GUI framework? The web is a
| single platform, but the desktop developer experience seems to
| vary wildly depending on the OS.
|
| I'm genuinely curious what OS and tooling you use that you find
| so much better, because every time I've tried desktop
| development I eventually give up and go back to the web. It
| might be because Linux support is always a requirement for me.
| criddell wrote:
| > which OS?
|
| The one you want to run your software on.
|
| > what GUI framework?
|
| Assuming you aren't making a game, each OS has a different
| answer. Making an iPadOS or macOS app? I'd probably go with
| SwiftUI. Linux? I'm partial to GTK. Windows? Probably WinUI
| (although I also still like MFC extended with raw Win32 API
| calls).
|
| There are cross platform tools, but none of them are very
| good. If you want to make something really great, target the
| most important OS and make the absolute best thing you can
| with the native features of that OS. Follow the conventions
| of the platform and you get a lot of stuff (like
| accessibility features) for little effort.
|
| > The web is a single platform
|
| I agree. The web as presented by the browser is its own
| distinct platform. A well written web app will almost always
| use more battery, memory, CPU, and network bandwidth than a
| similar well written native app. Sometimes, despite all the
| problems with web technologies, the web is where something
| belongs.
|
| I'm still a big believer in the _personal_ computer. The web
| takes power from individuals and is a step back to the days
| of dumb terminals and centralized computing.
| jksmith wrote:
| Both Delphi and FreePascal (less so) support windows, linux,
| mac, android with the same codebase (or calls rather). The
| Delphi model has really set the standard for a robust desktop
| framework, since before most people started writing code.
| karaterobot wrote:
| There are lots of great desktop apps, sure. And, for a specific
| task (like text editing, or watching videos, or playing music)
| a desktop app is usually better than a web app. However, I
| expect the ecosystem of desktop apps required to replace every
| website I use would be worse than the web.
|
| What I mean is, different websites work differently, and do
| different things. For example, you might imagine a single
| desktop app that replaces multiple news aggregators, like
| Reddit or HN. It would ignore the style of both sites, and
| replace it with a single, uniform way of displaying posts and
| threads. But, what features from each does it implement? Does
| it have both upvoting and downvoting, like Reddit, or just
| upvoting, like HN? Does it support deeply nested threads, like
| Reddit, or only a couple levels, like HN? You'd run into
| limitations like this when trying to have a single app do
| everything, so you'd end up having to have _n_ applications,
| one for each website you were replacing...
|
| I'm also not with you on the "gnashing of teeth" point. I've
| never struggled to install, uninstall, or upgrade a website I
| was browsing.
| tacone wrote:
| I used to have my hand-written mini version of htmlx ten years
| ago. It took a few jquery lines of code to have small parts of
| the UX to update without refresh.
|
| I don't see the point by the way, I think htmlx is here to stay
| and a good choice for many, but it's clearly not a silver bullet.
| You make decently fast UIs, not blazing fasts, there are no
| (proper) offline first apps with htmlx, caching is likely more
| difficult or impossible sometimes and the load for your server is
| inevitably greater (of course it could be more than acceptable in
| some cases, so why not?), that also means more bandwidth for your
| cloud provider as opposed for you cdn. You will still have to
| write javascript sooner or later.
|
| It depends on what you're doing. Nothing is aprioristic ly "the
| future", the future is "the future", and it has yet to come.
| [deleted]
| peter_retief wrote:
| I like htmx but have decided to use unpoly, for my current
| project, which is similar.
|
| The concept is great but why has it taken so long?
|
| https://unpoly.com/
| bfung wrote:
| The article reminds me of the early 2000s when we were all
| rolling our own XMLHttpRequest and replacing dom elements with
| html rendered from a java servlet.
|
| The more realistic and practical read is
| https://htmx.org/essays/when-to-use-hypermedia/#hypermedia-n...
| dfabulich wrote:
| People were making this prediction ten years ago. It was wrong
| then, and it's wrong now.
|
| This article makes its case about Htmx, but points out that its
| argument applies equally to Hotwired (formerly Turbolinks). Both
| Htmx and Hotwired/Turbolinks use custom HTML attributes with just
| a little bit of client-side JS to allow client-side requests to
| replace fragments of a page with HTML generated on the server
| side.
|
| But Turbolinks is more than ten years old. React was born and
| rose to popularity during the age of Turbolinks. Turbolinks has
| already lost the war against React.
|
| The biggest problem with Turbolinks/Htmx is that there's no good
| story for what happens when one component in a tree needs to
| update another component in the tree. (Especially if it's a
| "second cousin" component, where your parent component's parent
| component has subcomponents you want to update.)
|
| EDIT: I know about multi-swap. https://htmx.org/extensions/multi-
| swap/ It's not good, because the onus is on the developer to
| compute which components to swap, _on the server side,_ but the
| state you need is usually on the client. If you need multi-swap,
| you 'll find it orders of magnitude easier to switch to a
| framework where the UI is a pure function of client-side state,
| like React or Svelte.
|
| Furthermore, in Turbolinks/Htmx, it's impossible to implement
| "optimistic UI," where the user creates a TODO item on the client
| side and posts the data back to the server in the background.
| This means that the user always has to wait for a server round
| trip to create a TODO item, hurting the user experience. It's
| unacceptable on mobile web in particular.
|
| When predicting the future, I always look to the State of JS
| survey https://2022.stateofjs.com/en-US/libraries/front-end-
| framewo... which asks participants which frameworks they've heard
| of, which ones they want to learn, which ones they're using, and,
| of the framework(s) they're using, whether they would use it
| again. This breaks down into Awareness, Usage, Interest, and
| Retention.
|
| React is looking great on Usage, and still pretty good on
| Retention. Solid and Svelte are the upstarts, with low usage but
| very high interest and retention. Htmx doesn't even hit the
| charts.
|
| The near future is React. The further future might be Svelte or
| Solid. The future is not Htmx.
| geenat wrote:
| > it's impossible to implement "optimistic UI," where the user
| creates a TODO item on the client side and posts the data back
| to the server in the background.
|
| Pretty common patterns for this- just use a sprinkle of client
| side JS (one of: hx-on, alpine, jquery, hyperscript, vanilla
| js, etc), then trigger an event for htmx to do its thing after
| awhile, or use the debounce feature if it's only a few seconds.
| Lots of options, actually.
|
| React would have to eventually contact the server as well if
| we're talking about an equivalent app.
| listenallyall wrote:
| Intentionally or not, this doesn't read like a cogent argument
| against the merits of HTMX (and isn't, since it is factually
| incorrect) but just as a person who is trying to convince
| him/herself that his/her professional skill set isn't starting
| to lose relevance.
|
| From the February 31, 1998 Hacker News archives: "According to
| state of the web survey, Yahoo and Altavista are looking great
| on usage, Hotbot and AskJeeves are the upstarts. Google doesn't
| even hit the charts."
| qgin wrote:
| It's interesting that this paradigm is especially popular on
| Hacker News. I see it pop up here pretty regularly and not many
| other places.
| antoniuschan99 wrote:
| lol HN itself seems like it should be the poster child of
| htmx :P. It's literally just text.
| antoniuschan99 wrote:
| But isn't React going this route as well? There was some talk a
| week or so back with the React team talking about this
| direction.
|
| Also, it seems so cyclic, isn't HTMX/Hotwire similar to Java
| JSP's which was how things were before SPA's got popular?
| deltarholamda wrote:
| I guess it depends on what your definition of "the future" is.
|
| If it's teams of 10X devs working around the world to make the
| next great Google-scale app, then yeah, maybe React or
| something like it is the future.
|
| If it's a bunch of individual devs making small things that can
| be tied together over the old-school Internet, then something
| like HTMX moves that vision forward, out of a 90-00s page-link,
| page-link, form-submit flow.
|
| Of course, the future will be a bit of both. For many of my
| various project ideas, something like React is serious
| overkill. Not even taking into account the steep learning curve
| and seemingly never-ending treadmill of keeping current.
| jbergens wrote:
| Of course there are some challenges and some use cases where
| Htmx is not the best solution but I think it can scale pretty
| far.
|
| You can split a large app into pages and then each page only
| has to care about its own parts (sub components). If you want
| some component to be used on multiple pages you just create it
| with the server technology you use and include it. The other
| components on the page can easily target it. You may have some
| problem if you change a shared component in such a way that
| targeting stops working. You may be able to share the targeting
| code to make this easier.
| yawaramin wrote:
| > there's no good story for what happens when one component in
| a tree needs to update another component in the tree.
|
| Huh, no one told me this before, so I've been very easily doing
| it with htmx's 'out of band swap' feature. If only I'd known
| before that it was impossible! ;-)
| wibblewobble124 wrote:
| we're using htmx at work, migrating away from react. the
| technique we're using is just rendering the whole page, e.g. we
| have a page where one side of the screen is a big form and the
| other side is a view on the same data but with a different UI,
| updating one updates the other. we're using the morphdom
| swapping mode so only the things that changed are updated in-
| place. as a colleague commented after implementing this page,
| it was pretty much like react as far as "pure function of
| state."
| recursivedoubts wrote:
| never tell me the odds, kid
|
| https://htmx.org/img/memes/whowillwin.png
| OliverM wrote:
| I've not used Htmx, but a cursory browse of their docs gives
| https://htmx.org/extensions/multi-swap/ which seems to solve
| exactly this problem. And thinking about it, what makes it as
| difficult as you say? If you've a js-library on the client you
| control you can definitely send payloads that library could
| interpret to replace multiple locations as needed. And if the
| client doesn't have js turned on the fallback to full-page
| responses solves the problem by default.
|
| Of course, I've not used Turbolinks, so I don't know what
| issues applied there.
|
| Edit: I'm not saying htmx is the future either. I'd love to see
| how they handle offline-first (if at all) or intermittent
| network connectivity. Currently most SPAs are bad at that
| too...
| dfabulich wrote:
| I've edited my post to clarify.
|
| Multi-swap is possible, but it's not good, because the onus
| is on the developer to compute which components to swap, _on
| the server side,_ but the state you need is usually on the
| client.
|
| If you need multi-swap, you'll find it orders of magnitude
| easier to switch to a framework where the UI is a pure
| function of client-side state, like React or Svelte.
| BeefySwain wrote:
| The people using HTMX have never heard of stateofjs.com (though
| they are painfully aware of the state of js!)
| jgoodhcg wrote:
| I've spent almost my entire career working on react based SPAs
| and react native mobile apps. I've just started playing around
| with HTMX.
|
| > no good story for what happens when one component in a tree
| needs to update another component in the tree
|
| HTMX has a decent answer to this. Any component can target
| replacement for any other component. So if the state of
| everything on the page changes then re-render the whole page,
| even if what the user clicked on is a button heavily nested.
|
| > it's impossible to implement "optimistic UI," ... hurting the
| user experience
|
| Do we actually need optimistic UI? Some apps need to work in
| offline mode sure, like offline maps or audiobooks or
| something. The HTMX author agrees, this is not the solution for
| that. Most of the stuff I have worked on though ... is useless
| without an internet connection.
|
| In the case of "useless without internet connection" do we
| really need optimistic UI. The actual experience of htmx is
| incredibly fast. There is no overhead of all the SPA stuff. No
| virtual dom, hardly any js. It's basically the speed of the
| network. In my limited practice I've actually felt the need to
| add delays because the update happens _too fast_.
|
| I'm still evaluating htmx but not for any of the reasons you've
| stated. My biggest concern is ... do I want my api to talk in
| html?
| recursivedoubts wrote:
| > do I want my api to talk in html
|
| https://htmx.org/essays/splitting-your-apis/
| jgoodhcg wrote:
| One great thing about your docs is the anticipation to
| concerns.
| koromak wrote:
| My app would crash and burn without optimistic UI. For simple
| CRUD applications sure, but most products these days aren't
| CRUD apps anymore.
| jonomacd wrote:
| You can make use of htmx-indicator to show that the request
| is ongoing. From my perspective you have to be careful
| here. If you are _too_ optimistic and imply a request has
| been successfully sent to the DB when it really hasn't then
| users are not going to like that as their requests
| disappear.
| dfabulich wrote:
| > _Do we actually need optimistic UI? Some apps need to work
| in offline mode sure, like offline maps or audiobooks or
| something. The HTMX author agrees, this is not the solution
| for that. Most of the stuff I have worked on though ... is
| useless without an internet connection._
|
| > _It 's basically the speed of the network._
|
| Does your stuff work on mobile web? Mobile web requests can
| easily take seconds, and on a dodgy connection, a single
| small request can often take 10+ seconds.
|
| The difference between optimistic UI and non-optimistic UI on
| mobile web is the difference between an app that takes
| seconds to respond, on every click, and one that responds
| instantly to user gestures.
| BeefySwain wrote:
| I want my stuff to work on mobile web. What I don't want is
| for stuff to look like it worked on mobile web, because the
| front end is "optimistic", but it actually didn't work. I
| find this to be a much worse user experience than having to
| wait for a round trip most of the time.
| listenallyall wrote:
| In the case of bad internet connection, "optimistic UI" is
| the worst solution. User thinks the data he entered has
| persisted, but in fact it has not. Big surprise months
| later when he realizes his boss's birthday reminder never
| got saved to his calendar.
| dfabulich wrote:
| The fix is to save data to client-side storage
| (IndexedDB) before attempting a network connection, and
| retries when connectivity is restored.
|
| Optimistic UI probably isn't necessary for a web site,
| but you'll certainly want it for a web app (which is what
| Htmx claims to be good for).
|
| In the real world on the mobile web we actually have,
| TODO apps (which is what TFA is about), calendars, notes
| apps, etc. all work better with client-side state
| synchronized to the server in the background.
|
| React has a bunch of good libraries for this, especially
| TanStack React Query.
|
| Htmx doesn't.
| mixmastamyk wrote:
| > a single small request can often take 10+ seconds.
|
| Hah! Good luck getting React even to start up in that
| environment. Meanwhile oldschool HN will still be snappy.
| Speaking from experience.
| klabb3 wrote:
| > Hugely increased complexity both in terms of architecture and
| developer experience. You have to spend considerable time
| learning about frameworks.
|
| You have to learn something. You can claim bloat in JS
| frameworks, but that isn't solved by simply moving it to the
| server.
|
| Is htmx lean and nice today? Probably! But does it handle the
| same use cases that the React users have? What happens to it
| under pressure of feature bloat? Small-core frameworks like Elm
| who resisted this pressure were abandoned by big shops. You can't
| just take something immature (however good) and simply
| extrapolate a happy future.
|
| > Tooling is an ever-shifting landscape in terms of building and
| packaging code.
|
| Yes. JS is not the only language with churn issues and dependency
| hell.
|
| > Managing state on both the client and server
|
| Correct me if I'm wrong, but state can change for something
| outside of a htmx request, meaning you can end up with stale
| state in element Y in the client after refreshing element X. The
| difference is that your local cache is in the DOM tree instead of
| a JS object.
|
| > By their nature, a fat client requires the client to execute a
| lot of JavaScript. If you have modern hardware, this is fine, but
| these applications will be unusable & slow for those on older
| hardware or in locations with slow and unreliable internet
| connections.
|
| On unreliable connections you want as thick of a client as
| possible. If you have server-in-the-loop for UI updates, you
| quite obviously have latency/retry issues. It's much preferable
| to show stale state immediately and update in the background.
|
| > It is very easy to make an SPA incorrectly, where you need to
| use the right approach with hooks to avoid ending up with abysmal
| client-side performance.
|
| Bloat comes from reckless software development practices, and are
| possible in any technology. Angular and React have a shitton of
| features and ecosystem around it, whereas say Svelte is more
| lean. Enterprisey shops tend to prioritize features and not give
| a flying fuck about performance. This is a business choice, not a
| statement about technology.
|
| > Some SPA implementations of SPA throw away progressive
| enhancement (a notable and noble exception is Remix). Therefore,
| you must have JavaScript turned on for most SPAs.
|
| Finally, we cut to the chase. This is 100% true, and we should be
| talking about this, because it's still not settled: do we want
| web pages or web apps? If both, where is the line? Can you expect
| something like Slack to work without JavaScript? What about a
| blog with interactive graphs? Should everything degrade or should
| some things require JS/WASM?
|
| I love that htmx exists. I have absolutely nothing against it. It
| honors some of the early web philosophy in an elegant and simple
| manner. It may be a better model for server-centric apps and
| pages, which don't need offline or snappy UIs. But it cannot
| magically solve the inherent complexities of many modern web
| apps.
| doodlesdev wrote:
| > Finally, we cut to the chase. This is 100% true, and we
| should be talking about this, because it's still not settled:
| do we want web pages or web apps? If both, where is the line?
| Can you expect something like Slack to work without JavaScript?
| What about a blog with interactive graphs? Should everything
| degrade or should some things require JS/WASM?
|
| BINGO. At times, it seems everyone is talking through each
| other because we are thinking of different things: static
| pages, dynamic websites, web apps, etc. all require different
| approaches to development. Honestly, what gets me real mad is
| when you need to run JavaScript to see a static page, I just
| can't stand it, one lovely example is the blog post we are
| talking about which displays awful without running JavaScript,
| this proves that indeed HTMX is not a panacea, and you can also
| "hold it wrong" (the blog post in question uses HTMX in the
| backend).
|
| Overall, I believe most applications do well with a graceful
| degradation approach similar to what Remix offers and then
| everyone copied (the idea of using form actions webforms-style
| for every interactivity, so it works with and without
| JavaScript). I do agree that things like Slack, Discord,
| Element, or otherwise things we would call web apps are
| acceptable to be purely SPAs or not gracefully degrade without
| it enabled, the biggest problem I have with these is that they
| exist as web clients in the first place: the world would be a
| different place if approaches such as wxWidgets has paid off
| and gotten adopted, imagine how many slow and bloated web apps
| could've been beautiful and fast native applications. One can
| dream. I'm not that pessimistic, not yet.
| jdthedisciple wrote:
| This puts all the computational load on the server.
|
| Imagine 10s of thousands of clients requesting millions of HTML
| fragments be put together by a single server maintaining all the
| states while all the powerful high end computing power at the end
| user's fingertips goes completely to waste.
|
| Not convinced.
| IshKebab wrote:
| Most users these days are probably using phones, not high end
| computers.
| jdthedisciple wrote:
| Most phones have more computing power than all of NASA did in
| the 80s.
|
| I was specifically thinking of modern smartphones in fact,
| which are pretty damn fast at executing a little bit of JS.
|
| (Though I agree that some of the bloated bundles resulting
| from modern frameworks or their poor usage definitely go to
| far)
| dhosek wrote:
| Most phones have an awful lot od computational power.
| mixmastamyk wrote:
| This avoids unnecessary computation at the client, it does not
| substantially add to the burden of the server. Which would need
| to be reconciled regardless of the markup format used over the
| pipe. Alpine is available for local flair.
| jdthedisciple wrote:
| I don't know but adapting UI to reflect the edit state of a
| todo seems like a classic client responsibility imho, not
| unnecessary.
|
| What's unnecessary to me however is sending bytes thousands
| of miles across the wire to some server to do the same.
| mtlynch wrote:
| I really want to switch over to htmx, as I've moved away from
| SPAs frameworks, and I've been much happier. SPAs have so much
| abstraction, and modern, vanilla JavaScript is pretty decent to
| work with.
|
| The thing that keeps holding me back from htmx is that it breaks
| Content Security Policy (CSP), which means you lose an effective
| protection against XSS.[0] When I last asked the maintainer about
| this, the response was that this was unlikely to ever change.[1]
|
| Alpine.js, a similar project to htmx, claims to have a CSP-
| compatible version,[2] but it's not actually available in any
| official builds.
|
| [0] https://htmx.org/docs/#security
|
| [1] https://news.ycombinator.com/item?id=32158352
|
| [2] https://alpinejs.dev/advanced/csp
|
| [3] https://github.com/alpinejs/alpine/issues/237
| jeremyjh wrote:
| Alpine is a lightweight client side framework, not really at
| all equivalent to htmx.
| mtlynch wrote:
| I'm not sure what you mean. htmx and alpine.js are both
| client-side frameworks. To me, they seem to have similar
| goals and similar functionality.
|
| What do you see as the difference?
| summarity wrote:
| They're neither different nor similar. In fact they work
| together, with Alpine managing client side reactive state
| (NOT app state, just interaction) and htmx managing the
| actual request model. That's why the htmx docs often refer
| to Alpine. They should be used in combination, not to
| displace each other.
| mtlynch wrote:
| Ah, gotcha. Thanks!
| jeremyjh wrote:
| The purpose of htmx is to enable the server to send
| fragments of markup to update the dom in response to UI
| events. Alpine.is is purely client side, you may not even
| have an application server.
| mtlynch wrote:
| Oh, I didn't realize that. Thanks!
| recursivedoubts wrote:
| htmx can work w/ a CSP, sans a few features (hx-on, event
| filters)
| mtlynch wrote:
| My understanding based on the docs[0] is that htmx works with
| CSP, but it also drastically weakens its protection, as
| attackers who successfully inject JS into htmx attributes
| gain code execution that CSP would have normally prevented.
|
| Am I misunderstanding? If I can use htmx without sacrificing
| the benefits of CSP, I'd really love to use htmx.
|
| [0] https://htmx.org/docs/#security
| infogulch wrote:
| I don't understand the concern. If your backend is
| sufficiently compromised to inject arbitrary js into sever
| responses then you've already lost, and I don't see how
| that's worse than serving a compromised App.js from the
| same server.
| mtlynch wrote:
| The attacker doesn't have to compromise the backend to
| achieve XSS.
|
| Suppose your website displays user-generated content
| (like HN posts). If the attacker finds a way to bypass
| encoding and instead injects JS, then without CSP, the
| attacker gets XSS at that point. With CSP, even if the
| attacker can get user-generated content to render as JS,
| the browser will refuse to execute it.
|
| My understanding of htmx is that the browser would still
| refuse to execute standard JS, but the attacker can
| achieve XSS by injecting htmx attributes that are
| effectively arbitrary JS.
| BeefySwain wrote:
| I keep seeing people talk about this, can someone create a
| minimum example of what this exploit would look like?
| robertoandred wrote:
| If you don't like abstraction, why would use something as
| abstracted and non-standard is htmx?
| mtlynch wrote:
| It's a tradeoff, and either extreme has problems.
|
| Too much abstraction (especially leaky abstraction the way
| web frameworks are) makes it difficult to reason about your
| application.
|
| But if you optimize for absolute minimal abstraction, then
| you can get stuck with code that's very repetitive where it's
| hard to pick apart the business logic from all the
| boilerplate.
| mikece wrote:
| "You can use whatever programming language you like to deliver
| HTML, just like we used to."
|
| Is this suggesting writing any language we want in the browser? I
| have wondered for a couple decades why Python or some other open
| source scripting language wasn't added to browsers. I know
| Microsoft supported VBScript as an alternative to JavaScript in
| Internet Explorer and had it not been a security nightmare
| (remember the web page that would format your hard drive,
| anyone?) and not a proprietary language it might have a rival to
| JavaScript in the browser. In those days it wouldn't have taken
| much to relegate JavaScript to non-use. Today we just get around
| it by compiling to WASM.
| loloquwowndueo wrote:
| It is not suggesting that. On the server, you can use your
| language of choice to generate complete or partial HTML
| responses to be sent and then put in the right places on the
| page by JavaScript (htmx) running on the browser.
| biorach wrote:
| > Is this suggesting writing any language we want in the
| browser?
|
| Nope, server
| traverseda wrote:
| It is not suggesting running arbitrary languages in the
| browser. It's basically Ajax.
| mikece wrote:
| I hope the execution is better than Ajax! They way that was
| implemented in WebForms was horrible and a complete PITA to
| debug.
| avisser wrote:
| Commenting on "It's basically Ajax": Yes, and it's also a
| return to the basics of a browser. Making HTTP calls
| (Hypertext Transfer Protocol) to get HTML (the aforementioned
| Hypertext) and rendering it is the core thing that browsers
| do. It's both necessary and sufficient to being a browser.
| joseph_grobbles wrote:
| [dead]
| honkycat wrote:
| Lol, we're still having the SPA discussion 7 years later in the
| year of our lord 2023?
|
| Talk about the positives of YOUR approach, don't tear down a
| different approach that half the industry is using. You're not
| going to say anything new or interesting to the person you are
| trying to convince this way. Experienced engineers already know
| the trade-offs between an SPA and a server rendered experience.
| lofaszvanitt wrote:
| .. in an alternate universe.
| fogzen wrote:
| _Server-side apps cannot provide optimistic UI._ No matter how
| you feel about it, they are limited in this capability compared
| to client-side apps. The user doesn't care about the technology.
| For example, imagine a todo app that shows a new todo
| immediately. Or form validations that happen as soon as data is
| entered. That's a superior experience to waiting on the server to
| continue interaction. Whether that's harder to engineer is
| irrelevant to the user. We should be striving for the best
| possible user experience, not what we as engineers personally
| find easy or comfortable.
|
| HTMX is cool. HTMX may fit your needs. But it's not enough for
| providing the best possible user experience.
| adamckay wrote:
| You don't have to be restricted to just using htmx, you can use
| it with client side Javascript to give you that interactivity
| you need in the places you need it.
|
| Indeed, the creator of htmx has created another library called
| hyperscript which he's described as a companion to htmx.
|
| https://hyperscript.org/
| keb_ wrote:
| Does anyone have an example Hacker News client written in HTMX?
| teaearlgraycold wrote:
| I'd rather see either:
|
| * NextJS provide a holistic solution to backend code. Right now
| it's missing an ORM that works with serverless postgres. Given
| their recent additions of serverless postgres to Vercel I expect
| this will happen in 6-12 months.
|
| * RedwoodJS become more mature.
|
| The issues with SPAs IMO come from having to cobble together your
| full stack app, which requires making a ton of hard decisions in
| predicting the future of each major library you use. And then
| there's limited coherence between your ORM, API, and client
| without extra work. A mature, well designed, and financially
| supported full stack JS solution that truly rivals Rails would be
| perfect.
| majormajor wrote:
| > HTMX allows you to design pages that fetch fragments of HTML
| from your server to update the user's page as needed without the
| annoying full-page load refresh.
|
| I've been on the sidelines for the better part of a decade for
| frontend stuff, but I was full-stack at a tiny startup in 2012ish
| that used Rails with partial fragments templates for this. It
| needed some more custom JS than having a "replacement target"
| annotation everywhere, but it was pretty straightforward, and
| provided shared rendering for the initial page load and these
| updates.
|
| So, question to those who have been active in the frontend world
| since then: that obviously failed to win the market compared to
| JS-first/client-first approaches (Backbone was the alternative we
| were playing with back then). Has something shifted now that this
| is a significantly more appealing mode?
|
| IIRC, one of the big downsides of that "partial" approach in
| comparison with SPA-approaches was that we had to still write
| those JSON-or-XML-returning versions of the endpoints as mobile
| clients became more prevalent. That seems like it would still be
| an issue here too.
| dpistole wrote:
| From a front end perspective I think the selling points I see
| pitched for these new server side frameworks are "SEO" and
| "speed".
|
| SEO I personally think is a questionable motivation except in
| very specific use cases.
|
| Speed is almost compelling but the complexity cost and all the
| considerations around how a page is structured (which
| components are server, which are client, etc) does not seem
| worth the complexity cost IMO. Just pop a loading animation up
| in most cases IMO.
|
| I think I'm stuck somewhere in the middle between old-hacker-
| news-person yelling "lol were just back at index.html" and
| freshly-minted-youtube-devs going "this is definitely the new
| standard".
| efields wrote:
| FE dev/manager here. I'll tackle this one out of order.
|
| > one of the big downsides of that "partial" approach in
| comparison with SPA-approaches was that we had to still write
| those JSON-or-XML-returning versions of the endpoints as mobile
| clients became more prevalent. That seems like it would still
| be an issue here too.
|
| Yup. Still, if you're at the scale where you need to support
| multiple clients, things should be going well enough where you
| can afford the extra work.
|
| As soon as multiple clients are involved, you're writing
| SOMETHING to support specifically that client. 10+ years ago,
| you'd be writing those extra conditionals to return JSON/XML
| _and_ someone is building out this non-browser client (mobile
| app, third party API, whatever). But you're not rearchitecting
| your browser experience so that's the tradeoff.
|
| > Has something shifted now that this is a significantly more
| appealing mode?
|
| React especially led from one promise to another about _how
| much less code_ you'd have to write to support a wide range of
| clients, when in reality there was always another
| configuration, another _something_ to maintain when new clients
| were introduced. On top of that, the mobile device libraries
| (React Native, etc), were always steps behind what a true
| native app UX felt like.
|
| I think a lot of us seasoned developers just feel burned by the
| SPA era. Because of how fast it is to iterate in js, places
| like npm would seemingly have just the right component needed
| to avoid having to build custom in-house, and its simply an
| `npm add` and an import away. Meanwhile, as the author states,
| React and company changed a lot under the hood rapidly, so
| dependencies would quickly become out of date, now trying to
| maintain a project full of decaying 3rd party libs because its
| own tech debt nightmare. Just for, say, popper.js or something
| like that.
|
| I'm just glad the community seems to actively be reconsidering
| "the old ways" as something valuable worth revisiting after
| learning what we learned in the last decade.
| steve76 wrote:
| [dead]
| tgbugs wrote:
| I first encountered the principles behind htmx in its precursor
| intercooler.js. Those principles really resonated with my
| distaste for complexity. Amusingly I found out about htmx itself
| when rereading https://grugbrain.dev and it all clicked! htmx is
| crystal that trap internet complexity demon!
| fredrikholm wrote:
| Irony that they're all made by the same person!
| denton-scratch wrote:
| How's it not a SPA, if you're updating the DOM in JS without a
| full page reload?
|
| Sorry, I read a load of stuff about React, before I came to any
| explanation of HTMX. Turns out, it's loading fragments of HTML
| into the DOM (without reload), instead of loading fragments of
| JSON, converting them to HTML fragments client-side, and
| injecting the resulting HTML into the DOM (without reload).
|
| So I stopped reading there; perhaps the author explained why HTMX
| solves this at the end (consistent with the general upside-down-
| ness), but the "is the future" title was also offputting, so
| excuse me if I should have read the whole article before
| commenting.
|
| I never bought into the SPA thing. SPAs destroy the relationship
| between URLs and the World Wide Web.
| robertoandred wrote:
| SPAs work with complex, relevant, and unique URLs perfectly
| fine.
| unixhero wrote:
| As long as I don't have to learn it.
| can16358p wrote:
| I think "the future" definitely isn't some non-standard custom
| attributes.
___________________________________________________________________
(page generated 2023-05-05 23:00 UTC)