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

121–130 of 551 posts

Re: HTML First

#121

Post by wheelerof4te »

codeptualize wrote: post #89

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…

"I really don’t see how these would work in anything other than very basic scenarios, even less how they would achieve the objectives."

Well, what are the objectives? If they are complex, so should the code be complex. That's the nature of our job. By adding an advanced framework you up the complexity by default. Instead of adding more code, you add more build dependencies. This is especially wasteful on websites.

In my opinion, people today are afraid of writing code. Everyone wants some framework to write code for them. That is not how we push our industry forward.

Re: HTML First

#122

Post by codeptualize »

jackblemming wrote: post #111
codeptualize wrote: post #89

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…

[flagged]

If they did I'd honestly love to get the details and be proven wrong.

With just this list it's hard to imagine how this would work.

The only scenario where I can sort of imagine it being potentially helpful is an agency setting with many not-too-complex projects and limited ongoing development. I can imagine updating projects being a hassle. That said I don't have experience in that field, and I bet there are other ways to deal with that.

Re: HTML First

#124

Post by x0x0 »

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 a hint of why people eg prefer not defining styles inline (protip: fun at first. Now try changing one of them... have fun reviewing 3000 inline bits of css.) Like the industry settled on certain things for a reason, and you don't even attempt to engage with that reason.

You also cite dhh when you like his reasoning and ignore him when you don't. about which, well...

Re: HTML First

#125

Post by sylware »

I would add that for noscript/basic (x)html version of web sites, 2D "semantic" HTML documents are not harmful, and table navigation is ok for screen readers if not done too weirdly.

Of course, I am not talking about the abomination of "semantic web" we had a decade ago.

Re: HTML First

#126

Post by pphysch »

corethree wrote: post #94
pphysch wrote: post #24

Earlier quoted context omitted.

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.

There won't be a repeat. WASM is a clearly better compilation target than JS, and browsers have greatly improved the "vanilla" DX.

TypeScript ecosystem is the Enterprise Java of this decade, except it's built on shakier foundations, i.e. you can run some ancient JVM, but good luck relying on an ancient browser version & node dependencies. There will probably still be tons of job-security in the next couple decades, but it's not forward-looking technologically.

Re: HTML First

#127

Post by didip »

I like the spirit of the article.

My personal preference is server side templating using as much default HTML as possible with JS as progressive enhancement (using HTMX or something similar).

Re: HTML First

#128

Post by cphoover »

corethree wrote: post #94
pphysch wrote: post #24

Earlier quoted context omitted.

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.

Yes, I remember when Microsoft FrontPage was the go to wysiwyg editor for web development along with Dreamweaver most styles were added inline.

At some point wysiwyg editors fell out of favor as they generated both unmaintainable styles and markup.

Style sheets took hold and the insanity that was inline styles were dropped in favor of external style sheets.

Today we have tailwinds.css and inline styles are coming back in vogue.

Wysiwyg editors are coming back in the form of code generators that convert designs into react components.

This author is even a proponent of inline event handlers which were the standard way of doing things before JavaScript really became a powerful language and added "addEventlistener".

Flat circle repeated over and over again.

Part of me wonders if these authors are just too young to remember those days. Otherwise why wouldn't they mention the historical context when writing these kind of articles?

It's funny when younger people espouse these new ideas as new and revolutionary when really they are a return to older patterns that fell out of style for whatever reason and are now being resold with different packaging.

Re: HTML First

#129

Post by evantbyrne »

corethree wrote: post #92
robinhood wrote: post #21

Earlier quoted context omitted.

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.

Agree to disagree. Building a React frontend is extremely complicated compared to server rendering HTML with progressive enhancement. It introduces state management to the frontend for even the most basic tasks, which is not something most web applications benefit from. When I built my CI/CD platform (Beaker Studio), the React portion probably added a solid 50% extra time to the project and really did nothing for it functionally.

Re: HTML First

#130

Post by willsmith72 »

> If a developer who has familiarity with HTML but not with your backend framework looks through your view files, they should still be able to understand 90%+ of what they see

I don't see why this is beneficial

" Click Me "

I don't like this at all

Post reply on HN