Live data from Hacker News

HTML First

html-first.com

91–100 of 551 posts

Re: HTML First

#91

I love the ideas here, but honestly the examples are a bit weak here. > 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 butt…

>> Where possible, default to defining style and behaviour with inline HTML attributes

This was my critiquing point as well. Style configurations should be separate from actions, with only references linking the two. It's the only way that makes sense for anything meaningful.

Yes, I could technically write a python app where all SQL database connections have hardcoded SQL as one one long file, but that is poor practice. This suggested principle seems the same to me.

Re: HTML First

#92

React was designed to solve all these problems. Now these problems are used to solve react. Programming, like life, is a flat circle.

No, it was designed to address problems that were not solvable by the then-current state of simple technologies.

All the things React does is doable with plain javascript. There aren't any extra features added.

React was designed to address complexities. It is an abstraction.

Now we want to go backwards. Getting rid of the abstraction to get rid of complexities. But getting rid of complexities was the whole point of react.

Re: HTML First

#93
post #19

Earlier quoted context omitted.

The whole point of this essay is to encourage developers to avoid heavy frameworks like React, Vue, etc and use "lightweight" tools, including vanilla JS and native HTML features, instead.

Sure, I'm just talking about that middle ground where you're trying to go with this approach and find that you now need a bunch of JS framework features.

are you trolling? 10 people in this thread have already explained that the point is to avoid using a heavy framework, yet you keep insisting that one is necessary.

Re: HTML First

#94
post #24

React was designed to solve all these problems. Now these problems are used to solve react. Programming, like life, is a flat circle.

How was React designed to "avoid the build step" or "make View Source useful"?

React was designed as an abstraction layer on top of the source. Why?

Because the source was too complex.

Now we want to expose the source and get rid of the abstraction... Why?

Because the abstraction is too complex.

Recurse and repeat.

Re: HTML First

#95
OP Here. This got more engagement than expected, some of the bits I've picked up in discussion:

"Recommends skipping build step then mentions Tailwind": We use static-tailwind, a version with no build step, in development.

"Recommends hyperscript, a new non-js syntax" - Agree this isn't perfect & would prefer something which uses js. Was going to use Alpine but also have found that to be quite brittle in production. Nor do I love any of the libraries on unsuckjs.com, which has a good collection. We're working on something here which we'll launch at some point.

"OP should look at the recent Rails updates" - Been using Rails for 10+ years - everything we build is on top of Rails - I'll write a post on HTML First Rails at some point. I think they'll get there but currently all the named libraries (Turbo, Hotwire, Strada, Stimulus etc) are 1. Rails specific, and 2. Have a high learning curve. One of the points of HTML First is to avoid framework lock-in.

"This is a blog spam post written by an author that has no credibility in the space": Brutal

Re: HTML First

#97

This is fun in to theory and in simple examples, but show me a big project that applies this and how it made a difference. There are some bold objectives at the start that would be wonderful, but I’m a bit disappointed by the advice. I really don’t see how these would work in anything other than very basic scenarios, even less how they would achieve the objectives. I’m all for using the web platform to the max, and I…

For a frontend developer who is younger than jQuery, starting a project following this advice would be a good opportunity to learn why we do the things we do like build steps, and remember how much development sucked before HMR.

I suspect the author hasn't actually done this on a project with more than one person, supporting 99% of browsers in the wild. I also suspect they didn't run their own code, because either my screen is not as tasty, or "onlick" is not an handler of div.

Re: HTML First

#98

This seems like it came from a newbie/inexperienced dev. > substantially widen the pool of people who can work on web software codebases This isn't a problem. There's already more people who can work on web software than there ever was. > A second goal of HTML First is to make it more enjoyable and seamless to build web software Subjective. If people enjoy it like this that is fine but these shouldn't be touted as pr…

Not newbie or inexperienced, have built & managed multiple large teams & been thinking about this for a long time

https://x.com/tonyennis/status/1139071584935637000?s=20

Re: HTML First

#99
post #97

This is fun in to theory and in simple examples, but show me a big project that applies this and how it made a difference. There are some bold objectives at the start that would be wonderful, but I’m a bit disappointed by the advice. I really don’t see how these would work in anything other than very basic scenarios, even less how they would achieve the objectives. I’m all for using the web platform to the max, and I…

For a frontend developer who is younger than jQuery, starting a project following this advice would be a good opportunity to learn why we do the things we do like build steps, and remember how much development sucked before HMR. I suspect the author hasn't actually done this on a project with more than one person, supporting 99% of browsers in the wild. I also suspect they didn't run their own code, because either my…

Your suspicion is incorrect. Currently running 10 or so codebases with 8 devs using this approach. Thanks for catching the typo

Re: HTML First

#100
I made some web app with the least amount of logic in the JS, and almost all of it in a flask server, with a few ajax calls.

I have to admit that managing asynchronous js callbacks is really a pain to deal with.

JS is really an awful, awful language.

Post reply on HN