[c0nfused]

Web assembly always makes me a little sad. It feels like we are going back to flash only it won't be bad this time, I promise, no really.

I always feel like the most obvious use for it is to start writing truly hateful and abusive code.

I'm sure this is because I'm getting old.

[klodolph]

What makes WebAssembly like Flash? Please elaborate.

You already can't just read someone's JavaScript code if they're using a transpiler or uglify or something like that, it looks like line noise and you basically have to go through a lot of work to reverse engineer it. WebAssembly is no worse.

The JavaScript environment on the web reminds me of the "walled gardens" that were Lisp machines back in the day, that force you to write code in Lisp, or if you wanted to write in C you would get end up with a bit of a nightmare on your hands. The Lisp machines were beautiful and integrated and the source code was everywhere, but they weren't for everybody, and in the end it was the diversity of Windows, Unix, and Mac OS that replaced them.

WebAssembly is Unix, JavaScript is a Lisp machine.

[wwweston]

> What makes WebAssembly like Flash? Please elaborate.

It's pretty straightforward. Both tend towards the Big Binary Blackbox Blob.

It's true that WebAssembly has advantages Flash, Java, and Silverlight didn't really have in terms of being freely reimplimentable and (potentially) native to the browser. And it's probably a good thing that a browser can be a VM via a target-intended subset of JS. BBBB may be the right thing for some applications.

But to the extent that the browser becomes something developers see primarily as The VM That Lived (and there are clearly a lot of developers in this boat) yes, we're forgetting lessons we should have already learned from the difference between Flash/Java and the open web.

> You already can't just read someone's JavaScript code if they're using a transpiler or uglify or something like that, it looks like line noise and you basically have to go through a lot of work to reverse engineer it. WebAssembly is no worse.

I'm clearly in the minority, but I had qualms about uglify and other source manglers from the beginning for the same reasons people have qualms about Web Assembly: they break the benefits of view source.

I get that they can also be tools that help squeeze out performance, and I use them selectively for that reason, but as far as I can tell, most of the web development world uses this as an excuse to stop actually thinking about the issue -- and for that matter, to stop thinking about how they're putting together their web app ("we're using minification and gzip and doing an SPA using Ember/Angular/LatestDesktopLikeFramework because that's what professionals do now, why do we have performance problems?").

Similarly, I've seen a lot of people use compiling to JS as an end run around what are essentially aesthetic/subjective issues with JS as a language when they'd probably do just as well spending more time learning to use it (as far as I can tell in years of working with all of them, JS is in exactly the same league with Python and Ruby and Perl other similar dynamic languages). That doesn't mean there are no beneficial cases for JS as a target (personally, I'm intrigued by Elm), but I think I'm justified in being afraid that people will use it as insulation from superficial problems.

> that force you to write code in Lisp

Lisp doesn't force you to write code in Lisp. That's one of the reasons why it's awesome -- and potentially horrible. Transpiling/compiling can be similarly awesome and potentially horrible for a lot of the same reasons.

[klodolph]

I'm sorry, this is going to be a rant. Feel free to ignore if you don't care about my opinions on the subject.

The open web has nothing to do with "view source". It never did. "View source" just makes debugging easier, it's a technical solution to a technical problem. It's why we use JSON or XML instead of ASN.1 for our daily work.

The open web is a web where no company is the gatekeeper. It's a web where we have multiple browsers, competing JS engines, et cetera. No one company can hold the web hostage. This is exactly why Flash, Java, ActiveX, and Sliverlight failed. Every one of those technologies was owned by a single company. Every one of those technologies failed because it's impossible for one company to be the gatekeeper for a technology that is supposed to run on billions of heterogenous devices.

So the lessons of Flash are this: don't put all of your eggs in the Adobe basket.

Meanwhile, you're fighting against WebAssembly because you are ideologically against black box software. Getting rid of WebAssembly does not actually achieve that goal. It's like you're fighting against condoms because they encourage promiscuity. The promiscuity is already there, and condoms just make it a better experience for everyone involved.

----

Footnote: JavaScript is on par with Python/Ruby/Lisp in a lot of ways, but there are some important deficiencies with respect to typing and static analysis, deficiencies which cause actual bugs in real world problems and cost developers time and money to deal with. It's why we've been inventing TypeScript, Flow, Dart, CoffeeScript, et cetera. You say that other people's problems with JS are "superficial", but that's exactly how I see your problems with WebAssembly.

People are going to write code in C++ because they can hit performance targets on platforms where they ship native code, and WebAssembly means a lot to the folks working with Unity, Unreal, or thousands of other existing projects which the new open web. The new open web, with WebAssembly, is an open web with more diversity than ever before, rather than a JavaScript monoculture.

[EdSharkey]

