8 ms·

Finally , people will be able to get rid of javascript wholesale . No transpilation , asmjs whatsoever. It basically means that javascript will die in the long

by aikah 11y ago

Finally , people will be able to get rid of javascript wholesale . No transpilation , asmjs whatsoever. It basically means that javascript will die in the long run and people will be able to use whatever language they want to use, actionscript , java , c# you name it. That's a game changer and it's a future standard , so no plugins.

deleted 11y ago
[deleted]
jeswin 11y ago
I welcome being able to use any language. But, > No transpilation You'll have to compile instead. > people will be able to get rid of javascript wholesale Modern JS (ES6+) isn't worse than Java or C# in terms of expressiveness. In fact, it might even be better in some cases. No other language is going to come with built-in tools for editing within browser/client dev tools. Modern JS is going to be one of the easy languages to get started on. And of course, you totally underestimate the billions of lines of JS already written for the Web.
- aikah 11y ago
  > Modern JS (ES6+) isn't worse than Java or C# in terms of expressiveness. In fact, it might even be better in some cases. ES6 isn't statically typed. It might be better for you , it is not for me. > You'll have to compile instead. Yes, and without caring about Javascript. That's the point. Javascript will become irrelevant when it comes to front-end development. One language cannot possibly satisfy everybody's needs. If that was the case we would all be using nodejs on the server and that's hardly the case.
  - yareally 11y ago
    > ES6 isn't statically typed. It might be better for you , it is not for me. Perhaps you should just look into using TypeScript? It's basically ES6 with static typing.
    - tkubacki 11y ago
      or even better Dartlang is't optionally typed - for both sides of the fence
    - lmm 11y ago
      It's a pretty weak static type system, and it retains javascript's other warts (e.g. scoping). And if I'm going to have to do a separate compilation step anyway then I might as well use a nicer language.
      - jimbobimbo 11y ago
        TypeScript treats "let" correctly, while transpiling it down to ES3/5 that have no concept of "let".
  - egeozcan 11y ago
    > It basically means that javascript will die in the long run > Javascript will become irrelevant when it comes to front-end development. I understand the enthusiasm but this becomes a bit of an argumentum ad populum.
  - colin_jack 11y ago
    > Modern JS (ES6+) isn't worse than Java or C# in terms of expressiveness. > ES6 isn't statically typed. It might be better for you , it is not for me. So you are saying that because it isn't statically typed it's inherently worse in terms of expressiveness? There's a valid argument that static typing has big advantages (navigation, refactoring) but it worries me when people write off dynamic code entirely.
    - seanmcdirmid 11y ago
      Also performance, don't forget how effective unboxing is in many applications.
    - azth 11y ago
      OP (aikah) didn't mention anything regarding expresiveness. The post that replied to that one brought up the expresiveness issue. That being said, yes, it has been shown that, for large projects, statically typed languages are strictly superior than dynamically typed ones.
      - colin_jack 11y ago
        OK but he quoted the expressiveness in his reply which I thought meant that was the point he was addressing.
        bibabo 11y ago
        More like the point you wanted him to address so you could add a snarky reply.
        colin_jack 11y ago
        Utter nonsense, he replied to a comment about expressiveness with [1], its only natural that I assumed he was saying that lack of static typing lead to lack of expressiveness. [1] ES6 isn't statically typed. It might be better for you , it is not for me.
    - 11y ago
- colordrops 11y ago
  You could write an interpreter in WebAssembly and then run your scripts on top of that interpreter in the browser.
