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

421–430 of 551 posts

Re: HTML First

#421

Post by caseyross »

I wholeheartedly support this. But frameworks exist for one simple reason: HTML has never been powerful enough for the work people do.

The last two decades of web UI framework development has shown, over and over, what people need out of HTML that they're not getting. Componentization is one big area, and fortunately, it's already far along the path of integration into the native web platform. But there's another, bigger, area, which has not seen a single ounce of integration into native HTML: reactivity.

So what if we could just solve that? What is preventing us from adding native reactivity to HTML, a language that already contains numerous interactive elements and hard-coded ties to JavaScript? Seriously, why is this not already implemented when we have things like Shadow DOM out there already?

We could get a huge amount of impact with just minor changes. In my view, HTML could meet 90% of peoples' reactivity needs with just two simple tags:

1. ``: Renders as a text node that shows the current (live-updated) value of the referenced JS variable. If the value is undefined, renders nothing (special case).

2. ``: Renders as its children if the referenced JS variable is truthy, and as nothing if the variable is falsy.

That's it. Just these two almost-trivial tags would solve an incredible amount of use cases. And with sufficiently expanded componentization (say, React-style props for ``), the web platform would be well positioned to cover all others in time as well.

Re: HTML First

#422

Post by Izkata »

divbzero wrote: post #273
c-fe wrote: post #246

Earlier quoted context omitted.

Quick thought regarding date pickers, specifically: > Is the look/feel/controls consistent across browsers? (No.) Can we style them to get there? (Also no.) Assuming you design this website for users. Each users may use a different browser, but they probably use this same browser for all websites they visit. Hence IMO its more important that date pickers are consistent across all websites on 1 browser, then across 1…

This applies beyond date pickers too. To me, usability trumps consistency when your users access the website across a variety of platforms: mobile vs. desktop, touch vs. mouse, etc.

> etc.

Screen readers and voice input: https://a11ysupport.io/tech/html/input(type-date)_element

Re: HTML First

#423

Post by Izkata »

hoosieree wrote: post #408
arcanemachiner wrote: post #350

Earlier quoted context omitted.

ISO-style timestamps are the only only one that makes any sense. YYYY-MM-DD or GTFO.

no need to fight over it, compromise is both elegant and simple: YMYY-YD-DM

Non-jokingly, Kazakhstan has YYYY-DD-MM

https://en.wikipedia.org/wiki/Date_format_by_country

Re: HTML First

#424

Post by epiccoleman »

philihp wrote: post #97
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…

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…

> starting a project following this advice would be a good opportunity to learn why we do the things we do like build steps

Honestly, and sarcasm aside, I think this is an incredibly important thing for any new web developer to do.

Trying to learn web development in 2023 (or even in 2014, when I started my career) is so hard, because you're constantly standing on top of the shoulders of giants without even knowing how far you are from the ground.

I started a refresh of my personal site a few months back and resolved to write all the html and css "by hand", vanilla style, as a way of forcing myself to relearn the basics, and it was really refreshing to strip away all the layers of extra stuff and build it with simple tools. And I actually learned a ton of stuff that was useful on a daily basis while I worked on a React project during my day job, stuff that I just had never had to do or learn or use because some framework was always helping me out.

Recently I've been working on a little toy app in Phoenix, and I had the "revelation" that Eex / Phoenix components were slowing me down instead of speeding me up, because I didn't understand the underlying concepts as well as I needed to. As soon as I said "fuck it, I'm writing vanilla html and only using Eex where it's absolutely necessary" I was able to get through a whole host of issues that were giving me friction and actually build what I wanted.

I had a similar experience a few years ago when learning Phoenix. I just didn't get Ecto at all, and the reason was simple - I didn't know SQL and database design. Once I resolved to just figure out how to do the thing I was doing with raw SQL, Ecto immediately made way more sense.

We obviously can't peel back layers of the onion forever, or we'd never get anything done. At some point you have to get comfortable with abstracting away the details. But what I've found in web dev is that the big frameworks are written by people who've done the "vanilla" way so much that they've identified places where things hurt and built solutions that abstract that pain away. That's all well and good when you understand why the abstraction exists and the problem it solves, but it can really be confusing before you've put in the work to gain some of that context.

