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

431–440 of 551 posts

Re: HTML First

#431

Post by dools »

I published this article on Template Animation (aka DOM Templating) 12 years ago:

https://benkoworks.com/your-templating-engine-sucks-and-ever...

It fits nicely with this goal. My colleagues and I created a tool that allows HTML developers to work in HTML by compiling HTML using a Chrome extension, and then allowing developers to compile the same in their code platform of choice and operate on the DOM:

https://github.com/iaindooley/Fragmentify

https://github.com/iaindooley/fragmentify-js

Even if you're doing a SPA you can use this same method, by sending updates over the wire and doing the processing on the server. We created a standalone package that facilitated that by loading the initial page from the server then transparently allowing the server to send just the changes to the page and having them applied on the client side:

https://github.com/dgrinton/remote-standalone

The combination of "remote" and "fragmentify" and Template Animation/DOM Templating, in my opinion, would be a tremendous "retreat to move forward" in web development technologies.

Re: HTML First

#432

Post by Izkata »

zlg_codes wrote: post #292
josephg wrote: post #215

Earlier quoted context omitted.

Yep. It’s one of a handful of void elements along with and . Also using a slash to self close a tag is not part of the html spec and it never has been part of the spec. The browser doesn’t know what that means on any tag. If you write the browser ignores the slash and thinks you still haven’t closed your Div.

I'm adding context to this because you're only telling part of the story: self-closing tags are necessary for void elements in XML and XHTML, both technologies that are still supported on the Web. Since XHTML processes HTML as XML, it forces it to be well-formed. Unlike HTML, which has all sorts of tag-soup and quirks modes and other things, because it's lax in its syntax. Void elements lacking the need for a closing…

> Void elements lacking the need for a closing tag or closing slash is one of the weird edge cases in HTML. While it's not in the HTML spec

It's explicitly in the HTML5 spec as allowed, but not required.

Re: HTML First

#434

Post by notjoemama »

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

I'm not aware that an inline style, and particularly the inline JS in their example can be nonced to prevent script and style injection.

So no. I will not be following that part of the guideline. Not until the security aligns with reality.

Re: HTML First

#435

Post by evantbyrne »

willsmith72 wrote: post #164
evantbyrne wrote: post #79

Earlier quoted context omitted.

It might be easier to staff for. But developing a React frontend takes way more time than just server rendering HTML and layering in JS for the vast majority of use cases.

that's just speculation. I can say also anecdotally from my experience, developing a react frontend takes way less time.

I'm speaking from experience on a pretty wide variety of commercial web projects. Been building websites for twenty years. Frankly, it's not even a close competition. What I've found is that a lot of teams don't even track their time, so it's likely many developers don't realize how large the React penalty is. I would encourage devs to spike on both approaches and do a thorough accounting of their time.

Re: HTML First

#436

Post by chii »

gedy wrote: post #415
resonious wrote: post #396

Earlier quoted context omitted.

I tried to push for an "HTML first" style frontend at my job, but we hired some run-of-the-mill frontend devs and they basically didn't get it and just wanted everything to be divs with VueJS controlling all of the logic and content. One semi-objective thing we lost was accessibility. Much of the site is impossible to navigate via keyboard due to naively re-implemented behavior like links being divs with click event…

> One semi-objective thing we lost was accessibility. TBH that's not a framework vs HTML issue, that's just sloppy or inexperienced devs

I argue that it is a framework issue.

If the rendering framework doesn't support accessibility as a first class citizen (or better yet, automatically creates/makes accessibility part of what is rendered), then the framework is not suitable for production use.

Re: HTML First

#437

Post by wackget »

> "Prefer vanilla approaches using HTML"

> Proceeds to insert JavaScript and CSS into HTML attribute.

> "HTML is easy to understand"

> Proceeds to import external JavaScript library which uses an ultra-obscure, totally unclear HTML attribute `_=`

Re: HTML First

#438

Post by skydhash »

docmars wrote: post #402
zztop44 wrote: post #284

Earlier quoted context omitted.

But very often it is software development. And there isn’t always some bright line between them. Like it or not, the web is an excellent platform for delivering software applications to users, especially one-off or infrequently used applications. Let’s use software development tools, rather than web publishing tools, to develop that software.

It's worth mentioning that the friction to deploy a web app is nearly zero these days, depending on how complex it is. As an example, shipping a macOS or iOS app, via official means, requires a lengthy review & approval process, upfront costs, buy-in into native languages with little to no use outside of these platforms, a limited selection of tools, and hard decisions about which version of the OS to support based o…

My preference is local first desktop applications. Sometimes it’s because I prefer files, sometimes it’s because native apps are more fluid and more egonomic.

Re: HTML First

#439

Post by LudwigNagasena »

chii wrote: post #436
gedy wrote: post #415

Earlier quoted context omitted.

> One semi-objective thing we lost was accessibility. TBH that's not a framework vs HTML issue, that's just sloppy or inexperienced devs

I argue that it is a framework issue. If the rendering framework doesn't support accessibility as a first class citizen (or better yet, automatically creates/makes accessibility part of what is rendered), then the framework is not suitable for production use.

React simply diffs the DOM and updates it in an efficient way. If you are putting weird divs instead of anchors and buttons (or instead of special components provided by a React-based framework), that's entirely on you.
Post reply on HN