> This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript.

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

I really do hate javascript that much. It was somewhat acceptable when it was confined to the browser for simple scripting. But the more complicated the application and the more it moves out of the browser the more it's flaws get magnified.

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

Weird. I remember hating it ages ago. So much so that I was developing a Python->JavaScript transpiler (before all the cool kids were writing transpilers!) and blogging about how bad it was [1].

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

People have definitely had and continue to have successful careers in, and many actually enjoy, JS.

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.

This could be said for any language.

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.

It's a bit different. For system level programming you have a choice to get around C/C++.

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

Right, with JS there's almost no choice. C/C++ I actually really like, but I fear the great harm that I can inflict upon myself and others with them.

Anyway, the nouns are important.

These people are probably over represented here else things like Node.js, Electron would have never existed - and be successful.

Electron is awesome. And with webassembly, I think electron will be even better. Electrons success is because it offers a single Dev experience across all major platforms, windows, macOS, Linux and the web.

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.

I don't hate JS but would rather write my web codebase in something else, something that has a standard lib for instance. ES6 is also a transpile to JS language on the browser. The main problem is that we are stuck with ancient JS on the browser and WASM could fix that. Wouldn't you rather conpile ES6 to WASM instead of JS?

browsers that support WASM will support ES6 natively. compiling ES6 to WASM would not be a good idea, since you would have to send a garbage collector and full dynamic language runtime down the pipe instead of just using the one in the browser.

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

If all major browsers support 100% of the spec and every implementation is bug to bug compatible with the others, yes, I would rather run ES6 directly in the browser. The problem is fragmentation and not supporting the whole spec -- some functions working in Firefox and Chrome and not implemented in IE/Edge or Safari.

Has any runtime anywhere had 100% compatibility with anything ever?

The lack of choice has to be hated. Some hate JS just for that.

Not everyone can use ES6 or transpilers.

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.

I don't hate it, I just don't find it as productive as the server side language I use.

Absolutely

I don't quite agree with the all-or-nothing assessment, but your passion is exactly why this will happen.

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.

Is TypeScript as annoying a language to code in as Javascript? Or is it comparable to other modern languages like Swift and Go? If it is, I'd say that pain of dealing with Javascript (for developer productivity and happiness) is already taken care of.

Typescript is a type safe language that "compiles" into javascript. The Microsoft implementation compiles on save, so you work in your file.ts and a program running somewhere fires when the file is saved and converts it to file.js which you would distribute.

I haven't used it yet, but the demo from Anders looked good. It's an attempt to fix the "loosey goosey" nature of javascript. I would be great if browsers 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.

> 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

Thats not really what he asked though. If in the end a developer can work 98% in TS, do they really care if it runs as JS or something else if it solves their problems with the language ? I have heard from people that love TS, but surprisingly many that also prefer pure ES6 JS.

The only concerns I would have is I believe you have to debug the javascript rather than the typescript.

You can make the sourcemaps refer to the TypeScript code. I set breakpoints in TypeScript files and step through it all the time.

You should think of typescript as javascript+ more than a different language. It looks more like what javascript would look like in 2-3 version if the governing body thought static types were important to add.

That doesn't answer my question of whether TypeScript solves the concern of JS being frustrating to work in.

TypeScript is a joy to program in. I was on a project where we had the opportunity to turn on all the strict checks (no use of any, no implicit nulls, etc.), and it was super enjoyable and efficient to program in.

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.

But webassembly will allow for typescript or you language of choice, c/c++ and rust first, and as the OP suggests others too.

The question was whether the concern of JS being frustrating is already solved by TypeScript, in which case WebAssembly is less important than it would be otherwise.

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

Jup, I think pretty much the same.

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.

Wild guess? Oracle with Java.

Java failed to be what JavaScript became for a number of reasons, but I think the primary was the fact that it never integrated with HTML as cleanly as JS.

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

Java also has the problem of long startup times while the JIT is doing its thing. Javascript has always just started executing right away. Waiting a minute or two for a Java loading bar wasn't fun.

JavaScript hasn't always worked that way. My guess is that if Java had become the tool for this, then it's startup times would have been fixed. Pure speculation of course.

If Sun had not killed Hotjava and continued to develop and market it, Java instead of JS might have been the frontend web programming language today. There were millions of Java applets written in a very short time and a Java browser would have been a first class citizen for hosting those apps.

Java already compiles to JS via Kotlin.

And gwt

:troll: well played.

Not the intention, but I see that interpretation. It's not hard to imagine oracle making a netbeans plugin for free and an expensive enterprise version that's faster. Selling point is leveraging existing back end skills.