Re: HTML First

#425

Post by marwis »

josephg wrote: post #372
zlg_codes wrote: post #321

Earlier quoted context omitted.

I can't disagree with making sure you're using them when they matter and avoiding them when they don't. There was no real 'war', XHTML 5 is still a thing. Browsers are HTML engines because people who write HTML don't want to be forced into well-formed markup. They want the browser to guess what they meant and run with it. There's also the whole "we need to be compatible with almost every HTML file dating back to the…

> There was no real 'war' There was definitely a debate over how web browsers should interpret web pages - as XHTML or "quirks mode". HTML5 (with infinite backwards compatibility) was the outcome. Every major web browser implements HTML5 - complete with its super quirky and complex, but fully specified and consistent parsing rules. > XHTML 5 is still a thing. Is it though? On the web? I just tried, with this html: yo…

You need to serve it with the right mime time (application/xhtml+xml) or in case of local files use .xhtml extension. Then it's processed as XHTML and rendered as expected.

Also you need namespace declaration otherwise it will be rendered as unstyled xml.

This is all part of HTML5 spec: https://html.spec.whatwg.org/#the-xhtml-syntax

Re: HTML First

#426

Post by smegsicle »

caseyross wrote: post #421

I wholeheartedly support this. But frameworks exist for one simple reason: HTML has never been powerful enough for the work people do. The last two decades of web UI framework development has shown, over and over, what people need out of HTML that they're not getting. Componentization is one big area, and fortunately, it's already far along the path of integration into the native web platform. But there's another, bi…

whats keeping them from being provided by an import as in htmx?

Re: HTML First

#427

Post by firecall »

ativzzz wrote: post #231
jasonwatkinspdx wrote: post #216

Earlier quoted context omitted.

37 Signals has adopted some of these ideas. Would their apps qualify as "big" for you?

To be fair, 37 Signals (Basecamp) which is behind ruby on rails, changes their front end philosophy with every new major version of rails And to be fairer, it's generally a pretty good philosophy for greenfield apps at that particular point in time, but if I started an app on rails 4 or 5 there's no way I'm updating my front end every time they change their minds about how front end should work They believe this now,…

I wouldn’t say they’ve exactly changed their philosophy.

To me it seems more like they’ve evolved it.

From Rails UJS using jQuery, to vanilla Js, then TurboLinks and onto today’s tools like Turbo and Stimulus.

The evolution isn’t a bad thing, and the older approaches still work in modern rails.

They’ve changed and updates the build tools, but then you have to keep up.

They went from Sprockets, to Webpacker, and then module loading to replace Webpacker.

So they’ve haven’t changed philosophy as such, it’s just considered and measure evolution and refinement.

Feels that way in practice to me anyway! :-)

Re: HTML First

#429

Post by robertoandred »

Xeamek wrote: post #356
robertoandred wrote: post #293

Earlier quoted context omitted.

But all it is is fancier fetch()s. It can't remotely approach the functionality of React, so it just shifts any complexity to different places.

Yes, it shifts complexity to the backend. Which will already have it anyway (because it has to), has better tools to manage it, you can use literally anything you want instead of being forced to use javascript, has (relatively) instant access to the authoritative source of truth, and isn't resource constrained (at least not the same way that the client is). so "just shifts it somewhere else" might be underselling it…

And waiting much longer than an instant for a million server requests every time a template changes on a page is not a good use of those resources.

Re: HTML First

#430

Post by alethiophile »

joshghent wrote: post #383

The author raises some interesting points. But these arguments seem a little tired now. Does a customer actually care what technology you use - absolutely not. If react is easier for you, go for it. If that’s HTMX - fine. What matters is speed of delivery of new features. And react has huge amounts of support (and a large developer base) that makes development quick and cheap. I’ve never understood these html purist…

The customer probably cares if your app takes five seconds to load because of the resource size, or reliably pegs a CPU core whenever you're using it.

Of course, neither of these things are guaranteed in a React app. But they're definitely way easier to back into by accident.

Post reply on HN