181–190 of 238 posts
I'm trying to get my head around how the networking of it works. Is local.webcontainer.io being overridden somehow on the browser like a hosts file might do? Trying to figure out how I'm hitting that URL from another tab
Must be some sort of tunneling, because it works outside the browser too
Earlier quoted context omitted.
It looks like the problem isn't WASM features, but web I/O APIs, like the File System Access API.
Many of the more "advanced APIs" are unlikely to be shipped in either Firefox or Safari because of security and privacy concerns. For example, Chrome released File System Access by defaul tin Chrome 86, on October 6, 2020. And yet, as late as August 2020 they were saying that they'd just got the spec in shape: https://github.com/mozilla/standards-positions/issues/154#is... . And there are still unresolved issues arou…
It's not just about privacy of web APIs...it's about Apple's chokehold on iPhone users.
I mean, a console is nice and all. But I'm highly sceptic as to how the filesystem and networking works, because fetch cannot be used to have dgram or tls/net sockets. And that is literally the primary reason nodejs exists.
Wow, the PWA is really impressive. Honestly it's starting to get hard to tell the difference between this and Electron-based editors like VS Code. I'm really excited for integration with the File System Access API; that's the final puzzle piece I'd need to use something like this for serious work.
Me too and I was surprised to find that Chrome lists this as "ready" or "released" (I don't recall the exact term). I tried the example web based editor and found that the file system access API worked in Firefox too. I'm working on a note taking project right now that I think would be great as a web app, but I'd like to store the result in a flat text file and the file system access API looks like it will let me do…
For now, File System Access API seems to be available only in desktop Chromium browsers: Edge, Chrome, Opera. I believe Firefox has not implemented it yet.
https://caniuse.com/native-filesystem-api
---
Mozilla's current position on the specs:
> The ability to read and write from the filesystem is potentially very dangerous. We will need to carefully consider any solution in light of the security and privacy implications. We recognize that the spec authors take this issue seriously, but we are concerned that any solution will increase the risk of security incidents more than we are willing to tolerate.
> Right now, there isn't enough detail in the specification to make an assessment of these risks, so we will defer our decision until we have more information.
https://mozilla.github.io/standards-positions/#native-file-s...
Earlier quoted context omitted.
It looks like the problem isn't WASM features, but web I/O APIs, like the File System Access API.
Many of the more "advanced APIs" are unlikely to be shipped in either Firefox or Safari because of security and privacy concerns. For example, Chrome released File System Access by defaul tin Chrome 86, on October 6, 2020. And yet, as late as August 2020 they were saying that they'd just got the spec in shape: https://github.com/mozilla/standards-positions/issues/154#is... . And there are still unresolved issues arou…
These are mostly a to-do list...which makes sense at this stage?
I'm not sure what you're getting at.
Do you think that Apple or Mozilla can stop webapps from taking their rightful place?
If it really runs inside the Browser: How did they implement adapters for networking and crypto/tls? I mean, a console is nice and all. But I'm highly sceptic as to how the filesystem and networking works, because fetch cannot be used to have dgram or tls/net sockets. And that is literally the primary reason nodejs exists.
> WebContainers include a virtualized TCP network stack that's mapped to your browser's ServiceWorker API, enabling you to instantly create live Node.js servers on-demand that continue to work even when you go offline.
Earlier quoted context omitted.
Browser Javascript suffers from not producing a single "binary" as its build system output. You do get one bundle, but none of the parts know anything about each other, and it limits the ability to optimize. (It is a lot more like the C preprocessor, rather than a C compiler.) Methods that can't possibly ever be called end up being sent to each user, for no reason other than "well someone could write an eval() that n…
> the direction I'd like to see web development move is having a statically typed language that compiles to VM bytecode. Java… you want Java. And so the cycle continues!
Earlier quoted context omitted.
Many of the more "advanced APIs" are unlikely to be shipped in either Firefox or Safari because of security and privacy concerns. For example, Chrome released File System Access by defaul tin Chrome 86, on October 6, 2020. And yet, as late as August 2020 they were saying that they'd just got the spec in shape: https://github.com/mozilla/standards-positions/issues/154#is... . And there are still unresolved issues arou…
If business PCs are running Microsoft Teams + Outlook PWAs on Edge (Chromium based), personal PCs as a majority are running Chrome/Chromium...I can't see why Apple wouldn't come to a compromise to treat PWAs with respect. It's not just about privacy of web APIs...it's about Apple's chokehold on iPhone users.
Funny how you fully ignore Firefox's position
Earlier quoted context omitted.
>JS Developers come in: so we can compile node.js to WASM and run that in the browser?! Yay!! Now we can have backend JS running in the browser alongside browser JS! I remember back when SOAP still had the upperhand against REST but just barely the W3C published a document where they showed how you could implement HTTP over SOAP to basically mass ridicule. Unfortunately can't find it anymore, but it was pretty funny.
searching "HTTP over SOAP" finds a few leads: Tim Bray, 2004, "HTTP over SOAP!?!?!?": https://www.tbray.org/ongoing/When/200x/2004/05/01/SRRH Erik Wilde, 2008, "HTTP over SOAP over HTTP": https://dret.typepad.com/dretblog/2008/11/http-over-soap-ove... William Vambenepe, 2008, "WS Resource Access working group starting at W3C": http://stage.vambenepe.com/archives/436 Here are some of the specs: Web Services Transfer (…