9 ms·

Htmx, Raku and Pico CSS

184 points by librasteve 2y ago

monkmartinez 2y ago
I hope you are not a sole, and have the complete human embodiment of a soul. Otherwise, yes, I agree. My one off projects use more and more cdn loaded information. I love pico, bulma and htmx.
simonbarker87 2y ago
I’ve been using htmx for over a year now for our internal management application (order monitoring, partner management, CAD model uploading and management type stuff) and I continue to be delighted at how quickly I can add features and iterate existing ones. I write way less client side JS, the app is very fast and responsive and I don’t have to write the app twice like with a SPA + API.
- meowtimemania 2y ago
  I love htmx for internal dashboards. I find htmx difficult to use for user facing applications because it's difficult to get everyone on board with the constraints of htmx (no optimistic uis, simple ui/ux). When building complicated frontends with lots of popovers, modals, optimistic state, I like react.
  - synergy20 2y ago
    i used it for simple dashboard, worked well but for complex projects it leads to spaghetti code for me, I had to stick to react for that.
  - taberiand 2y ago
    I don't think htmx should be used on its own when implementing ui/ux - htmx has the job of getting the blocks of html, with data embedded, from the back-end to the front-end (and posting back up as necessary); once it's there, front-end client-only ui/ux can be handled by other tools in JavaScript
    - aurareturn 2y ago
      So why complicate things and just use something like React + Next.js, which is already designed for complex apps?
      - emseetech 2y ago
        Alternatively, use web components which are baked into the browser, don't require a compile step, integrate well with HTMX and are much more stable than React.
        kaoD 2y ago
        Web components are the stuff that nightmares are made of. The amount of boilerplate I had to write just to keep DOM attributes and JS properties in sync was not fun, the impedance mismatch between them (DOM attributes being strings) was painful to deal with, and templates/slots felt much worse than the React way. The DOM didn't seem like a great model for moderately complex apps. Feels like web components didn't take off for a reason. IMO they feel like the solution you come up with when you create an abstraction in paper instead of writing a real-world thing that will solve your immediate problems. Not very pragmatic. Plus they only work with JS enabled, unlike React+SSR where you can progressively enhance your app. Overall not a great experience for user-facing apps.
        emseetech 2y ago
        | Web components are the stuff that nightmares are made of. There's lit.dev for an easier approach. https://lit.dev https://lit.dev
        kaoD 2y ago
        But that's yet-another-layer-of-abstraction with its own set of tradeoffs (e.g. I think CSS-in-JS is a trap, which seems to be the way for Lit; slots are still a thing; no SSR nor progressive enhancement; decorators!?!?!; etc.) which builds on top of what already feels like the wrong abstraction in the first place, only to provide React-like capabilities. At that point why not just use React? What do I get from using Lit instead?
  - emseetech 2y ago
    UX designers are immersed in this world of React and frontend frameworks, so their designs are built with that in mind. Doing things the "htmx way" on a team requires buy-in from more than just devs and that can be hard. We should be careful not to push htmx too past what it was meant for, as well. I remember how much I admired React when it was released for its simplicity.
- rtpg 2y ago
  One thing I've been struggling with using HTMX... with an app and a frontend REST API I've found I can really kinda quickly craft a frontend by filtering down whatever resources I need (though it's honestly pretty wasteful at times). With HTMX I'm finding myself needing to have as many backend views as I have ways of interacting with a page. I still have to write the frontend, and on top of that I gotta make a bunch of one-off backend views for many interactions. What am I doing wrong?
  - BeefySwain 2y ago
    Check these out and see if they provide any insight for your specific issues :) - https://htmx.org/essays/template-fragments/ https://htmx.org/essays/template-fragments/ - https://htmx.org/essays/10-tips-for-ssr-hda-apps/ https://htmx.org/essays/10-tips-for-ssr-hda-apps/
  - djbusby 2y ago
    I make htmx sites built around view fragments rather than pages. And when I need a page it's just a set of fragments. I make "API" endpoints fir the needed fragments and call via ssr on first paint, then as needed from the htmx side.
    - hyperdang 2y ago
      [flagged]
      - esaym 2y ago
        rofl
    - hyperdang 2y ago
      [flagged]
    - librasteve 2y ago
      this is my medium term intent with HTMX & Raku ... I have in mind a programmatic / functional style of building websites where I can compose whole pages and sites
- zerr 2y ago
  For such an internal web app, why not do it in a fully traditional/multi-page/server-rendered manner?
  - simonbarker87 2y ago
    I guess I could have done but the server was initially set up to respond with JSON and then the pages aspect got added in later and it felt easier to boot in htmx and bolt in the partials system and keep the json endpoints that are still needed than rearchitect for a proper MPA. Plus I wanted an excuse to use htmx.
