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.

But yes, that's the future I'd like to see. Browsers only have a WASM engine, and provide a JS->WASM compiler client-side for backwards compatibility.

Obviously if we're trying to run a full JVM or CLR in WebAssembly, that will cause problems, but C# and F# both have compile-to-js targets that would likely just get faster.

You'll need most of a runtime anyway, since it provides much more than GC.

While I can agree that C# has tons of language features that make it more powerful than JavaScript, I take issue with the idea that those features are the defining characteristic of a "real" language. I think there are many reasons to choose C# over JS, but there are also a non-trivial of reasons to make the opposite choice.

https://blog.codinghorror.com/the-principle-of-least-power/

However, by then, TypeScript might be so darn good that people choose to keep going with it!

It really does have a better type system than C# in a lot of ways.

Const x = [{x: 3, y: "hi"}, {x: 9, y: "bye"}];

Automatically gets you x: "Array of {x : number, y: string }". And if you declare the same type somewhere else, as long as they're "structurally equivalent" (i.e. same x and y types) you can actually use them interchangeably. You can't do that e.g. with c#, where one class will never be exchangeable with an unrelated class , no matter how similar the definitions.

This lets you do some funny stuff like"subset type detection ": https://gist.github.com/hraban/66c1778cdd31868034b12db93fcce...

All in all, it's more of an oddity than an actual strength, if you ask me. It's necessary to emulate JS semantics, but I wouldn't consider it an advantage in a new language.

Agreed. Duck typing is a killer feature. I can't say how many time's I've rolled a new class for no reason other than data structuring, which would have been far preferable as something just defined inline.

All demonstrated here: https://www.typescriptlang.org/docs/handbook/advanced-types....

The result is a very nice, expressive way to state your types and get maximal benefit from the type checker.

Anders Hejlsberg is in charge of TypeScript and a apt compiler architect with a proven track record(turbo pascal, delphi, .net/C#).

I think JRuby does a similar thing for Ruby and Java Bytecode. TruffleRuby shows that it is possible to be faster, they do not compile to bytecode and use their own compiler.

There are some dynamically typed languages like Python or Dart that allow (or are in the process to allow) type annotations. But all these languages I know about claim that type annotations do not help performance. I guess you could define a fully statically typed subset of TypeScript that allows you to compile it to fast WebAssembly bytecode. But that would probably also mean to change some semantics: see int vs double for numbers in JavaScript.

Your claim was "it probably wouldn't take that much effort to surpass JS performance with a custom TypeScript -> WASM compiler"

I guess you basically have two options:

1) Implement a JS-Engine on top of WASM. Which is a lot of work. But what could you do to get better performance than current JS-Engines? Every optimization you can implement on top of WASM, you can also implement for native JS-Engines. Quite the contrary it is even harder, since you are an abstraction layer higher and can only make use of WASM opcodes.

2) Define a fully-statically typed subset of Dart and compile to WASM. You could sure do that, but don't forget about e.g. the ubiquitous number type in JS/TS. You may have to use double (almost) everywhere if you want to match semantics of JS. How many non-trivial TypeScript programs could such a subset run successfully? I assume not a lot.

I don't see how you could write a TypeScript to WASM compiler without much effort. Care to explain?

You can think of webassembly more like a common standard akin to the JVM specification. Anyone can implement the spec.

It's a formal definition of what people are doing with JS.

downsides will be some proprietary solutions will crop up.

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 for their language of choice. It's not just C/C++. Go, Rust, Ruby, Python, Crystal, Nim, D, and many more. Now you might get the reaction that "meh, why would anyone write web apps with Rust?", but that's an irrelevant question. Companies are going to see this as an opportunity to save resources and become more efficient, especially since wasm has so much better perf than JITed JS and the possibility of going isomorphic is a reality (back-end & front-end written in Ruby for example, deriving from the exact same codebase and shares code).

