4 ms·

Browsers are great at rendering. But they are terrible when it comes to exposing the raw power and capability of a machine to web apps that the user wants to t

Browsers are great at rendering. But they are terrible when it comes to exposing the raw power and capability of a machine to web apps that the user wants to trust. They spec their API implementations by committee (and committees of committees) and they rarely implement any spec in its entirety. The web is becoming increasingly fragmented as a result. The web is good for "web pages", but bad for "web apps". The web currently has no concept of a trusted web app. For example, we have been waiting for years for browsers to give web apps some way to access the filesystem, and all we have is an open dialog and a file instance (and the debris of the failed filesystem api). And when will web apps (not "web pages") get TCP or UDP? The browsers will never be able to match the module ecosystem and core power of Node. The way forward: 1. Give the power back to users. Give them a boolean way to indicate that they trust and want to install a web app. 2. If the web app is trusted and installed, give it access to Node. In a matter of months, this could exponentially boost web apps, lighten the bloated browser codebase, keep the focus on browser rendering, and keep committee fingers off web app innovation.

pdkl95 11y ago
> The web is good for "web pages" That is, after all, what it was designed for. Making web pages interactive in any way beyond a <form> has always been a hack. > give web apps some way to access the filesystem > And when will web apps (not "web pages") get TCP or UDP? First, if it's in a browser, there isn't much of a distinction between "web apps" and "web pages". The browser, by definition, exists as a sandbox that renders unsafe data and code. Allowing any kind of access to the filesystem or TCP or UDP will hopefully never happen. All networked software needs to implementing security concerns as the first and highest priority, If you aren't, you're putting the people that use your software at risk. The browser must always[1] be limited in what it an do. If you want to do more (which is fine), write a standalone application. If your favorite platform doesn't let you write such applications, complain to the vendor or change to something that isn't hostile to software development. > the module ecosystem and core power of Node. That ecosystem is tiny compared to what is available in /usr/lib64/. I like Javascript, but there is a lot more to computing outside that single ecosystem. [1] Unfortunately current browsers are already over the line with what they allow pages to access.
- deleted 11y ago
  [deleted]

pdkl95 11y ago

> The web is good for "web pages" That is, after all, what it was designed for. Making web pages interactive in any way beyond a <form> has always been a hack. > give web apps some way to access the filesystem > And when will web apps (not "web pages") get TCP or UDP? First, if it's in a browser, there isn't much of a distinction between "web apps" and "web pages". The browser, by definition, exists as a sandbox that renders unsafe data and code. Allowing any kind of access to the filesystem or TCP or UDP will hopefully never happen. All networked software needs to implementing security concerns as the first and highest priority, If you aren't, you're putting the people that use your software at risk. The browser must always[1] be limited in what it an do. If you want to do more (which is fine), write a standalone application. If your favorite platform doesn't let you write such applications, complain to the vendor or change to something that isn't hostile to software development. > the module ecosystem and core power of Node. That ecosystem is tiny compared to what is available in /usr/lib64/. I like Javascript, but there is a lot more to computing outside that single ecosystem. [1] Unfortunately current browsers are already over the line with what they allow pages to access.

deleted 11y ago
[deleted]