7 ms·
The Aha Stack
- Alifatisk 3y agoI love that we all agreed on leaving this heavily bloated website / webapp architecture
- eek2121 3y agoI like where the Rails team is going with Rails. No JS bloat at all, just simple and clean JS. No compilation step or anything.
- lghh 3y agoThere are benefits to a compilation (transpilation?) step that are worthwhile. Most notably, types/typescript. Everyone's bar for what is bloat is a bit different. Everyone's definition of simple and clean is different. Typescript, even with a compilation step, is simple and clean to me. Javascript without types is the opposite of simple. Javascript without types is the opposite of clean.
- paranoidxprod 3y agoI've been using JSDoc with tsserver and its been working great for development. Types from typescript are removed at compile time, so they just help with the dx around JS, but I've been noticing similar benefits just using JSDoc.
- j45 3y agodynamically rewriting JavaScript into not JavaScript as it evolves into a full programming language is an overhead that has its pros and cons. A build system for a simple hello world page is the example I can’t often wipe from my mind. Reactivity in web apps has been great but around for 20 years already from its roots in Ajax.
- riffic 3y agoit's all Lindy and not going anywhere anytime soon https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect
- stuff4ben 3y agoSweet! So my J2EE and SOAP skills will become relevant again?
- weinzierl 3y agoI'm all for getting rid of JavaScript, but I don't really see what sending HTML over the wire instead of JSON gets us?
- andsoitis 3y ago> but I don't really see what sending HTML over the wire instead of JSON gets us? HTML you can render as-is. JSON needs additional processing logic client-side.
- weinzierl 3y agoSure, but with HTML all I can do is render it. With a well designed JSON API I can wrangle and mangle it and use the same data in many places or different apps even.
- marcosdumay 3y agoYou can wrangle and mangle the original data much better than whatever JSON you decided to send. And you can make different apps with your database too.
- andsoitis 3y agoYep. In some cases it might be better to keep a local representation of the data and have different view and business logic all on the client to create a presentation & interaction experience for the user. Other times, centralizing it on the server might be best. Some apps lend themselves much more to doing a lot of interesting work on the client (Figma is an example, going so far as to implementing their own rendering engine, for instance).
- the_gastropod 3y agoHere's a pretty good essay by Max Chernyak on why using a generic JSON api to power your application's front end is a bad idea. https://max.engineer/server-informed-ui https://max.engineer/server-informed-ui tl;dr: Your JSON api has to figure out: - How to predict and enable all possible workflows - How to avoid N+1 requests for awkward workflows - How to test functionality, performance, and security of every possible request - How to change the API without breaking the existing workflows - How to prioritize API changes between internal and community requirements - How to document everything so that all parties can get stuff done And on then on the front-end, you have to figure out: - How to collect all the data needed to render a page - How to optimize requests to multiple endpoints - How to avoid using API data fields in unintended ways - How to weigh the benefit of new features against the cost of new API requests He goes on to point out that the "re-use" value of an api endpoint is extremely low. You can re-use virtually all the code that produced that endpoint to produce a different one with a different structure for precisely what you need in this new use-case.
- gmaster1440 3y agoIn a similar vein, I cannot recommend SvelteKit enough, which features some of the most consequential performance improvements[1] built right into the framework. [1] https://kit.svelte.dev/docs/performance https://kit.svelte.dev/docs/performance
- mattgreenrocks 3y agoSvelteKit actually lets me enjoy writing webapps. I haven't played with Astro much, it looks quite sane, but oriented more towards content-heavy sites vs webapps.
- rchaud 3y agoThis seems like more of an ad for building with HTMX than anything else. Everything they're describing is true of any server-side rendered app that doesnt need a build step. I use HTMX for my PHP app and it's great, I can drop a folder into a webserver and voila it's live!
- andrewmutz 3y agoYeah the part of the website devoted to Astro says as much: https://ahastack.dev/aha/2-astro/ https://ahastack.dev/aha/2-astro/ > If you know another classic Web Application server like Rails, Django, Laravel, or like building your own in Go or whatever, you can use anything you want.
- azemetre 3y agoThe owner of the site should change the acronym to alpine, htmx, and anything. Then stress the anything part.
- shove 3y agoRound and round and round she goes…
- endlessvoid94 3y agoI wish someone would write up a comparison of Turbo/Stimulus and HTMX/Alpine. The approaches seem extremely (spiritually) similar, yet seem to ignore each other.
- jack_riminton 3y agoI understand (kinda) why SPAs came about. My question is; what incentive do companies have to revert to the more sane and simple technologies of htmx, hotwire etc? I'm a rails dev and I love the framework but there's a realist in me that sees something akin to the phrase "markets can stay irrational for longer than you can stay solvent"
- j45 3y agoWhen technology decisions are too often made on signalling trendiness and shiny object syndrome, all organizations will eventually evolve out of this. Simple technologies leave innovation points to be spent in the problem and user instead of experimenting with new tech that is usually a rewrite of something else that’s already similar, except without the hardening and maturation
- candiddevmike 3y agoWhat's sane about swapping type safe, offline capable frontend code for spaghetti htmx/hotwire code?
- clivestaples 3y agoIn the case of Rails, I lose type safety but also get a huge boost of productivity in other with extremely well-documented features: database migrations, testing, mailers, queues/jobs, file storage, rich text, authentication helpers (especially v7), etc. Re: spaghetti: I'm not sure my Rails setup is less neat and tidy than the React, Redux, Saga, GraphQL Typescript codebase of my 9-5 TBH. Could be just me though. EDIT: typo
- jack_riminton 3y agoI've yet to be given a single example of how Rails suffers without types, it's just not an issue Hotwire is the polar opposite of spaghetti code
- boredtofears 3y agoRails does better than the rest of the Ruby ecosystem without types because it has strong conventions, but if you’ve ever adopted a rails app that doesn’t follow these conventions (or follows different ones like in the 3.x days where they were less defined) refactoring things across an entire codebase can be a gargantuan task. Following variable life cycles in Ruby in general is much harder than a typed language. There are tools like pry for this sort of thing, but that’s more work than just having types with good ide integration.
- klysm 3y agoI don't understand why all the arguments around frontend stacks on the web are treated with such dogma - it's a tradeoff space! You can send JSON, HTML, or whatever, but it depends on _what you are building_. The decision about what tools to use is nuanced, and difficult, and most importantly vastly depends on the context of what you are trying to accomplish.
- endisneigh 3y agoThere really is no incentive. I remember intercoolerjs a long while ago. People love arguing over nothing instead of picking a stack and shipping.
- hnrodey 3y ago>People love arguing over nothing instead of picking a stack and shipping. The most valuable code is the code that runs in production.
- blowski 3y agoThat’s an oft-quoted aphorism, but it’s not always true. Sometimes, the piece of crap you’ve just deployed becomes somebody else’s support and maintenance nightmare. With a bit more care, it could be avoided. Other times, the piece of crap was just what was needed, nothing more. It’s important to think about the right solution, and it’s also important to know when and why you’re putting something into production. Golden mean and all that.
- klysm 3y agoThat’s one way to deal with the trade off space - pick one and send it. Sometimes it even makes sense due to other constraints: the best technology for the task may not be the best technology to choose! If you can shoehorn something you have experience with then it might be worth it.
- lordgroff 3y agoYep. I have a Woocommerce site that's mostly modified by my own custom plugins. Most of my own custom work plugs in to the old school PHP server side rendering and that works just fine. I also have what's in effect two separate SPAs in the backend. Doing these in htmx and Alpine or whatever would be an absolutely enormous headache and it would perform worse. There's no one size fits all.
- endisneigh 3y agoJSON is superior imo, works with multiple clients, but if you insist on server side rendering why not use your servers built in method, e.g. Django templates? A well made SPA can work offline and doesn’t have most of the typical disadvantages with respect to routing and redirects. That being said, people should obviously use what they prefer. It’s interesting how these things have become a sort of holy war.
- alabhyajindal 3y agoI no longer have the patience to read through the praises of another frontend framework. I started web development just 2 years ago using React and at the time I didn't know any of the traditional frameworks like Rails, Django or Laravel. I learned Rails recently and have been using it for my side projects since. I'm having a great experience! When I see the headlines praising a frontend framework that's been around for < 5 years, I roll my eyes. I imagine it's been written by someone like me 2 years ago, who hasn't used traditional frameworks.
- WD-42 3y agoInteresting that you went from React to Rails, usually people go the other direction. It's neat seeing the good 'ol server side frameworks being "rediscovered".
- hipadev23 3y ago> usually people go the other direction I'm not sure that's true. Time has went that direction, for sure, but I don't think historical backend web devs have migrated to react. Mostly front-end devs expanding their horizons and younger devs starting there.
- WD-42 3y ago> but I don't think historical backend web devs have migrated to react. Really? Back in the day, myself and my peers weren't "backend web devs" we were just web devs. Stuff started shifting to the frontend and we all learned Backbone, Angular, React, etc because that's the way the industry went. I think a LOT of us migrated to React, maybe not completely, but who can call themselves a web developer these days without at least some experience with FE frameworks?
- hipadev23 3y agoGuess it depends on your role yeah. I'm familiar with React etc but I only use it when required, it's all so clumsy, constantly changing, and their best new ideas have existed in the ruby/python/php communities for decades. I still really limit my JS to just improving the client-side UI/UX.
- jkmcf 3y agoNote, this is not the stack used by https://aha.io https://aha.io
- endigma 3y agoAlternatively, the S stack: SvelteKit. I don't understand why you would use a pairing of different tools in this space when Svelte/Kit solves all these problems with one framework. This could also be said for NextJS/Nuxt/etc but SvelteKit is particularly well integrated.
- flufluflufluffy 3y agoah yes, that time of year when people reinvent the LAMP stack again
- jensenbox 3y agoI want the DHA stack - Django in place of Astro.
- mortallywounded 3y agoThere's a glaring issue with HTMX and I'm not sure how it can be resolved gracefully. Other related libraries solved this issue already (Turbo and Turbolinks). However, HTMX only returns HTML fragments and doesn't track head changes. It's not easy to explain.. but imagine if a user loads your webpage. Then the web page loads your assets are loaded (JS, CSS, etc). Then imagine a new deployment happens that introduces new styles and/or HTML for a given resource. The page that is loaded in the user's browser does not have the new styles and doesn't know they were updated. If the user interacts with the resource the page styles will break. This was fixed in Turbo and Turbolinks by introducing "data-turbo-track="true"" to a resource like a CSS sheet. When the server responds with a fresh page the head can be compared and a full reload can happen if the asset was updated. In HTMX, the page is just broken. edit: Currently, you would have to manually hack around this... like long polling for the current app version or returning it in every XHR request and adding a middleware to HTMX to do the check and pop up a "your page is out of date..." message.
- naasking 3y agoNot sure I get it. Non-immutable resources should be bundled as a URL that's a hash of the contents. Since htmx replies include updates to head, if the content changes then the URL changes, and head updates would update the URLs. Where's the issue? I can see you getting into a pickle if you don't bundle mutable resources, but that's why you should.
- recursivedoubts 3y agoit's true that htmx is mainly focused on partial HTML replacement and we usually recommend that people load javascript and CSS up up front and/or adopt inline scripting solutions for locality of behavior[1], but htmx also has a head-support extension: https://htmx.org/extensions/head-support/ https://htmx.org/extensions/head-support/ for htmx 2.0 i'm integrating this functionality into the core, it seems useful enough to be there. The extension is based on the head morphing algorithm of idiomorph: https://github.com/bigskysoftware/idiomorph/ https://github.com/bigskysoftware/idiomorph/ which 37Signals is going to integrate into Turbo for v8: https://twitter.com/ben_pylo/status/1717975035669876790 https://twitter.com/ben_pylo/status/1717975035669876790 [1] - https://htmx.org/essays/locality-of-behaviour/ https://htmx.org/essays/locality-of-behaviour/