- lqdc13 11y ago
  I tried JS multiple times. And every time, easy things are complicated when doing them in JS. It is much easier and faster for me to do those same things in C, even though I'm equally familiar with both. This is mostly because there are just so many gotchas. Here are some examples from this week: Checking whether a passed argument is an array or a dict: var a = [] if (Object.prototype.toString.call(a) !== '[object Array]') ... (perhaps not js itself, but how it is used) Leaking DOM nodes are a thing: https://developer.chrome.com/devtools/docs/heap-profiling-dom-leaks https://developer.chrome.com/devtools/docs/heap-profiling-do... Easy things like getting values of a dictionary: var d = { a: [1,2,3,], b:[4,5] } var values = Object.keys(d).map(function(key){ return d[key]; }); in Python, it's just .values() Errors aren't thrown when there are obvious issues with the code. String.replace replaces one instance instead of all instances in a string. Functions arguments are a bit of a mess. differences between for each (var myVar in myObject) for (var myVar in myObject) random things like these: http://stackoverflow.com/questions/2568966/how-do-i-pass-the-value-not-the-reference-of-a-js-variable-to-a-function http://stackoverflow.com/questions/2568966/how-do-i-pass-the... All the things here: http://www.toptal.com/javascript/10-most-common-javascript-mistakes http://www.toptal.com/javascript/10-most-common-javascript-m... If you import a library, they could have modified the global scope. This is common in JS libraries. Then some things you wrote don't work. undefined/null thing differences between var declared function and regular named function. Many things in the language are not obvious and you have to discover them through trial and error or study JS internals and find out how things are implemented.
  - kolme 11y ago
    > Checking whether a passed argument is an array or a dict Luckily solved in ES2015: Array.isArray(thing) The toString trick is pretty outdated, in ES5 you can also do: thing instanceof Array > (perhaps not js itself, but how it is used) Leaking DOM nodes are a thing Definitely not JS itself, it's easy to create circular references between JS objects and DOM elements. It's just the way the DOM is (poorly) designed and the way it interacts with JS. > for each (var myVar in myObject) That's not even standard, just a Mozilla "dialect". I don't think that's supported by any engines other than SpiderMonkey and predecessors.
- alkonaut 11y ago
  > Modern JS (ES6+) isn't worse than Java or C# in terms of expressiveness. It's hard to compare. Java is horribly verbose, but C# (and F# even more) is pretty concise these days, definitely comparable to JS if you factor in the increased lines of code you need in a dynamic language to have any certainty when refactoring.
  - edgyswingset 11y ago
    A lot of Java's verbosity has been addressed in Java 8. I would still call it terribly verbose if your codebase involved lots of OO-style structures (inheritance chains, factories, etc); but for more functional Java code it's got a feel to it that's very similar to C#.
- user_0001 11y ago
  >You'll have to compile instead. Good and 80% of JS bugs will disappear in a puff of smoke ;-)
- WorldWideWayne 11y ago
  You totally underestimate the millions of JS coders who want something better than JS, who have been using JS because that's their only choice. I think most coders would choose a language that has better tooling and robust standard library over Javascript which doesn't even have a standard library. This is certainly the death of JS.
  - swalsh 11y ago
    death? probably not... but dethroned? gosh i hope so.
- dragonwriter 11y ago
  > No other language is going to come with built-in tools for editing within browser/client dev tools. I think you've confused the present with the future. No other language comes with that today. There's no reason other languages shouldn't in the future, however.
silon7 11y ago
noscript better keep working. Also view-source.
- renekooi 11y ago
  view-source should keep working reasonably. WebAssembly defines a Text Format for exactly that purpose: https://github.com/WebAssembly/design/blob/master/TextFormat.md https://github.com/WebAssembly/design/blob/master/TextFormat...
kolme 11y ago
> It basically means that javascript will die in the long run Says who? I don't think it's going anywhere. I for one will be happily programming in ES2015+ in the future, for many years to come. And I know I'm not the only one (have you ever been at a JS conference?). Anyways WebAssembly is very much welcome. I can't wait to use python or haskell "natively" in the broweser.
- rocky1138 11y ago
  I totally agree. I love JavaScript but I also love the idea of WebAssembly. Bring on the future!
Fiahil 11y ago
Be able to use any language for the front end is great thing, but I have a concern for existing frameworks/libraries. If someone build a great tool, lest's say the equivalent of D3.js, in Java; I don't see a way I can use it in python without having to write a python API for that library. It's not necessarily bad. The first advantage being, that hopefully people are going to stop recreating new javascript frameworks every 2 months.
onion2k 11y ago
I don't see this replacing JavaScript. In fact, I believe it'll do the opposite - it'll make JavaScript more prevalent. If a company can deploy it's code to as browser-native blob it'd make a great deal of sense for developers and designers to be able to code things on top of it. JS is the obvious choice for doing that. And as a consequence, more developers from traditional desktop environments will need to get to grips with how to use JS in a browser-WASM-as-a-sandbox situation.
fagro 11y ago
I don't think javascript would go anywhere: https://github.com/WebAssembly/design/blob/master/FAQ.md#is-webassembly-trying-to-replace-javascript https://github.com/WebAssembly/design/blob/master/FAQ.md#is-... But It would be real nice to use C# as wasm.

