Hacker News new | past | comments | ask | show | jobs | submit login

I think my attitude to this stuff evolved after seeing that even with all the work we did with HTML, virtually nobody actually benefits from it.

In theory, HTML is device independent. In practice, we can't even get web apps to work on desktop and mobile, to the point where even sites like Wikipedia, the simplest and most obvious place where HTML should Just Work across devices, has a whole fricking separate subdomain for mobile.

In theory, HTML gives users ultimate control over presentation. In practice, after _years_ of trying to make alternate style sheets a reality, not a single browser in common use even has a UI for them. Nobody cares. A few people with extensions might occasionally make some minor tweak, but that's about it.

In theory, HTML is accessible. In practice, despite decades of advocacy, basic sites fail utterly to be accessible even for basic things because people ignore all of HTML's semantics, they just bolt things together to work for the common sighted able-bodied user and then, _if they are paid enough_, they _might_ just slap on some ARIA attributes to make it vaguely work for people with accessibility tools.

If HTML was all the things we wanted it to be, we designed it to be, if reality actually matched the fantasies we tell ourselves in working group meetings, then mobile apps wouldn't be written once for iOS and once for Android and then once again for desktop web, they'd be written once, in HTML, and that's what everyone would use. You wouldn't have an app store, you'd have the web. You wouldn't follow a link on your phone only to have it redirect to a locally-installed non-web application, it would just stay in your browser. Developers are scrambling to get out of the web and into the mobile app stores.

The reality is that for all of the work that we've put into HTML, and CSS, and the DOM, it has fundamentally utterly failed to deliver on its promise.

It's even worse than that, actually, because all of the things we've built aren't just not doing what we want, they're holding developers back. People build their applications on frameworks that _abstract out_ all the APIs we build for browsers, and _even with those frameworks_ developers are hamstrung by weird limitations of the web.

The parts of the web that have actually delivered are the ephemerality and the security model, the indexability (but only for content, not apps), deep linkability, and the platform-independence. We can keep all those, and throw out the decades of legacy that's holding us back, and we will lose nothing, we will only gain as we unleash the kinds of amazing interfaces that developers can build when you give them the raw bedrock APIs that other platforms already give their developers.




Ultimately, HTML/CSS are too low level tools for most people. We should have had Flutter/AMP like features (sans specific company dependency), right in the browser.

It'd been amazing if people can write <appBar></appBar> and get a consistent appBar that works in different display sizes and comes with accessibility built in; in all browsers. We have done so, in flutter, in iOS, in Android. But why did the browsers never bother? I remember HTML4 feeling dumb and HTML made more sense when I learned about HTML5 proposal. It finally made sense how HTML should progress but then suddenly, after years, everything is still the same?

As for your last paragraph, you mention how web actually delivered in terms of indexability and I'm really disappointed that Flutter (your primary focus right now I assume) is not prioritizing this. Flutter is amazing but it really needs to deliver what web delivered and them some.


Thank you for all of your work, but kindly, you just built the wrong things. No one needed <section> and <aside> they needed <tabs> and <accordion>. The story goes that you grepped the whole web and discovered folks needed section and aside. Why didn't I see them anywhere in my work as a developer? And why didn't they do anything?

Also, the quality wasn't there on what you shipped. The form controls are ugly and non-functional. They needed to be designed, *by designers*! Not everything is an engineering problem.

You only kind of achieved the first part of the extensible web manifesto, and never even tried the second part (paving the cow paths with higher level solutions).

And now the WhatWG is as stuck as HTML/XHTML ever was at the W3C. Maybe even more so. You got so much done, but by force of personality instead of systems that encourage contributions from lots of diverse people. Dictatorships are never going to work without the benevolent dictator. They are inherently unstable systems.

The focus on web components was a decade+ long distraction that didn't take into account the needs of framework authors but instead saw them as a competitor. It was a solution looking for a problem. I interviewed around 30 developers and almost all of them said they either tried WC and didn't like it or hadn't tried it and didn't want to.

* One dev said, "web components only kind of fixes a problem I had 10 years ago." * Another, at a co that uses WC extensively, said, "web components are a solution to big company problems but know using them will add a year and a half to any development timeline." (paraphrasing, but you get the idea) * Even a company built around web components said that it wou ld really be better as separate technologies rather then bundled, "give me style scoping separate from templating and slots".

You didn't solve the problems devs find challenging. Frameworks do. The existence of frameworks on the web is a feature, not a bug. And the reasons people use frameworks are diverse, but range from: team dynamics (having one right way to do things, documentation, easier to TL) to literally making it possible for devs to ship the features they are asked to ship. You can't really argue with, "I couldn't build these complex features without frameworks". These devs don't want even lower level solutions.

Developers mostly don't want the assembly language of the web, they want their chosen frameworks to have excellent DX and the UX they produce to be fantastic. When we see frameworks as a core customer/partner for web APIs, things turn out a lot better.

And, now for my childish moment, I told you back then about design systems and the need to support them properly. I told you it was the way folks were going to be building UI soon. You didn't listen. And that set the web back 10-15 years. I literally had to get a job as PM of Web UI at Chrome to correct this mistake. That is happening now. We're shipping container queries, scope, nesting, style queries, state queries and a host of other features devs tell us they need to architect component systems. I know "people are going to be building pages made out of 100s or 1000s of components" probably sounded wild at the time, but that is the thing about listening to your developers, they know what they need. They understand the biggest problems they face. As a PM, every day I assume I don't know what devs need, so I ask them.

HTML is an incredibly accessible technology for nearly any new developer, designer, or content creator to learn in a basic way. That is a strength that should weigh in heavily. We don't need to throw out HTML and CSS... we just need to fix mistakes that were made.


*hugs* sorry for my failings


> the kinds of amazing interfaces that developers can build when you give them the raw bedrock APIs that other platforms already give their developers.

They don't provide just the "raw bedrock APIs". They also provide a plethora of high-level APIs, including controls, layouts etc.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: