8 ms·

Google SoundScript: faster OOP for JavaScript

68 points by jashkenas 12y ago

dracolytch 12y ago
So there have been a lot of contenders to replace JavaScript, and it hasn't budged from it's market seat at all. Here's why: You can do almost anything in JavaScript these days. The down side? You can do almost ~anything~ in JS these days. Including lots of stupid things. Since JS works extremely well for user interaction, and is "good enough" for simple object-oriented programs, it will likely never go away in the foreseeable future in these realms. What I think things like SoundScript are for, is 1) for people who are used to strongly-typed programming languages to feel more comfortable on the web (which is actually pretty important), and 2) for larger OO or enterprise-style systems that really shouldn't have been written in JS in the first place (I'm looking at you Angular). I wonder if it will end up like Go, though. An interesting language which never gets more than a niche market.
- estava 12y ago
  Google are trying to find a direction for web programming. The browsers have made plugins obsolete, but the plugins did bring something that the standard web technologies may have been missing. What is hard is to change JavaScript from the outside. They may have found that impossible to do. The direction started with asm.js shows that JavaScript needs to change from the inside. JavaScript can be changed and remain largely compatible, but it will not be without the drawbacks. The path started with transpiling and polyfills may help to keep some backward compatibility, for example. :-) Not all problems can be solved with just 1 technology. It will continue to look more like a mash-up. The challenge is to make it cross-platform. Google have to run ads on those things for it to help with the bottom line.
- smrtinsert 12y ago
  In my opinion Javascript is on its path to marginalization. Just glancing the recent tooling options for ClojureScript and TypeScript, I'm pretty sure now is the time to start putting your alt-js experience ahead of Javascript on the resume. The syntactical checks are great (typescript ides) or instant feedback (clojurescript figwheel) but for me the killer is the performance optimization over 'raw' Javascript due to compilation optimizations. Better tooling, better performance, why would I want to go back? The language of the future includes a Javascript compilation target.
  - htilford 12y ago
    The typing notation of TypeScript is on it's way to becoming part of Javascript. See http://www.2ality.com/2014/10/typed-javascript.html http://www.2ality.com/2014/10/typed-javascript.html Going forward does not mean abandoning Javascript, just abandoning ES5
    - Touche 12y ago
      I don't foresee type annotations being standardized any time soon. The resistance to that is going to be fierce.
      - discreteevent 12y ago
        Brendan Eich made the following comment here recently: " Indeed we had structural types in ES4 toward the end, and almost bluffed MS into folding (I'm told by a reliable source). But ES4 was trying for too much too soon. At this point we really need to see ES6/7 and TypeScript + Flow "gene- culture co-evolution". As I said at the last TC39 meeting on the topic, big de-facto standard wins trump rushed de-jure standards any day. /be" and also: " Type system implementors and the JS stewards must communicate well for this to win. It's looking good so far, on Ecma TC39: JQuery, Facebook, Netflix, PayPal (Ebay originally, and again), Twitter all represented along with Apple, Google, Microsoft, and Mozilla. Also academic researchers from various universities, all of whom love type systems and theory :-)." https://news.ycombinator.com/item?id=8906807 https://news.ycombinator.com/item?id=8906807
  - untog 12y ago
    Before you start talking about what to put on your resume, I'd look at what job descriptions are asking for. I haven't seen many asking for ClojureScript or TypeScript yet. TypeScript (and to a lesser extent CoffeeScript) seem fine to me, but ClojureScript looks very different to JS. I'd always advise someone to learn JS first, then your compiled language of choice.
    - smrtinsert 12y ago
- jerf 12y ago
  I'm not sure you read the article. "Soundscript" is just a fancy name for "notifying the Javascript interpreter that you promise never to do certain things, thus the interpreter can stop checking for them on every access and the optimizer is allowed to make stronger assumptions". It's not a new language so much as slightly different 100%-backwards-compatible dialect. It is a way of deliberately putting down some of the often-silly dynamism Javascript provides. Whether it takes off or not, I can't call it a "contender to replace Javascript" when it is Javascript.
  - fineline 12y ago
    100% Backwards compatible? So this will work in IE6? Or 7, or 8, or 9, or 10? I think you meant 100% backwards compatible with ES6. As far as that goes, it sounds like a pretty good addition to the ES6 standard.