by aikah 11y ago

deleted 11y ago

[deleted]

jeswin 11y ago

I welcome being able to use any language. But, > No transpilation You'll have to compile instead. > people will be able to get rid of javascript wholesale Modern JS (ES6+) isn't worse than Java or C# in terms of expressiveness. In fact, it might even be better in some cases. No other language is going to come with built-in tools for editing within browser/client dev tools. Modern JS is going to be one of the easy languages to get started on. And of course, you totally underestimate the billions of lines of JS already written for the Web.

aikah 11y ago
> Modern JS (ES6+) isn't worse than Java or C# in terms of expressiveness. In fact, it might even be better in some cases. ES6 isn't statically typed. It might be better for you , it is not for me. > You'll have to compile instead. Yes, and without caring about Javascript. That's the point. Javascript will become irrelevant when it comes to front-end development. One language cannot possibly satisfy everybody's needs. If that was the case we would all be using nodejs on the server and that's hardly the case.
- yareally 11y ago
  > ES6 isn't statically typed. It might be better for you , it is not for me. Perhaps you should just look into using TypeScript? It's basically ES6 with static typing.
  - tkubacki 11y ago
    or even better Dartlang is't optionally typed - for both sides of the fence
  - lmm 11y ago
    It's a pretty weak static type system, and it retains javascript's other warts (e.g. scoping). And if I'm going to have to do a separate compilation step anyway then I might as well use a nicer language.
    - jimbobimbo 11y ago
      TypeScript treats "let" correctly, while transpiling it down to ES3/5 that have no concept of "let".
- egeozcan 11y ago
  > It basically means that javascript will die in the long run > Javascript will become irrelevant when it comes to front-end development. I understand the enthusiasm but this becomes a bit of an argumentum ad populum.
- colin_jack 11y ago
  > Modern JS (ES6+) isn't worse than Java or C# in terms of expressiveness. > ES6 isn't statically typed. It might be better for you , it is not for me. So you are saying that because it isn't statically typed it's inherently worse in terms of expressiveness? There's a valid argument that static typing has big advantages (navigation, refactoring) but it worries me when people write off dynamic code entirely.
  - seanmcdirmid 11y ago
    Also performance, don't forget how effective unboxing is in many applications.
  - azth 11y ago
    OP (aikah) didn't mention anything regarding expresiveness. The post that replied to that one brought up the expresiveness issue. That being said, yes, it has been shown that, for large projects, statically typed languages are strictly superior than dynamically typed ones.
    - colin_jack 11y ago
      OK but he quoted the expressiveness in his reply which I thought meant that was the point he was addressing.
      - bibabo 11y ago
        More like the point you wanted him to address so you could add a snarky reply.
        colin_jack 11y ago
        Utter nonsense, he replied to a comment about expressiveness with [1], its only natural that I assumed he was saying that lack of static typing lead to lack of expressiveness. [1] ES6 isn't statically typed. It might be better for you , it is not for me.
  - 11y ago
