5 ms·

>At the end of the day, though, JavaScript is the language of the web. And when webassembly arrives that will be over, and Typescript will be deprecated. I can

• mixedCase 10y ago
  WA with a performant web API, you mean. First iteration of WA won't let you touch things like the DOM without jumping through JS-land.
• talmand 10y ago
  Yep, then we can focus on other language's flaws by implementing new features.
• Enginerd3 10y ago
  At the end of the day, JS will always be the language of the web. You're still going to be doing DOM manipulation through JS. WASM is really going to benefit people who want to do more heavy duty edge cases such as image processing.
  • weberc2 10y ago
    Is this because browsers won't expose DOM manipulation at the WASM level, or is there a different reason?
    • Enginerd3 10y ago
      DOM manipulation is going to be available at the WASM level in the future but it's going to be inefficient to do so just as it is inefficient to do image processing in JS right now. The only difference is that JS is the only viable option now if you want to do image processing on the web. WASM exists to solve this problem and complement JS. Hell, look at WASM's and JS's logo. They're two puzzle pieces that fit together.
      • Rusky 10y ago
        Your analogy doesn't sound right to me- there's nothing about wasm that would make it slow to manipulate the DOM, while there is plenty about Javascript that makes it slow to process images. Manipulating the DOM from wasm shouldn't be any slower than Javascript. Slow in general because of the DOM, perhaps, but not because of wasm.
• pimterry 10y ago
  >> At the end of the day, though, JavaScript is the language of the web. > And when webassembly arrives that will be over, I really don't think this is true. I certainly agree that JavaScript isn't the perfect language, but it's a _very_ popular language. Even on the server-side, where right now you already do have the freedom to use languages like Haskell, Python, etc, you see a majority of developers now opting for Node.js. Even for desktop apps and data scientists, it's the most popular contender (all according to the latest SO survey). You can argue about reasons all you like, but I don't think the people using JavaScript on the web are doing so only because webassembly isn't easily available yet. I think they're doing so because, for better or worse, they genuinely want to be using JavaScript (or very closely related languages like TypeScript).
• zengid 10y ago
  IMO I feel like it is going to be a challenge to integrate the GC of another language with the GC of the JavaScript/DOM, and if so we'll be keeping JavaScript going for a while.
  • weberc2 10y ago
    WebAssembly doesn't have a GC, And I don't see any reason why the DOM should be subject to a JS GC.
    • zengid 10y ago
      Correct, but python (or haskell or java or whatever) running on top of WASM would, and there are plans to integrate WASM with the other GC's in the browser, however: "'compile the VM' strategies increase the size of distributed code, lose browser devtools integration, can have cross-language cycle-collection problems and miss optimizations that require integration with the browser" [1]. My prev comment was speculative, but my point is that its not going to be a piece of cake to just drop another high-level language on-top of WASM and use it as a 'better' scripting language without having to pay some overhead costs, one being GC issues. [1] https://github.com/WebAssembly/design/blob/master/FAQ.md#is-webassembly-only-for-cc-programmers https://github.com/WebAssembly/design/blob/master/FAQ.md#is-...
      • weberc2 9y ago
        I don't know what is meant by "there are plans to integrate WASM with the other GC's in the browser". Is the idea that the browser runs a GC for DOM elements that is separate from the JS VM GC? I wonder if they could follow a model like operating system resources (e.g., file handles) where the process is responsible for managing the resource lifetimes. This would make resource management trivial, and running (for example) Python on WASM would simply mean emitting WASM instructions instead of x86. Of course, lots of other problems remain, for example, downloading an entire runtime or "putting Python on WASM isn't going to magically make it fast". But I don't think the GC should be a particularly large challenge.
• camus2 10y ago
  > webassembly. is basically a better way to do ASM.js . How many Python,Haskell,Livescript have been built on top of ASM.js ? Do you really believe you can make your users download 10s of megabytes of binaries each time they visit a website just to bootstrap a language? And i'm not even talking about the runtime... Right now, the only viable languages for webassembly are the ones that don't use garbage collection and have a limited runtime, Rust,C and C++ .
  • douche 10y ago
    We make our users download tens of megabytes of shitty unoptimized JS for tracking, ad networks, unoptimized images, autoplaying videos, and so on and so forth now.
    • Enginerd3 10y ago
      Those aren't necessary for the site to function so you can use some sort of content blocker and still access the material. You're talking about downloading megabytes of data just to go through the door for your website.
• untog 10y ago
  And I can't wait for the rude awakening anti-JS developers have when they realise the vast majority of issues (particularly, performance) come from the DOM, not JavaScript. (And the first version of WebAssembly can't touch the DOM anyway) If people start writing Python for the web for no other reason than they just dislike JavaScript we're going to be forcing users to download a dozen different runtimes, just because of developer preference. This isn't a good thing.
  • pryelluw 10y ago
    What would you replace the DOM with?
    • untog 10y ago
      I honestly have no idea. It does so much that I don't know where you'd start - but I suspect that's also the problem. I remember seeing a demo of React Canvas a few years ago - basically, recreating a "DOM" of sorts inside a canvas tag - and the performance was crazy. Beautiful 60fps touch interactions. But, of course, it only does a tiny subset of what the DOM does. I'm still waiting for a good reason to use it myself to try out how the API feels.
      • pryelluw 10y ago
        I feel the same. Dunno wth we gonna do but we need something more performant.
    • deleted 10y ago
      [deleted]
  • recursive 10y ago
    My complaints about JS have nothing to do with the DOM. Like weird `this`, no integer types, surprising type coercion rules, and so forth.
  • deleted 10y ago
    [deleted]
  • 10y ago
