3 ms·

We need less API/standard, not more. To have more competition in web devtools, we need to simplify the web standard so more browser can appear instead of forci

We need less API/standard, not more. To have more competition in web devtools, we need to simplify the web standard so more browser can appear instead of forcing some new fancy API on our almost monopoly.

jakelazaroff 3y ago
There’s no way to simplify web standards without breaking existing websites.
- paulryanrogers 3y ago
  Websites should be built based on widely accepted standards, not quirks or monoculture 'standards'. When there were legally enforced browser ballots they had to ... and they did.
  - jakelazaroff 3y ago
    When I say “web standards”, I mean official W3C standards, and I think we should be actively hostile to corporate attempts to take over that process. But I disagree that we shouldn’t also try to accommodate quirks. That’s why we have `Array.flat` instead of `Array.flatten` — the standards body decided to come up with a slightly atypical name for the feature rather than breaking a bunch of websites.[1] Our collective history is too valuable for us to be breaking stuff just to make engineers’ lives easier. [1] https://developer.chrome.com/blog/smooshgate/ https://developer.chrome.com/blog/smooshgate/
    - paulryanrogers 3y ago
      > we should be actively hostile to corporate attempts to take over that process. Hard agree. I've become convinced their power to ignore, replace, and EEE standards requires legal intervention. So far it seems only randomized browser ballots can effect any meaningful change. Otherwise websites will just build for the dominant browser regardless of any agreements among them.
    - TheMode 3y ago
      > Our collective history is too valuable for us to be breaking stuff just to make engineers’ lives easier. I'd argue that software standards make it harder for everyone to write a "history". How many people simply gave up on their own websites and outsourced their work to an entity they do not control the actions of? How much of that fancy web standard is about optional visual? What are we really getting from it? Would you consider a new API for drawing rectangles "progress"? Your `Array.flat` example may make sense, but only because we are way too deep to even consider alternatives. We have mostly no idea how these standards will evolve and decided to keep on putting band aids to remain afloat. The best way to keep information accessible is to make it understandable by a human without mandatory automation. Don't you find it horrible that all the information websites can provide you is actually dependent on a thousands pages long spec? Is it really the only solution you can think of? The resiliency of the web is mostly equivalent to papyrus, if not worse.
      - jakelazaroff 3y ago
        What solution can you think of that doesn’t involve breaking any existing websites? Look, I don’t like how complex web browsers are any more than you do. But it’s the situation we’re in today.
        TheMode 3y ago
        There is none, but we should have a transition period to make a simpler web spec, entirely immutable (to ensure no future bloat). We have no reason to indefinitely use our web.
        jakelazaroff 3y ago
        Okay, but “a simpler spec” is not a compelling reason to switch to or build for another one. There’s a reason no one uses Gemini.
        TheMode 3y ago
        A simpler spec means more competition, which is more sustainable than 50 standardized APIs. More competition means having an easier time finding the perfect browser (or even make your own). I do not know about Gemini but the problem with current minimal formats is that they cannot evolve without change to the spec, they lack emergence. And therefore when you want to expand on it, you need to add complexity to the spec, not your code. One of the idea I had was to make all websites provide natural language text, without any standardization (send whatever text you want). Which would have these benefits: - Ease website development, your goal is to make the text as simple as possible to understand for a human. - (also means that website won't have the luxury to send unnecessary data anymore) - More performant. - Literally cannot break as it does not depend on any standard. Text will remain understandable forever. - You can have an infinite amount of browsers, some may only render the raw text, some may render the text and give you very fast tips as to how you should render it, and others dedicated to specific disabilities. - You can have a working browser in a matter of hours. And the way you expand on it is independent from how the server operates. - No fancy standard can appear to break this simplicity, as many people would depend on the text being unopinionated. - Can still support anything the web currently does, but tracking without contentment will become harder. As users would have a deeper understanding of what the website actually is, its text is on plain sight.
Sakos 3y ago
This isn't how anything works. If you want a better alternative compiler, you build a new compiler. You don't build an entirely new operating system that includes a new compiler. Want a better grep? Make a better grep, not a whole new shell. Forcing everybody to make their own entire browser in order to provide an alternative devtool is ... madness? What does making a devtool have to do with making a browser? Why should making one require making the other?
- TheMode 3y ago
  It is how it works. What's your suggestion for the fancy devtools API? Beg Google? Making the implementation of the web standard simpler means increasing the options available, meaning more chance of finding a devtools you appreciate and possibly modify. APIs/Standards deprecate. It is not even a question of "if" but "when". Lowering the barrier of entry is much more sustainable than engineering a whole new spec every time we encounter a problem.
  - jitl 3y ago
    There’s already a DevTools API, no need to beg. The Chrome devtools work by connecting to the browser using the Chrome DevTools Protocol. You can find a description of it here: https://chromedevtools.github.io/devtools-protocol/ https://chromedevtools.github.io/devtools-protocol/ Another tool you might have heard of that uses the Chrome Devtools Protocol are NodeJS APIs for remote-controlling browsers: Puppeteer (from Google), and Playwright (from Microsoft). You can access the underlying CDP connection from Playwright: https://playwright.dev/docs/api/class-cdpsession https://playwright.dev/docs/api/class-cdpsession Chrome extensions can add tabs to the Chrome devtools built into the browser. So, a competitor dev tool can be distributed as a Chrome extension and opened with the devtools keyboard shortcut. A user can “switch” to the alternative devtools by put the tabs it adds first and hiding the built in devtools tabs.
    - TheMode 3y ago
      My bad then, I stand corrected. Although the rest of my message remains correct, if writing a dummy browser only took a few hours/days, nobody would ever ask for new APIs.
amelius 3y ago
I don't see how that makes sense. Writing an API is less work than writing the devtools (which needs some kind of API anyway internally). So without a universal API, any serious new browser would take more effort to build.
- TheMode 3y ago
  Designing an API is a ton of work, especially if you care about backward compatibility (otherwise you may as well use that internal API). And at some point will be deprecated for removal. Without a standardized way of writing devtools - assuming the web standard is overall simplified - you can expose a more specialized API without the baggage associated with standards, break it every so often, and make it as easy as possible for developers (potentially even users) to port other devtools to it. I believe that instead of finding the "universal API", we should embrace the fact that there will be 15+ of them, and therefore simplify the porting process.
- seba_dos1 3y ago
  > Writing an API is less work than writing the devtools aka How to tell that you don't design APIs without telling that you don't design APIs.

jakelazaroff 3y ago

There’s no way to simplify web standards without breaking existing websites.

paulryanrogers 3y ago
Websites should be built based on widely accepted standards, not quirks or monoculture 'standards'. When there were legally enforced browser ballots they had to ... and they did.
- jakelazaroff 3y ago
  When I say “web standards”, I mean official W3C standards, and I think we should be actively hostile to corporate attempts to take over that process. But I disagree that we shouldn’t also try to accommodate quirks. That’s why we have `Array.flat` instead of `Array.flatten` — the standards body decided to come up with a slightly atypical name for the feature rather than breaking a bunch of websites.[1] Our collective history is too valuable for us to be breaking stuff just to make engineers’ lives easier. [1] https://developer.chrome.com/blog/smooshgate/ https://developer.chrome.com/blog/smooshgate/
  - paulryanrogers 3y ago
    > we should be actively hostile to corporate attempts to take over that process. Hard agree. I've become convinced their power to ignore, replace, and EEE standards requires legal intervention. So far it seems only randomized browser ballots can effect any meaningful change. Otherwise websites will just build for the dominant browser regardless of any agreements among them.
  - TheMode 3y ago
    > Our collective history is too valuable for us to be breaking stuff just to make engineers’ lives easier. I'd argue that software standards make it harder for everyone to write a "history". How many people simply gave up on their own websites and outsourced their work to an entity they do not control the actions of? How much of that fancy web standard is about optional visual? What are we really getting from it? Would you consider a new API for drawing rectangles "progress"? Your `Array.flat` example may make sense, but only because we are way too deep to even consider alternatives. We have mostly no idea how these standards will evolve and decided to keep on putting band aids to remain afloat. The best way to keep information accessible is to make it understandable by a human without mandatory automation. Don't you find it horrible that all the information websites can provide you is actually dependent on a thousands pages long spec? Is it really the only solution you can think of? The resiliency of the web is mostly equivalent to papyrus, if not worse.
    - jakelazaroff 3y ago
      What solution can you think of that doesn’t involve breaking any existing websites? Look, I don’t like how complex web browsers are any more than you do. But it’s the situation we’re in today.
      - TheMode 3y ago
        There is none, but we should have a transition period to make a simpler web spec, entirely immutable (to ensure no future bloat). We have no reason to indefinitely use our web.
        jakelazaroff 3y ago
        Okay, but “a simpler spec” is not a compelling reason to switch to or build for another one. There’s a reason no one uses Gemini.
        TheMode 3y ago
        A simpler spec means more competition, which is more sustainable than 50 standardized APIs. More competition means having an easier time finding the perfect browser (or even make your own). I do not know about Gemini but the problem with current minimal formats is that they cannot evolve without change to the spec, they lack emergence. And therefore when you want to expand on it, you need to add complexity to the spec, not your code. One of the idea I had was to make all websites provide natural language text, without any standardization (send whatever text you want). Which would have these benefits: - Ease website development, your goal is to make the text as simple as possible to understand for a human. - (also means that website won't have the luxury to send unnecessary data anymore) - More performant. - Literally cannot break as it does not depend on any standard. Text will remain understandable forever. - You can have an infinite amount of browsers, some may only render the raw text, some may render the text and give you very fast tips as to how you should render it, and others dedicated to specific disabilities. - You can have a working browser in a matter of hours. And the way you expand on it is independent from how the server operates. - No fancy standard can appear to break this simplicity, as many people would depend on the text being unopinionated. - Can still support anything the web currently does, but tracking without contentment will become harder. As users would have a deeper understanding of what the website actually is, its text is on plain sight.

Sakos 3y ago

This isn't how anything works. If you want a better alternative compiler, you build a new compiler. You don't build an entirely new operating system that includes a new compiler. Want a better grep? Make a better grep, not a whole new shell. Forcing everybody to make their own entire browser in order to provide an alternative devtool is ... madness? What does making a devtool have to do with making a browser? Why should making one require making the other?

TheMode 3y ago
It is how it works. What's your suggestion for the fancy devtools API? Beg Google? Making the implementation of the web standard simpler means increasing the options available, meaning more chance of finding a devtools you appreciate and possibly modify. APIs/Standards deprecate. It is not even a question of "if" but "when". Lowering the barrier of entry is much more sustainable than engineering a whole new spec every time we encounter a problem.
- jitl 3y ago
  There’s already a DevTools API, no need to beg. The Chrome devtools work by connecting to the browser using the Chrome DevTools Protocol. You can find a description of it here: https://chromedevtools.github.io/devtools-protocol/ https://chromedevtools.github.io/devtools-protocol/ Another tool you might have heard of that uses the Chrome Devtools Protocol are NodeJS APIs for remote-controlling browsers: Puppeteer (from Google), and Playwright (from Microsoft). You can access the underlying CDP connection from Playwright: https://playwright.dev/docs/api/class-cdpsession https://playwright.dev/docs/api/class-cdpsession Chrome extensions can add tabs to the Chrome devtools built into the browser. So, a competitor dev tool can be distributed as a Chrome extension and opened with the devtools keyboard shortcut. A user can “switch” to the alternative devtools by put the tabs it adds first and hiding the built in devtools tabs.
  - TheMode 3y ago
    My bad then, I stand corrected. Although the rest of my message remains correct, if writing a dummy browser only took a few hours/days, nobody would ever ask for new APIs.

amelius 3y ago

I don't see how that makes sense. Writing an API is less work than writing the devtools (which needs some kind of API anyway internally). So without a universal API, any serious new browser would take more effort to build.

TheMode 3y ago
Designing an API is a ton of work, especially if you care about backward compatibility (otherwise you may as well use that internal API). And at some point will be deprecated for removal. Without a standardized way of writing devtools - assuming the web standard is overall simplified - you can expose a more specialized API without the baggage associated with standards, break it every so often, and make it as easy as possible for developers (potentially even users) to port other devtools to it. I believe that instead of finding the "universal API", we should embrace the fact that there will be 15+ of them, and therefore simplify the porting process.
seba_dos1 3y ago
> Writing an API is less work than writing the devtools aka How to tell that you don't design APIs without telling that you don't design APIs.