6 ms·

This is a brilliant list, I'm a particular fan of HTMX and Alpine.js. The move back towards small dependancy free JS libs, in combination with modern JS ES Mod

This is a brilliant list, I'm a particular fan of HTMX and Alpine.js. The move back towards small dependancy free JS libs, in combination with modern JS ES Modules, is absolutely brilliant. I learnt web dev back in the late 90s by doing "view source", and was still learning about new things that way well over a decade later. If we can move back towards that, by not having a build step, it will be amazing for new devs starting out and learning new things. Obviously larger apps, with many dependancies, will require all the incredible work thats gone into modern JS tooling, but for so many simpler (and not so simple) sites this process really does make sense.

kitsunesoba 3y ago
> I learnt web dev back in the late 90s by doing "view source", and was still learning about new things that way well over a decade later. If we can move back towards that, by not having a build step, it will be amazing for new devs starting out and learning new things. Same here, and I couldn't agree more. Had minified library soup with dynamic page content been the norm back then it would've been much harder to get started, and there's a high chance I would've just given up somewhere in the process. Having a build step also increases activation energy and friction which impedes the sort of in-the-moment tinkering that often sparks projects.
- dheera 3y ago
  > Having a build step also increases activation energy and friction Yes this! As an interpreted language it should not need a build step. Every project should be git clone https://github.com/user/foo && cd foo && google-chrome index.html
  - Zelphyr 3y ago
    You guys are singing the song of my people. For years I've been confounded at the idea that we need to be building/compiling interpreted code. And the tooling... my God! I know this makes me sound like an old man (because I am) but, it used to be all I needed was an editor, an FTP client, and a browser. write-upload-refresh. Today, I find VS Code, `git push`, and a browser still serves me very well.
  - pmontra 3y ago
    I'm also against building and compiling (I work with Python and Ruby on the backend) but there were good reasons to have those steps, at least in the past and probably still now. Short and very incomplete list, feel free to reply and add points: * slow network, especially on mobile * reduce the size of the download by minifying * reduce the number of calls by bundling files in a single one * Inconsistent JS and HTML feature support among browsers * transpiling to a common older version of JS * add polyfills to implement missing features * add widgets to implement fucked up default implementations or widgets that are nearly impossible to standardize (date and time pickers might need tons of features and are projects on their own)
    - kitsunesoba 3y ago
      Most of those points could be taken care of by building only when deploying though, skipping the phase during development. I think most of the annoyance with a build step comes from how you can’t do anything unless the tooling for it is set up, as well as how it gunks up the tweak → reload cycle.
- jabart 3y ago
  Irony is that javascript handlers on elements were frowned upon in 90s/00s because of separate of concerns that HTML should be HTML and JS should attach it's events in a separate file. Now all of these libraries have an onclick that mirrors those original JS event handlers in the same html with no separation!
  - samwillis 3y ago
    Only thing missing is inlining your css styles on each element, only a mad man would try that though... [cough]... https://github.com/samwillis/x-style https://github.com/samwillis/x-style
    - endofreach 3y ago
      Or, tailwindcss…
      - efskap 3y ago
        Did you even click the link? The "Why?" section explains the problem with tailwind and the code sample shows it's doing a different thing, closer to htmx.
      - samwillis 3y ago
        Tailwind is awesome and gets so much right. However, it requires a build step using local dev tools, and it has a complete DSL that reimplements most of css as classes. Utility classes for uniform padding, spacing, border, colours etc at brilliant. But my suggestion with x-style is that placing the actual css on an element may be better. It's an experiment, seeing where it leads.
  - ximm 3y ago
    If implemented incorrectly, these onclick handlers are a security hazard, because they prevent you from using a strict content security policy. https://www.w3.org/TR/CSP2/#directives https://www.w3.org/TR/CSP2/#directives
- bobthepanda 3y ago
  Unfortunately we need the JS still because the standards are so lacking, and when they’re not it takes a while to get everybody on it. As a general example, despite three decades of the web existing across the world in many jurisdictions with more than one language, the solution to translation for a site is just some translation framework or tediously maintaining a whole copy of your site per language.
  - austin-cheney 3y ago
    The standards are fine. The problem is that the front end web is the DOM. I love the DOM, but it scares the shit out of people. Most people would rather cut their hand off or sell their children into child slavery than walk the DOM with 3 instructions. Its super weird and gets more weird when those people are actually confronted with this irrational behavior.
sureglymop 3y ago
If you use htmx what backend technology do you choose?
- acaloiar 3y ago
  The beauty of htmx is that it doesn't matter what you use on the backend. Literally anything that'll render HTML will suffice. Even static HTML files on a web server will do. No need for an application server at all if you're clever and your needs are simple.
  - sureglymop 3y ago
    What if I want the website to work even when JavaScript is not turned on? I'd need a backend server and some frontend logic handling that case.
    - iudqnolq 3y ago
      Not necessarily. It depends on what you need. For example suppose you were implementing an news reader with two panes. Left pane is a list of titles and previews, right pane is a full article for the selected item in the left pane. You can make the left pane a list of links to dedicated pages, and then add an htmx attribute to indicate that when the user has JavaScript to instead fetch a html snippet with just full article and swap it into the right pane. If you had a reasonably bounded set of articles you could statically generate all the /article/id.html and the /article/id/snippet.html files, though a backend probably makes sense.
      - sureglymop 3y ago
        At that point, how big is the difference really between sending the right pane only as opposed to the whole page performance wise? I'm just not sure if this approach is worth it for me.
    - wishinghand 3y ago
      In that case you need to have everything rendered server side and perhaps get creative with the usage of forms firing off events that can be intercepted by the server and then return a new page. Certain things like Nav menu drop downs and folding text can’t be done with native CSS and HTML.