• mhd 10y ago
  We'll just have a Babel of dialects, pun intended. There might not be a technical reason for having JS, but there's a social one -- we've got plenty of people who call themselvs "JavaScript programmers", and people tend to be set in their ways to an awful degree. I mean, on the backend, there's no ultimate technical reason why you couldn't switch -- the closest you can come to the browser situation is the limited PHP hoster of the early oughts -- and still we don't see a rapid progress away from awful languages. Just more people duct taping said languages into something slightly more sane. We'll get the same for JS. It's the new Pascal/C in that regard.
• whatever_dude 10y ago
  > And when webassembly arrives that will be over, and Typescript will be deprecated. I can't wait for a better modern language like Haskell, Python, Livescript, etc.. built on top of webassembly. Much of that is already possible and guess what, neither TypeScript nor JavaScript are deprecated.
• coltonv 10y ago
  To run python on WebAssembly you would have to compile the entire CPython executable, and every single dependency it has, into WebAssembly, then ship that giant executable with every page so you could then run Python code with it. You would then also most likely need a special library, which at some point someone will have to write or you'll have to write it yourself, to give Python a clean interface to the DOM. All of this together would be at absolute minimum 4.5 megabytes, which is absolutely unacceptably large for a frontend bundle. WebAssembly is very cool techonology, but it's not going to deprecate Javascript because Javascript will be, at least for a very long time, the only scripting language that runs efficiently on the web, and also will always be the most well supported. With WebAssembly you could write in any AoT compilation language that can compile on LLVM, but I, and many many other developers, have no interest in very low level languages like C, C++, or Rust in the browser, even though we acknowledge the flaws in JS. Maybe one day higher level languages besides Javascript will be practical, but that's a ways away.
  • mi100hael 10y ago
    > To run python on WebAssembly you would have to compile the entire CPython executable, and every single dependency it has, into WebAssembly, then ship that giant executable with every page so you could then run Python code with it. I mean, that's kind of already the case when you want to ship a Python project as a stand-alone package to run on the desktop. Alternatively, I could see a method of installing runtimes into your browser like plugins so it doesn't have to be shipped over the wire every time. Not saying I'd ever want to do something like that, just that alternatives exist. Browsers are moving more and more towards VMs that transcend the context of a single synchronous request/response.
    • coltonv 10y ago
      I could see the plugin system working, but we're years away from that. So saying JS/TS will be deprecated soon is still pretty incorrect.
    • deleted 10y ago
      [deleted]
  • 10y ago
• xamuel 10y ago
  >better ... language ... Python ES5 was a dumpster-fire. But ES2015+ is an amazing language. You just have to take the time to systematically study it. If you're choosing a language you'll spend thousands of hours with, you shouldn't use "initial learning curve" as sole criteria.
  • uranian 10y ago
    Amazing? make an object: in ESx: var myObject= { a: { b: { c: { d: 'some value' } } } }; in Coffeescript or Livescript: myObject= a: b: c: d: 'some value' now use it: in ESx: console.log myObject.b.c.d // crash, myObject.b does not exist how to prevent? if ( myObject.hasOwnProperty('b') and myObject.b.hasOwnProperty('c') ){ console.log myObject.b.c.d // undefined } in Coffeescript or Livescript: console.log myObject.b?.c?.d // undefined I can write almost a book with too many of such examples. So, NO it's not an amazing language, I wrote for many years in it and it sucks all the way.
    • Macha 9y ago
      It's cheating a bit to indent the JS option only. I don't think: myObject= a: b: c: d: 'some value' Is really _that_ much of an improvement over: myObject = {a: { b: { c: { d: 'some value' } } } } especially combined with an editor that will match those closing brackets for you. And the reality is that if you have object literals that deep, chances are the inner values will also be large enough to justify expanding it anyway. Also lodash plugs a large number of holes in the standard functionality. In most projects I work at, I'd write something like: _.get(myObject, 'b.c.d') for your second example.
• ken47 10y ago
  Have you actually used Typescript? It's definitely better than Python, and I'd personally prefer it to Haskell / Livescript. I would love to hear what people actually think the "flaws" are with ES6 Javascript and Typescript, because they have been disappearing fast over the past two years. WebAssembly will be great, but as a complement to Typescript, not as a replacement. I would love to import a native module for the small chunk of my code that needs to do heavy lifting. And I don't see any reason why the Typescript team couldn't eventually build a WebAssembly compatibility layer.
• Rapzid 10y ago
  I'd take the experience of working with TypeScript over Python any day of the week. All the days really; every day.