7 ms·

JavaScript ES6 is actually a very pleasant language to program in. JS already had good foundations with first class JSON, closures and event based asynchronous

JavaScript ES6 is actually a very pleasant language to program in. JS already had good foundations with first class JSON, closures and event based asynchronous programming. Now it has a modern syntax with await, classes, destructuring, default parameters, the spread operator, etc. Add to that an incredible debugger and amazing performance. Frankly at this point JS can stand on its own as a great programming language.

tim_hutton 9y ago
I like JavaScript a lot, I've got no problem with it. But when WebAssembly can access the DOM (or replace it) it seems likely that performance-critical code will use that instead.
- m0meni 9y ago
  But how often do front end applications have performance critical code that operates on the DOM? Even then, it's more likely that if you need to render something that requires that much processing power it'd make more sense to use something like canvas with WebGL.
- chatmasta 9y ago
  Sure, the major frameworks may move to wasm under the hood, but the users of the library will still likely be coding in ES6. We will probably see a lot of APIs where the backend is implemented in wasm with a friendly, scriptable frontend in typical ES6. That said, I’m actually skeptical wasm will ever find much of a use case with the DOM. The browser itself is already heavily optimized for working with the DOM, so wasm is unlikely to be competitive in speed except for specific use cases.
  - notheguyouthink 9y ago
    > Sure, the major frameworks may move to wasm under the hood, but the users of the library will still likely be coding in ES6. We will probably see a lot of APIs where the backend is implemented in wasm with a friendly, scriptable frontend in typical ES6. Why? If WASM has access to the DOM, and it's competitive in terms of performance - why would JS still by the goto? At that point, people will just choose whatever language they want, I don't see JS having an advantage there any longer. Especially since many people don't want to use JS to begin with, but have been forced to. > That said, I’m actually skeptical wasm will ever find much of a use case with the DOM. The browser itself is already heavily optimized for working with the DOM, so wasm is unlikely to be competitive in speed except for specific use cases. I'll be sad if that is true. Though, I'd even be willing to take minor performance hits to use the languages/etc I want. How much of a hit I'd be willing to take would really depend on the application needs, of course.
    - realusername 9y ago
      > Why? If WASM has access to the DOM, and it's competitive in terms of performance - why would JS still by the goto? At that point, people will just choose whatever language they want, I don't see JS having an advantage there any longer. Because of the built-in garbage collector, only non-garbage collector languages will actually be faster on WASM (so not that many of them) and the JS ecosystem is already so big that you would need a lot of work to match it in its current state.
      - goatlover 9y ago
        But it seems so far WASM mainly uses the canvas to draw it's own UI, which you might want from a heavy duty application like the Adobe products.
    - bryanlarsen 9y ago
      "why would JS still by the goto" Because that's where the libraries are. In most cases, a language's ecosystem is far more important than the language itself. We seem to get the next great front-end framework every couple years. Maybe the next great one will be in a language other than Javascript and at that point we'll start to see a significant language shift.
    - scottmf 9y ago
      Many of us do want to use JS. The language has evolved a lot over the past few years and people love it. Client-side JavaScript isn't going anywhere. Look how popular Node is despite all the alternatives.
      - pjmlp 9y ago
        Bulb effect.
      - notheguyouthink 9y ago
        > Many of us do want to use JS. The language has evolved a lot over the past few years and people love it. No one _(with any sense)_ thinks JS is somehow going to be deleted. Nor am I saying JS is going anywhere - if anything, I'm not even talking about JS, I'm not sure why you pointed out that JS is going to exist afterwards. Do I misunderstand your point? > Client-side JavaScript isn't going anywhere. Look how popular Node is despite all the alternatives. Well to be clear, there isn't alternatives, if the user wants a shared tooling, shared libraries, shared language. I don't think Node became popular years ago because JavaScript is so wooping awesome. Hell, when NodeJS came out transpilers (CoffeeScript/etc) were massively popular because of how much many people hated JavaScript. Node was popular despite many peoples dislike for the language. I worked for ~4 years at a company who built an entire platform in CoffeeScript, as did a few other companies we worked with. That's not to say that JavaScript is terrible, ES6+ is becoming really nice. I'm just saying, Node's popularity is clearly not evidence of JavaScript being awesome. Node is a symptom of people wanting a singular environment, and not having any choice about JavaScript.
  - goatlover 9y ago
    WASM will also be used to port applications in other languages to the web. And if you're a Rust or C++ shop, maybe you don't want to write your frontend in JS.
