Earlier quoted context omitted.
They're unable to keep anything close to security parity with Chromium — even with hundreds of millions of dollars. You're right — frankly, I don't look to Mozilla as the leader or voice of web development anymore.
> They're unable to keep anything close to security parity with Chromium Funny how you went from "Apple's chokehold on iPhone users" to "unable to keep anything close to security parity". I wonder in which respects Safari "can't keep up"? > I don't look to Mozilla as the leader or voice of web development anymore. - There are only two other independent browser engines of any importance, and their input is increasingl…
WebContainers: Run Node.js natively in the browser
231–238 of 238 posts
Re: WebContainers: Run Node.js natively in the browser
#232Earlier quoted context omitted.
> Which stage is it? The stage where a majority of professional web devs (y'know, the people who aren't here!) still haven't even heard, or fully assimilated, the term "PWA" yet. > the "todo list" covers important issues around permissions, restricting file system access we etc. They've proven very capable of managing this in AOSP. > I think that Chrome plays fast and loose with web standards, and has essentially rep…
> compared to properly configured Chromium. Ah yes. Because that's exactly what you want from a browser: spend time properly configuring it to make it secure.
The security is inherent.
Re: WebContainers: Run Node.js natively in the browser
#233Earlier quoted context omitted.
> Which stage is it? The stage where a majority of professional web devs (y'know, the people who aren't here!) still haven't even heard, or fully assimilated, the term "PWA" yet. > the "todo list" covers important issues around permissions, restricting file system access we etc. They've proven very capable of managing this in AOSP. > I think that Chrome plays fast and loose with web standards, and has essentially rep…
Can you give a few examples to backup your claim that chrome is head of Firefox in terms of security and privacy?
Re: WebContainers: Run Node.js natively in the browser
#234I used to teach web development and was always frustrated with just how much effort went into setting up a machine. It would be really nice if a developer could just include a script tag in their project that setup a TypeScript compiler inside service worker. I managed to get the basics down, even fixing relative import statements. Requests like localhost:3000/main.tsx would compile and cache on the fly. There were a…
Yes web developing is so hard... sudo apt install apache2 php libapache2-mod-php; vim /var/www/html/index.php
Re: WebContainers: Run Node.js natively in the browser
#235Earlier quoted context omitted.
> compared to properly configured Chromium. Ah yes. Because that's exactly what you want from a browser: spend time properly configuring it to make it secure.
The configuration is for privacy. The security is inherent.
Chrome is more secure.
So, not so simple as a blanket statement you provided.
Re: WebContainers: Run Node.js natively in the browser
#236Earlier quoted context omitted.
The configuration is for privacy. The security is inherent.
So, FF doesn't need configuration to provide privacy, Chrome has to be "properly configured". Chrome is more secure. So, not so simple as a blanket statement you provided.
Which is why I recommend Ungoogled Chromium.
Or just Chromium.
Re: WebContainers: Run Node.js natively in the browser
#237Earlier quoted context omitted.
> Faster than your local environment. Builds complete up to 20% faster and package installs complete >= 5x faster than yarn/npm. Above is a quote from the post. I feel like this is a stupid question, but how can running yarn/npm in a browser on my machine be faster than running yarn/npm on my machine? Particularly when each page load runs a fresh npm/yarn install? Nonetheless, this is a incredible piece of software t…
I've also asked myself this question. I think the comparison is not with a local environment but rather with running node/yarn/npm on a remote virtual machine/ci. This is my hypothesis, I have no proof that's what they meant.
If that is the reason, then if your machine becomes memory constrained, the performance will drop through the floor quicker than with full-local installs.
It could be a mix of this and your suggestion (lower network latency related bottlenecks than experienced with non-local deployment).