> at expense of browsers complexity rivaling operating systems.
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.
> If Google ever discontinued Chrome support it would be picked up by the community in a flash.
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?
Servo never had significant market share of any kind, but it has recently been picked back up by a foundation. Firefox has been outcompeted by Chrome and Mozilla has made a number of strategic blunders over the years. But by and large people stopped using Firefox because Chrome/Chromium was better on most metrics users care about. Even developers tend to use Chrome/Chromium because of the superior native debugging tools.
But last I checked Firefox is still very much maintained by Mozilla.
> We have just as many left to die. We just don't know or don't talk about them anymore.
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
What other open source browsers have been left without maintainence? Ones with no market share? As mentioned, Servo was never really finished and yet it has recently been scooped up by the Servo Foundation. Mozilla still very much maintains Firefox.
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 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.
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, they do. And your point? That they are "a community that will pick up Chrome dveelopment in a flash"? That's not how it 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?
> And your point? That they are "a community that will pick up Chrome dveelopment in a flash"? That's not how it works.
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/
Browsers are now so essential, that there is little incentive for Google to drop out and very much incentive for everyone else to continue or increase their involvement.
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.
Pushing for whatever feature they fashion, pushing against stuff that they didn't create, doing things differently for no reason, making sure their software works badly on competitor platforms...
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.
What does it have to do with the number of people forking and developing their own browser? Agent string sibstitution/emulation has been a thing since time immemorial.
You make your own browsers and issue correct UA (User Agent) only for GMail to stop working. But works fine when issuing Chrome UA. I guess Google is staffed by Howler monkeys, or malicious.
Except for the hot reloading (which you mention twice btw) the tooling for the popular languages has everything in the list, and most can be achieved with GDB and Wireshark alone, in any language that GDB supports.
Don't get me wrong the web pays my bills and I like it but there's no point exaggerating.
> Except for the hot reloading (which you mention twice btw) the tooling for the popular languages has everything in the list, and most can be achieved with GDB and Wireshark alone, in any language that GDB supports.
"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.
Have you used GDB? And network requests is what Wireshark was created for.
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).
> 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.
> So, out-of-thebox int their primary tool frontend developers get: viewport simulation, cpu throttling, network throttling, sensor simulation (geolocation and orientation).
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.
> Many languages have all of that tooling and more. For example C# and Java.
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 :)
Well, java in debug mode can hot swap class methods, for what it worth.
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.
Most backend frameworks can just route new requests to the updated code - so a refresh is all you need (though there are tools that simply make that refresh automatic, which is pretty much how js frameworks work as well. Intellij can also make the whole recompile-replace code function happen on window defocus, so by the time you switch to your browser, it is already refreshed. And nowadays the compile of something like Java can well be faster than whatever that npm monstrosity does)
Javascript hot reloading requires a "recompile", you just don't notice it. Import a plain js file without any node tooling and see what you get for free.
It's not a "recompile". JS doesn't get compiled, it may get transpiled or minified. Node.js is only used for sending data over a local websocket from the file system to the browser. You can totally also achieve this effect on a local offline webpage that wasn't even being served if you added an input on the page (ie the React docs: https://react.dev/learn).
Yes. But the difference in this context is nitpicking. The browser needs to know what file was changed, and what to do with those changes right? And preserve state. That doesn't magically happen it's the tooling that supports 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.
> I get F5 to refresh the page when source code changes.
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.
Yes, I know I was just surprised it even checks for changes without being prompted, but I guess that's where all the resources go. The point I was trying to make was a response to your claim that hot reloading magically happens without "compiling", it doesn't (I know I know, it's transpiling in js).
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.
- 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
...