- fvdessen 9y ago
  AFAIK web assembly is not much faster than native javascript for general purpose code. I think the main usage of web assembly will be in optimising hot paths in math libraries, codecs and various performance sensitive code, but those are not critical parts for the majority of JS projects.
  - vanderZwan 9y ago
    > AFAIK web assembly is not much faster than native javascript for general purpose code. I've heard this before, and I'm sure it's true for "naive" code, but I find this a very unsatisfying truism because it does not tell me why. What is keeping WASM from being faster? Or alternatively: what is giving JavaScript an inherent edge in certain tasks. My guess would be that for more complicated tasks, WASM currently shines wherever Typed Arrays used to potentially give an increase in performance: wherever you can allocate a big chunk of memory once, and fast access to it is the main bottleneck, and that for most other things still is too much overhead in communication with the rest of the browser. But I simply don't know and it annoys me tremendously.
    - _Tev 9y ago
      From what i have seen UI / IO / glue code does not need that much performance. Therefore 80-90% of JS code you write does not need that much performance. So WASM will be great for specialized libraries, but for most stuff it will not be "much" faster than JS.
    - muthdra 9y ago
      The answer is compilers. The WASM compilers are still being optimized. Most of what you see in the wild is compiled using LLVM, even the Rust project. The WASM target is still under development so you can expect a lot of improvement there. One day we will see a language that compiles natively to WASM. Maybe even exclusively to WASM, with crazy optimizations akin to GCC's tricks with x86. I just hope it won't have objects.
      - vanderZwan 9y ago
- dspillett 9y ago
  > performance-critical code will use that instead Yes, but how much of the browser code out there is is truly performance critical. For a lot of code out there it is important that it perform well enough but it won't see much benefit from WebAssembly because of bottlenecks elsewhere (the DOM, the user, the network). Keeping the maintainability benefits JS currently has over WA is a bonus worth paying a small performance price, but you still want that price to be as small as practically possible. As WA and the toolchanins for which it is the final compile target mature, this may change. But I suspect JS has a place, a place where performance considerations are often not insignificant, for some time to come, with WA for extra performance in truly critical areas (i.e. proper number crunching).
- hajile 9y ago
  If that was shipping today, it would be another 7-10 years for browsers to catch up. At wasm's current rate, it won't be available for another few years. The ability to make decent garbage collectors also looks to be very far out. If you are writing JS today with even a couple years of experience, it's guaranteed to be used for everything until you retire (well, if retiring from a company after putting in your 20 was still a thing).
deleted 9y ago
[deleted]
m0meni 9y ago
Also add to that the huge amount of libraries available, great tooling, Flow and Typescript, and, even though it's kinda contrary to your point, all the compile-to-js languages that can leverage the JS ecosystem.
gigatexal 9y ago
Was JavaScript the first language to do event driven programming — if not it at least made it popular right? Maybe Erricson’s Erlang did it first? Which came first the actor or the onMouseOver?
- pjmlp 9y ago
  Smalltalk and Interlisp-D did it first.
- lambda 9y ago
  Event driven programming has been the norm for GUI systems as long as they have existed. I think that the heritage came from Simula in the 1960s, which influenced SmallTalk in the 1970s, which was a major influence for most object-oriented languages and GUI systems since then. Erlang and JavaScript come much much later on in the evolution of programming languages; Erlang originated in the late 1980s, and JavaScript in 1995.
  - gigatexal 9y ago
    That makes sense. I’ve bren dabbling in GUI apps with C# and I see some of that though I don’t quite understand it all yet.
- deleted 9y ago
  [deleted]
