The reason you can't do this is that Node of course has a bunch of file system APIs that for security reasons necessitate an application designed for automatically downloading and executing arbitrary source code can never, ever, have access to.
But you could rephrase the authors point this way: Browsers make a ton of concessions to regular users at the expense of developers. Consider for example that the act of developing a web application in fact often does not involve executing arbitrary source code online, it involves executing specific source code you have control over, which has different security requirements.
The author is expressing something I'm surprised more developers don't pick up on: The browser is a consumer tool first, and yet it's a favorite tool of developers despite the fact that it barely caters to developers at all. Take for example the "Developer" menu item, which is two levels deep in Chrome. A rational developer, who spends all day with a browser open for development, would be frustrated that one of their primary use cases has such a low priority in the application. But that's not how developers perceive the browser, developers have a fondness for the browser that's not reciprocated.
Another example of the low priority of developer use cases in browsers is that the commonality of the other main developer tools, text editors and terminals, is that they achieve incredibly powerful functionality through process management. E.g., code completion, linters, integrated debugging, `grep`, `git`, are all based on text editor's and terminal's ability to manage external processes. But browsers can't do this, which firmly limits their usefulness, and creates bizarre situations like having to manually hit the refresh button because your server process can't talk to the browser application itself.
A thought experiment if you have time for it: Let's say you take a word processor. It's a great word processor, well-designed for its purpose. But it's primarily designed for "consumer" text editing, things like resumes, school papers, and the like. And let's say you add some programmer specific functionality to it, but do it in a way that doesn't interfere with any of the consumer-first features. E.g., you make it automatically syntax highlight source code files, you make it use a more sophisticated find-and-replace when editing these files, you add a file drawer that you can toggle via two levels in the menu bar, etc...
Would you be interested in using this word processor for programming over your text editor or IDE which is designed first-and-foremost for programming? If not, what's the difference between this and the way Chrome treats developers? (I'm not being disingenuous here, I honestly don't see the difference personally.)
If I really liked that word processor for general use then I might also use it for simple one-off programming tasks, like how I use my browser's developer tools today (Firefox though).
What's the alternative though? Is the suggestion that browsers ought to be competitive out of the box with whole off-the-shelf IDEs that can cost thousands of dollars, prioritizing that use case over even web browsing?
I wasn't suggestion browsers should compete with IDEs, just that consumer browsers and developer browsers should be different applications with different features, just like word processors and text editors are different applications with different features.
Regarding the word processor experiment, I don't really mean as something you'd use for one-off programming tasks, I mean as a replacement for a dedicated programmer's text editor. E.g., the point is that a developer-first browser could have features and developer-experience that consumer-first browser can never match, just like adding developer features to a word processor would struggle to match a dedicated programming text editor.
No, I wasn’t, thanks for pointing it out! I’d love to hear which of the issues I listed that it addresses. The tag line “welcome to your new favorite browser. Get the latest features, fast performance, and the development tools you need to build for the open web”, as well as the features listed on the homepage, don’t address any of the points I listed directly. (This doesn’t mean the app itself doesn't, but I'm not encouraged by the features as they’re listed on the homepage, which feels more like some new features for developers, rather than a re-imagining of how we think about how developer tools are integrated into the browser like I’m describing.)
I’m not sure it is a complete reimagining, but it does take a developer first approach. Many Dev tools need to be extendable and the Firefox team has tried to do that with the built-in dev tools.
> The new Firefox DevTools are powerful, flexible, and best of all, *hackable*. This includes a best-in-class JavaScript debugger, which can target multiple browsers and is built in React and Redux.
But you could rephrase the authors point this way: Browsers make a ton of concessions to regular users at the expense of developers. Consider for example that the act of developing a web application in fact often does not involve executing arbitrary source code online, it involves executing specific source code you have control over, which has different security requirements.
The author is expressing something I'm surprised more developers don't pick up on: The browser is a consumer tool first, and yet it's a favorite tool of developers despite the fact that it barely caters to developers at all. Take for example the "Developer" menu item, which is two levels deep in Chrome. A rational developer, who spends all day with a browser open for development, would be frustrated that one of their primary use cases has such a low priority in the application. But that's not how developers perceive the browser, developers have a fondness for the browser that's not reciprocated.
Another example of the low priority of developer use cases in browsers is that the commonality of the other main developer tools, text editors and terminals, is that they achieve incredibly powerful functionality through process management. E.g., code completion, linters, integrated debugging, `grep`, `git`, are all based on text editor's and terminal's ability to manage external processes. But browsers can't do this, which firmly limits their usefulness, and creates bizarre situations like having to manually hit the refresh button because your server process can't talk to the browser application itself.