[mamcx]

I wonder why browser makers not take full advantage of the high churn of the JS ecosystem to move forward.

Let put a end to the madness, and say "after 2020, not more in the old apis" and do a clean standard. Then take advantage of the fact html/js have tags that could declare versions, and when a old page show, use the old rendered, and when a new, use the clean one.

By then, most PC/mobile devices are powerfull enough to have 2 renders alive and the transition will be fast for more big/popular sites.

[joshvm]

Back to doctypes? I remember as a younger person being very confused at why there were about five different options. Do I use strict? transitional? xhtml?

There are multiple versions of ECMAScript, analogous to whether your compiler supports C++11/14/17/etc. It doesn't make sense to say "let's all use ES8" because ES8 is back-compatible (I think). It's up to the browser to decide what to support, and you have the same issues in C++ where some compilers don't fully support feature X.

Then, which APIs do you deprecate? How do you define "old"? Anything prior to stable is a good rule of thumb, but since JS can be loaded locally, people will use whatever they downloaded and that they know works. Some people advise not to use auto-updating CDNs precisely because a patch might break your page. And remember it's mostly down to the API developers to ensure compatibility across major browsers, not vice versa.

There's nothing wrong with vanilla JS. Really we just need to get people to be less excited about using frameworks for tiny projects that don't require them. Or you have problems like e.g. some text transition that requires loading every single version of the typeface.

[kerng]

Yes, reminds me of "we have 14 different standards. Let's implement a new one that encompasses all that is needed and obsolete the other ones. Now, we have 15 different standards"

[mamcx]

But this is exactly what is happened, just that every new one is ad-hoc, and on top of the olds. Every time a new api happened you create standard + 1 * N browsers.

Eventually, you increase ad infinitum the tech debt, or restart.

I think the cost of the whole web stack is high enough not only for the browser makers but EVERYONE ELSE. Is multiply JS (n-versions) + CSS(n-versions) + HTML(n-versions) * N Browser * N OS.

Now, what other rational option can be offered... push forward and keep doing the same and increase the tech debt? Not exist a way to refactor this?

[kerng]

I believe what will happen is what happens continuously with technology, a new layer of abstraction will evolve and thats it. Most devs want to use some abstraction layer (or build one themselves) and thats it. That's how computers work, just layers of abstractions stacked on top of each other. The underlying details, complexity but also power (eg features, security issues,..) only very few understand.

[amaccuish]

Credit where it's due: https://xkcd.com/927/

[ionforce]

> There's nothing wrong with vanilla JS.

Understatement of the century for 500.

[tannhaeuser]

Sorry but this sounds not very informed to me. HTML5, including the APIs it specifies, is already the big rewrite/consolidation of browser standards. Considering the massive investment in JS engines and browser tech since V8 came out in 2008 or so, and considering the shrinking Web, this isn't going to happen. The approach of specifying features/API levels with requirement levels declared in page metadata etc. has long been dismissed by browser developers. Even HTML5+ doesn't bother to version their specs eg WHATWG's "living standard" thing.

[cm2187]

What do you mean by the shrinking web? Even desktop apps are now using html. It feels we are going fast toward a “all gui html”, for better or for worse.

[tannhaeuser]

I meant growth wrt to the original purpose of the Web as a self-service publishing platform.

[codetrotter]

Even though the JS ecosystem has high churn there are many many existing websites that were made years ago that continue to exist and that the browser makers don’t want to break for their users.

[mamcx]

That is why I say both editions must be supported. The old and the new. But the thing is put a deprecated warning to the old so is possible to build a better new. This also will help to clean JS/CSS.

[ethbro]

Any viable improvement to the status quo needs to take multiple stakeholders into account:

Web developers - want a clean, extensible, sane system to code against

Major consultancies (e.g. IBM) - want lock-in, wide and cheap talent pool, and minimal changes (unless it's an issue they have)

Browsers - want to render whatever they see fastest and securely

Content developers and end customers - never want to have to update their site that they bought in 1995

[wild_preference]

Because now you’ll just have two problems.

[smacktoward]

The vast majority of those existing websites are being served over HTTP. Google seems fine with breaking them for that reason.

[michaelmrose]

If this is true then almost all of them will update to https and almost none of them would bother otherwise.

So I guess the question is not if its ok for chrome to break the web for half the world its if its ok for chrome to impose this cost on site owners on behalf of users for the benefit of users.

Incidentally while there may be a lot of tiny sites that don't use https aprox 3/4 of page loads are already over https. Making myrandomhomepageaboutcats.com switch to https seems a reasonable cost for making the rest of the web more secure.

[amelius]

A better approach would be to allow websites to implement their own render engine. If they don't supply a render engine, then the browser picks the default one (which, at some point, will stop being updated).

[gmfawcett]

Maybe we could give the rendering engines catchy names like Shockwave, Flash, Silverlight, and JavaApplet. :)