Now I'm not saying "WebAssembly will take over JS!", what I'm saying is that it perhaps, possibly, maybe will. It will depend on these languages and how they add support for it, what abstractions and integrations they provide with their current ecosystems. And of course, how WebAssembly will improve over the coming years.

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. Now that a doorway to replacing it with a general-purpose solution has been cracked, I expect the industry to kick it wide open as soon as possible. Not because JS is bad per se (it has certainly gotten much better), but because a lot of developers would simply prefer to use something else.

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, mobile and desktop?

Microsoft? Come on. Apple? Google? Google tried with dart and failed.

Who else, seriously, is going to step up?

We can day dream about the magical 'no js' world, but it's never going to happen if web assembly doesn't work.

Currently we're seeing the reverse, js stretched off the browser, onto the server, into mobiles, onto iot devices.

You've got to layout some pretty damn fine arguments about why that trend is going to suddenly reverse.

Web assembly is pretty much our last best chance to flip javascript off and have something better...but it might already be too late for that to work. :/

Do people really hate JavaScript that much? I've grown fond of it in recent years, especially after ES6.

Granted, that was back in 2008 and most of my complaints have been addressed now almost a decade later (except for destructors, it still doesn't have those, but I also don't need them anymore).

These days I move between JavaScript, Python, Go, and C seamlessly and I can honestly say that I don't hate any of them as much as clients, managers, and 3rd party code.

[1] http://davywybiral.blogspot.com/2008/01/javascript-bad.html

I would never debate that. I think language choice for many people is a personal decision. There are some that I will hold my nose and use; not even complain too much. There are others that the minute there is an alternative to, I would use that instead. JS is in the latter camp for me.

If it helps, my current favorite language is Rust... they may be syntactically similar, but I just can't stand the semantics, or lack there of, of JS.

Yes. People really hate C that much. C++ brought some sanity to the language, but I continue to be firmly in the camp of continuing to hate and despise its existence.

For browser programming, or full stack in a single language, you have less choice, and none if you reject transpiling.

Anyway, the nouns are important.

It's a great container for reducing the work to deliver code across platforms.

JavaScript is a necessary evil right now; it's the least common denominator for delivery. I would probably choose typescript if I were starting a new app right now to target it, though I want to play with Rust and webassembly soon.

It's success is not bc of JavaScript; it's because it merges the cross platform Dev experience.

wouldn't you rather just run ES6 right in the browser instead of compiling it first at all?

For example, on the type of projects I work on, all tooling is certified by customers IT and anything extra requires change request, that might get approved, or not.

Too many of the silent developer masses (probably mostly back-end engineers) have and continue to feel this way about being stuck with JS. The genie's out of the bottle, it's not going back in.

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 supported it as a built in language.

https://channel9.msdn.com/posts/Anders-Hejlsberg-Introducing...

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

You have algebraic types (well, 99%), union types, and concise ways of expressing tree types.

I would imagine it is more pleasant than Swift or Go, though I haven't used either of those very much.

(Which isn't to say that there aren't other questions like efficiency and already-existing codebases written in other languages.)

JavaScript is freaking everywhere.

Your DMS? Chances are it understands JavaScript.

Your scanning software? Understands JavaScript.

Your security gateway? JavaScript.

You API management software? Also JavaScript.

And a ton more. JavaScript is here to stay.

It could have been JS, but it was strangled to death by Sun (on the client).

When I read this I realised that WASM might just pave the way for something more fundamental: browser runtime stdlib.

One of the big issues, even highlighted in this very thread, is that people are wary of forcing 10MB+ blob downloads on their users. What would the effect be if browser provided a proper stdlib?