Yeah ... blackbox blob binaries (BBBB's?) don't strike me as the parent commenter's problem. It's not having access to a software's _original_ sources that you can build and deploy yourself that is the problem. Ideally, there would be some nuclear-powered version of View Source that gave you nice access to the original sources for the code loaded on a page - sort of a formalized "Fork Me on GitHub".

When I am being philosophical, smoking a cigar and sipping tequila after midnight, I begin to understand that the only software I've written that has a chance of outliving me is my open source. Everything else I've done has just been to serve up fleeting amusements. There is literally nothing commercially closed that I have contributed to that shouldn't be utterly scrapped.

If I died tonight, my positive impact on this planet for its people now and in the future is probably just constrained to my kids surviving me. Not an inconsequential thing, I love my kids like crazy and they're going on to do greater things than me. I just have the sense I've got more to offer than procreation and raising good people.

In my opinion, any hairy audacious moonshot goals humanity chooses to tackle should be open sourced in every way possible - otherwise the efforts cannot be fully genuine and transparent to generations that follow. Perhaps the increased open-sourcing of code and designs we see from industry today versus 20 years ago is the best we can hope for in competitive capitalist societies; maybe what we have is good and is the most we can expect.

[Yen]

I agree with you on some points, and disagree with you on others.

> The open web is a web where no company is the gatekeeper.

Absolutely!

> The open web has nothing to do with "view source". It never did. "View source" just makes debugging easier, it's a technical solution to a technical problem.

I think "view source" was essential to the web we have today. It's not just a technical solution to a technical problem - it's an accidental UI/defaults solution to a social problem we didn't realize we had.

(note that, in general, this applies to the web of maybe 15~20 years ago. Geocities, inline styles, table-based layout, the works)

The problem, namely, is how to educate the general internet-using populace on the means of content-creation, and encourage them to actually create. If different companies can put out their web sites or their technologies with slightly reduced barriers on innovation, sure, that's kinda nice I guess. But, the web reaches it's true potential when the average nobody uses it not just to consume, but to create, produce, and publish.

There's a very small subset of the population that can just read an HTML spec (or at best, a tutorial), and actually churn out a working web page at all. Most people like to learn implicitly, by example and by imitating. With "view source" available, any web page you see is an example to learn from - or a code snippet to take, edit, and make your own.

---

now-a-days, we're up to our ears in HTML/CSS/JS classes, tutorials, etc., reasonably priced hosting, code snippets, the works. And yet, a smaller percentage of the internet population (and, I think, a smaller absolute number of people) actually create their own website.

Sure, there's more technology to grapple with, and the bar has been raised on what constitutes a "good" website the author would be satisfied with, but I think the real failure is that it's pretty much impossible to read the source of any interesting, non-trivial website.

[bigger_cheese]

I learnt to write HTML files in the early 90's (The Geocities era as you refer to it - forget tables back then everything was frames). I learnt exactly how you surmised by using view source on existing websites.

As a 13 year old kid who was mildly curious I was able to build a web site for my high school by hand in 'pure' html code. It looked laughably simple compared to the web pages of today but it was easy. I can and did teach many other people to make websites the same way.

Nowadays it seems to me like you don't have a hope in hell of hand writing a website (maybe some people still do seem like an exercise in frustration to me). Everything is all frameworks and scripting languages.

Earlier this year 20 years after I wrote html pages for my school's web site I had cause to write some HTML again. I work as an engineer (the non software type) in an industrial plant. I needed to display some non critical data to our plant operators on a screen in the control room. I thought 'hey I'll put it on a web page'. It would save me from having to mess around with C which is what our HMI system is written in. So I built something using 1990's era HTML mostly from my memory (although I did move on to using tables instead of frames) It worked.

A few weeks later some one asked to make it possible to view historical results so I built a simple html form (also 1990's era technology) to allow user to input the date range he wanted to view results from. It worked but did no input validation was finicky about the format you enter dates into it etc...

A few weeks later I decided I'd modernise it - modern websites have things like popup calendars which allow the user to "pick" a date instead of having to type dates into a text field. I found a framework written in javascript which provided those sorts of things and attempted to use it. Seemed to work but a lot of subtle bugs kept popping up.

When you clicked on a date in the calendar such as 12th of January the framework passed it to the form in US style 01-12-2015 format I live in Australia we use 12-01-2015 as out date format. I could find no way to change the way the framework functioned. I searched google and a few other people complained about the same issue seemed to be no solution. I thought I'd dig into the javascript file try to edit the program to provide date in format I needed it to be in. The file was 'minified' impossible to read javascript. I gave up and modifed my script to assume US style date input instead.

Maybe I'm just to old to learn new tricks now but I miss the older simpler web sometimes.

[icebraining]

In some ways, the recent HTML specs allows the dev to go back to that old-school handwriting.

For example, instead of bringing in a JS framework, you could now just replace the input type with "date", and a modern browser would show the date picker.

[woah]

If you were using an open source framework, the source is available. The minified file is just to save space.

[devsquid]

Well said.

Its even built into the spec of WASM to at least try to make the bytecode convert into human readable code. https://github.com/WebAssembly/design/blob/master/HighLevelG...

But as you state, its not integral to a "open web". IMO WASM is a long time coming and I think it will drastically help the "open web" which is suffering from some library bloat. Next we need an open and better image format.

[wwweston]

> The open web has nothing to do with "view source". It never did. "View source" just makes debugging easier.

This is about as true as the idea that the only use of seeing source code is debugging (or building/deploying your own version of the app).

Which, of course, every developer here knows is not true.

Reading source code is useful for figuring out how to do something you didn't know how to do. It's useful for discovering idioms you didn't know, even if you already knew another way. It's very useful if you're trying to do bookmarklets/extensions/mashups or even more significantly engineered interop.

I don't know if there's a formal gatekeeper out there with a list of all the things that capital-O Officially make the The Open Web(TM) great, so I guess there's no way to settle what's on it.

But I don't know how anyone could argue that these things weren't significant bullet points in a much longer list of reasons why the web has seen faster and broader adoption than any of the competing VMs and why it was/is often more useful and nice to work with despite more limited capabilities.

And I think it goes almost without saying that list is much bigger than the "no single gatekeeper" point.

> you're fighting against WebAssembly because you are ideologically against black box software

I am neither fighting against WebAssembly nor ideologically against any kind of black box software. My earlier comment makes it clear I think WebAssembly has a place (and, more generally, that transpiling does) as well as its hazards.

I am stepping in to point out that Flash and WebAssembly have significant things in common, some of which are tradeoffs against things that have made the Web an effective and proliferating medium.

> [JS] some important deficiencies with respect to typing and static analysis

See my aside about Elm. Given the fact that dynamic languages (including maligned ones like JS and even PHP) seem to be about as equally successful in terms of shipped software as statically manifest typed languages, whether or not even something like TypeScript is really going to give engineering teams an edge seems like far from a settled question to me. But I'm interested to see what happens where we're talking significantly augmented capabilities rather than the largely aesthetic differences that something like CoffeeScript represents.

(Speaking of which: "TypeScript, Flow, Dart, CoffeeScript"... at least one of these things is not like the others if you're invoking static analysis and typing as reasons for transpiling.)

> You say that other people's problems with JS are "superficial", but that's exactly how I see your problems with WebAssembly.

I can't tell exactly what you're saying here, but at a close approximation, it sounds like you might be suggesting that the readability of WebAssembly is going to be on the same order of difficulty that an experienced Python developer has reading idiomatic human-written JS (ie, aesthetic). This is potentially possible, I guess, in a world where everyone writing compilers that target WebAssembly is conscientious at/above the level that the CoffeeScript developers were (CS output is really fairly readable, arguably more so than minified JS). But then again, that's not what the name suggests WebAssembly is for. In practice, most of the time it's probably going to read... a lot like assembly language dressed in C-like syntax.

[spion]

> Given the fact that dynamic languages (including maligned ones like JS and even PHP) seem to be about as equally successful in terms of shipped software as statically manifest typed languages, whether or not even something like TypeScript is really going to give engineering teams an edge seems like far from a settled question to me

I'm always so frustrated when I read this, because I've worked on a few dynamic language codebases as well as seen a few open source ones on github. Very often I see the pattern of the project contributors losing control over the dynamic language project. They slip up, the tests become insufficient and now they refuse / are afraid to touch critical parts of the code. Soon development slows down to a crawl. Or rather, there are no more changes - only additions / grafts to the existing codebase.

When I first started using TypeScript, I feared that I'm going to lose the benefits of a dynamic language and that I'll have to write a lot more boilerplate. I had no idea how little of that was true. TypeScript really goes out of its way to model as many JS idioms as possible, including some really dynamic ones:

  * Structural types are formalized duck type checking. You don't 
    have to say your object implements an interface: if it has all 
    the right fields, and they're of the right type, it does. This is 
    similar to Go interfaces (but a bit more powerful in what it can express).
  * Unions types plus type guards can model dynamic function arguments
  * Intersection types can model record (object) merging

The entire type system in TypeScript is basically a formalization of the typical duck typing patterns that are common in JavaScript. As a result, TypeScript can model almost any common JS idiom. The loss of expresivity was very minimal - maybe 1% of the most dynamic code only. And even there, you can tell the type system "I know what I'm doing" (cast to `any`), turn it off, do your dynamic stuff and then tell it the resulting types (cast to whatever types are the result before returning).

Given the above, theres been absolutely no doubt in my mind whether TypeScript gave us an edge or not. Its been incomparably better than just plain JS.

[devsquid]

Hey incase you aren't aware, having WASM output a human reading version is part of the spec.

"define a human-editable text format that is convertible to and from the binary format, supporting View Source functionality." https://github.com/WebAssembly/design/blob/master/HighLevelG...

[fulafel]

> JS is in exactly the same league with Python and Ruby and Perl other similar dynamic languages

There's a big difference to strongly typed dynamic languages that go out of their way to catch programming mistakes at runtime. With JS you get some "wtf" result when things go wrong and it propagates a long way before manifesting (if it's caught at all). Combine with JS's many weird semantics and special cases that are hard to keep in mind at once...

Recent favourite (minimized case after discovering unexpected piles of NaN's in some faraway place)

  > parseInt("0")
  0
  > parseInt("1")
  1
  > parseInt("2")
  2
  > ["0", "1", "2"].map(parseInt)
  [ 0, NaN, NaN ]

[heinrich5991]

Can you explain that one? Does it have something to do with parseInt being able to take more than parameter?

[fulafel]

Array.map does not work like map in other languages.

They decided that map shall receive the array index as the second argument, and there's also a third argument that does something else. JS happily mashes these 3 arguments into parseInt's argument list of (stringValue, radix) without error. Hilarity ensues.

(This code also sins against "never call parseInt without the radix argument", see point about too many minefields to remember at once)

[nly]

Seems to me the answer here would be to bind the radix argument of parseInt with a wrapper before applying map

[teh64]

> JS is in exactly the same league with Python and Ruby and Perl other similar dynamic languages

I don't know about Perl, but Python and Ruby both give you a type error for [] + {} or {} + [] or 1 + "1". And both Python and Ruby give you an error when you do something like "".notavalue, whereas javascript just gives you undefined. They might look similar enough visually, but under the hood they are different in terms of strictness and types.

[bromuro]

> I'm clearly in the minority, but I had qualms about uglify and other source manglers [...]: they break the benefits of view source

Not really: we have source maps for this.

[jacobolus]

“View source” is a tool for outside end-users who want to understand or reverse-engineer code on websites they don’t control. “Source maps” is a tool for inside developers trying to debug their own code. Whether or not the browser supports source maps is irrelevant if you don’t have access to the original code, but only the minified/mangled version with all single-character variable names.

[Arnavion]

>Whether or not the browser supports source maps is irrelevant if you don’t have access to the original code

Sourcemaps can embed the original source inline, though of course that is a decision made by the author and they can decide not to make sourcemaps that way. It is more likely that the end-user doesn't have access to the source maps anyway.

[wwweston]

I would love to see examples of source maps working in the wild.

[tahssa]

> they break the benefits of view source.

The benefits are not that great these days. At least not for people who don't support a web ad monetization model or have no interest in being on the VC boat to float model.

[odonnellryan]

> It's pretty straightforward. Both tend towards the Big Binary Blackbox Blob.

A huge part of the project is to ensure decompilation to asm.js

[PuercoPop]

> "walled gardens" that were Lisp machines back in the day, that force you to write code in Lisp,

Lisp machines come with Fortran and C compilers.

[1ris]

I never used it, but allergly they where not only comming with a Fortran, but the best Fortan IDE.

[KirinDave]

The idea that UNIX is somehow the "open" and "inclusive" variant of computing is a good example of "The victors write history."

It's really frustrating to see people parrot it. UNIX succeeded for a lot of reasons, but not because of these. In fact, at the time it was the more restrictive and closed option. It also put a lot of burdens on the developer in the name of time-to-market.

The entire "worse-is-better" mythology is essentially a story of how market velocity is a powerful force in the face of "doing it well."

[KirinDave]

> WebAssembly is Unix

The irony of this is that almost no UNIX offers a compelling, complete developer integration outside of things which produce slavishly detailed C-compat layers that introduce an ever growing number of undefined behaviors.

It also ignores that many lisp machines actually shipped with compilers for competitive languages. LispMs just had a lot of work (for the time done) on optimization for lisp environments. We take for granted the trivial execution overhead of interactive environments but this was no small feat back in the feat.

[TeMPOraL]

> WebAssembly is Unix, JavaScript is a Lisp machine.

Isn't this an argument against WebAssembly? We've already made the mistake once.

[jacobolus]

The main use for it (for me at least) is to write fast numerical code (physics modeling, audio processing, image processing, machine learning, 3D rendering, statistical analysis, etc.) in a deterministically fast way against an easy-to-reason-about programming model with an ability to manually allocate memory and structure data, instead of hoping that every browser’s heuristic-driven JIT will be able to optimize some high-level code the same way.

Most of the program logic can remain standard Javascript, but the little kernels of hot numerical code can be much more effectively optimized.

This gives Javascript/browsers the ability to handle problems which were previously only possible to tackle with native C programs.

[ezy]

The issue with this is that if you care about speed, you need to be using SIMD -- and wasm doesn't seem to want to support it -- stating a "minimum viable" standard from the year 2000.

[azakai]

SIMD.js is in progress for JS, so JS VMs are already working on it. It is on the roadmap for being added to WebAssembly, likely with a similar API.

[zurn]

Is there a technical restriction why JS JITs don't transparently apply SIMD to existing loops like normal compilers (=autovectorization)? Or is it in the cards to build it on top of SIMD.js?

[yoklov]

Autovectorization is hard and fragile in the best of times -- tight stable loops with no (or few) branches and little/no memory access that may be aliased, etc.

For a dynamic language JIT this is pretty much infeasible (as I understand it). Every loop might have branches for guards/bailing out due to deopts, and at least in JS, TypedArrays are allowed to alias eachother.

[jacobolus]

Existing Javascript JITs also don’t output SIMD instructions as far as I know.

I expect SIMD support can be added to wasm at some future date.

[ezy]

I wasn't really referring to wasm vs JS (which is easy to outperform), but reaching equivalent speed to native, which is the ultimate goal, I'd hope. Otherwise you're just throwing performance away...

But, I was a little quick on the trigger. It's not obvious, but after drilling through the design docs for a half hour.. I found a tentative discussion of how SIMD might be added later (based on some kind extension mechanism).

[nwmcsween]

Why wouldn't llvm be able to emit SIMD when it can vectorize? The idea the SIMD is the end all to fast computing is pretty short sighted IMO.

[jacobolus]

SIMD isn’t the “end all”, but upcoming Intel chips have instructions for handling 8 doubles or 16 floats per instruction, and if you’re trying to implement a video codec or large-scale physics simulation, an order of magnitude of speed difference can make or break your app.

To take an example where timeliness is crucial, think of the difference between, say, 10 frames per second vs. 60 frames per second in a first-person shooter game.

[nwah1]

The important use case is to allow people to write web applications with their language of choice, instead of horrible javascript. And get near full performance.

[klodolph]

I think this is important. Probably because I have the "worse is better" article from 1991 open in another tab, and if you s/Lisp/Javascript/g then many of the criticisms ring true. Some of what made Unix, Windows, and Mac OS healthy environments for development was the fact that all developers were equally well off, you didn't have to pay a tax for writing something in a language other than Lisp. You could keep your Fortran code, and mix it into a C program, run from a Bourne shell, running in terminal emulator written in C and a WM written in Lisp. You can replace any part with a part written in a different language.

JavaScript will continue to be dominant, but we desperately need to be able to write things in the language of our choice.

[nostrademons]

Hmm? You paid a huge tax in desktop development for writing in a language other than the one the OS was written in. All of the platform documentation & examples were in its "native" language. You usually had to marshall data structures yourself to fit the data formats of the native language. You had to write shims (oftentimes in assembly!) that would bridge the calling conventions of your preferred language to those that the frameworks were written in.

There's a reason that C became the dominant language during the 80s and early 90s: it's because Win32, UNIX, and MacOS >=7 were all written in it. That's a large part of what Worse is Better was about. Richard Gabriel founded a company to write software for Lisp Machines, pivoted it to run Lisp on commodity hardware, found that all of his customers would rather just write in C, pivoted it again to do a C++ dev environment, and eventually went out of business.

The renaissance for other languages was really during the web era, when everything just spit out HTML and it didn't matter what the server was written in. Once customers started demanding rich interactivity on the client, there was a strong incentive to write everything in Javascript, and then a strong incentive to write the servers in Javascript too, and then a strong incentive to use Javascript for other things like native apps and IoT devices too.

[klodolph]

Yes, you paid a tax. But my argument here is that the tax for writing in different languages on Win32, Unix, and Mac OS was far cheaper than the tax for writing in other languages on a Lisp machine. This is because translating low-level code to high-level code is not as straightforward as the reverse operation. For example, if I compile C to JavaScript, how do I even think about writing a function like memcpy()? You end up with a monster like asm.js where interacting with the DOM is a chore.

Yes, the web brought a renaissance in different languages. But we already had a bunch of different languages lying around when the web became important. We were already using different languages to write desktop software. I didn't even learn C until the late 1990s, but I was happily writing software before then.

WebAssembly is going to make languages other than JavaScript palatable in the browser, and I can only see that as a good thing.

[lispm]

> Richard Gabriel founded a company to write software for Lisp Machines,

The company Gabriel founded (Lucid Inc.) was never supposed to write software for Lisp Machines. Its mission from day zero was to develop a Common Lisp implementation for stock hardware (SUNs, etc.). Symbolics, the Lisp Machine maker, refused to fund a portable Common Lisp implementation (which Gabriel and Benson, the latter then at Symbolics, proposed).

> found that all of his customers would rather just write in C, pivoted it again to do a C++ dev environment, and eventually went out of business

Actually the Lisp business of Lucid Inc. financed the C++ development.

It was a gamble. They easily could have continued to develop and sell Common Lisp (their main competitors from that time, Franz Inc. and LispWorks are still alive) and stay in a small/shrinking niche. But Lucid tried to diversify and to grow. The idea was to write a C++ environment with a similar and improved development experience as a Lisp system. They used the cash cow they had and eventually sunk the whole company when the C++ system flopped in the market. Their C++ system (Energize) was very expensive, technically complex, ...

[z3t4]

I think that's like saying: "I prefer to use the hammer instead of the screwdriver" for something with a helical ridge.

You are better off re-inventing Java or Python, but in a container and streamed over the Internet from an URL.

[jondubois]

I can't believe people still bash JavaScript.

I've used a lot of different languages including Java, C#, C++, AVR Assembly, Python and others but JavaScript is my favourite and I would not want to go back.

I think its a shame that some people just didn't seriously try JavaScript. It's a very powerful, expressive language.

Also, testing with JS is amazing - Especially unit testing on Node.js. It lets you do stuff like redefine entire objects, properties or methods at runtime (for stubbing).

Also, JS is great for writing asynchronous logic.

[orangecat]

I can't believe people still bash JavaScript.

I can't believe people actually like it. It might be understandable if you're comparing it to enterprisey Java, but I'm baffled that anyone could prefer ES5 to Python or Ruby. (I will acknowledge that ES6 puts it somewhere in the area of Python 2.5).

It's an incredibly powerful, expressive language.

Not if you want super advanced features like a hashtable with non-string keys, or checking if two objects are equal.

It lets you do stuff like redefine entire objects, properties or methods at runtime (for stubbing).

As does any other dynamic language.

Also, JS is great for writing asynchronous logic.

As is any other language with first-class functions. And with others you don't have to do silly contortions to work around JavaScript's broken "this".

I think its a shame that some people just didn't seriously try JavaScript.

Tried it, have written it professionally for many years, and as a result am very much looking forward to WebAssembly.

[spion]

An interesting aspect which JS has and other languages don't is the "objects are hashes" notion. Combined with TypeScript / Elm / PureScript's ability to write and check the types of these (especially Elm before the refactor that removed the add/delete field features), this is very powerful. I often wish Haskell's built in records were as powerful as Elm's / PureScript's, but wonder if thats doable in an efficient way without the JIT logic in engines like V8.

Also, there is something to the whole "modules are records/hashes" idea which is quite elegant, IMO. I'm not sure why we still put up with the idea that the module system needs to be a whole different language with different rules. But I'm not sure if there is a type system capable of modelling this very well.

[fanf2]

Are there any dynamic languages in which objects are not hashes?

[hawkice]

Ruby -- object data is all private, and the reader/writer/attr things just make the getters and setters for you.

[spion]

Python is another example. You can assign dynamic properties, but there is no object literal syntax

[aikah]

> I can't believe people still bash JavaScript.

Can you believe you can satisfy every programmer out there with a single language? of course not. Why did you have to use all the languages you listed? Because some made sense in a specific context, other didn't.

> Also, testing with JS is amazing - Especially unit testing on Node.js. It lets you do stuff like redefine entire objects, properties or methods at runtime (for stubbing). Also, JS is great for writing asynchronous logic.

Testing with Python is also amazing. It doesn't matter how amazing it is if I hate writing Python code.

No, the reality is that, in 5/10 years, javascript skills wont matter, only a good knowledge of the DOM and WebAPIs. In fact I'm pretty sure you'll see more opening for C++ developers on the front-end than Javascript ones.

[pcwalton]

> In fact I'm pretty sure you'll see more opening for C++ developers on the front-end than Javascript ones.

I would be happy to take a bet that this will not be the case.

The fact is that JS is much easier to learn than C++, has a broader ecosystem in the browser, is faster to write than C++ due to memory safety among other considerations, and is fast enough for app logic.

Think about it. C++ code has been supported for years on mobile. Yet Java/Dalvik is king on Android, and Objective-C is king on iOS. JS is faster than both (in the case of Objective-C, JS property access is faster than Obj-C virtual method dispatch due to ICs). So I see no reason why this will not be true on the Web as well. Web Assembly is very needed and important, but JS won't be going away.

[cballard]

If you're dissatisfied with objc_msgSend performance, you can write C or C++ seamlessly - or use that other language that's partially designed to address the dynamic dispatch nightmare.

If you're dissatisfied with JavaScript call performance, you have no choice.

[pcwalton]

> If you're dissatisfied with JavaScript call performance, you have no choice.

Other than the topic of this article?

[catnaroek]

I have no idea what you mean by JavaScript being "easier" to learn than C++. My experience has been the exact opposite.

C++ is a giant beast, but most of it was relatively easy to learn after I internalized the general principles that guide the language's design. These principles were the first coherent account I ever found of how programs manipulating ephemeral resources should be written. [I am aware that Rust improves on C++, but it builds on, rather than replace, the general principles established by C++.]

On the other hand, in JavaScript I have never found anything even remotely close to methodological guidance for writing programs. JavaScript seems to make sense of anything as long as it is syntactically valid - a very low bar. As a result, I felt like I had to navigate a really huge space, hoping to eventually find a correct program somewhere.

JavaScript's ability to run in the browser is, as far as I can tell, its only advantage over C++.

[pcwalton]

> I have no idea what you mean by JavaScript being "easier" to learn than C++. My experience has been the exact opposite.

You are a tiny minority in this. I've taught C++ and JS and have never once seen JS be harder to pick up.

> On the other hand, in JavaScript I have never found anything even remotely close to methodological guidance for writing programs.

The #1 selling JS book is (was) literally called "JavaScript: The Good Parts". It teaches "methodological guidance" for writing JavaScript programs. Just as modern C++ books teach the "good parts" of C++.

> JavaScript seems to make sense of anything as long as it is syntactically valid - a very low bar.

That's (a) not true, with the static resolution semantics in modules; (b) to the extent that it is true is mostly a criticism of dynamic typing, which has a lot of advantages and is not a criticism of JavaScript.

> JavaScript's ability to run in the browser is, as !far as I can tell, its only advantage over C++.

Memory safety? GC? A module system (as compared to #include)? Dynamic typing? This is silly.

(NB: I also think C++ has a lot of advantages over JS for certain domains. I'm a language pluralist.)

[cballard]

I've tried JavaScript, and I decided I preferred type safety. This kind of thing:

> It lets you do stuff like redefine entire objects, properties or methods at runtime

Sounds horrifying to me, because, as in Ruby[1], library authors will decide that's a good idea. Typeclasses/protocols solve this problem perfectly, while maintaining type safety.

[1]: for some reason, this seems to be less of an issue in Python and Obj-C, even though it's totally doable?

[vardump]

If type safety is what you miss, why not to use some transpiler like TypeScript?

http://www.typescriptlang.org/Tutorial

[cballard]

Then you're not writing JavaScript, which was OP's concern. TypeScript is fine (although Elm, Swift, and Haskell are more interesting, IMO).

[vardump]

TypeScript is very close to normal JavaScript. It's basically just JavaScript + type annotations which a compiler can check.

Compilation phase removes the annotations, after that point it is pure JavaScript.

How are Swift and Haskell relevant for client side web development?

Edit: Removed Elm

[1ris]

Look at purescript. In order to install this madness you need to install not less than 5 package managers, but you might like it.

[zeveb]

> I can't believe people still bash JavaScript.

== vs ===

!==

hasOwnProperty

> Also, testing with JS is amazing - Especially unit testing on Node.js. It lets you do stuff like redefine entire objects, properties or methods at runtime (for stubbing).

Doable in Common Lisp for 21 years…

> Also, JS is great for writing asynchronous logic.

ITYM JavaScript has first-class functions. So does Lisp, so does Python, so does Go…

[sklogic]

Now try to take a look at some real languages. At the languages with well-defined, simple, orthogonal semantics.

And, no, JavaScript is nowhere near any "powerfull, expressive language". It is embarrasingly low level for a supposedly scripting language and it does not provide any powerful productivity features whatsoever.

JS is also a nightmare for the implementers, it does not have a sane specification, therefore most of the tooling is not comprehensive.

[1ris]

It's not a bad language, but it's not good either. But who is it powerfull? It's a very poor man's scheme, and scheme is not powerfull either. If javascript has anything to over it's IMO simplity and not power.

But I'll never understand who thought this asynchronous API was a good idea.

I just wanted to draw pictures in a canvas _in order_, because they should overlap. A common task you could mean. I ended up building a monadic builder for callback chains, that creates a javascript string that is evaled. I felt like this language and the api was incredibly cumbersome, minimalistic and limited. It lacks a blocking api, monad support, dsl support, macros and lazy evalution.

But mayme there is a simple solution to that, that I'm not aware of.

[wtetzner]

> scheme is not powerfull either

In what sense is Scheme not powerful? It has TCO, syntax-rules, call/cc, etc.

Of course, all of those are things scheme has that JavaScript doesn't.

[1ris]

No types, a very minimal syntax, a standard library so slim that everything interesting is a implementation-detail. And, as I a said, javascript has less. Javascript even lacks integer variables, while scheme has the numeric tower. (Although that is not required by rsr4/rsr5 and that what most implementations care about)

[wtetzner]

> No types, a very minimal syntax

I don't see how these make the language less powerful. Especially the syntax part, which plays a big part in Scheme's power, as an enabler for macros.

> a standard library so slim

I agree with this though.

[masswerk]

Sorry to say, but the web isn't about writing apps in the language of your choice. If it's beyond plain, passive HTML, it's about running applications on foreign hosts/resources without a well specified license to do so. Scripting languages provide both audible code and a small load as compared to binary object code (which is, why we had them on servers and clients in the first place).

If we turn the web into an anything-goes bonanza using binary code without any keys, credentials, or permissions, WebAssembly (and Turing complete CSS as well) may be well the beginning of end of the web as we know it, giving raise to a new, leaner and more restricted platform (for which some are already on the lookout, BTW).

[Edit] A small real world example: Client asks me to implement a third party plugin to allow them direct communications with their users via their website. A quick scan of the source code tells in a minute that the script isn't just doing that, but is also tracking user behavior and is phoning home related data. Now I can ask the client, if they really want to expose their users to this. With WebAssembly, there's no chance to do so.

[icebraining]

Try looking at the source of Google.com and saying all it's doing in under a minute.

You could look at the APIs it's using - why is it calling XMLHttpRequest or looking at the user's cookies? - but you can do the same with binaries, you just have to use a tool, e.g. 'nm -D <binary>' shows you the external functions the program calls.

I held the same position until circa 2008 (?), when JS minifying became truly widespread; nowadays, I think that battle is already lost.

[masswerk]

So, just give up?

(Please mind that there has to be a strict relation between a minified code and a plain source code provided at some repository. This is not true, at least in terms of the resources needed to verify this and the probability of this being covered by average budgets, for binary codes. – Recommended reading: "Reflections on Trusting Trust" by Ken Thompson)

Edit: At best you're winning a year's worth of Moore's law in performance and are paying for it in terms of page load. On the down-side, binary code is just as bad an idea as e-voting: You're putting the interests of your users against literary trillions of dollars of interest in exploiting the system (yes, the leverage would be enorme) – and if the worst has become true, it's already too late to revert.

[Rapzid]

Probably solve it the way we do with the rest of shared libs and open computing:

Require the source. Download compiled code from trusted sources.

Download a nuget package; dll's. Download an apt package; binaries and so's. This won't blow up web.

[masswerk]

Not your everyday real-life story. Client: "Integrate this (see attachment)". You, "No, they have first to hand over the source code in order to allow me auditing their software." Client: (gone).

As for the real-life example given above: The third party is billing the client only a few bucks, since the real business is in profile building and exchanging profiles. So, are they expected to hand out the source code for 5 bucks or so? Probably not. Who is to lose? Everyone visiting the website.

[MichaelGG]

Why are you under the impression there won't be disassemblers and decompilers for WebAssembly?

It's not like a bunch of minified JS is going to be "quick" to go through.

[masswerk]

Even, if there would be a suitable disassembler, this would just account to an exponential curve in terms of auditing any software. (We're not speaking of minutes here anymore, but rather of months or even years – who will be willing to pay for it?) BTW, with minified JS, you've just to recode variable names (while anything adequate to system calls has to be in plain text somewhere by definition), with WebAssembly, this becomes an entirely different story. – No comparison.

[MichaelGG]

This is basically the same case for traditional binaries. I'm no RE expert, but when I've done such work it consists of "renaming variables" including functions and looking for calls to imported functions. Intentionally obfuscated code is harder.

But nothing stops JS from loading a bunch of encrypted strings, self-modifying at runtime, using eval+substring (at various offsets) on loaded and renamed functions to make it hard to know if there are calls to other functions, let alone what they are.

It can still be done, and obfuscated JS is probably easier than obfuscated x86 but saying it makes an audit only take minutes means it's not really being obfuscated.

[Senji]

>But nothing stops JS from loading a bunch of encrypted strings, self-modifying at runtime, using eval+substring (at various offsets) on loaded and renamed functions to make it hard to know if there are calls to other functions, let alone what they are.

There is a solution to that. Control the platforms. You have like what, 4? major vendors of browsers. Convince them to make eval disabled by default and you warp the entire usable market. The percentage of people who would bother to go hunting the setting to turn it on would be minuscule.

Use the power of the default to affect the whole space.

[masswerk]

I really don't get the down voting: While we've come globally to the conclusion that we require signed software, curated app stores and kill switches for traditional applications, because sh#t happens, we're going to distribute binary software in the browser without any such limitations? With the average user not even knowing that she is running some software from untrusted sources? (Yes, I know, it will be sandboxed, and there will never be a zero-day anymore in any browser ...)

[kristopolous]

We will eventually come to terms with the fact that Flash was 15 years ahead of everything else on multiple fronts and we ought to have been just chastised the terrible developers doing awful and horrendous things with pretty technically sound software.

[Scaevolus]

HTML5 _still_ isn't able to deliver the quality interactive experiences (Games) without applying a lot more effort. Even "simple" things like cross-browser low-latency sound effects are still difficult.

Flash presents a single platform with a single vendor that can innovate as quickly as they like. The web platform is inevitably cumbersome and slow in comparison -- over a decade later they're still playing catch-up.

I'm looking forward to WebGL ads that eat battery life with excessive shaders.

[kristopolous]

As a strong supporter of open source, doing a comparative analysis of HTML5 and Flash, I have to admit that private enterprise was able to kick the ball forward so much faster here ...

I remember watching a vector animation version of a "tell-tale heart" in flash in 1998. On a 28.8 connection it played smoothly full-screen on a 120mhz pentium with 16mb of ram. I remember clicking the play button and having it just miraculously starting to play without any wait, streaming down and uncompressing in real time. I was floored by it. 12 years later I was invited to watch a spiderman animation demo using HTML5 ... there was a 30 second load time, the framerate was probably 1fps, the audio didn't work, the content didn't render properly ...

It's like how Microsoft was able to pull off nearly everything we could do today by shoe-horning their activeX technology into ie3. Just load a bunch of cab files and drop them into the page like OLE components and bam, you got just about everything. The interactivity could bootstrap - that is, not need any extra plugin and you could engage with the other content on the site using vbscript or javascript interfaces in a two-way manner. It was pretty nice.

Netscape retorted with their JVM integration but it just wasn't the same ...

[DanWaterworth]

If you want to go fast, you go alone. If you want to go far, you go together.

[Bjartr]

For all the problems Flash had, one problem it didn't have was a lack of mature tooling (compared to its alternatives at any given point in time). A lack of tooling makes making HTML 5 games very difficult, the abstraction layers that existed for Flash don't for HTML 5, at least not to the same level. Even if HTML 5 were capable of precisely the same level of performance, or better, as Flash today it would still be some time before the experience of a content creator reached parity with what already existed for Flash.

At no point has the debate between Flash and HTML 5 content ever included "Content creators will have an easier time with HTML 5". It's an ecosystem that has to develop over time, and HTML 5 the content platform has only approached feature parity with Flash in the past couple of years.

[chillingeffect]

I'm glad you pointed this out. My roommate's career was a flash developer and his primary skills were animation and graphic design. He spent hours doing that and got me to help out with the few numerical/mathematical tasks he needed to fill-in.

I was a dork and overacted to his use of 100% global variables, etc. He gracefully tried to use Flash's OO to appease me and improve himself, but really he got quite far in life doing graphics and even basic database access in Flash.

I think the tooling might be the point where HTML5/JS (h5js?) becomes divergent. Think about it: making a flash-like editor for HTML5 requires an investment in time and different groups/companies will want to do it differently... Then, they'll start to add tiny features to push their implementation over the time and poof~ towerofbabel.jpg.

[kristopolous]

I place very strong bets that Adobe will create a dominant tool here. It will be nearly identical to flash but emit all the new fangled html5 asm.js stuff instead - in some nice tight drop-in way ... like

<div id="container">

  <script src="//ad.be/UNIQID"></script>

</div>

Where ad.be is a "cloud" service you pay $xx/month to "host" your "app" for you. Essentially you make the thing, it saves to the cloud, generates your uniqid, and you put it in a container. They keep the source file and can continually regenerate the js as their "engine" improves and browser tech moves forward. It's a future-proof plugin-less flash with a large existing user and customer base.

If that's the flow, Adobe might as well just start minting money.

[wtetzner]

> I'm looking forward to WebGL ads that eat battery life with excessive shaders.

As opposed to flash ads that eat battery life and bring the browser to its knees?

[andybak]

I think that was his point.

[Eric_WVGG]

How would that have fixed Flash’s horrible CPU cost, chronic security vulnerabilities, awful touch support, or constant prone to crashing, even in the hands of competent developers?

[lmm]

Like HTML5 is better at any of those? I'm pretty sure Flash crashed an order of magnitude less often than WebGL does.

[guelo]

Performance-wise flash wasn't that bad on Windows. Probably because Adobe put in a decade's worth more engineering into Windows than Mac. And of course they were caught off guard by the iPhone, like the rest of the industry.

[Eric_WVGG]

Better than Mac… but not good

http://www.pcworld.com/article/2960741/browsers/tested-how-f...

[loup-vaillant]

If only Flash weren't proprietary…

[modeless]

Web assembly doesn't add new APIs or capabilities to the web platform. It only makes code run faster and makes porting C++ code easier. What about that is hateful or abusive?

[kuschku]

That now we can’t read the source of webpages at all anymore?

The whole "anyone can look at it, learn from it" part is gone?

We’re steering towards more proprietary code.

Say, for example, if I want to run Google’s "Star Wars" easter egg in Firefox. With JS, I could grep through the de-uglified and de-obfuscated code quickly, and find that its useragent detection would work if I’d just append "AppleWebKit Chrome/45.0.0.0." to the UserAgent. With WebAssembly, I’d have to spend far more work.

[modeless]

You can't read the obfuscated code directly. You have to use tools to deobfuscate it. With Web Assembly it will be the same. There will be tools to help you read the code. You may proclaim that they won't work as well but I think it's premature to say that. Web Assembly is not machine code.

[kuschku]

Web assembly is very generic byte code.

I fear I’d end up spending ages in IDA breaking a DRM scheme implemented in WebAssembly, just like I did with NaCl.

That’s not neat.

[c0nfused]

Sorry, my intent was not to imply that web assembly was hateful or abusive but that the code I might write using it falls into two categories

1. Performance critical code 2. Sneaky stuff I really don't want the user to be able to read.

Category two seems like the sort of thing that I would absolutely want to be able to write binary code that executes without user interaction.

It seems like right now the focus is quite rightly on #1, but that #2 seems like it will inevitably become an issue.

[ghthor]

> 2. Sneaky stuff I really don't want the user to be able to read.

The user is already going to have a hard time reading the unuglified JS. If they are looking for "phoning home" they have to search for WebSocket sends and ajax calls. Both of those will have well defined APIs that will be just as easy to spot in dissembled webasm as they are in unuglified JS. I bet they'll be even easier to spot.

[Sanddancer]

You're missing category 3: Code that runs in more than a browser. If I have code written in Fortran that already solves my problem, why should I have to rewrite it? If I'm more comfortable in C#, why should I be forced to use Javascript for writing front-end code? WebAssembly fixes the mistake that the web should be a monoculture, and allows people to use the best language for the job.

[sklogic]

3. Any other code written in a language better than JS.

[sliverstorm]

Many of the worst parts of flash had to do with (IMO) the single-source nature, that is to say Adobe. Flash is using all your RAM? Flash is slow? Flash is hard to develop good UI for and integrates poorly in browsers? Too bad, it's Adobe's runtime & plugin, or nothing.

[sklogic]

WebAssembly is a way to finally get rid of that overgrown scripting abomination that people started to take for a real language. And arguably it is the only way to get rid of that thing, any other will simply create another insufferable abomination.

[aikah]

The big difference is that WebAssembly can only do what Web APIs allows it to do. You'll have to do the same AJAX calls, the same DOM manipulations as with Javascript. There is no plugin here.

> I always feel like the most obvious use for it is to start writing truly hateful and abusive code.

Sure, but it will also developers to have a better experience by allowing them to chose the language they want, and not to be forced to use JavaScript. Choice is good, it's something you cannot deny.

[walterbell]

Do you like any other visions for the future of the web? Brendan Eich's startup hasn't shared much about their plans, http://www.cnet.com/news/mystery-startup-from-ex-mozilla-ceo...

[coldtea]

>Web assembly always makes me a little sad. It feels like we are going back to flash only it won't be bad this time, I promise, no really.

Only if you miss the obvious and blatant technical and license differences.