ksec 3y ago
I still wish 80 to 90% of those JS function on the list should be part of HTML5 and not as a JS library.

kitsunesoba 3y ago

> I learnt web dev back in the late 90s by doing "view source", and was still learning about new things that way well over a decade later. If we can move back towards that, by not having a build step, it will be amazing for new devs starting out and learning new things. Same here, and I couldn't agree more. Had minified library soup with dynamic page content been the norm back then it would've been much harder to get started, and there's a high chance I would've just given up somewhere in the process. Having a build step also increases activation energy and friction which impedes the sort of in-the-moment tinkering that often sparks projects.

dheera 3y ago
> Having a build step also increases activation energy and friction Yes this! As an interpreted language it should not need a build step. Every project should be git clone https://github.com/user/foo && cd foo && google-chrome index.html
- Zelphyr 3y ago
  You guys are singing the song of my people. For years I've been confounded at the idea that we need to be building/compiling interpreted code. And the tooling... my God! I know this makes me sound like an old man (because I am) but, it used to be all I needed was an editor, an FTP client, and a browser. write-upload-refresh. Today, I find VS Code, `git push`, and a browser still serves me very well.
- pmontra 3y ago
  I'm also against building and compiling (I work with Python and Ruby on the backend) but there were good reasons to have those steps, at least in the past and probably still now. Short and very incomplete list, feel free to reply and add points: * slow network, especially on mobile * reduce the size of the download by minifying * reduce the number of calls by bundling files in a single one * Inconsistent JS and HTML feature support among browsers * transpiling to a common older version of JS * add polyfills to implement missing features * add widgets to implement fucked up default implementations or widgets that are nearly impossible to standardize (date and time pickers might need tons of features and are projects on their own)
  - kitsunesoba 3y ago
    Most of those points could be taken care of by building only when deploying though, skipping the phase during development. I think most of the annoyance with a build step comes from how you can’t do anything unless the tooling for it is set up, as well as how it gunks up the tweak → reload cycle.
jabart 3y ago
Irony is that javascript handlers on elements were frowned upon in 90s/00s because of separate of concerns that HTML should be HTML and JS should attach it's events in a separate file. Now all of these libraries have an onclick that mirrors those original JS event handlers in the same html with no separation!
- samwillis 3y ago
  Only thing missing is inlining your css styles on each element, only a mad man would try that though... [cough]... https://github.com/samwillis/x-style https://github.com/samwillis/x-style
  - endofreach 3y ago
    Or, tailwindcss…
    - efskap 3y ago
      Did you even click the link? The "Why?" section explains the problem with tailwind and the code sample shows it's doing a different thing, closer to htmx.
    - samwillis 3y ago
      Tailwind is awesome and gets so much right. However, it requires a build step using local dev tools, and it has a complete DSL that reimplements most of css as classes. Utility classes for uniform padding, spacing, border, colours etc at brilliant. But my suggestion with x-style is that placing the actual css on an element may be better. It's an experiment, seeing where it leads.
- ximm 3y ago
  If implemented incorrectly, these onclick handlers are a security hazard, because they prevent you from using a strict content security policy. https://www.w3.org/TR/CSP2/#directives https://www.w3.org/TR/CSP2/#directives
bobthepanda 3y ago
Unfortunately we need the JS still because the standards are so lacking, and when they’re not it takes a while to get everybody on it. As a general example, despite three decades of the web existing across the world in many jurisdictions with more than one language, the solution to translation for a site is just some translation framework or tediously maintaining a whole copy of your site per language.
- austin-cheney 3y ago
  The standards are fine. The problem is that the front end web is the DOM. I love the DOM, but it scares the shit out of people. Most people would rather cut their hand off or sell their children into child slavery than walk the DOM with 3 instructions. Its super weird and gets more weird when those people are actually confronted with this irrational behavior.

sureglymop 3y ago

If you use htmx what backend technology do you choose?

acaloiar 3y ago
The beauty of htmx is that it doesn't matter what you use on the backend. Literally anything that'll render HTML will suffice. Even static HTML files on a web server will do. No need for an application server at all if you're clever and your needs are simple.
- sureglymop 3y ago
  What if I want the website to work even when JavaScript is not turned on? I'd need a backend server and some frontend logic handling that case.
  - iudqnolq 3y ago
    Not necessarily. It depends on what you need. For example suppose you were implementing an news reader with two panes. Left pane is a list of titles and previews, right pane is a full article for the selected item in the left pane. You can make the left pane a list of links to dedicated pages, and then add an htmx attribute to indicate that when the user has JavaScript to instead fetch a html snippet with just full article and swap it into the right pane. If you had a reasonably bounded set of articles you could statically generate all the /article/id.html and the /article/id/snippet.html files, though a backend probably makes sense.
    - sureglymop 3y ago
      At that point, how big is the difference really between sending the right pane only as opposed to the whole page performance wise? I'm just not sure if this approach is worth it for me.
  - wishinghand 3y ago
    In that case you need to have everything rendered server side and perhaps get creative with the usage of forms firing off events that can be intercepted by the server and then return a new page. Certain things like Nav menu drop downs and folding text can’t be done with native CSS and HTML.

ksec 3y ago

I still wish 80 to 90% of those JS function on the list should be part of HTML5 and not as a JS library.