（评论）

（评论）
(comments)

原始链接: https://news.ycombinator.com/item?id=40709769

一个团队考虑向 HTML 添加 TreeView 组件以改善开发人员体验和效率，但由于潜在的实施时间和财务影响而面临反对。相反，他们专注于使用 Rust 语言和相关工具增强现有的 Web 应用程序，例如用于 Web 应用程序的 axum、用于交互的 axum-htmx、用于数据库访问的 rusqlite 以及用于 HTML 模板的 Maud。他们利用 htmx 通过 HTTP 请求动态加载组件，从而提高性能和用户交互性，而无需对前端代码进行重大更改。他们更喜欢 Maud，而不是流行的替代方案，因为它易于编写标记和测试功能，为各个页面部分维护单独的模板，并根据请求处理端点以服务这些部分。端点 URL 遵循域/页面/部分格式，确保正确路由，同时返回带有更新数据的渲染模板。最终，他们的重点仍然是 Rust 后端和高效的资源利用，而不是在 Web 标准中纳入额外的树视图功能。

One of the happiest days of coding in the last 10 years for me happened in September last year when I added htmx to an internal self serve web app I develop for our company. With the addition of maybe 5 htmx attributes I was able to delete about 500 lines of client side JS.

The app is now chock full of htmx interactions and has very little client side JS for the size of the app and it’s a joy to work on.

Without htmx I would not be able to turn around features as quickly as I do for the wider team so thank you, thank you, thank you.

I’ve been in web dev for 20 years and this feels like what we should have made all along.

The one area I would like to see some development is the file upload experience, I’ve had to do something a bit weird to get htmx and dropzone playing nice.

It was all normal JS code to handle a complicated form we have on a customer facing portal page. By moving to htmx I was able to rely on the server side to handle basically everything with only a small addition of code to what it was already doing.

I'm qurious what that code was doing that could be just moved to the backend. Usually forms have some validation for a better experience with the final validation on the server. Did you get rid of that and just show an error if the submission failed?

As someone that has long since soured on frontend things despite having tried everything from the start - mootools, jQuery, backbone.js, SproutCore, Ember, React, Vue, etc.

I genuinely think htmx is the only one I have liked even after I built something substantial in it.

To me that is big, to be able to walk away from a significant amount of time with something and say "yeah! I want to use that again!" instead of some variant of "it's the least bad option" is both rare and cherished so thanks for all the hard work.

Not a question, but I just wanted to say that HTMX is a joy to work. I’m using it in production to slowly replace VueJS wherever full SPA interactions aren’t needed, and it has made development so much simpler. HTMX is such a breath of fresh air from the over-engineered jenga tower that web dev has evolved into over the past decade.

Thank you!

Are there any efforts to push functionality like this into the HTML standard? It would be nice if htmx eventually became unnecessary as browsers implemented it, and the work you're doing with proving it out in the wild seems like a crucial part of that.

I don't have contacts in those groups, but chrome is in contact w/them and has pushed forward hypermedia-friendly features e.g. https://developer.mozilla.org/en-US/docs/Web/API/View_Transi...

i have told my chrome team contacts about bugs in other browsers (e.g. safari not properly updating completion results when datalist elements are replaced asynchronously) and they have communicated these issues to those teams and gotten them fixed

if anyone reading this from other browser teams is interested in getting in contact w/me they can email me at carson at bigsky dot software

No question but I wanted to say, I was pulling my hair out trying to figure out which js framework was less of an overkill, and finding htmx was pure joy

yeah, looked at it, unfortunately fetch() and xhr have a non-intersecting set of features (in particular, upload progress for xhr) so we decided not to touch it

i may restructure the internals to allow for mocking out responses using events, it comes up, especially w/ extensions

Thanks for all your hard work; htmx is a breath of fresh air and an escape from the morass of needless complexity.

My only question: how can I get a set of those sweet sweet floppy disks?

