- Instant hot reload of application
- Inspect app/page structure in runtime
- Runtime debugging
- Monitor all network requests
- Tools to monitor time spent in functions, painting, redrawing...
- Runtime changes instantly applied
...
And now there is essentially one browser who can afford such complexity. Until Google discontinues it.
That's a feature, not a bug, as open source browsers have loosened the importance of the operating system (freed us from the MS monopoly) and enabled an multi trillion dollar web app industry to flourish.
If Google ever discontinued Chrome support it would be picked up by the community in a flash. That's the beauty of open source.
Of course it wouldn't. The number of people capable of managing and developing a full-blown browser is minuscule. Even Microsoft gave up and went with Chrome in the end.
Case in point: how many people picked up Servo? Hell, even Firefox?
Source: https://archive.is/tgIH9
What Google is doing isn't much different from the MS from the 90's, except that they didn't stop improving their browser. At least yet.
Browser development is prohibitively expensive. Even Microsoft, a trillion-dollar company, gave up on developing their browser. What makes you think that some magical community will just pick up the development of Chrome?
Yes it really is how it works. You see, Chromium is used by numerous teams and products already. Developers from these projects already contribute support and patches to Chromium on the regular. That's exactly how open source development works.
> Browser development is prohibitively expensive. Even Microsoft, a trillion-dollar company, gave up on developing their browser. What makes you think that some magical community will just pick up the development of Chrome?
Microsoft (especially Ballmer era MS) sucks at a number of things. That internet explorer was a bloated piece of trash beyond all repair is hardly an indication that browser development is beyond the capabilities of an open source community. It wasn't that it was "too expensive" for Microsoft to maintain IE. It's just that IE could not possibly compete with Chromium, because they were saddled with too much technical debt from years of bad decisions.
Entire operating systems and databases are maintained by open source foundations. Have you ever heard of Linux? MS cannot compete with Linux at the server game. They waved the white flag on that battle a long time ago as well.
Besides, when you fork a project, you don't have to instantly rebuild everything from scratch. A foundation would kick things off by prioritizing bug patches, security fixes, etc. The RFC process for deciding new web features is already handled by a consortium: https://www.w3.org/
With Firefox there is even a viable alternative that isn't controlled by Google in any form. I'd agree on many projects that would be the case. For Chrome, no.
But last I checked Firefox is still very much maintained by Mozilla.
Why doesn't community pick other browsers in a flash?
We have plenty of examples of open source databases, operating systems, libraries and languages leaving the major companies they were created at and being scooped up by a foundation or consortium to maintain.
WebOS is a great example. Created by Palm as a mobile OS before they sold it to HP, who open sourced it. Now the primary contributor is LG, who uses it in smart tvs.
But there's plenty of other examples in the open source world. Chromium is far too important, and there's already thousands of eyeballs on that code base. There would be a Chromium Foundation established very quickly if Google abandoned.
We have just as many left to die. We just don't know or don't talk about them anymore.
> WebOS is a great example. Created by Palm as a mobile OS before they sold it to HP, who open sourced it. Now the primary contributor is LG, who uses it in smart tvs.
Ah. So the mythical "community" that will scoop in and continue developing is a compani with a 60-billion yearly revenue. Got it.
> Chromium is far too important, and there's already thousands of eyeballs on that code base.
Eyeballs rarely, if ever, translate into understanding the codebase, or being able to do anything about it.
> There would be a Chromium Foundation established very quickly if Google abandoned.
Can I interest you in Apache Foundation where great amazing projects no longer supported by their original company go to slowly slide into oblivion?
Yes, irrelevant products that no one uses eventually die. At present, Chromium is not one of those, and is installed on billions of devices and used every single day on mobile and on desktop. Entire businesses and derivative ecosystems have been built on top of Chromium (Edge, Brave, Node.js and all of its dependencies, Electron, etc.). If there's an economic incentive to keep an open source product going, it will keep going. Anyway, here's the repo if you're interested in contributing: https://github.com/chromium/chromium
Browsers cost a bunch to develop. Just CI for Servo was 10k per year.
While there are some admirable efforts (Ladybird), browsers complexity means your only specification is Chrome source code.
Don't get me wrong the web pays my bills and I like it but there's no point exaggerating.
"Can be achieved" with some additional tools. I doubt you can easily expect the structure of the app, how it repaints, see all the relevant network requests, and also introspect and query the running app, emulate various hardware, inspect and debug animations etc. in most languages.
Yes, there are collections of tools that may give you all that in aggregate, but frankly, it's not close to an "out-of-the-box" experience.
> there's no point exaggerating.
It's not really exaggeration.
Browser developer tools don't "emulate hardware" they change the viewport and throttle network, there's a huge difference. It seems you don't have much experience in the tools you're comparing against. In GDB you would connect to a running application on actual hardware or in a VM, if that's what you're testing. Screen sizes and network can be done locally.
As far as all-in-one solutions go that's a new goal post, your first comment mentioned "tooling", and hot reloading is not a part of the browser so it's still an "aggregate" as you like to call it.
For me it's the unixy way of doing things and just the way I like it. Do one thing and do it well.
I've used debuggers in general (IDEA, Resharper, Visual Studio), and even dabbled with disassemblers like IDA in my youth.
> Browser developer tools don't "emulate hardware" they change the viewport and throttle network, there's a huge difference.
So, out-of-thebox int their primary tool frontend developers get: viewport simulation, cpu throttling, network throttling, sensor simulation (geolocation and orientation).
And can emulate performance with different number of processor cores. Not bad https://developer.chrome.com/docs/devtools/performance/refer...
> As far as all-in-one solutions go that's a new goal post, your first comment mentioned "tooling", and hot reloading is not a part of the browser
Wat. The original comment claimed this: "Maybe the web ecosystem will finally get some sane tooling". So yes, hot loading is a part of tooling. I've yet to see anything outside the web manage hot reloading with any degree of confidence and speed.
You don't like the hot loading, and let's focus on non-moved non-goal non-posts. I hope you noticed the ellipsis at the end of my list?
What's that immediately available tool for GDB and Wireshark whatever that:
- can let me examine and change the UI of the app on the fly? Including handful tools like layout overlays, layers etc.
- examine and debug animations?
- analyze paint/re-paint performance?
- view and debug delayed background actions?
- record and replay user flows?
...
^ Note the ellipsis again.
The build tools for Web are undoubtedly atrocious. However, there are very few, if any, tools that come even close to the versatility and ease of use of the tools that exist for the web ecosystem.
The linux kernel has KVM, doesn't get more out of the box than that. Do what you want with it. Emulate ARM? Sure why not.
> The original comment claimed this: "Maybe the web ecosystem will finally get some sane tooling".
Not my comment, I'm addressing your claim of "tooling most languages can't even dream of". The ellipsis doesn't really matter I'm not here to guess what you're meaning.
- can let me examine and change the UI of the app on the fly? Including handful tools like layout overlays, layers etc.
Most debuggers including GDB can print and set state.
> - examine and debug animations?
> - analyze paint/re-paint performance?
I don't do GUI development but you'll have to use a tool specific to the environment you're working with (just like how the DOM is a specific environment). What tool do you use to debug webview? Not your main browser. Systems development is the same.
> - view and debug delayed background actions?
You can get the time spent on anything down to individual assembly instructions if you wish.
> - record and replay user flows?
rr (which is GDB compliant hence integrates well with termdebug in vim).
I don't disagree that there are many tools for web dev. But they're not always better or easier to use. The built-in nodejs debugger is shit compared to GDB for example. My point is that everything you can do in browsers that aren't browser specific exists for other languages as well. Many times very specialized with better features that the devtools version.
Again, I love web development, but I also live in the terminal and love those tools even more. I wish they existed for the web.
I think Rust has all of that except the hot reload and runtime changes.
Instant hot reloading? Runtime introspection into apps, and into strucutre of the apps, direct view into what the app sends over the network etc.? Open up development tools in your favorite browser, you'll be surprised :)
But the web is definitely the most used “GUI framework” ever, so there is no competition with that on tooling ground, even if there is nothing inherently that would block it, as a dom inspection is pretty easy to implement - just print out the tree of ui nodes.
Flame charts in Visual Studio 2003? Sorry, try again.
I get F5 to refresh the page when source code changes. All the other tooling remains the same: https://developer.chrome.com/docs/devtools/
I mean, Chrome even has an animations debugger
Really? That's surprising but so overkill. How does it know what files to poll and which not to, I assume file:// and localhost but more specific? Does it do it for a webpack/vite app which has its own hot reloading setup?
F5 refreshes the browser page. This has been the way to develop pages since the first browsers.
And the original question was "Import a plain js file without any node tooling and see what you get for free." You don't get hot reloading but you get all I wrote in my original comment and much more for free.
It usually goes something like this: some tool watches the file system for changes > trigger build > another tool in the chain injects changes into session > picked up by client to reflect changes, if done well without resetting state.
These are many tools in a toolchain working well together. This DOES exist in other languages, incremental builds exists. You can save and restore a binary at a certain state, and it's less hassle than it is in js.
One thing the systems development world has that I haven't seen in browser tools is radare/ghidra to follow code paths but it probably exists as a browser extension. The web is just reinventing and repackaging tools that have existed for decades.
> you get all I wrote in my original comment and much more for free
Yes, but `apt install gdb` is just as "free" as `apt install chrome` no? Everything you mentioned exists in systems development, you just haven't used it.
I could probably set up a simple environment to watch for changes, run make, reload the binary at $current_state in gdb with a one-liner. But it doesn't really fit the work flow, and GDB already gets all changes after I run make.