131–140 of 238 posts
I 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…
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!
Everyone thought WASM would enable developers to write code in any language they wanted (with type checking and higher performance) and deploy it on the web. 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! Jokes aside: this is actually quite interesting, the demo is very impressive (except for the "onl…
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!
Can we please call it NodeJS and stop calling it Node.js? It's not a .js file, and it's not written in JavaScript .
Does this mean we can use sqlite natively on the browser now?
I think very few people will realize the systemic effects that a demo like this entails. Very, very good work StackBlitz team!
Everyone thought WASM would enable developers to write code in any language they wanted (with type checking and higher performance) and deploy it on the web. 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! Jokes aside: this is actually quite interesting, the demo is very impressive (except for the "onl…
>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.
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 (WS-Transfer). This specification describes a general SOAP-based protocol for accessing XML representations of Web service-based resources. https://www.w3.org/Submission/WS-Transfer/
Web Services Resource Transfer (WS-RT). This specification defines extensions to WS-Transfer. While its initial design focuses on management resource access its use is not necessarily limited to those situations. https://www.w3.org/Submission/WSRT/
Earlier quoted context omitted.
Did you read the post? You might be pleasantly surprised :)
Can you please go into more detail as to what exactly is being compiled to wasm? The post does not describe it. In particular there seems to be a lot of confusion about whether the JS engine itself is running in wasm or not.
Rather, I assume they compiled a library or two, but otherwise they use the JS VM in the browser, and they've ported the Node.js runtime scripts to that environment.
That doesn't take anything away from the achievement here - it's really impressive! It's better to use the VM in the browser, if you can get those runtime scripts portable enough, which from other comments it seems like the answer is (or will be) yes.
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!
We started with Java. It didn't gain any traction for browser scripting. They took "Java" out and called it JavaScript. Now we take the "script" out and call it WebAssembly. If someone in 1995 made Java a DOM-editing thing instead of an applet thing, we could have saved 25 years of running around in circles :)
(Going back even further, we all connected to a mainframe with a dumb terminal. The desktop revolution happened... and now we're back to dumb terminals attached to a mainframe. But we call it "The Cloud" instead, and the dumb terminal fits in your pocket.)
Maybe the past wasn't as dumb as we think it was. We just weren't smart enough to understand it at the time.