- PeCaN 9y ago
  Tcl had event-driven programming much longer than JavaScript (and much more pleasant). I think Erlang may have been the first production platform to do it, but I'm not sure about that. I suspect the idea has been around for a very long time, and there's probably some obscure language out there from 1960s IBM mainframes that came up with the idea.
- goatlover 9y ago
  Visual Basic did exist in the 80s. I don't know where this idea came form the JS pioneered event driven programming. There have been GUIs with events since the 70s.
Ixiaus 9y ago
The modern syntax you're speaking of is catching up to the early nineties and it still doesn't have a good static type system. It is not a great programming language, it is hanging onto relevance. With WebAssembly we now have a much more reasonable target for far more modern (and productive and enjoyable) languages like purescript.
- abritinthebay 9y ago
  Static type systems are incredibly overrated. Type inference is useful but there’s tooling to add that.
  - wenc 9y ago
    They are not overrated. Static type systems are tremendously useful for preventing a common class of programming errors, not to mention they enable reliable refactoring of complex codebases.
    - abritinthebay 9y ago
      Yes, you’ve repeated the same tired and unconvincing argument you read in your textbook. Meanwhile in the real world it’s demonstrate every day by users of dynamic type system that this is not true or required.
      - muthdra 9y ago
        It's a hardware overhead that harms automatic testing, dude. Dynamic type systems are an abstraction used to make programming faster and that's pretty much it. Also they only show up in interpreted languages so that tells a lot about focus on performance. I personally think it's overwhelmingly more interesting to drop this abstraction in favor of stability.
      - wenc 9y ago
        > Yes, you’ve repeated the same tired and unconvincing argument you read in your textbook. That is quite presumptuous. I spoke from personal experience (15 years in a dynamic language, 5 years in a statically typed language). > Meanwhile in the real world it’s demonstrate every day by users of dynamic type system that this is not true or required. Static type systems are not required (though you do incur a cost in writing a lot more tests in dynamic languages), but it is not true that they are overrated. It does sound like you inhabit domains that are well-suited to dynamic languages, hence you've arrived at an opinion that is a local optimum for your limited experiences. If you've ever worked with complex, multiparty, multidependency projects, you would not express such disdain for static type systems. The mypy project in Python recognizes that there is a place for static typing.

tim_hutton 9y ago

I like JavaScript a lot, I've got no problem with it. But when WebAssembly can access the DOM (or replace it) it seems likely that performance-critical code will use that instead.

