It's 2024! Is it perhaps time to give attention to HTML?
It's a time when many people are interested in going back to the basics! Even whole teams...
For further actions, you may consider blocking this person and/or reporting abuse
Why do you want to reinvent the wheel? If you want to make HTML a programming language, you probably will fail. I tried the opposite approach including HTML into Javascript, so I get anything out of the box: Object orientation, reference encapsulation and a very powerful programming language to power this machine. HTML wasn't the best thing humanity ever invented, so it's not a shame if we don't use this language as much anymore.
I guess we've all been there with JavaScript! And I can tell you that the question isn't whether JavaScript can do magic! It's whether we're still checking the box:
✅ HTML-First + Progressive Enhancement
That said, you allude to something about OOHTML looking like a programming language. Care to clarify?
Given the task Tim Berners-Lee wanted to solve, HTML was pretty ok. Ok, you can set a letter to boldface or italic, but no color, why? Because the computers a Cern did not have colors, only green letters on a black background.
If we just want to input some text, we can use ASCI or markdown, but if we want to describe a layout, there are much better solutions than HTML. OK, they added CSS, but even this twin does not work very well together. It lacks proper scoping, is very verbose and not even use a preprocessor to ease your pain. There are good reasons why tools like tailwind are used so widely. And there are also good reasons why Wordpress is so popular. Tailwind tries to heal some misconceptions of CSS and Wordpress just ignores them.
That said I see a lot of good reasons to uncheck the box and use something more adaequate. Javascript is a good basis to implement those tools.
The whole system of HTML/CSS/JS has so many misconceptions you need to deal with using this HTML-first approach, reagardless if we use OOHTML or HTMX or whatever toolbox is created to make things slightly more usable. It will end up playing a shell game or trying to use ASCII-text to build a beautiful graphical artwork.
HTML is a markup language, very similar to markdowns and not much more than plain ASCII. It is a way to input text. It was heavily influenced by XML, which serves a similar purpose. But the time we write our letters on a black screen with green letters is long gone (ok, developers just invented the dark mode again :-) ).
Taking me longer to try to see your point. But it's a misconception that a HTML-first + Progressive Enhancement approach means no tooling! The message is right in the wording: HTML-first, then Progressive other things: JavaScript, tooling, etc.
I´m sure HTML-first needs a lot of tooling, as it is built on a weak foundation. Most of the tools used for web development today are only made to overcome the limitations of the concept.
JS-first gives you anything, even HTML if you like. But you can also use markdown, latex or whatever is helpful to create your content. Most websites are interactive graphical artwork anyway. I would not try to paint the Mona Lisa using HTML and CSS-commands (even if i could).
(image was lend from youtube.com/watch?v=2yaxGjIFLGA)
"JS gives you everything"? I know that thinking all too well! But I am happy to tell you: the web has been there!
And perhaps, this calls for a little explanation on the motivation
for HTML-first + ProgressiveEnhancement!
I like to be able to write HTML by default and progressively add JavaScript (and, in the same way, progressively involve tooling) instead of go ahead of the problem by going the other way around!
Also turns out that UIs are more resilient when built on the same principles:
I completely understand your point of view. If HTML is the right choice for your application, everything is fine. So you are writing more or less static pages with some reactive additions.
I have used the opposite approach, delivering only the text content and let Javascript do all the heavy lifting: Analyze my document, build navigation from the content, put anything where it belongs. You can do the same with a static site generator or a reactive framework, I just found that my approach removes much of the complexity of the tooling. Even responsive design is something you get out of the box with some lines of Javascript.
We had done thoroughly testing of the page performance, and it is absolutely true, HTML renders fast, very fast. But building the DOM for JS is not much slower, if you avoid some common pitfalls (mainly to load heavy frameworks). In detail, things are very complex and it is easy to cause delay´s, but it is also easy to avoid them). Anyway, the browser cannot start to display anything before CSS is completely loaded and analyzed. So, even a heavy CSS or SCSS-solution can slow anything down.
Regardless which approach you are using, you can build fast loading pages and get perfect results. It is just a question of your effort. For me it is easier to let the computer work for me than other way round.
I need to read through it again in more detail, and probably have a play... but one question that sprung up initially is: will tooling in editors be able to nicely work with the content of the render attribute? i.e. autocompletion/intellisense of function, variable names etc. from the bindings. I guess I'm asking if it is possible that an LSP package would be able to handle this? Such tooling exists for Vue etc. and is awesome.
That's something I personally want to see happen. Hopefully soon, after having settled on syntax, we should begin to see that come around on IDEs.
low-key mind blown by finding out
<?...>creates a comment in HTML 🤯Working on oohtml was that opportunity for me. 😅