You can barely trust a typical Web site to run Javascript in your browser without leaking personal information to God knows who. I'm not going to trust them with a full-blown rendering engine.

[amelius]

Once people can run JavaScript and WASM in a sandboxed environment (the browser), you might as well give them the ability to run a rendering engine. There is nothing magical about rendering engines.

Comparison with Flash et al. is not accurate anymore, since these ran in an unprotected environment. Also, they were cumbersome install whereas WASM apps don't need installation (but can live in a cache if desired, and could even be shared among websites).

[dTal]

"Cumbersome installs" and "unprotected environment" were not why people hated Flash. People hated flash because it couldn't be {scraped, crawled, searched}, broke elementary browser controls like copy/paste and the back button, resulted in laggy and clunky UIs, and was excessively heavy on bandwidth. All of this would apply just as much to WASM 'apps'.

Fundamentally the problem is the conflict between the browser as an 'app' platform and the browser as a document viewer. Put simply, would you rather your user interface be 1) a magnificent piece of software with thousands of man-years put into it, debugged over decades, where every use case has been meticulously considered, or 2) a shitty script written by an overworked web developer?

[mbrumlow]

And am sure this will happen. At some point websites will start shipping rendering with webasm. I am it keen on the details but a well done one could use a canvas to do the rendering.

As a anadotal. We can already fo to websites that run vms and emulate old operating systems. I dont this it is far fetched to run a web browser in a web browser.

[wvenable]

Unfortunately that destroys accessibility. If you want to support accessibility, then you need a more complicated rendering target than something like a canvas.

[orbitur]

It will for a bit. The people who build UI frameworks in wasm will either make it a priority or they'll add it later.

It sucks but this is the way we're heading. I'm not sure web devs will even be writing HTML in 5 years beyond adding a canvas tag.

[amelius]

With modern ML, that is not true. For example, a browser could easily run OCR on the frame-buffer and read it out loud.

In fact, the approach would be more general, since a lot of text is already embedded in images on a lot of websites (think also about ads).

[Anarch157a]

In other words: "Print the file, send the printed sheets by fax to the remote office, once received, OCR them and save to a file"

Not to mention that there's no such thing as "Easily run OCR", considering how many weird fonts there are, and that they could be rendered in such small size as to make it difficult even for humans to tell them apart.

[realityking]

If you look at any platforms accessibility APIs, there’s a lot more to it than just exposing text.

The simplest example: how do you indicate a graphic or piece of text is a button or link? How do I set the alternate text if it’s a graphical button.

[amelius]

The render engine still has to do that. But that isn't much different from how it works now, where the website has to provide the necessary information.

Besides, nobody says we can't have a protocol for some additional accessibility information.

[geezerjay]

> For example, a browser could easily run OCR on the frame-buffer and read it out loud.

And then we wonder where all the software bloat comes from.

[zackbrown]

This can already be done today through canvas & webgl, or through clever combinations of DOM + JS + CSS. You can control every pixel that's rendered to the screen through the browser.

So why doesn't everyone roll their own? Some issues:

  - footprint - that whole runtime has to come across the wire just to render "hello world"
  - javascript's single-threaded tendencies make perf a big challenge
  - text rendering [this happens to be the thing the document-focused Web really excels at]
  - text semantics [SEO]
  - gigantic implementation effort [custom engines RARELY make sense even for the demands/budgets/returns of AAA games; how many websites justify this kind of investment?]

[TomMarius]

Yeah, that's because it's not really supposed to be used for that. Every single one of these is solvable if they wanted to support this use case. Ad footprint and implementation effort - of course there'd be just a few major ones that'd be cached at client side. Ad2 implementation effort, we can simply compile Qt or Gtk to WASM; it even works today, it's just slow because of platform limitations. This'd be used for applications primarily, document-oriented pages could stay HTML/CSS and HTML/CSS could be simplified thanks to complex web apps turning to other means.

[tokyodude]

That is a horrible idea. How many of them are going support Chinese, Korean, Thai, Japanese, and Arabic? If all you're supporting is English it's easy. As soon as you go international it's extremely hard to handle all the stuff you're unfamiliar with and shutting out people because their names isn't ASCII is not very inclusive.

[TomMarius]

So Gtk, Qt, Cocoa, Winforms, all of these are too hard to do? We can literally reuse (some of) these, all it takes is compiling them to WASM, it was already tried and it works, it's just slow due to current platform limitations.

[gaius]

There’s actually no reason the web couldn’t have been made of hyper-PostScript. Imagine how slick that would be.

[intrasight]

This approach has a long history. Of course the rendering engine was running server-side.

[mr_toad]

Browser APIs are deprecated surprisingly often (although, usually the ones that were not often used or didn’t work out well).