Linux + BusyBox is less than 2MB (I've fitted it in floppies not too long ago) if you don't include the drivers for everything. I've created a 10MB binary set that implements an entire email server, with everything statically linked, and in Haskell (that leads to inherently big binaries).

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.

Take a look at the source for any molasses-slow news site. The only site-specific JS will be jQuery, and a few basic event handlers to do things like show and hide elements, which could have been done with CSS.

99.9% of the JS will be advertising, analytics, and tracking. People understand that these sites are tracking them, but I think most people have not idea just how much tracking is going on. Major news sites have hundreds of tracking libraries loaded per-page. That is the only reason they are slow.

I travel between countries and of course I hate staying in huge cities because they're expensive and noisy. But when you move to smaller towns, there're usually limited options for connecting to the Internet.

Last year in India I spent 2.5 hours incessantly trying to open my bank website to make an urgent payment. All these huge React/Redux bundles were loading for ages, and they aren't cached and there's no support for resuming download after it dies because of some timeout or because you were looking at the spinner for 30 minutes and decided to click reload button.

And even when these huge SPA load, they're totally broken on slow connections. People become lazy and they don't handle timeouts and responses coming in weird order because of the slow channel. Even if you manage to open SPA on slow connection, it's a pain to use, almost impossible with all these XMLHttpRequests on every click transferring megabytes of data after every click or typing any letter. :(

that's peasant level net :P. 100 or bust {literally what I have home and better at work). seriously though, indeed the web is overbloated and I don't think there is coming back

Thankfully on Android and WP devices I was able to take the battery out, when the web site developer got too creative for the device's CPU/GPU.

If you read point 3 on this page (http://webassembly.org/docs/high-level-goals/) you should realize that the need for JavaScript won't be required at that point.

edit: I'd like to clarify that I'm not saying wasm will boom in usage over night, but as time goes on, the rough edges clears up & features like these are added it might become the better choice.

They wanted to progress on the spec and push it out without that, but it's on the roadmap. (Along with GC integration).

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 WebAssembly will perform well, since it fits these languages' runtime model better. But for garbage-collected languages, compiling to JavaScript may result in smaller and faster code, since you can reuse JavaScript's runtime instead of downloading it. There may not be any reason for Elm or Dart (for example) to replace a compiler that works well with one that targets WebAssembly. Or if you like Go, I'd at least try out GopherJS before thinking you need a whole new toolchain.

It's not just performance, either. Generating somewhat-readable JavaScript that you can debug using Chrome Devtools when something goes wrong is a pretty nice advantage.

I have to assume the browser teams are working on this

Each language has its own peculiarities for how objects are represented on the heap.

It can be done. There may be pain, but the pain can be managed.

EDIT: by that I mean that one would need to maintain two heaps. One for data that interacts with the browser and that is wrapped by the FFI as external resources, and one for the internal system itself, which can be managed via GC. Only the WebAssembly code would have to manage GC roots, which can be done as per any GC language.

There's the 1% edgy companies built on node+rust/D and what-have-you, and then there's the 80% wordpress crowd who longs for a human-readable programming language a la Star Trek. I think the latter is a future that will come unimpededly over this century, as far as the majority of the industry is concerned.

More pressingly, people are waiting for async and other cool multi-threaded features in JS, and ES6 really is a second coming of sorts in that regard. Long gone are the days of horrendous paradigms once we adopt the 2016 spec, really.

Economically, because that's the true judge ultimately, we have to consider the existing JS ecosystem: actual prods, skillsets, experience, actual needs of businesses who fund the construction of the web currently solved by JS, and so on and so forth. It's a giant thing, that JS. If we had a better alternative today, we'd still be writing JS in many projects in 2020 and maintaining some of it late into that decade. Let's face it, JS is here to stay, there's no turning back now --see how polarizing Java has always been for another historical case, and see how it's still top 3: can't suddenly undo all that cash poured into production, can't instantly retrain hordes of programmers.

I'll say one thing about wasm though: it's a formidable effort that paves the way towards a truly 'next-gen' web paradigm, most notably suited to be actuated (viewed) within a VR/AR environment; it's also a prime candidate to run on the smallest devices at the heart of an "ambient"/IoT ecosystem. I'm considering a superset of low-level networking protocols that go beyond the web, obviously. And I haven't researched anything about it yet but I suspect the low-level hooks of wasm could be hacked to do some fancy ML stuff on-the-spot (thinking low-cost online algos and reinforcement learning here, if we are to make our 'ambient' IoT ecosystem able to 'learn' about us as users and map the physical world semantically).

Ha, fascinating times, really. Let's just not lose sight of how the real world operates, though, if only to improve on that. In due time when ideas become feasible under the right circumstances. Low-level programming is very much not how we've trained the bulk of tech people since the smartphone era / mobile paradigm essentially. It'll take time to shift, if we ever did. I don't think we will, in the grander scheme of things.

Yes, you can get into trouble when you decompile code: http://security.stackexchange.com/a/30375/93013

[0] http://webassembly.org/

[1] http://webassembly.org/docs/faq/#will-webassembly-support-vi...

https://github.com/WebAssembly/design/blob/master/TextFormat...

However, a weird, highly-annotated strict subset of JS is not the ideal representation of what is basically portable assembly language. WebAssembly's big strength over asm.js is it has smaller executables and they can be rapidly decoded and verified in binary IR form, rather than having to shove megabytes of ungzipped bracket-fest through a JS parser.

It's not about the "smallness" as measured in the number of bytes, the minimized (that is, short variable names, no comments and whitespaces) asm.js code with the "bracket-fest" can actually be quite compact.

It is about the form which does save some lexing, parsing, searching and allocation steps in the run-time. Which matters when the code is measured in megabytes and the goal is to run it as soon as possible and save as much battery as possible on the mobile devices. From the FAQ:

https://github.com/WebAssembly/design/blob/master/FAQ.md#why...

"The kind of binary format being considered for WebAssembly can be natively decoded much faster than JavaScript can be parsed (experiments show more than 20× faster). On mobile, large compiled codes can easily take 20–40 seconds just to parse, so native decoding" "is critical to providing a good cold-load user experience."

Not quite. SpiderMonkey has AOT compilation, whereas Chakra and V8 throw it at the JIT, though Chakra's compiler is specially optimised for asm.js AIUI.

Thing is, specific support for asm.js is unnecessary, a sufficiently good JIT is good enough. V8 hasn't implemented asm.js AOT because it doesn't need to. I assume the same would be true of WebAssembly.

> Asm.js also still hasn't become a formal spec

Though it is a spec.

Why does it never need to re-optimise the JITed code? I know WebAssembly and asm.js are more static than JS, but even very static languages like C benefit from speculative optimisations which may need to be reversed. For example asm.js and WebAssembly have branches don't they? Does the JIT always compile both branches even if one has never been taken in practice?

And what is the reoptimisation overhead anyway? If deoptimisation is caused by a bad speculation on the same thread, it's zero overhead on the fast path until it's used isn't it?

WebAssembly is treated just like other "real binaries" produced for the "real" OS. Whatever survived the static optimizations while producing the binaries is converted, at the end, to the pure machine code, you don't "trace" it in run-time by the user.

> even very static languages like C benefit from speculative optimisations which may need to be reversed.

I'm not aware of "speculative optimisations which may need to be reversed" in C, and I'd be very interested to read what you mean when you write that, possibly with some links and references. Do you mean run-time, by the user, or something else?

In fact, that's similar to how a CPU runs "real binaries". Modern CPUs use _some_ runtime information to make code run faster. Examples include branch predictors and the recognition of stride lengths to move data into the cache before the instructions being executed need it.

That's only small bits, but it _is_ runtime information. I do not rule out that WebAssembly developers, similarly, will find hat there are ways to use runtime information that speed up WebAssembly code.

For the "plain" JavaScript, there are the run-time decisions.

> Modern CPUs use _some_ runtime information to make code run faster. Examples include branch predictors and the recognition of stride lengths to move data into the cache before the instructions being executed need it.

Sure. But that run-time information is internal to the CPU. And the CPU will use it for the native binary code that is the final result of asm.js or WebAsm, just like any other. But that native binary code is "static," it's explicitly not "small traced chunks" the way "plain" JavaScript is handled.

> I do not rule out that WebAssembly developers, similarly, will find hat there are ways to use runtime information that speed up WebAssembly code.

Think about that: it they would find something like that, exactly the same technique could be used to speed any native code, including Linux kernel and anything native you imagine.

If you manage to develop software method that actually improves the execution speed of the native code in run-time, you'd be famous and (if you know how to market it) rich.

Think about that: it they would find something like that, exactly the same technique could be used to speed any native code, including Linux kernel and anything native you imagine.

That's exactly what profile-guided optimization does. It's not a new invention, it's working technology. And it's far from inconceivable that PGO could be applied to the intermediate code that web assembly effectively is.

Specific example: a common tradeoff made in compilation is between space and speed, and there are some cases - like padding to align a jump target - that can win big speed improvements in inner loops, but are pessimal when used liberally (because code size inflates and doesn't fit in cache). Realigning jump targets is something that can be done to compiled code, in particular compiled code before it has been linked, when all the relocations and fixups are still available. Having information about hot code can make a big difference here.

(BTW: optimizing linkers are surprisingly involved here, particularly for targets that have a bunch of addressing modes, like x86. Some ways of writing in fixups can result in smaller code (e.g. 1 byte offsets rather than 2 byte offsets), but this effect cascades: making code smaller can make what used to be a 2 byte offset possible to fit in 1 byte. Don't underestimate the amount of optimization that your linker does with native code (if you have a smart linker; my experience is from the Delphi compiler source).)

A developer could do some kind of PGO before he produces the final binary, I can imagine that. But then it's still just a static binary.

And I personally can't imagine PGO being done in the user's browser and not being slower than the alternative of not doing it, just like I've never heard of some OS which does PGO on the native binaries when user runs them. Maybe you know of something like that? The PGO I know is always a slow process, done only before shipping the binary to the user, it's a kind of "post-processing" step of compiling, not of the normal execution at the user's computer.

Even some swing apps benefit once you get it started up..

That said, I'm not sure the full JVM is coming to browsers anytime soon.

Java VM receives the classes, methods, strings, has GC and all that, but it has to JIT to reach that lower level to be efficient and has to do a kind of establishing what's actually used, similarly to what tracing JIT engines for classic JavaScript do.

I believe that kind of run-time measurements and then code generation and optimization is what some Java people call PGO, and what asm.js at the moment intentionally (by design) avoids.

In short, Java's PGO on the user side is not what PGO for static languages like C is (by the developer). And asm.js is even lower than C. It's really closer to... asm.

Exactly because asm.js avoided these decisions was Firefox with asm.js support faster than Chrome at the time the later treated all js code the same.

Because its marginal returns?

Not that it is all around terrible, but definitely much preferred if we can choose the best language for the job instead of being strictly stuck with JavaScript.

From what I had heard the plan was not to do that until the final standard was settled on, but I wasn't able to find any corresponding announcement.

[1]: https://github.com/WebAssembly/binaryen/releases/tag/version...

Does this mean instead of a normal "native app" I'm going to start getting C applications compiled with wasm and distributed in electron? What does this possibly gain the end user?

For instance, access to the DOM doesn't really matter for game engines like Unity or Unreal, or for lower level libraries like OpenCV, libsass, or libarchive which you might want to use in your web application.

No one is arguing that WebAssembly will completely replace JavaScript, especially not right out of the gate, but it will be used to optimize hot code paths within JS apps, as well as allowing robust, efficient, native libraries to be used directly on the Web. This is more about the pie getting larger than it is about WebAssembly hypothetically crowding out JavaScript.

My point was who wants these to be in the browser? I mean they're cool as demos, but I don't see the use. Is it just people using web browsers as the content delivery platform instead of e.g. Steam?

Anybody that resents the user having ultimate control over the User Agent. A game in e.g. the Unity engine isn't important. Instead, there are a lot of people that would love to replace their (easily adblockable) web page with a small opaque binary that contains freetype, custom layout/UI library, and maybe "drm"-like obfuscation. You don't need the DOM if you intent to render everything yourself.

At best, we will see a new wave of "flash intro"[1] style "custom user experience" replacing perfectly usable HTML pages. At worst, this could be the catalyst that replaces what remains of the open web with a locked down "cable tv"-like mess.

[1] http://www.zombo.com/

I support anything that improves performance and efficiency. But the best of both worlds is always great. I'm wondering if it would be possible to implement reference counting (and maybe automatic reference counting) similar to Objective-C, and if so, would that simply be a matter of the particular language and WebAssembly transpiler you're using supporting it? And are there disadvantages to reference counting that make it a bad idea? I enjoyed using it doing earlier iPhone programming.

I thought it had a performance cost.

- the data isn't stored next to the count so you get two pointer indirection per access, or

- the data is stored next to the count, and the object gets cached-in when it gets collected.

Piggybacking on the thread because I haven't had much concrete experience with smart pointers: how does the "circular chain" problem seem to manifest? Is it

- "goes wrong quickly," usually picked up and fixed without too much trouble,

- "like any old memory leak" -- maybe a problem if processes run a long time, hard to track down, or

- devs are usually smart enough to see them coming, knowing to keep the "has a pointer to" relation a partial order (either by type or some other natural hierarchy.)

?

This may even end the craze around JS frontend tooling.

Can't wait!

Nothing to install, no updates, no license key, not tied to a machine.... ?

Modern app stores like the Mac App Store make installing an one click affair. It will take me more clicks to login to their Word website...

Also, "nothing to install" means "nothing to own".

>no updates

There will still be updates, only I won't be controlling them, and I wont be able to stick with an older version.

Besides, it has been ages since updates for apps have been totally painless (e.g. with something like the Mac App Store, or a framework like Sparkle).

>no license key

Yes, but a password. And presumably a subscription, and my access to this "WebAssembly-based Office" lost when I can't fork out the money for a few months.

(Also no piracy option for the developing world anymore).

>not tied to a machine....

I can have that with regular software not running on a browser. I can use Reason e.g. (a native application) on any machine I care to install it with their over-the-internet verification.

A quick reminder from just the parent comment above to which we're answering: "Imagine MS Word is running in your browser without them having to rewrite it in JS!".

That is, we're not talking about the native MS Office "right now".

Improved with respect to what, then, if not the current "right now" Office?

[1]: https://nwjs.io

[2]: https://electron.atom.io

Does that make more sense?

At least js could be unminified and many standard libraries are somewhat trusted.

Though there are people on HN who can do that, given some development time, like me.

Is anyone working on such a thing?

How long until there's a really good JVM written in JavaScript of some form and embedded Java apps end up running in JavaScript for performance and security reasons?

It'll be even more ridiculous and hilarious if the "j" in "jruby" ends up meaning "JavaScript".

I though JS was named to piggyback on Java's popularity, not because it was actually intended to complement Java.

http://www.infoworld.com/article/2653798/application-develop...

That's an amusing idea. But it's extremely unlikely for the same reason that you are unlikely to see C++ rewritten in JavaScript.

It's possible, however, that over time, more and more languages might target JavaScript, rather than the JVM or the native hardware.

For instance, I program in Scala for a living. The main platform for Scala is the JVM, but there's also Scala.js, which targets JavaScript. And in fact, we now write most of our "JavaScript" in Scala, rather than in JavaScript.

I suppose that someday there might be a version of Java that targets JavaScript, and then your dream might come true. Oh wait... it already happened! It's called GWT and it's been around for a decade.

I still wonder what might have been if Eich had been allowed to write the Scheme system he had been hired to do. While I'm not a fan of Scheme by any means, it is approximately 281,757,423,024,353 better than JavaScript.

And Scheme's a great little language for implementing other languages. Imagine, we could have had transpiling years ahead of time. We might be using S-expressions instead of JSON. Heck, we might even have moved to an S-expression syntax for HTML & CSS by now.

Imagine, one syntax for everything (thanks to https://www.w3schools.com/js/tryit.asp?filename=tryjs_intro_... & https://www.w3schools.com/css/css_howto.asp for the examples):

    (html (head (title "Example")
            (style (body (background-color linen))
                   (h1 (color maroon)
                       (margin-left (px 40)))))
          (body
           (h1 "What can JavaScript do?")
           (p (@ (id "demo")) "JavaScript can " (em "change") " HTML content.")
           (button (@ (type "button")
                      (onclick (set! (inner-html (get-element-by-id document "demo"))
                                     "Hello JavaScript!")))
                   "Click me!")))

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:-)

Not to mention that there were other ways to execute code in the browser in those days. We have 'no choice' but Javascript today simply because it's the option that people eventually gravitated towards, forcing the others out of the market.

The original suggestion was that people would use Javascript, or any other language in its place, simply by virtue of it being the only option. I argue that the wrong language would hamper adoption, and eventually some other language – like, say, VBScript which came only 6 months later – would have taken over.

Javascript persisted, and eventually completely dominated, because it was good enough. A language not good enough would have not had the same success, even given the otherwise same environment to grow up in.

If JavaScript had had Lisp syntax, then everyone would still be using Flash. Or some other plugin that provided a language with a more popular syntax.

IME it's a learned thing from only knowing languages that at least superficially resemble ALGOL.

JS is a first language for a lot of people - because their goal was to make a website do something. Scheme would not have been any different.

IME many computer programmers learned Lisp in college and for some reason hated it–I think in part due to the syntax and in part because they had a hard time with recursion and other "mind-bending" concepts. They often still harbor an irrational precedent to this day.

Me, on the other hand, I loved Lisp as soon as I learned it. (Perhaps I was primed by having learned APL in high school.) I changed my major from Astrophysics to Computer Science because I felt that SICP was even cooler than black holes and neutron stars.

If people disliked the syntax enough to avoid the language (and the browser that uses it), I imagine that other browsers would've started supporting other languages, and something else would've dominated.

In IE world, things were actually even crazier, because the whole scripting story was extensible (via Active Scripting). So you could use Perl, for example...

Did you see the '(set! (inner-html (get-element-by-id document "demo")) "Hello JavaScript!")' bit? That's DOM-handling in Scheme. Not a really great API, but it's not terrible either.

I do not want to ever have to update Flash again. Ever.

Much of the JVM is written in C++ (From the docs: "There are nearly 1500 C/C++ header and source files, comprising almost 250,000 lines of code.")

I disagree. In moving to the single-threaded async style of JS concurrency, the hardest part for me has been to rid myself of the ugly habit I acquired from Java's threading model, i.e. asking myself at each line of code, what happens if my thread gets preempted here?

Java is just a language that runs on JVM, there have been many many attempts to replace it with languages brand new ( scala), existing languages ( jruby) including javascript( nashorn/ringojs ect), but no language has even come close to dethroning it. Its unlikely that javascript will replace it just because jvm is rewritten in java script.

that is not what oc meant. he is talking about runtime env, not source language

The linear memories, on the other hand, are up to you - you can execute operations on address within a linear memory, and it's up to you if you messed up and overwrote or read out data that you shouldn't have. What you do get is a) protection against heap overflows affecting values outside the heap, and b) protection against execution of heap data. In the future, they're also planning to support multiple linear memory segments, which would allow you to isolate memory used for potentially-buggy dynamically-allocated buffer code from memory used by less-fragile or more-sensitive code. WebAssembly.org's descriptions indicate that linear memories would be used both for C/C++ heap allocations and for any local/global variables accessed with operators (like the & reference operator) that make it hard to make these distinctions statically.

More information on the security properties of the system: http://webassembly.org/docs/security/

General information on linear memory semantics: http://webassembly.org/docs/semantics/#linear-memory

There is plenty to be excited about here. This will enable faster [media apps, games, etc](http://webassembly.org/docs/use-cases/) on the web. Wasm is knocking at the door and I can't wait to see what it's bringing with it.

Edit: HN really should support a few more formatting options.