7 ms·

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, n

by mamcx 8y ago

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 8y ago
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 8y ago
  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"
  - amaccuish 8y ago
    Credit where it's due: https://xkcd.com/927/ https://xkcd.com/927/
  - mamcx 8y ago
    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 8y ago
      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.
- ionforce 8y ago
  > There's nothing wrong with vanilla JS. Understatement of the century for 500.
  - deleted 8y ago
    [deleted]
amelius 8y ago
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 8y ago
  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 8y ago
    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 8y ago
      "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 8y ago
  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.
codetrotter 8y ago
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 8y ago
  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.
  - wild_preference 8y ago
    Because now you’ll just have two problems.
  - ethbro 8y ago
    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
- smacktoward 8y ago
  The vast majority of those existing websites are being served over HTTP. Google seems fine with breaking them for that reason.
  - michaelmrose 8y ago
    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.
deleted 8y ago
[deleted]
tannhaeuser 8y ago
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 8y ago
  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 8y ago
    I meant growth wrt to the original purpose of the Web as a self-service publishing platform.
mr_toad 8y ago
Browser APIs are deprecated surprisingly often (although, usually the ones that were not often used or didn’t work out well).

by mamcx 8y ago

joshvm 8y ago

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 8y ago
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"
- amaccuish 8y ago
  Credit where it's due: https://xkcd.com/927/ https://xkcd.com/927/
- mamcx 8y ago
  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 8y ago
    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.
ionforce 8y ago
> There's nothing wrong with vanilla JS. Understatement of the century for 500.
- deleted 8y ago
  [deleted]

amelius 8y ago

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 8y ago
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 8y ago
  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 8y ago
    "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 8y ago
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.

codetrotter 8y ago

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 8y ago
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.
- wild_preference 8y ago
  Because now you’ll just have two problems.
- ethbro 8y ago
  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
smacktoward 8y ago
The vast majority of those existing websites are being served over HTTP. Google seems fine with breaking them for that reason.
- michaelmrose 8y ago
  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.

deleted 8y ago

[deleted]

tannhaeuser 8y ago

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 8y ago
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 8y ago
  I meant growth wrt to the original purpose of the Web as a self-service publishing platform.

mr_toad 8y ago

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