undefined | Better HN

0 pointsdanShumway6y ago0 comments

> Would it blow your mind if I told you that you can create a complex treeview without having to use third-party libraries

No, not any more than C#'s giant standard library blows my mind.

Keeping the web small is a strategic decision -- it may look like chaos, but it's really just that we realized that embracing 3rd-party libraries is a better architectural decision than polluting the core spec with features that will be outdated in a few years.

QT doesn't have these problems because QT doesn't have to be infinitely backwards-compatible. If QT makes a mistake, it can fix it in the next version. The web can't do that, so we have to be more careful. If anything, my biggest criticism of the web is that we move too quickly and stick too many "modern" features in. I would have been happy to drop Classes and Arrow Functions from the JS spec, and I would have been happy to drop `sticky` from the CSS spec. As an engineer, I absolutely don't want a hamburger menu as a core HTML component.

I've had people argue to me that HTML needs more 2-way data binding and element types -- they want the ability to tie a list to a JSON object or something, instead of needing to render out separate `<li>` elements. These people are missing the point.

HTML is your user-presented state. We have a few elements that break this convention, but for the most part we want your final HTML to be static and human-readable. It's not for you, it's for your users. And 2-way data bindings would get in the way of that.

For laying things out and creating complicated lists, we have third-party libraries/frameworks -- and honestly, they work fine. If you think the web is overcomplicated or has too many frameworks right now, just wait until we start stuffing a new first-party component into it every time any design trend becomes popular.

And even if we did add all of that nonsense, people would just ignore those components anyway. No manager I've ever worked with has ever said to me, "you know, pure HTML select inputs look great and I don't mind them rendering differently in different browsers." I would be reimplementing them in JS anyway just to get the styling consistent between IE and Firefox. The good HTML components I can actually use are the low-level ones like simple input fields -- because they're small and simple enough that they can be styled and incorporated into larger custom-built solutions.

Heck, I've had managers complain to me about scroll-bar styling before. But sure, they'd totally be happy with a giant, pre-built, monolithic tree-view component that's using mid-2000s styling.

0 comments

simias6y ago

I'd argue that the problem isn't so much backward compatibility than being opinionated vs not. Qt knows what it's doing, knows what it isn't doing and then from there defines the perimeter of its APIs.

For better or worse the web never did that work, HTML+CSS+JS is meant to be both a way to make static websites, but also interactive e-shops, but also mail clients, but also videogames, but also ultra-heavy single-page apps like Discord etc...

And that's the greatest power of the web, but I can't see how this state of affair won't lead, one way or the other, towards a more monolithic architecture. Keeping HTML and CSS cleanly separated and JS only for the fancy stuff (but always optional!) is noble but it's a pipe dream when the use cases are so diverse. WebAssembly, or something like it, seems to be clearly the path forward.

Overall I think we should be happy too, at least it's not a closed source blob. Remember how long it took us to get rid of bloody Flash? Actually if Steve Jobs hadn't decided to drop it from iPhones I wouldn't be surprised if it had survived in common use to this day.

joshuarubin6y ago

It's hard to identify specific decisions made by Jobs from the outside, but killing Flash on the iPhone seems like something _only_ Jobs could have done. Sure he and Adobe were in a tiff... Anyway, it's likely that this is a rare case where one person making a unilateral, perhaps tyrannical, decision benefited the whole world.

BlueTemplar6y ago

The fancy stuff can go live in apps, it has nothing to do in a browser designed for webpages first. I mean, just compare the GUIs of VLC and YouTube!

shadowgovt6y ago

But with the strong advantages of access to the Internet that a website brings (which is itself a whole bag of hard problems to solve), the appeal of building things accessible via browser user-agent (regardless of what the thing is) is huge.

It shouldn't be necessary to toss out the cookie jar, the HTTP connection handler, the XSS protection just because one wants to do something a bit different with the final rendering stage.

1 more reply

millstone6y ago

Complicated lists on the web are really bad. If you have a lazily populated table, it breaks the browser's Find, it typically breaks the scroll bar positioning, there's visible holes while it populates, scrolling is janky slow, the scroll bar will jump unexpectedly.

This is one place where HTML does not give enough primitives for a quality library-based solution.

pier256y ago

> These people are missing the point

Maybe not.

If data binding, dynamic markup, reactivity, etc, were baked into browser we'd save a ton of kbs and CPU cycles.

j / k navigate · click thread line to collapse