React was designed to solve all these problems. Now these problems are used to solve react. Programming, like life, is a flat circle.
HTML First
21–30 of 551 posts
Re: HTML First
#22Re: HTML First
#23> Where libraries are necessary, use libraries that leverage html attributes over libraries built around javascript or custom syntax
And then they demo using _hyperscript [0] as encouraged. However, that's a library built around a custom syntax. It's only using an HTML attribute to encode a script that's in a new language you need to learn. Is this serious?
Re: HTML First
#24React was designed to solve all these problems. Now these problems are used to solve react. Programming, like life, is a flat circle.
Re: HTML First
#25“Locality of behaviour” is such a poorly defined rule. It’s just an invented name for going against separation of concerns. Calling CSS “spooky action at a distance” is a massive stretch too. Good principles here but the arguments are quite weak and could be much simpler.
Customization isn’t required as long as defaults work. As such the efficiency gains from CSS etc take a back seat to simplicity.
Re: HTML First
#26> Where possible, default to defining style and behaviour with inline HTML attributes
but their example wouldn't work.
should probably be
which I think makes it a little more clear how weird this could get if you wanted to add more styles. You just keep growing the params passed to the ClassList add method, in a string. I would personally find
button:active { background: green; }
to be much more readable, but the author seems to imply this is complicated due to their approach of "Locality of Behaviour".--
> Where libraries are necessary, use libraries that leverage html attributes over libraries built around javascript or custom syntax
I totally agree! But why is your example of a library not built around javascript or a custom syntax feature:
That "on input put me into #output" I think is more jarring that the library shown as the bad example. Even better, this could just be some JS, without a framework at all.--
> Prefer "naked" HTML to obfuscation layers that compile down to HTML
Their example is to not use Rails ERB tag helpers, in your templates. I don't think this is that big of an issue, these helpers can actually handle a lot of things that will look messy if you use the minimal amount of templating to write them. The example leaves off unique dom ids, turbo tags (very HTML/no JS focused!) and iteration.
Re: HTML First
#27I want to agree with this based on the title, but why would you do something like this: Click me if you're already using React? Yes the React code is a lot more verbose and has a bunch of "cruft" for lack of a better word. But you're already using it for the rest of your site, so you should (IMO) continue using it rather than mixing and matching approaches.
Re: HTML First
#28This is a blog spam post written by an author that has no credibility in the space rather than creating an agency that touts itself as "A software agency that doesn't suck.". How bizarre. Even more, the author uses every possible library under the sun, from Tailwind to Framer, only to evangelise about raw HTML and topics he provides no credibility on. To add to that, even the links to learn more about their agency al…
Re: HTML First
#29My experience has been that proponents of HTMX and the like skew heavily backend and never feel comfortable with CSS.
Why listen to UX thoughts from a population who are scared of UX?
Re: HTML First
#30In my current company we started with HTML and embedded JavaScript at the bottom and Styles at the top. Everything in one file, very easy to find and understand.
It was "a little bit" slower. Pagespeed Insights didn't like it.
Now we are "modern" with CSS and JS in a build process. And nobody knows which file to look at...
My new Projects will start with HTML first, again.
My credibility: 45 years, commercial web programming >25 years, 3 successful web companies founded as CTO