←back to thread

Less Htmx Is More

(unplannedobsolescence.com)
169 points fanf2 | 6 comments | 08 Apr 25 08:42 UTC | HN request time: 0.22s | source | bottom
Show context
kolektiv ◴[08 Apr 25 10:12 UTC] No.43620012[source]▶
It is amazing how quickly a simple, traditional, "collection of pages" type website actually works if you don't do annoying things to slow it down. Most websites would be absolutely fine if a) HTTP was used reasonably well to set things like cache headers, and so (as mentioned in the article) and b) if a load of user-irrelevant stuff like tracking and advertising code wasn't thrown in as well. A simple page with standard HTML, passably optimised assets where needed, and only the JS needed for actual functionality, should be almost instant on most modern connections.
replies(3): >>43620362 #>>43620363 #>>43620930 #
1. Manfred ◴[08 Apr 25 11:14 UTC] No.43620362[source]▶
I believe some of these issues are caused by framework abstractions.

New developers learn the framework and never learn how HTTP and HTML work.

Experienced developers have to learn how to punch through the framework to get to these features we get automatically with statically hosted assets.

replies(4): >>43620425 #>>43620499 #>>43620782 #>>43622435 #
2. kolektiv ◴[08 Apr 25 11:25 UTC] No.43620425[source]▶
Very likely. I remember reading a while back about developers who thought of rendering things on the server side as novel, which was absolutely wild to someone who was writing web pages before JS was a thing! It's such a shame because HTTP + HTML is actually a very, very simple system to learn with literally decades of hard-won knowledge baked in (particularly HTTP and surrounding standards). People end up inventing incredibly complex solutions to problems that could have been alleviated by reading a few RFCs.
3. thrance ◴[08 Apr 25 11:36 UTC] No.43620499[source]▶
I don't believe you can break past "absolute beginner" without learning some HTTP and HTML. Most JS frameworks aren't very good abstractions (which is fine).
replies(1): >>43621319 #
4. codegeek ◴[08 Apr 25 12:12 UTC] No.43620782[source]▶
Pretty much. I can't tell you how many times I interview these "framework developers" and they cant tell me how a regular HTML form submission works. Boggles my mind.
5. skydhash ◴[08 Apr 25 13:04 UTC] No.43621319[source]▶
They know the keywords, but not how everything fit together, even in the basic sense.
6. xiphias2 ◴[08 Apr 25 14:49 UTC] No.43622435[source]▶
As you can see even the basic documentation is compromised at this point:

https://unplannedobsolescence.com/blog/behavior-belongs-in-h...

<button onclick="alert('I was clicked!')">Click me</button>

,,You can find HTML attribute equivalents for many of the event handler properties; however, you shouldn't use these — they are considered bad practice. It might seem easy to use an event handler attribute if you are doing something really quick, but they quickly become unmanageable and inefficient.''

,,You should never use the HTML event handler attributes — those are outdated, and using them is bad practice.''

And then proceeds to suggest this:

<button>Click me</button>

<script> const btn = document.querySelector("button")

btn.addEventListener("click", () => { alert('I was clicked!') }) </script>

After this, next step would be putting javascript to a separate file, and on a slow mobile connection in a random airport with thousands of people using the same wifi, a simple working code gets timeouts.

20 years ago all I needed to know was this, and it worked great:

<button onclick="alert('I was clicked!')">Click me</button>