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.
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.
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.
aka How to tell that you don't design APIs without telling that you don't design APIs.
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.
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/
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
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.
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.
However, I do believe the same for operating systems and application binary in general. Nobody would ever complain about X or Y operating system if writing your own was sufficiently easy.
Not saying that we can simplify operating systems the same way we can browser, but we can make it easier to start from a clean base and quickly support Windows, Linux, macOS, Android & iOS app binaries. As an example, how hard is it to interpret an android app binary? Is this complexity really necessary? Couldn't we depend on languages with more emergent behaviors to ease the implementation of VM/interpreters?
Just to be clear, I am NOT and have never said that we should all write our own browser or OS, but that simplifying them would result in more choice and no more begging from users to support X or Y features (which happen in every single standardized/monopoly situation)
> which makes no sense and it's not how anybody does anything in the real world.
In the real world you have people begging everywhere for features to be implemented in software they have no control on. Software standards have never solved any issue, they increase the barrier of entry and make users powerless.
When there were legally enforced browser ballots they had to ... and they did.
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.
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.
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.
Look, I don’t like how complex web browsers are any more than you do. But it’s the situation we’re in today.
We have no reason to indefinitely use our web.
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.