Earlier quoted context omitted.
Wild guess? Oracle with Java.
:troll: well played.
[deleted]
What makes WebAssembly fast?
131–140 of 238 posts
Re: What makes WebAssembly fast?
#132> In the last article, I explained that programming with WebAssembly or JavaScript is not an either/or choice. We don’t expect that too many developers will be writing full WebAssembly code bases. I see this statement all the time, but it doesn't make sense. If you're looking at any programming language out there, they all have a growing members of their community asking and showing interest in targeting WebAssembly…
JavaScript is strong competition both on the front end (source ecosystem) and the back end (compiler target). For people who don't want to use JavaScript (they are using a different source ecosystem), compile-to-WebAssembly toolchains will be in direct competition with compile-to-JavaScript toolchains. It's not at all clear which ones will win. It may be different for each language. For C++ and Rust I'd expect WebAss…
Isn't debugging just a short interation away from being like native debugging? You get a source map, you see C++ in the devtools with C++ variables and a C++ call stack and an option to "view webassembly"
I have to assume the browser teams are working on this
Re: What makes WebAssembly fast?
#133Earlier quoted context omitted.
They wouldn't have had a choice, though, just as folks don't have a choice with JavaScript. I imagine that folks would have cottoned on to the advantage pretty quickly. And those that didn't … I guess they could have always become telephone cleaners or something:-)
Pure Scheme would not be sufficient. You need at least DOM-handling libraries. And if those libraries were poorly designed, then people wouldn't cotton onto the advantage quickly. Look at DSSSL.
Because of macros lisps are more resistant to bad APIs than other languages, in my experience.
Re: What makes WebAssembly fast?
#134Earlier quoted context omitted.
Is TypeScript as annoying a language to code in as Javascript? Or is it comparable to other modern languages like Swift and Go? If it is, I'd say that pain of dealing with Javascript (for developer productivity and happiness) is already taken care of.
Typescript is a type safe language that "compiles" into javascript. The Microsoft implementation compiles on save, so you work in your file.ts and a program running somewhere fires when the file is saved and converts it to file.js which you would distribute. I haven't used it yet, but the demo from Anders looked good. It's an attempt to fix the "loosey goosey" nature of javascript. I would be great if browsers suppor…
> If you watch the video, you'll notice the argument notation is name: type rather than type name. I think Anders is reminiscing about his Delphi days.
ActionScript and the proposed ECMAScript 4 also use the name:type notation, so there is definitely some prior art in the web sphere
Re: What makes WebAssembly fast?
#135Earlier quoted context omitted.
> something else that offers native bindings to other languages will eventually... No it won't. This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript. Let's be realistic; who has the man power, community good will and business savvy to push an entirely new language across all platforms, mob…
> This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript. Do people really hate JavaScript that much? I've grown fond of it in recent years, especially after ES6.
I don't hate JS but would rather write my web codebase in something else, something that has a standard lib for instance. ES6 is also a transpile to JS language on the browser. The main problem is that we are stuck with ancient JS on the browser and WASM could fix that. Wouldn't you rather conpile ES6 to WASM instead of JS?
Re: What makes WebAssembly fast?
#136Earlier quoted context omitted.
> something else that offers native bindings to other languages will eventually... No it won't. This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript. Let's be realistic; who has the man power, community good will and business savvy to push an entirely new language across all platforms, mob…
Is TypeScript as annoying a language to code in as Javascript? Or is it comparable to other modern languages like Swift and Go? If it is, I'd say that pain of dealing with Javascript (for developer productivity and happiness) is already taken care of.
You should think of typescript as javascript+ more than a different language. It looks more like what javascript would look like in 2-3 version if the governing body thought static types were important to add.
Re: What makes WebAssembly fast?
#137Earlier quoted context omitted.
Is TypeScript as annoying a language to code in as Javascript? Or is it comparable to other modern languages like Swift and Go? If it is, I'd say that pain of dealing with Javascript (for developer productivity and happiness) is already taken care of.
Typescript is a type safe language that "compiles" into javascript. The Microsoft implementation compiles on save, so you work in your file.ts and a program running somewhere fires when the file is saved and converts it to file.js which you would distribute. I haven't used it yet, but the demo from Anders looked good. It's an attempt to fix the "loosey goosey" nature of javascript. I would be great if browsers suppor…
Thats not really what he asked though. If in the end a developer can work 98% in TS, do they really care if it runs as JS or something else if it solves their problems with the language ?
I have heard from people that love TS, but surprisingly many that also prefer pure ES6 JS.
Re: What makes WebAssembly fast?
#138What makes a compiled executable faster than interpreted code seems kind of self evident.
Many developers have no practical exposure to compiled languages, and are prone to believe that Node.js is generally "faster" than Java and comparable to C++. We all had to learn this stuff somewhere. :)
Re: What makes WebAssembly fast?
#139My excitement for WASM has nothing to do with speed or efficiency of the runtime. It's all about finally having a universal compile target for the web. We're finally going to be able to develop web apps in a proper language of our own choosing, without needing hacks like TypeScript.
Hopefully, this will lead to real dedicated IDE tooling and standardized libraries for the web along the lines of what's available in iOS and Android native development.
Re: What makes WebAssembly fast?
#140> In the last article, I explained that programming with WebAssembly or JavaScript is not an either/or choice. We don’t expect that too many developers will be writing full WebAssembly code bases. I see this statement all the time, but it doesn't make sense. If you're looking at any programming language out there, they all have a growing members of their community asking and showing interest in targeting WebAssembly…
I agree completely, but I would take it a step further: If wasm doesn't overtake JS, something else that offers native bindings to other languages will eventually. There are huge benefits to be had for teams that want to be able to code their full stack in a language that isn't JS. We never asked for JavaScript (well the vast majority of us), but we've been stuck with it for the past two decades for all things web. N…
no, WASM will not replace JS unless somehow, overnight, the idea of downloading 30mb of compiled runtime libraries to read an inaccessible-to-screenreaders news article becomes appealing.
but i wouldn't hold my breath for 1990's style java applet loading throbbers to come back into fashion. there's a reason that stuff got outcompeted by the supposedly "inferior" javascript.
what wasm competes with is flash games, insecure java applets, and npapi and nativeclient in general.