HTMX is like a glimpse into the road not taken, where HTML is the main language of the web instead of JS. Sometimes the grass really is greener on the other side, and I hope as an industry we make the switch.

My cynical take: this is by design. Those web committees are staffed by companies that each have their non-web platform they're pushing (or were, until it died, see Microsoft), so even the most well meaning members are somehow contorted into compromises that make the web as a platform a bad technical choice in terms of actual design, but the best one in terms of flexibility and of course ubiquity.

It's completely stupid HTML, by default, doesn't have basic controls found in EVERY UI toolkit since circa 1980. The standard examples being ListView and TreeView.

> It's completely stupid HTML, by default, doesn't have basic controls found in EVERY UI toolkit since circa 1980. The standard examples being ListView and TreeView.

This is one of my greatest frustrations with the web as a platform. These controls are so basic they should just be there, eliminating the need to sift through dozens of third-party implementations all with wildly varying feature sets, performance profiles, framework compatibility, levels of upkeep, etc to find one that works for your project.

Well, they're not, and I can't find any good reason for why they aren't, when we're putting entire GPUs languages in there, except for the fact that somewhere in the HQ of one or more of those companies guiding web standards there is a discussion that goes something like:

Web Platform Dev: Boss, can we add TreeView to HMTL?

Web Platform Boss: Sounds cool, what are the advantages and disadvantages of doing this?

Web Platform Dev: Advantage: cross platform widget that's going to be super useful to many developers, replacing 3rd party ones of varying quality. Disadvantage: would take N months to implement and M years to have full adoptions, and yeah, it would probably increase adoption of the web platform, maybe even on mobile platform, where there is a chance that indirectly we will lose about $1-2bn per year from our walled garden, coupled with other web platform enhancements we should also make, regarding progressive web apps, local storage, etc.

Walled Garden Boss: Hey, SVP, can we please FIRE Web Platform Dev and Web Platform Boss as what they said amounts to a 2% drop in our share price?

Don’t attribute to malice… Many people working on frontend came from application or backend development and preferred the JavaScript model to a more declarative one. Not understanding enough the document context that drives the web. This makes everything more fragile and slow but hey “functionality” wins over everything else in todays world.

This doesn't explain ListView and TreeView. Or the lack of a DatePicker widget.

Look at Windows, MacOS, iOS, Android, Gtk, Qt.

Which of those doesn't have these widgets?

I'm tired of defending mega corps with thousands of employees with IQs through the roof, working on this for decades. It has to be latent malice. Banality of evil, if you will.

It is possible for normal everyday people to make contributions to the standards. I'm sure if you created a patch that showed these things working in firefox/webkit/chrome and wrote up a proposal and sent it to the correct listserv, you would at least have something more than baseless conspiracy to be mad about

I'm not a C dev and it's not my job to do something when people are literally paid for this stuff, a lot more than me. Every mainstream OS has what I'm talking about.

One example of this is the lack of an include-tag that could fetch a fragment from the server (useful for headers/footers). Developers have wanted it for decades and have been forced to reproduce the functionality themselves using frames and/or javascript.

Htmx users, can you please share your backend stacks and approaches? Me specifically interested in templaters for node (+ts) and your thoughts on endpoint management, but all ideas are welcome I guess.

My backend for a simple web application I'm working on is entirely in Rust. Highlights:

- axum: web application framework - https://github.com/tokio-rs/axum

- axum-htmx: axum extractors, responders, guards for htmx - https://github.com/robertwayne/axum-htmx

- rusqlite: SQLite bindings - https://github.com/rusqlite/rusqlite

- maud: HTML templating as a macro - https://maud.lambda.xyz

The way maud lets you compose markup works very nicely with htmx. The HX-Request header lets you know if the request is coming from htmx or if it is a regular request. You either call the top-level function if it's a regular request to get the entire page rendered, or call a subset of functions to get the appropriate partial rendered if it's an htmx request.

