Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTML First

html-first.com

Post reply on HN
Print view View original

191–200 of 551 posts

Re: HTML First

#191

Post by athrowaway3z »

Jtsummers wrote: post #23

This one confuses me: > 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? [0] https://hyperscript.org

I suspect this is a 'List of tips' written explicitly to promote hyperscript.

Its example is also pretty weak. Vanilla solutions (Tip 1) works just as well:

Re: HTML First

#192

Post by codeptualize »

timeon wrote: post #175
codeptualize wrote: post #167

Earlier quoted context omitted.

This. Even for basic websites you benefit from some form of templating/components for example to get the nav & footer on each page.

Even basic websites? It is developer vs user then. I think otherwise. I.e.: blog shouldn't be web app just because it's content management is.

Not at all. There are a lot of frameworks that support static exports and/or pre-rendering. Often those produce incredibly fast results, in many cases faster than hand rolled solutions.

If you use a CMS you have already a templating situation and dynamic content, using a framework, or jamstack like situation is not that different, depending on the specifics it might produce faster results.

Re: HTML First

#193

Post by tonyennis »

x0x0 wrote: post #124
tonyennis wrote: post #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.…

Well, also, you make some claims that could be interesting then provide zero proof or even discussion at all. The entire world: interesting in eng being more productive and interested in more maintainable software. So the first 2 sections are interesting. You then chase them with a list of assertions with zero discussion as to how they make eng more productive, or lead to more maintainable software. Also without even…

"list of assertions with zero discussion as to how they make eng more productive" - this is fair. Initial versions of the post had much more of this but I felt it added noise to the core principles. I will be following up with some more posts and real world examples though. "Like the industry settled on certain things for a reason" - In my experience An industry "settling" on something hasn't been a great indicator of its effectiveness. Industries tend to settle on practices that increase the value of its practitioners and increase barriers to non-practitioners. The legal industry, for example, is still remarkably expensive, laborious and bureaucratic, and while outsiders recognise this, there are few people within the industry who seek to change it. Thanks for the feedback

Re: HTML First

#194

Post by assimpleaspossi »

athrowaway3z wrote: post #191
Jtsummers wrote: post #23

This one confuses me: > 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? [0] https://hyperscript.org

I suspect this is a 'List of tips' written explicitly to promote hyperscript. Its example is also pretty weak. Vanilla solutions (Tip 1) works just as well:

note that the tag does not use and does not need a closing slash and never has in any HTML specification.

https://html.spec.whatwg.org/dev/embedded-content.html#the-i...

Re: HTML First

#195

Post by gemstones »

I get real confused by these.

Imagine if an iOS developer posted a blog about the specifics of files backing UIViews and how the XML configuration language was underutilized.

Wouldn’t that be kind of a weird blog post? The declarative syntax of various UI frameworks is an implementation detail. The hard part is in CSS on the web, or style properties in native frameworks. Business logic as well. Presumably encapsulated in a component, which React does well and web technologies are catching up to.

Why should I care about this, any more than I should care about XML config files on Android? It’s a markup language that is an artifact of the runtime we’re using. I don’t care about that in other contexts, and it’s the least interesting thing in a web development setting too.

Re: HTML First

#196

Post by pech0rin »

I’m sorry but what? This is terrible advice. I have never understood the desire to keep the web “inclusive”. Is the web not already inclusive? Can someone not already build a website with simple html/css?

The web has evolved and taken the place of desktop apps by and large. That is what SaaS has done. These websites are built to be fully functioning pieces of complex software. Using some tiny tools to markup html is never going to work for these types of applications.

I find this hand wringing over the complexity of the web so strange. Can we all just move on? The web has changed. I have been programming for over 15 years professionally. Yeah its changed. yeah frontend frameworks are a pain in the ass a lot of the time. So lets make it better, not fall backwards to a “simpler” time.

Re: HTML First

#197

Post by robertoandred »

max_ wrote: post #144
zelda-mazzy wrote: post #141

In theory these principles are really good concepts from an education standpoint. Where I teach, we teach students vanilla javascript and HTML as much as possible before moving on to frameworks that make things easier. Some of these points I'm a bit confused on... is the point behind "Where possible, maintain the right-click-view-source affordance" supposed to be to make the learning barrier lower? While I understand…

Have you used HTMX? I am yet to find a reason for using frameworks like React instead of HTMX.

What's the reason to use a framework like HTMX instead of React?

Re: HTML First

#198

Post by stanislavb »

For the sake of being precise - the “form_with” is not equivalent to the presented HTML. The form_with helper injects an additional hidden input element that makes sure that the form cannot be submitted “illegally”.

Re: HTML First

#199

Post by codeptualize »

wheelerof4te wrote: post #184
jaapbadlands wrote: post #156

Earlier quoted context omitted.

No one is afraid of writing code, we're afraid of maintaining code, and solving tedious and repetitive problems that already have solutions. Frameworks abstract complexity, which in practical terms decreases the complexity I personally have to deal with, and shifts the complexity to the minds of a team of open-source developers who support the framework or library in parallel. Abstraction is exactly how we push the i…

"No one is afraid of writing code, we're afraid of maintaining code, and solving tedious and repetitive problems that already have solutions." Then, enjoy maintaining React apps once React inevitably bites the dust and ends up in the JS framework graveyard.

When there are so many projects that run on React, and so many companies rely on React, it's inevitable that it will be supported for a long time to come, even if it would go out of fashion.

And speaking from experience maintaining React apps is quite nice. React has great backwards compatibility, and where it doesn't there are usually codemods available. Dependencies can be tricky, but that's not exclusive to React.

Also don't forget React evolves, backed by multiple #huge companies, and still innovating.

Re: HTML First

#200

Post by dartos »

1shooner wrote: post #183
dartos wrote: post #65

Earlier quoted context omitted.

I think there are some other benefits of tailwind. Say you have a set of css classes for different components. Then say one component on one page now needs to be styled differently. You have 3 options: 1. Create a whole new class which duplicates much of the previous class 2. Create a smaller class which is intended to override some rules from the first class 3. Factor out the common styles into smaller classes. All…

Generally this makes sense to me, and if you are just dropping markup onto the page, and don't need to worry about repeating yourself when using that component, I think that works well. Definitely better than your alternatives. But if you've encapsulated the component at all, you're going to need to manage that variant somehow. You can't just have an 'extra tailwind classes' prop, since you can't ensure your override…

I’m not entirely sure what you mean by component-level tokens, but it sounds like tailwind’s themes do what you’re saying.

Most of tailwind’s classes use css variables under the hood, so setting some of those variables in a class and apply thing that class to the top level element of a component will do the trick.

But you could have an “extraClasses” prop with tailwind. Classes that appear later in a class attribute take precedence over one’s that appear earlier.

I also thing it’s possible to mark tailwind classes as important, though I don’t like doing that.

Post reply on HN