m0meni 9y ago
But how often do front end applications have performance critical code that operates on the DOM? Even then, it's more likely that if you need to render something that requires that much processing power it'd make more sense to use something like canvas with WebGL.
chatmasta 9y ago
Sure, the major frameworks may move to wasm under the hood, but the users of the library will still likely be coding in ES6. We will probably see a lot of APIs where the backend is implemented in wasm with a friendly, scriptable frontend in typical ES6. That said, I’m actually skeptical wasm will ever find much of a use case with the DOM. The browser itself is already heavily optimized for working with the DOM, so wasm is unlikely to be competitive in speed except for specific use cases.
- notheguyouthink 9y ago
  > Sure, the major frameworks may move to wasm under the hood, but the users of the library will still likely be coding in ES6. We will probably see a lot of APIs where the backend is implemented in wasm with a friendly, scriptable frontend in typical ES6. Why? If WASM has access to the DOM, and it's competitive in terms of performance - why would JS still by the goto? At that point, people will just choose whatever language they want, I don't see JS having an advantage there any longer. Especially since many people don't want to use JS to begin with, but have been forced to. > That said, I’m actually skeptical wasm will ever find much of a use case with the DOM. The browser itself is already heavily optimized for working with the DOM, so wasm is unlikely to be competitive in speed except for specific use cases. I'll be sad if that is true. Though, I'd even be willing to take minor performance hits to use the languages/etc I want. How much of a hit I'd be willing to take would really depend on the application needs, of course.
  - realusername 9y ago
    > Why? If WASM has access to the DOM, and it's competitive in terms of performance - why would JS still by the goto? At that point, people will just choose whatever language they want, I don't see JS having an advantage there any longer. Because of the built-in garbage collector, only non-garbage collector languages will actually be faster on WASM (so not that many of them) and the JS ecosystem is already so big that you would need a lot of work to match it in its current state.
    - goatlover 9y ago
      But it seems so far WASM mainly uses the canvas to draw it's own UI, which you might want from a heavy duty application like the Adobe products.
  - bryanlarsen 9y ago
    "why would JS still by the goto" Because that's where the libraries are. In most cases, a language's ecosystem is far more important than the language itself. We seem to get the next great front-end framework every couple years. Maybe the next great one will be in a language other than Javascript and at that point we'll start to see a significant language shift.
  - scottmf 9y ago
    Many of us do want to use JS. The language has evolved a lot over the past few years and people love it. Client-side JavaScript isn't going anywhere. Look how popular Node is despite all the alternatives.
    - pjmlp 9y ago
      Bulb effect.
    - notheguyouthink 9y ago
      > Many of us do want to use JS. The language has evolved a lot over the past few years and people love it. No one _(with any sense)_ thinks JS is somehow going to be deleted. Nor am I saying JS is going anywhere - if anything, I'm not even talking about JS, I'm not sure why you pointed out that JS is going to exist afterwards. Do I misunderstand your point? > Client-side JavaScript isn't going anywhere. Look how popular Node is despite all the alternatives. Well to be clear, there isn't alternatives, if the user wants a shared tooling, shared libraries, shared language. I don't think Node became popular years ago because JavaScript is so wooping awesome. Hell, when NodeJS came out transpilers (CoffeeScript/etc) were massively popular because of how much many people hated JavaScript. Node was popular despite many peoples dislike for the language. I worked for ~4 years at a company who built an entire platform in CoffeeScript, as did a few other companies we worked with. That's not to say that JavaScript is terrible, ES6+ is becoming really nice. I'm just saying, Node's popularity is clearly not evidence of JavaScript being awesome. Node is a symptom of people wanting a singular environment, and not having any choice about JavaScript.
- goatlover 9y ago
  WASM will also be used to port applications in other languages to the web. And if you're a Rust or C++ shop, maybe you don't want to write your frontend in JS.
fvdessen 9y ago
AFAIK web assembly is not much faster than native javascript for general purpose code. I think the main usage of web assembly will be in optimising hot paths in math libraries, codecs and various performance sensitive code, but those are not critical parts for the majority of JS projects.
- vanderZwan 9y ago
  > AFAIK web assembly is not much faster than native javascript for general purpose code. I've heard this before, and I'm sure it's true for "naive" code, but I find this a very unsatisfying truism because it does not tell me why. What is keeping WASM from being faster? Or alternatively: what is giving JavaScript an inherent edge in certain tasks. My guess would be that for more complicated tasks, WASM currently shines wherever Typed Arrays used to potentially give an increase in performance: wherever you can allocate a big chunk of memory once, and fast access to it is the main bottleneck, and that for most other things still is too much overhead in communication with the rest of the browser. But I simply don't know and it annoys me tremendously.
  - _Tev 9y ago
    From what i have seen UI / IO / glue code does not need that much performance. Therefore 80-90% of JS code you write does not need that much performance. So WASM will be great for specialized libraries, but for most stuff it will not be "much" faster than JS.
  - muthdra 9y ago
    The answer is compilers. The WASM compilers are still being optimized. Most of what you see in the wild is compiled using LLVM, even the Rust project. The WASM target is still under development so you can expect a lot of improvement there. One day we will see a language that compiles natively to WASM. Maybe even exclusively to WASM, with crazy optimizations akin to GCC's tricks with x86. I just hope it won't have objects.
    - vanderZwan 9y ago
