13 ms·
Htmx, Rust and Shuttle: A New Rapid Prototyping Stack
- ge96 3y agoAt some point I wonder when is progress enough. Comparing htmx (modifiers in html, lot of abstraction) vs remix (front/backend in same file) and then the readability of rust (lot of chaining/calls and "decorators" eg. tokio). It just works but if you get used to that syntax/rely on abstraction. I'll learn what's hot to be employed but yeah. I've been happy with just ReactJS/Express.
- worthless-trash 3y ago> At some point I wonder when is progress enough. Its never enough, progress continually marches forward. If we accepted no progress we'd still be running fortran/cobol and other old tooling.
- ge96 3y agoRight and computers wouldn't advance more/be capable of cool things like VR. Seems like one day you'll just say "import website" and it's done which for me isn't fun but does get the job done. Keep up with the change or get left behind. At my job they outsourced the html/css writing so we just glue stuff together, it' s depressing.
- stmblast 3y agoIf your company outsources the HTML/CSS, then presumably the people who are working at the company are working on the backend services and none of the frontend at all?
- ge96 3y agoHaha ownership is trying to replace people with AI. Gave a presentation on chatGPT... content writer/SEO people sweating. It's just funny/ironic the infighting in my viewpoint, they don't trust us to make high quality front end code so they pay another company to do it and then we have to templatize/glue it back together. Oh well... sucks to suck move to another company. edit: response to below, the html/css stuff they did outsource to other humans, I'm saying it's a joke because that's our job as frontend devs
- stmblast 3y agoThat's even worse than I thought. I was thinking maybe they'd at least outsource it to other humans.
- vlunkr 3y agoSure, but is it really progress to swap our tooling around every couple of years? Do you know what users think about the progression of spaghetti js, to jquery, to backbone, to angular, to ember, to react, to svelte, to htmx? They don't think about it. It literally does not matter to them except that your site may have better (or worse) performance and fewer (or more) bugs.
- Capricorn2481 3y agoThat the frontend community is a monolith marching towards the same area is a weird HN old wives tale. Most people are still using React and Jquery
- mg 3y agoI wonder what to think of htmx. Their primary example is this: <button hx-post="/clicked" hx-swap="outerHTML"> Click Me </button> But that is rarely what I want to do when a button is clicked. My typical example would be I have list of - say - cars, and each car provides a button to delete it: <button onclick="carList.deleteItem(this)"> Delete this car </button> And then in deleteItem(), I typically: let item=getItem(e); if (!confirm(`Really delete ${item['name']}?`)) return; let item_id=getItemId(e); items.splice(item_id,1); document.getElementById('items').innerHTML = template(items); Where "template" is a handlebars template. Would htmx have anything to say about this?
- kitd 3y agoHere's Htmx's "Delete a row" example, which I think is what you're after: https://htmx.org/examples/delete-row/ https://htmx.org/examples/delete-row/ The Examples page in general shows most typical use cases.
- monknomo 3y agoI think where htmx would differ in your example is that it would not maintain the state of the list of cars in javascript, but would instead keep that state in the html, and the server. I think the button might be something like this, I'm borrowing from their [delete row example](https://htmx.org/examples/delete-row/ https://htmx.org/examples/delete-row/). `<button hx-confirm="Really delete {{item.name}}?" hx-target="closest tr" hx-swap="outerHTML swap:1s" hx-delete="<the url>">Delete this car</button>` In terms of your update example, yeah I think that's what htmx would do, just on the server, and returning rendered html.
- budafish 3y agoAlso if you didn't want to do a hx-confirm, you could pop up a separate modal on button press. And then when the delete is pressed in the modal use a hx-target to update the specific row.
- mg 3y agoHmm.. I don't think you can simplify their example to just that one line. For example, where is the url which is supposed to be requested to delete the item on the server.
- lakomen 3y agoHow to you solve humanized time with htmx? Humanized time means, now, a second ago, 3 hours ago etc. When you create let's say a post and it's returned the rendered humanized time, every post you create will return "now" as its time. And next how to you keep track of the humanized time client side. Riddle me this and I'll start believing in htmx
- naasking 3y agoThe server is aware of the client's local time.
- danpalmer 3y agoWhy does this need doing? Pages aren't kept open for that long, especially not when using HTMX and page loads happen more often. Saying "now" for the post you've just submitted isn't that useful, but neither is saying "1 minute ago" when you leave the page open for 1 minute. Humanisation of date times is easy to do server side, so the next time you render the page it will have newly correct timestamps. The vagueness of humanised times also reduces the need to update as they can be quite out of date and still look up to date.
- uallo 3y agoWeb Components, e.g. https://github.com/github/relative-time-element https://github.com/github/relative-time-element
- jakswa 3y agoCame to upvote this. I think that github component in particular worked really well for me on a recent experiment. Server-rendered HTML can use custom components in our fancy world today! It's a feel-good place to be compared to just a decade ago imo.
- danpalmer 3y agoHTMX is great for rapid prototyping, but Rust has never struck me as suitable for rapid prototyping. There are some nice abstractions here than reduce the amount of code for sure, but that's only one aspect of rapid prototyping. Rust still has a high learning curve, compiles relatively slowly, and still takes a lot more code to achieve things than the equivalent Python or even JavaScript/TypeScript. Shuttle looks pretty cool as a platform, but it seems that it has decided that because Rust is a good language for a platform (makes sense!) that it must be good for usage on the platform. I really don't think I agree with this. In my experience, Django + Heroku (or the Heroku competitor du jour) is a convincing rapid prototyping setup for larger sites. And things like RunKit or Glitch are a convincing setup for smaller builds. I'm not sure whether Shuttle adds anything over these options unless the requirement is to use Rust.
- civilitty 3y ago> HTMX is great for rapid prototyping, but Rust has never struck me as suitable for rapid prototyping. There are some nice abstractions here than reduce the amount of code for sure, but that's only one aspect of rapid prototyping. Rust still has a high learning curve, compiles relatively slowly, and still takes a lot more code to achieve things than the equivalent Python or even JavaScript/TypeScript. In order to support the borrow checker, Rust has a richer type system that allows programmers to encode far more of the business domain than most other languages. Short of logic bugs, the vast majority of my Rust code is in the "if it compiles, it works" bucket which makes it great for rapid prototyping despite the slow compile times. I have to spend a lot less time and mental bandwidth on testing and defensive coding and Rust's version of the public/private distinction o makes it great for wrapping the data model behind types that can only be used correctly - like making sure a user id can only come from a User model type instantiated by the database code and not an arbitrary integer. My favorite part though is that web frameworks like Rocket make it really easy to manage all of the magic going on behind the scenes using trait definitions, in contrast to mega-frameworks like Django. (Rocket was created by the Flask author iirc)
- stmblast 3y agoThe first framework I used was Rocket! I'm sad that the development pace for it has slowed down extremely significantly though.
- brundolf 3y ago> The runtime will then do static code analysis to figure out what needs provisioning and will then spin up the relevant infrastructure required - for example, if you need a Postgres instance, you can just declare it in your fn main arguments, use cargo shuttle run to run locally and then it'll spin up a container for you using Docker without any further input on your part! I've never heard of Shuttle before, that is wild. Maybe I'll play with it soon
- fulafel 3y agoAlso interesting that they combine this with app logic in Rust, this way they can compensate for the more difficult language. Infra-as-code part is half the job (and requiring separate domain expertise) for lots of apps so it's no small thing. I guess the catch is that you have to use their cloud platform.
- ctvo 3y agoIt's so gross: ... <tag hx-target="closest tr" hx-swap="outerHTML swap:1s" /> ... <button onclick="htmx.trigger('#request-button', 'htmx:abort')"> Cancel Request </button> ... If you don't want state management at the UI layer, totally understandable, move it to your server. You don't need a new framework with some whacky untyped DSL to do it. The swings in the front-end community move from one extreme to another so violently.
- deleted 3y ago[deleted]
- Xeamek 3y agoYou literally do though, if you want to keep user experience on par. What alternative are you implying?
- ctvo 3y ago> You literally do though, if you want to keep user experience on par. On par with what? Use any of your existing UI frameworks and instead of keeping state client side, let the server tell you. Instead of doing things like eagerly updating client side state (deleting an item -> removing it from your in-memory array), let the server tell you after it's processed and updated its state. Dumbly reflect what the server returns. I understand this isn't what the tutorials for React, for example, show and breaks away from all the auxiliary things they've been using with it for state management, but there's nothing stopping you from doing this. You can do all of these things today. You don't need to adopt this. You don't need to move to server side templating and downloading chunks of HTML to inject into elements.
- naasking 3y agoYou'd end up partly reinventing htmlx to reduce network traffic, just badly. htmlx literally is just dumbly reflecting what the server returns.
- Xeamek 3y ago>Instead of doing things like eagerly updating client side state (deleting an item -> removing it from your in-memory array), let the server tell you after it's processed and updated its state. So this literally what htmx does, no? Except You'd be operating on framework-sourced components rather then built in html structures. And the swapping itself would be performed by frameworks code rather then htmx library. Is that what you mean? If so then sure, I get that it would be cleaner then with htmx, but logic is the same and htmx simply let's you expand this logic for core html elements, rather then having to remake all of them into frameworks components that can handle the partial updating.
- TobyTheDog123 3y agoHTMX/Rust seem like great choices for making good architectural decisions, having long-term scalability, and having great performance, but certainly not for rapid prototyping. If I'm validating a business idea / building a proof of concept, I'm using something like SvelteKit or even NextJS. Going the middle-of-the-road seems to me like either a waste of resources or a waste of time depending on your goals.
- mcpar-land 3y agoHaving worked on a home-tooled stack similar to this with Rust and HTMX, I think HTMX suffers from the same issue as Tailwind where it's a huge step in the right direction, but just adding your functionality as strings in HTML loses you all the hard-fought type safety of the clientside-js-heavy solutions they are trying to replace. Locality of behavior is a great trend but it's going through tooling growing pains. I think in a few years we'll get versions of these tools that aren't just strings inside HTML props.
- felipellrocha 3y agoSo... Hsh?
- ageofwant 3y agoRust is many things, "rapid development" is not one of those things.
- rwaksmunski 3y agoRust can be pretty rapid if you unwrap() and clone() everything. You are building a prototype after all. Adding error handling, traits and modules can be done later if the project has merit.
- preommr 3y agoI love Rust. But I don't recommend Rust for this kind of stack - only because Rust's ecosystem is not that stable. I swear rust has some of the fastest iteration, with sometimes really complicated setups out of any mainstream language. There's always some nightly build, some feature flag, some cargo setup that often gets in the way. Just consider that Axum here is only two years old. Built on top of and heavily tied with tokio, which is really popular, but no guarantees as the defacto solution moving forward. I'd say anything else ts, python, sigh even golang would be better alternatives.
- stmblast 3y agoHere's to hoping Rust's ecosystem becomes more stable in the future! I'm very much looking forward to things like generators/coroutines (or whatever they're called now) once they're made stable as well as async traits and whatever makes the Pavex framework able to be used on stable Rust.
- pie_flavor 3y agoFull-time rust developer here. We have never experienced instability of any form outside of what instructions the WASM target supports; statements like this tend to conflate 'what's shiny and new' with 'what works'. Code written yesterday will work tomorrow, and that's all that matters; pick the most popular thing by download count and stick with it and you will have zero problems. Nightly unstable features are best worked around by not using them, and everything else related to 'cargo setups' are caused by not reading the instructions carefully enough. Funny that you then compare to typescript i.e. npm, which is infamous for actually having this problem.
- LispSporks22 3y agoI’d reach for Rails, Django or Laravel for rapid prototyping. They all have super fast edit test loops. Rust would be an awful choice for this.
- hankchinaski 3y agoRust rapid prototyping? It’s an hallucination
- zcmack 3y agothis seems like great for rapid prototyping for those that are already well-versed in rust and really really hate javascript.
- exabrial 3y agoHTMX is a massive relief from the client side Javascript mess. "Modern" Javascript frameworks are just terrible for so reasons. If Rust gets a Dependency Injection framework (like CDI) and a Mocking framework (like Mockito), I'm 100% in.
- stmblast 3y agoDefinitely! I remember my first thoughts when moving from Next.js 13 to using a HTML templating engine were "wow, this is much simpler" and "should've done this sooner". It's saved me quite a lot of time in terms of not having to think about props/SSR
- jbjohns 3y agoWhy would Rust need a Dependency Injection framework? It's functional, no? I really hope drifting OO practitioners don't wreck the language putting a bunch of OO stuff that is better done in functional programming.
- pie_flavor 3y agoIt is imperative/procedural, and programming paradigm has nothing to do with DI, which is about automatic generation of certain function parameters.
- jbjohns 3y agoIt's not automatically generated though, it's just specified somewhere else. This is what makes OO projects so hard to read from the outside: you first need to figure out what thing is having an effect on what. In a proper functional style I can go to main and follow everything from there. As someone else said, if you have some kind of interface to "mock" you can just make this a parameter to a function and pass in the "mock" versions for tests and the regular one for the real program (or select from a set of them based on some parameter or something). A framework would just mean I can't just read from main, I'll have to figure out which DI framework is being used, where that is configured and what things effect its decision making. I see why we ended up doing this in OO but I really don't see the benefit anymore in functional programming with the more direct (and no less flexible) approach.
- gregors 3y agoOf all the great things rust is top notch at .....rapid prototyping just isn't one of them. In fact just about any other stack is better at that. Elixir, Ruby, JS, Python all blow it away for rapid prototyping. Just my experience.