Hacker News Reader

Comment by Sakos | Hacker News Reader

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?

View on HN

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.

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/

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.

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.

It simply isn't. Just look at how Linux works. Combining tools over agreed upon interfaces. If you want to replace one tool with another, you don't need to change every other tool and have knowledge of every other problem domain. What you're suggesting is replacing everything, which makes no sense and it's not how anybody does anything in the real world.

We are only talking about the browser here, where the few choices come from the extreme complexity of the spec.

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.

Reply on news.ycombinator.com