dspillett 9y ago
> performance-critical code will use that instead Yes, but how much of the browser code out there is is truly performance critical. For a lot of code out there it is important that it perform well enough but it won't see much benefit from WebAssembly because of bottlenecks elsewhere (the DOM, the user, the network). Keeping the maintainability benefits JS currently has over WA is a bonus worth paying a small performance price, but you still want that price to be as small as practically possible. As WA and the toolchanins for which it is the final compile target mature, this may change. But I suspect JS has a place, a place where performance considerations are often not insignificant, for some time to come, with WA for extra performance in truly critical areas (i.e. proper number crunching).
hajile 9y ago
If that was shipping today, it would be another 7-10 years for browsers to catch up. At wasm's current rate, it won't be available for another few years. The ability to make decent garbage collectors also looks to be very far out. If you are writing JS today with even a couple years of experience, it's guaranteed to be used for everything until you retire (well, if retiring from a company after putting in your 20 was still a thing).

deleted 9y ago

[deleted]

m0meni 9y ago

Also add to that the huge amount of libraries available, great tooling, Flow and Typescript, and, even though it's kinda contrary to your point, all the compile-to-js languages that can leverage the JS ecosystem.

gigatexal 9y ago

Was JavaScript the first language to do event driven programming — if not it at least made it popular right? Maybe Erricson’s Erlang did it first? Which came first the actor or the onMouseOver?

pjmlp 9y ago
Smalltalk and Interlisp-D did it first.
lambda 9y ago
Event driven programming has been the norm for GUI systems as long as they have existed. I think that the heritage came from Simula in the 1960s, which influenced SmallTalk in the 1970s, which was a major influence for most object-oriented languages and GUI systems since then. Erlang and JavaScript come much much later on in the evolution of programming languages; Erlang originated in the late 1980s, and JavaScript in 1995.
- gigatexal 9y ago
  That makes sense. I’ve bren dabbling in GUI apps with C# and I see some of that though I don’t quite understand it all yet.
deleted 9y ago
[deleted]
PeCaN 9y ago
Tcl had event-driven programming much longer than JavaScript (and much more pleasant). I think Erlang may have been the first production platform to do it, but I'm not sure about that. I suspect the idea has been around for a very long time, and there's probably some obscure language out there from 1960s IBM mainframes that came up with the idea.
goatlover 9y ago
Visual Basic did exist in the 80s. I don't know where this idea came form the JS pioneered event driven programming. There have been GUIs with events since the 70s.

Ixiaus 9y ago

The modern syntax you're speaking of is catching up to the early nineties and it still doesn't have a good static type system. It is not a great programming language, it is hanging onto relevance. With WebAssembly we now have a much more reasonable target for far more modern (and productive and enjoyable) languages like purescript.

abritinthebay 9y ago
Static type systems are incredibly overrated. Type inference is useful but there’s tooling to add that.
- wenc 9y ago
  They are not overrated. Static type systems are tremendously useful for preventing a common class of programming errors, not to mention they enable reliable refactoring of complex codebases.
  - abritinthebay 9y ago
    Yes, you’ve repeated the same tired and unconvincing argument you read in your textbook. Meanwhile in the real world it’s demonstrate every day by users of dynamic type system that this is not true or required.
    - muthdra 9y ago
      It's a hardware overhead that harms automatic testing, dude. Dynamic type systems are an abstraction used to make programming faster and that's pretty much it. Also they only show up in interpreted languages so that tells a lot about focus on performance. I personally think it's overwhelmingly more interesting to drop this abstraction in favor of stability.
    - wenc 9y ago
      > Yes, you’ve repeated the same tired and unconvincing argument you read in your textbook. That is quite presumptuous. I spoke from personal experience (15 years in a dynamic language, 5 years in a statically typed language). > Meanwhile in the real world it’s demonstrate every day by users of dynamic type system that this is not true or required. Static type systems are not required (though you do incur a cost in writing a lot more tests in dynamic languages), but it is not true that they are overrated. It does sound like you inhabit domains that are well-suited to dynamic languages, hence you've arrived at an opinion that is a local optimum for your limited experiences. If you've ever worked with complex, multiparty, multidependency projects, you would not express such disdain for static type systems. The mypy project in Python recognizes that there is a place for static typing.