fragmede 2y ago
(sole = bottom of shoe soul = spiritual part of a human)
mixmastamyk 2y ago
Pico looks like it may be the classless styler I was looking for, thanks.
- synergy20 2y ago
  it's arguably the most starred classless css indeed, it's my default styler
sergiotapia 2y ago
i know tailwind wasn't created in a vacuum and solves a massive problem. but part of me does feel sad it "won" and now we all are forced to deal with it in one way or another. i remember when HTML was clean and semantic, and crawlable. there was a certain respect in that way.
- _heimdall 2y ago
  It won mainly because it was a much better solution for styling in react than what existed at the time. In react today I'd still probably reach for Tailwind. In any other scenario I'd only reach for it I wasn't comfortable with CSS.
- earthboundkid 2y ago
  You can’t remember a time that never existed.
  - hecanjog 2y ago
    bootstrap won just a few years ago. something else will win soon. edit: I'm trying to impress the fact that things change. looking at if this library "won" or not misses the point.
    - dartos 2y ago
      I think 10 years is a good metric for “won” in FE land. React “won” Wordpress “won” Java applets did not Those iPhone web apps that were around before the App Store should’ve, but didn’t. Tailwind undecided
      - ducktective 2y ago
        Vue did not win, right? Seems like nowadays Svelete took its place, though still undecided imo
        dartos 2y ago
fny 2y ago
I have been in web dev since 1999, and recently switched to a backend role. I am never going back. The endless thrashing on front end borders on psychosis. Something is clearly broken, and that thing is my feeble mind.
- movedx 2y ago
  Like the article's writer, I remember the Netscape days and when JS came into existence. I was only a kid back then, like 9 years old, and was _just_ getting into coding in C and playing around with HTML/CSS. The results I produced, as you might have imagined, were akin to the results a toddler would produce given a wet loaf of bread to play with: mess everywhere. Anyway, back then the HTML was simple (but it was tables and spacer GIFs ha ha!) and the CSS even simpler. Now it's just such a chaotic mess that people actually think Web Assembley is a good idea; as if somehow they've invented something new: the sandbox and the machine code. Like running a process at the OS level and making _that_ better, more secure, etc. wasn't the right path. HTMLx is as close to the UI as I'll come. Everything else is an absolute headache to get into.
- Hammershaft 2y ago
  I think the churn and misery of front end development is the inevitable result of 30 years of path dependence on technologies that were either substandard to begin with (javascript, css) or were never designed for what they're used for (html, css).
- giancarlostoro 2y ago
  For me I'll never go back to normal front-end work after doing Blazor with C#. It's the nice bits of React (reusable code) but the flexibility of never having to decide between front-end only focused code, or some back-end powered AJAX style code, that is transparently rendered for you. You never have to touch JavaScript, but there's ways to do so. WASM is the best thing that ever happened to the web. When other major web frameworks adopt template engines that compile to WASM, we will see a shift in focus on JS heavy frameworks, and just people building things instead of fighting and trying to remember all the weird quirks of JavaScript.
chris_armstrong 2y ago
> I am a simple sole, I want to reduce the cognitive load in my web projects. The general idea is to go back to the halcyon early days of the web before Netscape dropped the JS-bomb. You know HTML for the layout and CSS for the style. An elegant division of roles. (I'm not quite sure if this is the author's sentiment), but the point shouldn't be to escape JS entirely, but make it into something that can be used in a repeated pattern that works in lockstep with your application, such that you are neither creating custom JS for each page (e.g. React), nor blindly manipulating the DOM (like JQuery). The division of roles between CSS and HTML is an almost contradictory point - your styling and layout should be coupled if you are to impose any meaningful order in your design. If you are rejecting the "decoupling" of front-end and back-end that React gives you, then why would you expect to be able to do it between HTML and CSS?
- deleted 2y ago
  [deleted]
- librasteve 2y ago
  these two points are exactly where I am coming from ... (i) I am deliberately starting from a(n over-) simplified pov to see how far I can get with zero JS ... but as I read the comments above I realise that, for real applications, I will need to "sprinkle" some Alpine and Tailwind here and there. (I chose Cro for the user auth.) (ii) Indeed HTML and CSS are in an intricate contradictory dance. In the purest sense I think that my sites should be composed of reusable parts that sit within context. These parts can be composed from roles and may selectively tweak them. The roles convey aspects of the design (colours, typography, containment, scale, size). The parts contain content (text, image, actions), identity and semantic intent. Role mixing in SASS is a small start in this direction. [This is a very weak stab at a very thorny problem ... please let me know if there is any reading that you recommend.] HTMX is a great tool to bring the UI implementation back into the realm of more capable & expressive languages. And to start with a new perspective. My personal preference is Raku, but you may prefer OCAML, Rust, Go, Python, Haskell, Elixir, ROC, Zig ...
  - niutech 2y ago
