5 ms·

>Based on its own merits it’s a pretty average language with lots of design flaws. I don't really judge a language based on the number of design flaws. That is

>Based on its own merits it’s a pretty average language with lots of design flaws. I don't really judge a language based on the number of design flaws. That is like judging a computer based only on its specs. >and most of its users never really got a chance to solve the same problems with a better language. I don't really think there is such a thing as "better languages". Also your statement is probably true, and was said about php as well. It is only true though because it has the most number of people using it, so will have the highest percentage of casual programmers. As with php though, you also have very good programmers using it. I am not really sure what the point of characterising the users is other than to subtitute for a lack of any arguments related to the language. But of course, the arguments on these topics are just a bunch of copy and paste from "list of reasons javascript sucks" articles. These just list design flaws like === and so on. "My PC is better because it has 2GB more ram than the mac". etc.... >web assembly Web Assembly is not supposed to remove javascript, it is supposed to be used in addition to it when you need high performance. If people try to promote it as a way to not have to use javascript, it will just result in a more fragmented client-side programming situation, where libraries are not available for particular languages, etc.

pjmlp 8y ago
> Web Assembly is not supposed to remove javascript, it is supposed to be used in addition to it when you need high performance. If people try to promote it as a way to not have to use javascript, it will just result in a more fragmented client-side programming situation, where libraries are not available for particular languages, etc. I guess you have been missing the news what is being done in Go, Java, .NET, Rust, Unity and everyone else regarding WebAssembly. We will have the revenge of plugins, like it or not. The only way out is if the browser vendors backtrack and remove WebAssembly support.
- lol-lol 8y ago
  Yep, exactly that will happen. There are lots of developers that stayed as backend engineers as they couldnt stand javascript (as a language and its integration with DOM), they stepped over the beginner phase with their development skills while javascript forced them to write BASIC (LOGO) level code. On the top of it, there were always some junior engineers that barely started to develop and were playing smart and bragging how cool the javascript is. There is a lot of rage stored in those circles and there are lots of excelent developers (I can tell you that 90% of top developers (not 25 years old kids, people that are able to write runtime compilers and OSes if given enought time) I know never wanted to work in javascript). Different reasons but I can tell you that most of them would say "I dont like java, but javascript is humiliating". Now the webasm is comming, I am preparing to bet that the frameworks will start to pop out in year or something after DOM is supported and they will overrun javascript in shortest possible time, just to prove the point - it sucks big time. QT is beeing prepared, all the "real" languages are starting to prepare to support compiling into webasm... the traditionally backend languages (that... you wouldnt believe... backend engineers know very well) are now having a chance to shine in browser that was restricted for them due to javascript monopoly. I wouldnt take the javascript future as really bright, in best case it will be used in same way as today shell scripts are (this is what they meant that webassembly is not replacement for javascript). To glue some parts of "system" (read as: browser) together. And quite frankly, this is step that should be done 10 years back. It would save world a lot of trouble. And have fun: https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGard...