colordrops 11y ago
You could write an interpreter in WebAssembly and then run your scripts on top of that interpreter in the browser.
lqdc13 11y ago
I tried JS multiple times. And every time, easy things are complicated when doing them in JS. It is much easier and faster for me to do those same things in C, even though I'm equally familiar with both. This is mostly because there are just so many gotchas. Here are some examples from this week: Checking whether a passed argument is an array or a dict: var a = [] if (Object.prototype.toString.call(a) !== '[object Array]') ... (perhaps not js itself, but how it is used) Leaking DOM nodes are a thing: https://developer.chrome.com/devtools/docs/heap-profiling-dom-leaks https://developer.chrome.com/devtools/docs/heap-profiling-do... Easy things like getting values of a dictionary: var d = { a: [1,2,3,], b:[4,5] } var values = Object.keys(d).map(function(key){ return d[key]; }); in Python, it's just .values() Errors aren't thrown when there are obvious issues with the code. String.replace replaces one instance instead of all instances in a string. Functions arguments are a bit of a mess. differences between for each (var myVar in myObject) for (var myVar in myObject) random things like these: http://stackoverflow.com/questions/2568966/how-do-i-pass-the-value-not-the-reference-of-a-js-variable-to-a-function http://stackoverflow.com/questions/2568966/how-do-i-pass-the... All the things here: http://www.toptal.com/javascript/10-most-common-javascript-mistakes http://www.toptal.com/javascript/10-most-common-javascript-m... If you import a library, they could have modified the global scope. This is common in JS libraries. Then some things you wrote don't work. undefined/null thing differences between var declared function and regular named function. Many things in the language are not obvious and you have to discover them through trial and error or study JS internals and find out how things are implemented.
- kolme 11y ago
  > Checking whether a passed argument is an array or a dict Luckily solved in ES2015: Array.isArray(thing) The toString trick is pretty outdated, in ES5 you can also do: thing instanceof Array > (perhaps not js itself, but how it is used) Leaking DOM nodes are a thing Definitely not JS itself, it's easy to create circular references between JS objects and DOM elements. It's just the way the DOM is (poorly) designed and the way it interacts with JS. > for each (var myVar in myObject) That's not even standard, just a Mozilla "dialect". I don't think that's supported by any engines other than SpiderMonkey and predecessors.
alkonaut 11y ago
> Modern JS (ES6+) isn't worse than Java or C# in terms of expressiveness. It's hard to compare. Java is horribly verbose, but C# (and F# even more) is pretty concise these days, definitely comparable to JS if you factor in the increased lines of code you need in a dynamic language to have any certainty when refactoring.
- edgyswingset 11y ago
  A lot of Java's verbosity has been addressed in Java 8. I would still call it terribly verbose if your codebase involved lots of OO-style structures (inheritance chains, factories, etc); but for more functional Java code it's got a feel to it that's very similar to C#.
user_0001 11y ago
>You'll have to compile instead. Good and 80% of JS bugs will disappear in a puff of smoke ;-)
WorldWideWayne 11y ago
You totally underestimate the millions of JS coders who want something better than JS, who have been using JS because that's their only choice. I think most coders would choose a language that has better tooling and robust standard library over Javascript which doesn't even have a standard library. This is certainly the death of JS.
- swalsh 11y ago
  death? probably not... but dethroned? gosh i hope so.
dragonwriter 11y ago
> No other language is going to come with built-in tools for editing within browser/client dev tools. I think you've confused the present with the future. No other language comes with that today. There's no reason other languages shouldn't in the future, however.

silon7 11y ago

noscript better keep working. Also view-source.

renekooi 11y ago
view-source should keep working reasonably. WebAssembly defines a Text Format for exactly that purpose: https://github.com/WebAssembly/design/blob/master/TextFormat.md https://github.com/WebAssembly/design/blob/master/TextFormat...

kolme 11y ago

> It basically means that javascript will die in the long run Says who? I don't think it's going anywhere. I for one will be happily programming in ES2015+ in the future, for many years to come. And I know I'm not the only one (have you ever been at a JS conference?). Anyways WebAssembly is very much welcome. I can't wait to use python or haskell "natively" in the broweser.

rocky1138 11y ago
I totally agree. I love JavaScript but I also love the idea of WebAssembly. Bring on the future!

Fiahil 11y ago

Be able to use any language for the front end is great thing, but I have a concern for existing frameworks/libraries. If someone build a great tool, lest's say the equivalent of D3.js, in Java; I don't see a way I can use it in python without having to write a python API for that library. It's not necessarily bad. The first advantage being, that hopefully people are going to stop recreating new javascript frameworks every 2 months.

onion2k 11y ago

I don't see this replacing JavaScript. In fact, I believe it'll do the opposite - it'll make JavaScript more prevalent. If a company can deploy it's code to as browser-native blob it'd make a great deal of sense for developers and designers to be able to code things on top of it. JS is the obvious choice for doing that. And as a consequence, more developers from traditional desktop environments will need to get to grips with how to use JS in a browser-WASM-as-a-sandbox situation.

fagro 11y ago

I don't think javascript would go anywhere: https://github.com/WebAssembly/design/blob/master/FAQ.md#is-webassembly-trying-to-replace-javascript https://github.com/WebAssembly/design/blob/master/FAQ.md#is-... But It would be real nice to use C# as wasm.