deleted 12y ago
[deleted]
adrianlmm 12y ago
I thing this is a testament that strong typed is more desired than dynamic.
greggman 12y ago
This makes sad, as Douglas Crockford said in this recent talk > The prototypal school has a lot of advantages particularly compared to the classical school > So in the classical school you have to create a classification of all the objects that are likely to be in your system. And, it's a lot of work to figure out what they all are and identify them and what their characteristics are and so on and then you have to determine how they are all related to each other, what’s going to inherit from what, what’s going to implement what, what’s going to interface with what, and that’s really complicated. And it usually happens at the beginning of the project before you fully understand what all this stuff means. So it’s likely your going to get the taxonomy wrong. It’s inevitable. > And then you’ve got two hard choices. One is you have to live with a broken taxonomy and if you do that then with each new class you introduce things get weirder and weirder because everything’s wrong, or you have to refactor and refactoring is hard and it’s error prone and it’s another world of hurt. > Those are your two choices and people who grew up in the classical school assume that’s just the way life is so no sense in complaining about it since that’s life. > But in the prototypal school you don’t do any of that. You just make an object, if you don’t like the way it works you make another one and that is literally it. > So you can tell people from the classical school “You don’t have to do all of that” and they go “Yea, I hear ya, but you still have to do it” and you say “no, you don’t have to do it” and they go “yea, yea, yea” (blowing you off) > And so that’s why I think classes in ES6 are a bad part because they lock you into that paradigm. > applause > So when you’re locked in a paradigm like that, when you can’t see past it, you just have no understanding how miserable you are. And you’ll never know until you change your model from https://www.youtube.com/watch?v=bo36MrBfTk4#t=28m50s https://www.youtube.com/watch?v=bo36MrBfTk4#t=28m50s
- jashkenas 12y ago
  I don't mean to be argumentative (being argumentative on HN is so passé), but what you just quoted is so full of shit that I feel like someone is obligated to comment. In the prototypal model — as it exists in JavaScript — you do do all of that. You make a series of prototypes that you intend to use in your application, and those prototypes (or classes), serve as the effective taxonomy for many of the objects you're making in your app. Classes in ES6 are prototypes. They don't lock you into any such Java-esque paradigm unless you're going to be willfully ignorant about them. Please don't repeat baloney just because Crockford said it. --- For example, to be concrete: class Crockford { speechify() { return "...you're going to get the taxonomy wrong. It’s inevitable."; } } A class. A terrible, inflexible, prototype-destroying, paradigm-locking-in, JavaScript class. Eww, gross. But wait! What's this? Crockford.prototype.speechify = function() { return "...the shape of an object can change at any instant, because \ someone can fiddle with the prototype."; }; You can have your classical cake and eat prototypal cookies too. Because in any decent dynamic language, the two concepts are synonymous.
cromwellian 12y ago
I see the 'stricter' mode (without types) as a kind of asm.js assertion. The code is 100% legal JS and will work on all JS VMs, you're just telling the VM that it can assume you won't modify class prototypes after load. The VM can check this assertion and fail if you violate it, and then run at fulls peed. On other VMs that ignore "use 'stricter'" the same code runs, just less optimized by the VM. The stricter+types stuff will be harder to swallow by the community since it extends the language grammar. That will break other VMs without transpilation. Maybe they could do a "use 'stricter+asm'" which has the class-sealing properties SoundScript, but with the type-declaration syntax of asm.js (|0, 0, etc)
- azakai 12y ago
  I'm still unclear on the relevant details, though. If this is just a hint - no semantic effect - then JS engines already speculate and assume you won't modify class prototypes after load. Such speculation is what JS engines put a lot of work into. Maybe the hint would justify more aggressive speculation, I suppose? Or, if this is more than a hint - if it has semantic effects, like "use strict" does - then this would be very different than "use asm". I guess when more info comes out this will become clearer.
  - cromwellian 12y ago
    I'm guessing that it implicitly implies Object.seal() on all prototypes. Any legal program that uses 'stricter' and depends on sealed prototypes would be a legal program on a VM that ignores stricter, except in the case of bugs where code was modifying prototypes when it shouldn't, but those would presumably be caught during testing on VMs which did use it. Presumably, "use stricter" on a codebase that contained attempted prototype modifications would generate errors instead of silent failures. I don't know the full reasoning behind this, but it might be more about startup time than runtime speed. If you assume early-bound classes, snapshotting becomes a lot easier, you can ahead-of-time trivially compile hidden classes without having to discover them after the fact, and without having to put in code to revert the assumptions later. Seems like this would be a startup and memory win mobile web, especially if you can easily snapshot a previously loaded app.