exabrial 2y ago
> While HTMX is well suited to 90% of this, if you are building a webapp like FaceBook […], then it’s not for you I completely completely disagree. This is all you need.
- murkt 2y ago
  Agree, Facebook can be easily done with HTMX and similar things. How would you do that with Figma, YouTube, etc?
  - Nathanael_M 2y ago
    Figma is mostly WASM, no?
    - murkt 2y ago
      That's not too HTMX-friendly technology, is it?
      - consteval 2y ago
        WASM isn't friendly with any other web technologies because it's compiled code. You can't interact with the DOM at all, so if you're doing rendering via WASM it's always gonna be in it's own little island.
jakelazaroff 2y ago
The main example in this article — immediately following a section on semantic HTML — is a list of <a> tags with the hrefs all set to `#` and the hyperlink behavior emulated with htmx. So we’ve taken what would otherwise be a perfectly functional list of links, removed the most important semantic attribute, broken a bunch of behavior and rendered them useless without a ~16kb JavaScript library. …and look, that’s an okay mistake to make — it takes time to learn this stuff — but when you also go out of the way to pine for “the halcyon early days of the web before Netscape dropped the JS-bomb” it makes it difficult to take you seriously. A list of links is, like, the most basic essence of a website; if you aren’t able to make that work without a JavaScript library, what are you even pining for?
- niutech 2y ago
  Try HTMZ, which is progressively enhanced and is just using a single <iframe>.
  - deleted 2y ago
    [deleted]
  - jakelazaroff 2y ago
    It’s not really about the tooling. My point is that people who talk about the “good old days” of the web often (charitably) are unfamiliar with or (cynically) don’t care about the medium they venerate.
nanis 2y ago
> I am a simple sole, ... go back to the halcyon early days of the web before Netscape dropped the JS-bomb. You know HTML for the layout and CSS for the style. I am not sure if this is intended as humor, but JavaScript came before CSS.
- culi 2y ago
  And "HTML for structure, CSS for style" is a philosophy that developed later. As is evidenced by early HTML tags like <small>, <center>, <b>, <i>, etc
  - stavros 2y ago
    I remember when CSS Zen garden was showcasing what you can do with CSS, and browsers (well, "browser", singular, as there was basically only IE 6 back then) supported Javascript and VBScript.
    - austin-cheney 2y ago
      Back in 2008 we had a team building exercise to create a Zen Garden sample. Here was mine: https://prettydiff.com/zen/ https://prettydiff.com/zen/ In those days the three content columns vertically aligned to the same height cross-browser.
- SoftTalker 2y ago
  And it's soul, not sole. Unless the author is also a fish.
  - philsnow 2y ago
    I read that as "sole [proprietor]"
  - librasteve 2y ago
    sorry - maybe we need AI smell checkers