It's also nice to easily have tests for the rendered pages. My unit tests cover verification of the rendered HTML, too.

Django user here. HTMX fits in perfectly with the Django templating system. A fairly common approach is to use the same view but check for the HTMX header and then return a template file with the specific bit of HTML being swapped. There's also work in the Django space to be able to return parts of a template based on the request, which will suit HTMX perfectly too.

Go: go templates and fiber for http serving. I have a mini framework for adding some structure to the templates (folder per feature: contains controller, templates, etc, and some naming conventions)

Go with fasttemplate.

Most people prefer templ but I don't like logic in templates, I just want to parse values. I keep different states in different template files.

Each template file is a portion of a full page which makes it easy to create an endpoint that pulls the partial with the latest values. HTMX can then hit that endpoint to load or refresh values.

Endpoints are usually

    domain/page/partial

so if I'm on a configuration page at

    example.com/config

then the endpoint for the privacy settings partial would be

    example.com/config/privacy

Going directly there in a browser would get a 404 because I check for the HX-Request header.

Endpoint handlers return a processed template with the current state. I use those functions to both compose the full page on the backend, and to build the output for the partial endpoint.

I don't automatically expose all partials. I add endpoints as I need them. This is probably more idiomatically Go than anything to do with htmx.

Htmx + Kotlin with ktor and the html dsl was really fun to play with on a personal project. Static typing, autocomplete and a full-fledged programming language available to use in your html markup is a game changer. I was structuring my endpoints as pairs of "data" and "render", where the render endpoint just reused the function for the date endpoint.

Well, as I expected, templating is the hardest part of migrating to htmx on nodejs.

After reviewing few templaters/etc (handlebars, ejs, lit-html, virtual-dom) and few abstractions (html``, just ``, h()), barely anything seems too easy and too freedom-y. Arcane syntaxes, high character noise (ejs, lit, js), lack of typing (all non-`` based), trivial screw ups (virtual-dom, handlebars), experimental status (lit ssr). Sigh.

This was my experience as well. No great template generator on the node side.

I use PUG. I don’t like to close HTML tags. This cuts 30% of the visual bloat out of my templates.

NestJS with Handlebars templates. I don’t love Handlebars but I have past experience with it so was the most pragmatic choice.

I’m interested in trying EdgeJS as a templating alternative to HB but haven’t got round to it yet.

I’ve added a NestJS error handler that looks to see if the request came from an htmx request and then serve the error response as html, if not then it sends back json since I do have json api end points as well in the back end.

I just want to take advantage of this news to say: I love HTMX so much! :D It makes web development fun again. I can still use all the fancy js libs I want -- but my main logic lives on the server, using plain HTTP and HTML. Really clear and simple.

i havent used htmx yet, but it sounds like a breath of fresh air. no npm library with 1000 dependencies with slow build times. just plain simple js library like the good old days ^_^

Has anyone here used htmx for embedded devices? That is to provide web UI served by the device, for configuration / data access / control? Can you share the experience and if you would use it again?

Anybody know if there’s something like HTMX that plugs into Turbo? Every time I start using a stimulus controller, I have the thought that it should be more like HTMX instead.

I'm probably totally ignorant, but how would htmx work with a static site generator? Isn't the whole point of htmx that it extends the front end to dynamically interact with the server and get responses to inject?

You could have static elements pre-rendered, but only loaded on demand. For example, if you had a blog with comments, you could have the comments pre rendered in htmx fragments, but only loaded when they are clicked.

Or a photo gallery with thumbnails that are enlarged when clicked.

At least, that’s one way it could work.

I knew about Htmx and that HN loves it. But this post is what I actually got to take a good look, and oh my god it felt like such a fresh breath!

We have a few jQuery-era websites (that still work today because why not), and Htmx could be where we trim hundreds of lines.

It has already been pirated by various groups and made available for download assuming you have the bandwidth. Unbelievable. Big Sky has to make money somewhere.

（评论） (comments)

（评论）
(comments)