- 12y ago
misfo 12y ago
Could this be (partially) motivated by making Dart-compiled JS run faster in Chrome?
chipsy 12y ago
If I had to place a bet now, it would be on asm.js. It's the abstraction that nobody wants but everyone can live with, because it takes the standards bodies out of the equation on the higher level decisions that have to be done differently per domain.
tracker1 12y ago
IMHO for the most part, programming with classes in JS is just waiting for pain. If you use generic objects for state, then compose your applications by using generic functions passing in state, and any other arguments that function needs to operate, it goes much smoother than OOP. You can create wrappers by binding independent methods against said state for composite objects with encapsulation... It tends to keep code cleaner and more modular. Sometimes just thinking about the problem differently will lead to a more elegant solution... var Promise = require('i-promise') ,getDealerPendingStream = require('./process-get-dealer-pending-stream') ,transformDealerPending = require('./process-transform-dealer-pending-stream') ,calculatePayment = require('./process-payment-calculation') ,logTransaction = require('./process-log-transaction') ,updateSalesforce = require('./process-update-salesforce') ,runPayment = require('./process-payment') ,logItemOutput = require('./process-log-item-output') ; module.exports = function(){ return new Promise(function(resolve, reject) { getDealerPendingStream() .pipe(transformDealerPending()) .pipe(calculatePayment()) .pipe(runPayment()) .pipe(logTransaction()) .pipe(updateSalesforce()) .pipe(logItemOutput()) //email notifications for processing errors (dataObject.error) .on('error', reject) //should never happen .on('end', resolve) .resume() // needed so last stream can process data ; }); }
- aikah 12y ago
  How would you write a GUI framework with this method? because that's where OOP shines.Here,you're just doing sequential operations on a chunk of data.How would you write layouts and widgets? people often forget that OOP was kind of created because it solves the UI problem.
  - masklinn 12y ago
    Same way Elm does?
  - tracker1 12y ago
    You can still uses events and state against UI constructs without going full-on OOP. An application can render in similar ways to how flux, mercury, elm and other patterns are handled. (not suggesting a virtual DOM... but there's more to an application than the UI alone, and there are more functional ways to apply state and eventing to a UI. uicontrol.on('eventName', handleSomeEvent.bind(null, state, uicontrol)); In this case, you still have a uicontrol, that raises events, and can use that to trigger a generic handler pre-bound against a given state. You can remove this farther by having the handleSomeEvent being a method that is already part of a state machine that is bound against an instance of said state. If you follow 1-way dataflows (like flux) you can break some of the other constructs down... just the same, the above example is not OOP, but can still use UI events, and be composable.

68 points by jashkenas 12y ago

So there have been a lot of contenders to replace JavaScript, and it hasn't budged from it's market seat at all. Here's why: You can do almost anything in JavaScript these days. The down side? You can do almost ~anything~ in JS these days. Including lots of stupid things. Since JS works extremely well for user interaction, and is "good enough" for simple object-oriented programs, it will likely never go away in the foreseeable future in these realms. What I think things like SoundScript are for, is 1) for people who are used to strongly-typed programming languages to feel more comfortable on the web (which is actually pretty important), and 2) for larger OO or enterprise-style systems that really shouldn't have been written in JS in the first place (I'm looking at you Angular). I wonder if it will end up like Go, though. An interesting language which never gets more than a niche market.

estava 12y ago
Google are trying to find a direction for web programming. The browsers have made plugins obsolete, but the plugins did bring something that the standard web technologies may have been missing. What is hard is to change JavaScript from the outside. They may have found that impossible to do. The direction started with asm.js shows that JavaScript needs to change from the inside. JavaScript can be changed and remain largely compatible, but it will not be without the drawbacks. The path started with transpiling and polyfills may help to keep some backward compatibility, for example. :-) Not all problems can be solved with just 1 technology. It will continue to look more like a mash-up. The challenge is to make it cross-platform. Google have to run ads on those things for it to help with the bottom line.
smrtinsert 12y ago
In my opinion Javascript is on its path to marginalization. Just glancing the recent tooling options for ClojureScript and TypeScript, I'm pretty sure now is the time to start putting your alt-js experience ahead of Javascript on the resume. The syntactical checks are great (typescript ides) or instant feedback (clojurescript figwheel) but for me the killer is the performance optimization over 'raw' Javascript due to compilation optimizations. Better tooling, better performance, why would I want to go back? The language of the future includes a Javascript compilation target.
- htilford 12y ago
  The typing notation of TypeScript is on it's way to becoming part of Javascript. See http://www.2ality.com/2014/10/typed-javascript.html http://www.2ality.com/2014/10/typed-javascript.html Going forward does not mean abandoning Javascript, just abandoning ES5
  - Touche 12y ago
    I don't foresee type annotations being standardized any time soon. The resistance to that is going to be fierce.
    - discreteevent 12y ago
      Brendan Eich made the following comment here recently: " Indeed we had structural types in ES4 toward the end, and almost bluffed MS into folding (I'm told by a reliable source). But ES4 was trying for too much too soon. At this point we really need to see ES6/7 and TypeScript + Flow "gene- culture co-evolution". As I said at the last TC39 meeting on the topic, big de-facto standard wins trump rushed de-jure standards any day. /be" and also: " Type system implementors and the JS stewards must communicate well for this to win. It's looking good so far, on Ecma TC39: JQuery, Facebook, Netflix, PayPal (Ebay originally, and again), Twitter all represented along with Apple, Google, Microsoft, and Mozilla. Also academic researchers from various universities, all of whom love type systems and theory :-)." https://news.ycombinator.com/item?id=8906807 https://news.ycombinator.com/item?id=8906807
- untog 12y ago
  Before you start talking about what to put on your resume, I'd look at what job descriptions are asking for. I haven't seen many asking for ClojureScript or TypeScript yet. TypeScript (and to a lesser extent CoffeeScript) seem fine to me, but ClojureScript looks very different to JS. I'd always advise someone to learn JS first, then your compiled language of choice.
  - smrtinsert 12y ago
jerf 12y ago
I'm not sure you read the article. "Soundscript" is just a fancy name for "notifying the Javascript interpreter that you promise never to do certain things, thus the interpreter can stop checking for them on every access and the optimizer is allowed to make stronger assumptions". It's not a new language so much as slightly different 100%-backwards-compatible dialect. It is a way of deliberately putting down some of the often-silly dynamism Javascript provides. Whether it takes off or not, I can't call it a "contender to replace Javascript" when it is Javascript.
- fineline 12y ago
  100% Backwards compatible? So this will work in IE6? Or 7, or 8, or 9, or 10? I think you meant 100% backwards compatible with ES6. As far as that goes, it sounds like a pretty good addition to the ES6 standard.

deleted 12y ago

[deleted]

adrianlmm 12y ago

I thing this is a testament that strong typed is more desired than dynamic.

greggman 12y ago

This makes sad, as Douglas Crockford said in this recent talk > The prototypal school has a lot of advantages particularly compared to the classical school > So in the classical school you have to create a classification of all the objects that are likely to be in your system. And, it's a lot of work to figure out what they all are and identify them and what their characteristics are and so on and then you have to determine how they are all related to each other, what’s going to inherit from what, what’s going to implement what, what’s going to interface with what, and that’s really complicated. And it usually happens at the beginning of the project before you fully understand what all this stuff means. So it’s likely your going to get the taxonomy wrong. It’s inevitable. > And then you’ve got two hard choices. One is you have to live with a broken taxonomy and if you do that then with each new class you introduce things get weirder and weirder because everything’s wrong, or you have to refactor and refactoring is hard and it’s error prone and it’s another world of hurt. > Those are your two choices and people who grew up in the classical school assume that’s just the way life is so no sense in complaining about it since that’s life. > But in the prototypal school you don’t do any of that. You just make an object, if you don’t like the way it works you make another one and that is literally it. > So you can tell people from the classical school “You don’t have to do all of that” and they go “Yea, I hear ya, but you still have to do it” and you say “no, you don’t have to do it” and they go “yea, yea, yea” (blowing you off) > And so that’s why I think classes in ES6 are a bad part because they lock you into that paradigm. > applause > So when you’re locked in a paradigm like that, when you can’t see past it, you just have no understanding how miserable you are. And you’ll never know until you change your model from https://www.youtube.com/watch?v=bo36MrBfTk4#t=28m50s https://www.youtube.com/watch?v=bo36MrBfTk4#t=28m50s

jashkenas 12y ago
I don't mean to be argumentative (being argumentative on HN is so passé), but what you just quoted is so full of shit that I feel like someone is obligated to comment. In the prototypal model — as it exists in JavaScript — you do do all of that. You make a series of prototypes that you intend to use in your application, and those prototypes (or classes), serve as the effective taxonomy for many of the objects you're making in your app. Classes in ES6 are prototypes. They don't lock you into any such Java-esque paradigm unless you're going to be willfully ignorant about them. Please don't repeat baloney just because Crockford said it. --- For example, to be concrete: class Crockford { speechify() { return "...you're going to get the taxonomy wrong. It’s inevitable."; } } A class. A terrible, inflexible, prototype-destroying, paradigm-locking-in, JavaScript class. Eww, gross. But wait! What's this? Crockford.prototype.speechify = function() { return "...the shape of an object can change at any instant, because \ someone can fiddle with the prototype."; }; You can have your classical cake and eat prototypal cookies too. Because in any decent dynamic language, the two concepts are synonymous.

cromwellian 12y ago

I see the 'stricter' mode (without types) as a kind of asm.js assertion. The code is 100% legal JS and will work on all JS VMs, you're just telling the VM that it can assume you won't modify class prototypes after load. The VM can check this assertion and fail if you violate it, and then run at fulls peed. On other VMs that ignore "use 'stricter'" the same code runs, just less optimized by the VM. The stricter+types stuff will be harder to swallow by the community since it extends the language grammar. That will break other VMs without transpilation. Maybe they could do a "use 'stricter+asm'" which has the class-sealing properties SoundScript, but with the type-declaration syntax of asm.js (|0, 0, etc)

azakai 12y ago
I'm still unclear on the relevant details, though. If this is just a hint - no semantic effect - then JS engines already speculate and assume you won't modify class prototypes after load. Such speculation is what JS engines put a lot of work into. Maybe the hint would justify more aggressive speculation, I suppose? Or, if this is more than a hint - if it has semantic effects, like "use strict" does - then this would be very different than "use asm". I guess when more info comes out this will become clearer.
- cromwellian 12y ago
  I'm guessing that it implicitly implies Object.seal() on all prototypes. Any legal program that uses 'stricter' and depends on sealed prototypes would be a legal program on a VM that ignores stricter, except in the case of bugs where code was modifying prototypes when it shouldn't, but those would presumably be caught during testing on VMs which did use it. Presumably, "use stricter" on a codebase that contained attempted prototype modifications would generate errors instead of silent failures. I don't know the full reasoning behind this, but it might be more about startup time than runtime speed. If you assume early-bound classes, snapshotting becomes a lot easier, you can ahead-of-time trivially compile hidden classes without having to discover them after the fact, and without having to put in code to revert the assumptions later. Seems like this would be a startup and memory win mobile web, especially if you can easily snapshot a previously loaded app.
12y ago

misfo 12y ago

Could this be (partially) motivated by making Dart-compiled JS run faster in Chrome?

chipsy 12y ago

If I had to place a bet now, it would be on asm.js. It's the abstraction that nobody wants but everyone can live with, because it takes the standards bodies out of the equation on the higher level decisions that have to be done differently per domain.

tracker1 12y ago

IMHO for the most part, programming with classes in JS is just waiting for pain. If you use generic objects for state, then compose your applications by using generic functions passing in state, and any other arguments that function needs to operate, it goes much smoother than OOP. You can create wrappers by binding independent methods against said state for composite objects with encapsulation... It tends to keep code cleaner and more modular. Sometimes just thinking about the problem differently will lead to a more elegant solution... var Promise = require('i-promise') ,getDealerPendingStream = require('./process-get-dealer-pending-stream') ,transformDealerPending = require('./process-transform-dealer-pending-stream') ,calculatePayment = require('./process-payment-calculation') ,logTransaction = require('./process-log-transaction') ,updateSalesforce = require('./process-update-salesforce') ,runPayment = require('./process-payment') ,logItemOutput = require('./process-log-item-output') ; module.exports = function(){ return new Promise(function(resolve, reject) { getDealerPendingStream() .pipe(transformDealerPending()) .pipe(calculatePayment()) .pipe(runPayment()) .pipe(logTransaction()) .pipe(updateSalesforce()) .pipe(logItemOutput()) //email notifications for processing errors (dataObject.error) .on('error', reject) //should never happen .on('end', resolve) .resume() // needed so last stream can process data ; }); }

aikah 12y ago
How would you write a GUI framework with this method? because that's where OOP shines.Here,you're just doing sequential operations on a chunk of data.How would you write layouts and widgets? people often forget that OOP was kind of created because it solves the UI problem.
- masklinn 12y ago
  Same way Elm does?
- tracker1 12y ago
  You can still uses events and state against UI constructs without going full-on OOP. An application can render in similar ways to how flux, mercury, elm and other patterns are handled. (not suggesting a virtual DOM... but there's more to an application than the UI alone, and there are more functional ways to apply state and eventing to a UI. uicontrol.on('eventName', handleSomeEvent.bind(null, state, uicontrol)); In this case, you still have a uicontrol, that raises events, and can use that to trigger a generic handler pre-bound against a given state. You can remove this farther by having the handleSomeEvent being a method that is already part of a state machine that is bound against an instance of said state. If you follow 1-way dataflows (like flux) you can break some of the other constructs down... just the same, the above example is not OOP, but can still use UI events, and be composable.