cantSpellSober 2y ago
Why Pico specifically? Lots of classless frameworks. > I am a simple sole [sic] `href=#` + JS library + config file + setting routes for each tab button doesn't feel simple
- joshka 2y ago
  As a more backend focused dev (though one who's touched a bunch of different JS / CSS frameworks over the years), seeing Pico in this article seemed pretty nice in comparison to what I've seen in the past. What are some of the similar frameworks that compete in your opinion?
eddyg 2y ago
Raku is such a fantastic, feature-laden language. Cool to see it get a (tiny) bit of HN attention!
- librasteve 2y ago
  Yeah - I think that many people are put off Raku by its imo undeserved reputation ... if languages were clothing, then Raku would be the tank top.
bravura 2y ago
I'm just curious if anyone is using unpoly instead of HTMX? I know that HTMX has a much larger userbase, its main dev is well known and beloved, and the landing page doesn't look web 1.0 With that said, unpoly appears to have a similar feature set and one feature that HTMX doesn't: The ability to create modals without loading a new page.
- jazzypants 2y ago
  With popover[1] and dialog[2], do you really need this from a JS framework? 1: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/popover https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att... 2: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
- LaundroMat 2y ago
  I use it for a rewrite I'm doing because tracking state on both back- and front-end got too cumbersome. I'm using Django, and a big positive of using unpoly is that I can write views like a traditional Django application and have a reactive frontend. It does mean however that heavy pages impact front-end reactivity. So if there's only one tiny element that needs to be updated on the front-end, that takes more time than if the backend would only have to return a template partial (htmx) or some JSON (alpine). Also, the documentation is really a reference. You need it read it front to back a few times to understand unpoly's capabilities. It's strange that there are so few tutorials about it, because it's been around for a while already, it really has its use and it is still under active development.
  - tecleandor 2y ago
    How does it work with Javascript deactivated? In theory it should work that way, isn't it?
- murkt 2y ago
  I'm using twinspark.js: https://twinspark.js.org/ https://twinspark.js.org/ It has "actions" that bridge a need for some client-side interactivity, without resorting to write lots and lots of JS. I have some interactive stuff that don't touch server. Also it's pretty easy to add more actions when needed. And if I need to do something really complex, I can just go and read its source code. Which is really hard to do with unpoly and its really complicated OOP style.
karaterobot 2y ago
> As we have seen in the previous posts, HTMX eliminates the need for JS to make dynamic web content. Well, sort of! I suppose that for certain definitions of eliminating Javascript, this Javascript framework eliminates the need for Javascript completely.
- nsonha 2y ago
  htmlx, taiwind and the like certainly help back-end dev churn out web codebases faster, eliminating a lot of poor souls who have to maintain them afterward!
- niutech 2y ago
  HTMX is whooping 45KB of JS, which is being often loaded in <head> blocking rendering HTML, whereas you can have a fully functioning interactive website with pure CSS framework like Spectre.css (https://niutech.github.io/spectre/ https://niutech.github.io/spectre/) and a sprinkle of 166-byte (sic!) HTMZ. See my demo: https://kodus.pl https://kodus.pl
  - mardifoufs 2y ago
    Which is a bit surprising considering that react is 90kb unzipped, 46kb zipped. Yet there's this weird sentiment that react is JS bloat while htmx isn't.
  - dpe82 2y ago
    ~14kb gzip'd, and it solves a bit of a different problem.
mediumsmart 2y ago
I do believe this is still in the first half of the rococo phase and that rubble is a long way off so by all means, carry on.
murkt 2y ago
HTMX, Unpoly and Twinspark are great, can't say anything about Raku. I also really liked an idea about class-less CSS frameworks, as I was frustrated with all the `<table class="table">` and so on. Then I've tried it for one project where I had to integrate Leaflet map on a page. And it's just not possible to do with class-less CSS frameworks. Since then I write `<table class="table">` and have zero problems with that.
- echoangle 2y ago
  How is it not possible? Can you not just use classes for the map tags and keep everything else the same? Or is the problem that the map styles are affected by the classless CSS?
  - murkt 2y ago
    Yes, map styles are affected by the classless CSS.
    - echoangle 2y ago
      But can’t you just do #map{ foo: initial } #map *{ foo: initial } For the styles that are a problem? That’s maybe 10 properties you need to remove?
      - murkt 2y ago
        I guess you're right and "impossible" was too strong of a statement. I just didn't feel like debugging those CSS things, especially when adding any new Leaflet plugins, or any other things. So I just switched to a style that I knew will work robustly.
      - kolme 2y ago
        I find "removing" or resetting styles kind of hacky. Another solution might be packing the map in a shadow element so that it doesn't get affected by the page CSS.
stephankoelle 2y ago
Recently, I’ve been working with Quarkus[1], the quarkus-qute[2] (a type-safe templating engine), and htmx. I found the experience quite positive. Quarkus offers lightning-fast compilation with a hot-reloading Maven wrapper (mvnw), making development seamless. Picking up qute was straightforward, and combining it with htmx, especially with qute’s #fragment support for htmx, felt like a natural fit. [1] https://quarkus.io/ https://quarkus.io/ [2] https://quarkus.io/guides/qute https://quarkus.io/guides/qute
deleted 2y ago
[deleted]
allan_s 2y ago
For the "semantic web" part, what we've been using in my company recently , is the `<x-something>` tag which are valid html5 so except if there's a really fitting html5 tags (like footer, h1 , main ), we will have `<x-card>` `<x-avatar><img ></x-avatar>` (In case we must have an additional ) so that it's easier to convey the semantic (especially when looking in the dom inspector) for the css we've been using tailwind (and couldn't be happier), but for personnal projects I guess picocss would be a really nice fit with `<x-semantic>` tags
niutech 2y ago
Better than using HTMX - 48KB of JS - use my PHOOOS technique (https://kodus.pl https://kodus.pl) with pure HTML out-ouf-order streaming, pure CSS framework Spectre.css (https://niutech.github.io/spectre/ https://niutech.github.io/spectre/) and a sprinkle of 166B (bytes, not KB!) HTMZ (https://leanrada.com/htmz/ https://leanrada.com/htmz/) for extra interactivity.

184 points by librasteve 2y ago

I hope you are not a sole, and have the complete human embodiment of a soul. Otherwise, yes, I agree. My one off projects use more and more cdn loaded information. I love pico, bulma and htmx.

simonbarker87 2y ago

I’ve been using htmx for over a year now for our internal management application (order monitoring, partner management, CAD model uploading and management type stuff) and I continue to be delighted at how quickly I can add features and iterate existing ones. I write way less client side JS, the app is very fast and responsive and I don’t have to write the app twice like with a SPA + API.

meowtimemania 2y ago
I love htmx for internal dashboards. I find htmx difficult to use for user facing applications because it's difficult to get everyone on board with the constraints of htmx (no optimistic uis, simple ui/ux). When building complicated frontends with lots of popovers, modals, optimistic state, I like react.
- synergy20 2y ago
  i used it for simple dashboard, worked well but for complex projects it leads to spaghetti code for me, I had to stick to react for that.
- taberiand 2y ago
  I don't think htmx should be used on its own when implementing ui/ux - htmx has the job of getting the blocks of html, with data embedded, from the back-end to the front-end (and posting back up as necessary); once it's there, front-end client-only ui/ux can be handled by other tools in JavaScript
  - aurareturn 2y ago
    So why complicate things and just use something like React + Next.js, which is already designed for complex apps?
    - emseetech 2y ago
      Alternatively, use web components which are baked into the browser, don't require a compile step, integrate well with HTMX and are much more stable than React.
      - kaoD 2y ago
        Web components are the stuff that nightmares are made of. The amount of boilerplate I had to write just to keep DOM attributes and JS properties in sync was not fun, the impedance mismatch between them (DOM attributes being strings) was painful to deal with, and templates/slots felt much worse than the React way. The DOM didn't seem like a great model for moderately complex apps. Feels like web components didn't take off for a reason. IMO they feel like the solution you come up with when you create an abstraction in paper instead of writing a real-world thing that will solve your immediate problems. Not very pragmatic. Plus they only work with JS enabled, unlike React+SSR where you can progressively enhance your app. Overall not a great experience for user-facing apps.
        emseetech 2y ago
        | Web components are the stuff that nightmares are made of. There's lit.dev for an easier approach. https://lit.dev https://lit.dev
        kaoD 2y ago
        But that's yet-another-layer-of-abstraction with its own set of tradeoffs (e.g. I think CSS-in-JS is a trap, which seems to be the way for Lit; slots are still a thing; no SSR nor progressive enhancement; decorators!?!?!; etc.) which builds on top of what already feels like the wrong abstraction in the first place, only to provide React-like capabilities. At that point why not just use React? What do I get from using Lit instead?
- emseetech 2y ago
  UX designers are immersed in this world of React and frontend frameworks, so their designs are built with that in mind. Doing things the "htmx way" on a team requires buy-in from more than just devs and that can be hard. We should be careful not to push htmx too past what it was meant for, as well. I remember how much I admired React when it was released for its simplicity.
rtpg 2y ago
One thing I've been struggling with using HTMX... with an app and a frontend REST API I've found I can really kinda quickly craft a frontend by filtering down whatever resources I need (though it's honestly pretty wasteful at times). With HTMX I'm finding myself needing to have as many backend views as I have ways of interacting with a page. I still have to write the frontend, and on top of that I gotta make a bunch of one-off backend views for many interactions. What am I doing wrong?
- BeefySwain 2y ago
  Check these out and see if they provide any insight for your specific issues :) - https://htmx.org/essays/template-fragments/ https://htmx.org/essays/template-fragments/ - https://htmx.org/essays/10-tips-for-ssr-hda-apps/ https://htmx.org/essays/10-tips-for-ssr-hda-apps/
- djbusby 2y ago
  I make htmx sites built around view fragments rather than pages. And when I need a page it's just a set of fragments. I make "API" endpoints fir the needed fragments and call via ssr on first paint, then as needed from the htmx side.
  - hyperdang 2y ago
    [flagged]
    - esaym 2y ago
      rofl
  - hyperdang 2y ago
    [flagged]
  - librasteve 2y ago
    this is my medium term intent with HTMX & Raku ... I have in mind a programmatic / functional style of building websites where I can compose whole pages and sites
zerr 2y ago
For such an internal web app, why not do it in a fully traditional/multi-page/server-rendered manner?
- simonbarker87 2y ago
  I guess I could have done but the server was initially set up to respond with JSON and then the pages aspect got added in later and it felt easier to boot in htmx and bolt in the partials system and keep the json endpoints that are still needed than rearchitect for a proper MPA. Plus I wanted an excuse to use htmx.

fragmede 2y ago

(sole = bottom of shoe soul = spiritual part of a human)

mixmastamyk 2y ago

Pico looks like it may be the classless styler I was looking for, thanks.

synergy20 2y ago
it's arguably the most starred classless css indeed, it's my default styler

sergiotapia 2y ago

i know tailwind wasn't created in a vacuum and solves a massive problem. but part of me does feel sad it "won" and now we all are forced to deal with it in one way or another. i remember when HTML was clean and semantic, and crawlable. there was a certain respect in that way.

_heimdall 2y ago
It won mainly because it was a much better solution for styling in react than what existed at the time. In react today I'd still probably reach for Tailwind. In any other scenario I'd only reach for it I wasn't comfortable with CSS.
earthboundkid 2y ago
You can’t remember a time that never existed.
- hecanjog 2y ago
  bootstrap won just a few years ago. something else will win soon. edit: I'm trying to impress the fact that things change. looking at if this library "won" or not misses the point.
  - dartos 2y ago
    I think 10 years is a good metric for “won” in FE land. React “won” Wordpress “won” Java applets did not Those iPhone web apps that were around before the App Store should’ve, but didn’t. Tailwind undecided
    - ducktective 2y ago
      Vue did not win, right? Seems like nowadays Svelete took its place, though still undecided imo
      - dartos 2y ago

fny 2y ago

I have been in web dev since 1999, and recently switched to a backend role. I am never going back. The endless thrashing on front end borders on psychosis. Something is clearly broken, and that thing is my feeble mind.

movedx 2y ago
Like the article's writer, I remember the Netscape days and when JS came into existence. I was only a kid back then, like 9 years old, and was _just_ getting into coding in C and playing around with HTML/CSS. The results I produced, as you might have imagined, were akin to the results a toddler would produce given a wet loaf of bread to play with: mess everywhere. Anyway, back then the HTML was simple (but it was tables and spacer GIFs ha ha!) and the CSS even simpler. Now it's just such a chaotic mess that people actually think Web Assembley is a good idea; as if somehow they've invented something new: the sandbox and the machine code. Like running a process at the OS level and making _that_ better, more secure, etc. wasn't the right path. HTMLx is as close to the UI as I'll come. Everything else is an absolute headache to get into.
Hammershaft 2y ago
I think the churn and misery of front end development is the inevitable result of 30 years of path dependence on technologies that were either substandard to begin with (javascript, css) or were never designed for what they're used for (html, css).
giancarlostoro 2y ago
For me I'll never go back to normal front-end work after doing Blazor with C#. It's the nice bits of React (reusable code) but the flexibility of never having to decide between front-end only focused code, or some back-end powered AJAX style code, that is transparently rendered for you. You never have to touch JavaScript, but there's ways to do so. WASM is the best thing that ever happened to the web. When other major web frameworks adopt template engines that compile to WASM, we will see a shift in focus on JS heavy frameworks, and just people building things instead of fighting and trying to remember all the weird quirks of JavaScript.

chris_armstrong 2y ago

> I am a simple sole, I want to reduce the cognitive load in my web projects. The general idea is to go back to the halcyon early days of the web before Netscape dropped the JS-bomb. You know HTML for the layout and CSS for the style. An elegant division of roles. (I'm not quite sure if this is the author's sentiment), but the point shouldn't be to escape JS entirely, but make it into something that can be used in a repeated pattern that works in lockstep with your application, such that you are neither creating custom JS for each page (e.g. React), nor blindly manipulating the DOM (like JQuery). The division of roles between CSS and HTML is an almost contradictory point - your styling and layout should be coupled if you are to impose any meaningful order in your design. If you are rejecting the "decoupling" of front-end and back-end that React gives you, then why would you expect to be able to do it between HTML and CSS?

deleted 2y ago
[deleted]
librasteve 2y ago
these two points are exactly where I am coming from ... (i) I am deliberately starting from a(n over-) simplified pov to see how far I can get with zero JS ... but as I read the comments above I realise that, for real applications, I will need to "sprinkle" some Alpine and Tailwind here and there. (I chose Cro for the user auth.) (ii) Indeed HTML and CSS are in an intricate contradictory dance. In the purest sense I think that my sites should be composed of reusable parts that sit within context. These parts can be composed from roles and may selectively tweak them. The roles convey aspects of the design (colours, typography, containment, scale, size). The parts contain content (text, image, actions), identity and semantic intent. Role mixing in SASS is a small start in this direction. [This is a very weak stab at a very thorny problem ... please let me know if there is any reading that you recommend.] HTMX is a great tool to bring the UI implementation back into the realm of more capable & expressive languages. And to start with a new perspective. My personal preference is Raku, but you may prefer OCAML, Rust, Go, Python, Haskell, Elixir, ROC, Zig ...
- niutech 2y ago

exabrial 2y ago

> While HTMX is well suited to 90% of this, if you are building a webapp like FaceBook […], then it’s not for you I completely completely disagree. This is all you need.

murkt 2y ago
Agree, Facebook can be easily done with HTMX and similar things. How would you do that with Figma, YouTube, etc?
- Nathanael_M 2y ago
  Figma is mostly WASM, no?
  - murkt 2y ago
    That's not too HTMX-friendly technology, is it?
    - consteval 2y ago
      WASM isn't friendly with any other web technologies because it's compiled code. You can't interact with the DOM at all, so if you're doing rendering via WASM it's always gonna be in it's own little island.

jakelazaroff 2y ago

The main example in this article — immediately following a section on semantic HTML — is a list of <a> tags with the hrefs all set to `#` and the hyperlink behavior emulated with htmx. So we’ve taken what would otherwise be a perfectly functional list of links, removed the most important semantic attribute, broken a bunch of behavior and rendered them useless without a ~16kb JavaScript library. …and look, that’s an okay mistake to make — it takes time to learn this stuff — but when you also go out of the way to pine for “the halcyon early days of the web before Netscape dropped the JS-bomb” it makes it difficult to take you seriously. A list of links is, like, the most basic essence of a website; if you aren’t able to make that work without a JavaScript library, what are you even pining for?

niutech 2y ago
Try HTMZ, which is progressively enhanced and is just using a single <iframe>.
- deleted 2y ago
  [deleted]
- jakelazaroff 2y ago
  It’s not really about the tooling. My point is that people who talk about the “good old days” of the web often (charitably) are unfamiliar with or (cynically) don’t care about the medium they venerate.

nanis 2y ago

> I am a simple sole, ... go back to the halcyon early days of the web before Netscape dropped the JS-bomb. You know HTML for the layout and CSS for the style. I am not sure if this is intended as humor, but JavaScript came before CSS.

culi 2y ago
And "HTML for structure, CSS for style" is a philosophy that developed later. As is evidenced by early HTML tags like <small>, <center>, <b>, <i>, etc
- stavros 2y ago
  I remember when CSS Zen garden was showcasing what you can do with CSS, and browsers (well, "browser", singular, as there was basically only IE 6 back then) supported Javascript and VBScript.
  - austin-cheney 2y ago
    Back in 2008 we had a team building exercise to create a Zen Garden sample. Here was mine: https://prettydiff.com/zen/ https://prettydiff.com/zen/ In those days the three content columns vertically aligned to the same height cross-browser.
SoftTalker 2y ago
And it's soul, not sole. Unless the author is also a fish.
- philsnow 2y ago
  I read that as "sole [proprietor]"
- librasteve 2y ago
  sorry - maybe we need AI smell checkers

cantSpellSober 2y ago

Why Pico specifically? Lots of classless frameworks. > I am a simple sole [sic] `href=#` + JS library + config file + setting routes for each tab button doesn't feel simple

joshka 2y ago
As a more backend focused dev (though one who's touched a bunch of different JS / CSS frameworks over the years), seeing Pico in this article seemed pretty nice in comparison to what I've seen in the past. What are some of the similar frameworks that compete in your opinion?

eddyg 2y ago

Raku is such a fantastic, feature-laden language. Cool to see it get a (tiny) bit of HN attention!

librasteve 2y ago
Yeah - I think that many people are put off Raku by its imo undeserved reputation ... if languages were clothing, then Raku would be the tank top.

bravura 2y ago

I'm just curious if anyone is using unpoly instead of HTMX? I know that HTMX has a much larger userbase, its main dev is well known and beloved, and the landing page doesn't look web 1.0 With that said, unpoly appears to have a similar feature set and one feature that HTMX doesn't: The ability to create modals without loading a new page.

jazzypants 2y ago
With popover[1] and dialog[2], do you really need this from a JS framework? 1: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/popover https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att... 2: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
LaundroMat 2y ago
I use it for a rewrite I'm doing because tracking state on both back- and front-end got too cumbersome. I'm using Django, and a big positive of using unpoly is that I can write views like a traditional Django application and have a reactive frontend. It does mean however that heavy pages impact front-end reactivity. So if there's only one tiny element that needs to be updated on the front-end, that takes more time than if the backend would only have to return a template partial (htmx) or some JSON (alpine). Also, the documentation is really a reference. You need it read it front to back a few times to understand unpoly's capabilities. It's strange that there are so few tutorials about it, because it's been around for a while already, it really has its use and it is still under active development.
- tecleandor 2y ago
  How does it work with Javascript deactivated? In theory it should work that way, isn't it?
murkt 2y ago
I'm using twinspark.js: https://twinspark.js.org/ https://twinspark.js.org/ It has "actions" that bridge a need for some client-side interactivity, without resorting to write lots and lots of JS. I have some interactive stuff that don't touch server. Also it's pretty easy to add more actions when needed. And if I need to do something really complex, I can just go and read its source code. Which is really hard to do with unpoly and its really complicated OOP style.

karaterobot 2y ago

> As we have seen in the previous posts, HTMX eliminates the need for JS to make dynamic web content. Well, sort of! I suppose that for certain definitions of eliminating Javascript, this Javascript framework eliminates the need for Javascript completely.

nsonha 2y ago
htmlx, taiwind and the like certainly help back-end dev churn out web codebases faster, eliminating a lot of poor souls who have to maintain them afterward!
niutech 2y ago
HTMX is whooping 45KB of JS, which is being often loaded in <head> blocking rendering HTML, whereas you can have a fully functioning interactive website with pure CSS framework like Spectre.css (https://niutech.github.io/spectre/ https://niutech.github.io/spectre/) and a sprinkle of 166-byte (sic!) HTMZ. See my demo: https://kodus.pl https://kodus.pl
- mardifoufs 2y ago
  Which is a bit surprising considering that react is 90kb unzipped, 46kb zipped. Yet there's this weird sentiment that react is JS bloat while htmx isn't.
- dpe82 2y ago
  ~14kb gzip'd, and it solves a bit of a different problem.

mediumsmart 2y ago

I do believe this is still in the first half of the rococo phase and that rubble is a long way off so by all means, carry on.

murkt 2y ago

HTMX, Unpoly and Twinspark are great, can't say anything about Raku. I also really liked an idea about class-less CSS frameworks, as I was frustrated with all the `<table class="table">` and so on. Then I've tried it for one project where I had to integrate Leaflet map on a page. And it's just not possible to do with class-less CSS frameworks. Since then I write `<table class="table">` and have zero problems with that.

echoangle 2y ago
How is it not possible? Can you not just use classes for the map tags and keep everything else the same? Or is the problem that the map styles are affected by the classless CSS?
- murkt 2y ago
  Yes, map styles are affected by the classless CSS.
  - echoangle 2y ago
    But can’t you just do #map{ foo: initial } #map *{ foo: initial } For the styles that are a problem? That’s maybe 10 properties you need to remove?
    - murkt 2y ago
      I guess you're right and "impossible" was too strong of a statement. I just didn't feel like debugging those CSS things, especially when adding any new Leaflet plugins, or any other things. So I just switched to a style that I knew will work robustly.
    - kolme 2y ago
      I find "removing" or resetting styles kind of hacky. Another solution might be packing the map in a shadow element so that it doesn't get affected by the page CSS.

stephankoelle 2y ago

Recently, I’ve been working with Quarkus[1], the quarkus-qute[2] (a type-safe templating engine), and htmx. I found the experience quite positive. Quarkus offers lightning-fast compilation with a hot-reloading Maven wrapper (mvnw), making development seamless. Picking up qute was straightforward, and combining it with htmx, especially with qute’s #fragment support for htmx, felt like a natural fit. [1] https://quarkus.io/ https://quarkus.io/ [2] https://quarkus.io/guides/qute https://quarkus.io/guides/qute

deleted 2y ago

[deleted]

allan_s 2y ago

For the "semantic web" part, what we've been using in my company recently , is the `<x-something>` tag which are valid html5 so except if there's a really fitting html5 tags (like footer, h1 , main ), we will have `<x-card>` `<x-avatar><img ></x-avatar>` (In case we must have an additional ) so that it's easier to convey the semantic (especially when looking in the dom inspector) for the css we've been using tailwind (and couldn't be happier), but for personnal projects I guess picocss would be a really nice fit with `<x-semantic>` tags

niutech 2y ago

Better than using HTMX - 48KB of JS - use my PHOOOS technique (https://kodus.pl https://kodus.pl) with pure HTML out-ouf-order streaming, pure CSS framework Spectre.css (https://niutech.github.io/spectre/ https://niutech.github.io/spectre/) and a sprinkle of 166B (bytes, not KB!) HTMZ (https://leanrada.com/htmz/ https://leanrada.com/htmz/) for extra interactivity.