With any of this, isn’t it a, “build it and they will come,” situation?
Web Assembly, for example, is pretty pointless if browsers don’t support it. Browsers now support it, so it can be used, and that’s slowly happening.
It seems like the new document standard would need to be written, the benefits would need to be demonstrated, to the point support is integrated into the mainstream browsers, and then people who see benefit from the (I assume) easier/faster/better development, can start using it for new projects or integrating it into existing projects.
Trying to make an entirely new internet based on a new document standard would be rough. At this point, I don’t see that as a way forward, unless it brings something extremely compelling that users want and go crazy for, which can’t be duplicated with existing technology. I’m thinking Napster levels of hype and consumer desire.
But then no one bothers implementing your document format because their existing HTML already works and it's not worth investing more time into such a small userbase, and then you're maintaining even more code
As a transitive format. There are no places full of Markdown documents to read and share, where Markdown is the final display format. It's all translated to HTML.
If you did write a "markdown over http" spec and implemented a browser for it, it would be about 15 seconds before someone reimplemeted it as a JS library.
In fact, if I was trying to build "markdown over http" I'd start with the JS library. Skip the native browser application entirely.
One problem with markdown is it's technically a superset not a subset of HTML. You can put a canvas and video that's in it. It's not a great standalone format
That sounds awful. Some of my favourite thing about the web are the semantics. This like links that have common shortcuts across all sites (like open in new tab) and a rich contect menu (send to another device, archive at archive.org). I have extensions to translate text to find URL anchors in documents.
If the web primatives where WebHID + WebGPU every site would lack any of these.
Of course this would come from the Flutter people who don't seem to care about this. Flutter on web is completely unusable and often Android and desktop versions are barely tolerable.
There's no reason extensions can't be made for it as well, HTML and CSS in the browser is just rendered via Skia anyway, so it's not much different to keep the renderer but change out the underlying languages. This is in fact exactly what Flutter does.
How do you read text out of a bunch of pixels rendered on a canvas? Yes the dom is eventually rendered by Skia but still exposes an api for querying the underlying structure
Flutter also exposes the semantics tree via the DOM so you can actually still target elements, but yeah if you want to target the WebGPU elements, there needs to be a new API for that, which I believe there will be in the future because a lot of WebGPU renderer are coming out, in Dart, Rust, C#, etc.
By the prominent semantic markup advocate and Web standards developer Ian “Hixie” Hickson, who now works on Flutter and, it seems, gave up on the Web. The article proposes a modern riff on the Flash VM more or less.
It really is, it’s just that I don’t want to live in the world where his proposal is the main way to discover and deliver information. His solution to semantics going unused is motivated in the last paragraph, and I just can’t bring myself to feel any of the enthusiasm the writing attempts to convey:
> 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.
I also have to admit I simply don’t—can’t—trust a proposal to make the (path of least resistance of the) Web less inspectable when it comes from the general direction of Google, even when it’s honest-to-goodness Hixie writing one upon evidently deep reflection; the same way I don’t trust a proposal to make a compiler toolchain collect user data by default when it comes from that direction, even when it’s honest-to-goodness Russ Cox writing one upon evidently deep reflection.
(In the case of Go telemetry, I still remember how Cox responded to a privacy-related question I raised on HN—but don’t even remember now—by proposing the organization maintain an anonymizing proxy for its many employees. Which was a fairly satisfactory solution, if you’re an organization and have many employees. And it seemed clear his mind had no other cases in its working set. Maybe it’s just something in the air there.)
I don’t mean to pass judgment here, to be clear. Hixie in particular has done more to improve the open Web than most people whose explicit job it was to improve the open Web, let alone web programmers, let alone programmers in general (the only cohort of those to which I can lay even a vague claim of membership). I don’t even mean that my upfront bias here is correct or should be emulated by anybody.
I only mean to warn you that I’m just unable to engage with the proposal without considering its source, most of all emotionally, so you should keep that in mind when I say it and its apparent excitement feel bleak, like a coat of bright paint on a rusty playground slide in the midst of a concrete Constructivist slum.
His proposal is more for web apps, not web sites that have information on them, so the way he talks about all of those topics, like "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" seems much more suited to, well, interface design, rather than informational conveyance in the form of a web page. On that aspect, I agree, it's not necessary to cram a document object model into an interface design model, which is where Flutter comes from, precisely understanding that fact, and where, it seems, all the new WASM and WebGPU etc renderers are coming from too.
He also left Google yet still maintains his stance in the article, to my knowledge, if that's any consolation to you that he's not necessarily thinking about the topic from a Google lens, at least, not anymore.
A lot of people don't really feel like Flutter & the towards a modern web stack ideology are "web" apps. None of our extensions will work, our accessibility tools will all be broken.
It's an entirely new stack for apps unlike what the web is. Maybe that can be good for developers, maybe, perhaps, but gee it sure seems like a really bad bargain for users, user agency, and the technical legibility of our online world.
Yes, it's an entirely new stack, that's what the higher level commenter was talking about. I realize we've discussed this same article before but I do believe it is the way forward, for web apps at least, because the current HTML and CSS stack is really not as good as it could be, and as well, we are seeing a lot of new renderers in various languages coming out, so they'd need a new unified API. There is no reason to think that extensions would break once that new API is finished, because at the end of the day, it's all just Skia rendering the content, whether it translates from HTML or WASM.
I spent over a decade being the center of the ecosystem for something akin to web extensions for native Objective-C++ apps on iOS/macOS. I maintained a similar solution for Android/Java, and was starting work on something similar for C#.
The HTML/CSS web isn't some panacea for extensions. The code is minimized to the point of being obfuscated, and JavaScript engines provide almost no introspection into frames or closures. After-the-fact extending these apps is hard.
I would very honestly rather be sitting around in someone else's Flutter app with the goal of making some extension modification to the behavior than in someone's crazy DOM-based app, as at least the rules are clearer.
As it stands, though, HTML/CSS are just too complex. I could--probably alone, but certainly with a small team--build a browser that worked fully if the spec were something like WebAssembly connected directly to something like WebGPU.
The idea of a monopoly on browsers at that point would be laughable: we'd have a hundred of them, made by every company of any decent size, embedded into everything, and that spec would be both stable and would matter.
As it stands, we have like 2.5 web browsers at best, and I'm betting we are going to be down to 1.75 or so in the not-so-distant future. And yet, we continue to make the web MORE complicated to implement, which is simply demoralizing.
We can't even build a partial / limited browser renderer anymore, as progressive enhancement is dead now: if you don't support the full set of features then you'll run into modern React sites just giving up and showing a blank screen: even a browser that was fully capable just a few years ago is now dead in the water as it won't have all the crazy new CSS and JavaScript features you need.
And, why are we making this so hard? Because we think that the web is somehow more transparent than even a native app? It really isn't. There is a reason why we had tons of really invasive app behavior extensions for iOS and you almost never see anything integrated when it comes to web extensions: it is because the web's programming model is actually much more difficult to introspect and modify for anything other than superficial styling or wedged-in buttons that add mostly tacked-on behaviors.
There was someone recently on HN who went and added some feature to Gmail as an extension, and they seriously just bring up their own pane and require the user to have Oauth tokens for Gmail from their app, and the reason was because it is just too difficult to reach into Gmail and massively modify its behavior... but we would do that sort of thing on iOS all the time and it was not just easy, it was fun! Maybe a browser could be built that would give users the same kind of extension ability for the web--by ripping through all of the layers of JavaScript scope optimizations--but no one is going to ever build that as building a browser at all is an impossible task :/.
That's fair. One of the things that I hope Blitz's modular approach will enable is more experimentation around this kind of things. It should be quite easy to take the rendering support and add your own syntax or layout algorithms for example.
How feasible this is in practice remains to be. I'd be interested to see/hear what your vision would look like.
HTML feels quite complicated, and also it was not designed for dynamic rendering.
I like lean and kiss, and html doesn't feel like it's lean or simple enough for me.