- hajile 8y ago
  There's currently zero support for efficient garbage collectors and no Dom API access. Until a few more primitives are added, wasm is a pipe dream. Even once support exists, there's a payload issue. Nobody wants to spend loads of bandwidth downloading runtimes.
  - cm2187 8y ago
    The runtime is probably still be a fraction of the bandwidth consumed by all the photos and videos on modern websites. But the web is only one aspect. Web apps are likely going to take over a huge part of client development.
    - hajile 8y ago
      Runtime size depends on a few things. The biggest is JIT vs native. If you're willing to dedicate the time to making (or interfacing with) a completely native compiler, then the runtime penalty isn't that large. In contrast, any halfway decent JIT is going to be several MB of code (and unlike an image, has to be parsed and executed -- potentially on slow phones). In both cases, the GC issue is non-trivial. LLVM has finally started to make performant GCs possible. Wasm (to my knowledge) doesn't have similar capabilities and guarantees (I suspect the are actually impossible with untrusted GC code). The only viable solution IMO is the addition of GC primitives and hope that your particular language maps well on that specific browser's GC. https://medium.com/dartlang/dart-on-llvm-b82e83f99a70 https://medium.com/dartlang/dart-on-llvm-b82e83f99a70
  - pjmlp 8y ago
    That is just FUD. It is certainly possible to package a runtime way smaller that the analytics crap most people have to endure. Unity WebAssembly games are just a few hundred KB. Who cares about DOM, WebGL takes care of the UI part.
    - hajile 8y ago
      Consider python. With all the built-in libraries, it's many MB of code. If my app is 1-2mb, I'll be pushing the limits (I'll definitely be looking at multiple bundles to reduce and spread out the load parse time). If that goes up to 10-15mb (which can't be split), you're now going to have major usability issues. That's before all that analytic stuff that isn't going away. People do notice the difference and will just leave. Unity complex with basically zero runtime and uses webgl so it doesn't need to include that either (just the actual game itself). People use the Dom because it's standard, doesn't have to be downloaded every time, and offers tons of features. Nobody is going to write directly to webgl for a standard website (That's easily 9,999 out of 10,000 sites). That means you have to do something like drag Qt or GTK everywhere which takes even more time to download and parse. Your idea seems to be: download and parse a bloated runtime, download and parse a huge display library set, download and parse the misc shim pieces, and then download and parse your app. This is all done with the hope that your crud app that spends most of it's time doing nothing will be a fraction faster and you can write it in something that isn't JS. Not a great plan.

pjmlp 8y ago

> Web Assembly is not supposed to remove javascript, it is supposed to be used in addition to it when you need high performance. If people try to promote it as a way to not have to use javascript, it will just result in a more fragmented client-side programming situation, where libraries are not available for particular languages, etc. I guess you have been missing the news what is being done in Go, Java, .NET, Rust, Unity and everyone else regarding WebAssembly. We will have the revenge of plugins, like it or not. The only way out is if the browser vendors backtrack and remove WebAssembly support.

lol-lol 8y ago
Yep, exactly that will happen. There are lots of developers that stayed as backend engineers as they couldnt stand javascript (as a language and its integration with DOM), they stepped over the beginner phase with their development skills while javascript forced them to write BASIC (LOGO) level code. On the top of it, there were always some junior engineers that barely started to develop and were playing smart and bragging how cool the javascript is. There is a lot of rage stored in those circles and there are lots of excelent developers (I can tell you that 90% of top developers (not 25 years old kids, people that are able to write runtime compilers and OSes if given enought time) I know never wanted to work in javascript). Different reasons but I can tell you that most of them would say "I dont like java, but javascript is humiliating". Now the webasm is comming, I am preparing to bet that the frameworks will start to pop out in year or something after DOM is supported and they will overrun javascript in shortest possible time, just to prove the point - it sucks big time. QT is beeing prepared, all the "real" languages are starting to prepare to support compiling into webasm... the traditionally backend languages (that... you wouldnt believe... backend engineers know very well) are now having a chance to shine in browser that was restricted for them due to javascript monopoly. I wouldnt take the javascript future as really bright, in best case it will be used in same way as today shell scripts are (this is what they meant that webassembly is not replacement for javascript). To glue some parts of "system" (read as: browser) together. And quite frankly, this is step that should be done 10 years back. It would save world a lot of trouble. And have fun: https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGard...
hajile 8y ago
There's currently zero support for efficient garbage collectors and no Dom API access. Until a few more primitives are added, wasm is a pipe dream. Even once support exists, there's a payload issue. Nobody wants to spend loads of bandwidth downloading runtimes.
- cm2187 8y ago
  The runtime is probably still be a fraction of the bandwidth consumed by all the photos and videos on modern websites. But the web is only one aspect. Web apps are likely going to take over a huge part of client development.
  - hajile 8y ago
    Runtime size depends on a few things. The biggest is JIT vs native. If you're willing to dedicate the time to making (or interfacing with) a completely native compiler, then the runtime penalty isn't that large. In contrast, any halfway decent JIT is going to be several MB of code (and unlike an image, has to be parsed and executed -- potentially on slow phones). In both cases, the GC issue is non-trivial. LLVM has finally started to make performant GCs possible. Wasm (to my knowledge) doesn't have similar capabilities and guarantees (I suspect the are actually impossible with untrusted GC code). The only viable solution IMO is the addition of GC primitives and hope that your particular language maps well on that specific browser's GC. https://medium.com/dartlang/dart-on-llvm-b82e83f99a70 https://medium.com/dartlang/dart-on-llvm-b82e83f99a70
- pjmlp 8y ago
  That is just FUD. It is certainly possible to package a runtime way smaller that the analytics crap most people have to endure. Unity WebAssembly games are just a few hundred KB. Who cares about DOM, WebGL takes care of the UI part.
  - hajile 8y ago
    Consider python. With all the built-in libraries, it's many MB of code. If my app is 1-2mb, I'll be pushing the limits (I'll definitely be looking at multiple bundles to reduce and spread out the load parse time). If that goes up to 10-15mb (which can't be split), you're now going to have major usability issues. That's before all that analytic stuff that isn't going away. People do notice the difference and will just leave. Unity complex with basically zero runtime and uses webgl so it doesn't need to include that either (just the actual game itself). People use the Dom because it's standard, doesn't have to be downloaded every time, and offers tons of features. Nobody is going to write directly to webgl for a standard website (That's easily 9,999 out of 10,000 sites). That means you have to do something like drag Qt or GTK everywhere which takes even more time to download and parse. Your idea seems to be: download and parse a bloated runtime, download and parse a huge display library set, download and parse the misc shim pieces, and then download and parse your app. This is all done with the hope that your crud app that spends most of it's time doing nothing will be a fraction faster and you can write it in something that isn't JS. Not a great plan.