4 ms·

Why go through so much pain to avoid JavaScript, coffeescript now Dart? JavaScript is not the problem, it's how terrible our community is at sharing/creating mo

Why go through so much pain to avoid JavaScript, coffeescript now Dart? JavaScript is not the problem, it's how terrible our community is at sharing/creating modular things. Classes and shitty syntax wont help you there

munificent 14y ago
> JavaScript is not the problem, it's how terrible our community is at sharing/creating modular things. Classes and shitty syntax wont help you there How would you switch communities without switching languages? As far as I can tell, it's actually much easier to switch tech than it is to convince a million existing users to change their culture to something different.
- tjholowaychuk 14y ago
  Not really just stop using/promoting bad design like jQuery plugins, eventually people catch on.
  - michaelwww 14y ago
    I'd like to know how they prevent plugins from colliding and polluting the $ namespace.
    - tjholowaychuk 14y ago
      We shouldn't use a $ namespace haha, that's a big part of the problem, which has nothing to do with JavaScript. jQuery was and always will be poor design. It's a great project and has obviously helped a lot of people but it makes no sense.
michaelwww 14y ago
I think you're wrong. JavaScript has a great community with tons of talent. JavaScript is the problem. You don't see nearly the same level of problems in the Python community for example.
- _jmar777 14y ago
  The problem here is browsers, not JavaScript. Python has evolved much since the '90s, just like JavaScript has. The problem unique to JavaScript is browsers, and end users running browser versions with a decade span in between them. This is also why the "IE9+" requirement is so relevant to this conversation, because developing with that luxury is entirely different than developing for IE7+ (or, for some poor souls still out there, IE6+).
oinksoft 14y ago
You touch on a good point, but I'm not sure it has to do with this particular piece. Rather, the author seems really confused: There are great projects like Underscore, Sugar, Prototype, jQuery, CoffeeScript and many many more that help to work around JavaScript’s language quirks. Unfortunately they don’t mix and match very well. Also, which map() or forEach() implementation should I use if I have multiple available? That's like comparing barricuda, rubberbands, and bolts. Only one of the projects he mentions has anything to do with "JavaScript’s language quirks," and that's CoffeeScript. Just another person who did not know JavaScript/frontend development, expected it to be like any other programming environment, and bailed rather than stepping back and reconsidering his original assumptions.
- tosh 14y ago
  I understand what you're saying but I'm humbly disagreeing. I do believe that all the mentioned frameworks (while positioned differently) do offer solutions to work with/around JavaScript language quirks. e.g. simple things like * working with collections * working with objects * extending 'things' * iterating over 'things' * working with async That's one of the main things that I (and probably more) people find confusing about the JavaScript ecosystem even while I'm not new to it.
  - oinksoft 14y ago
    JavaScript provides arrays and objects, and also functions for grouping data (via closures). What else would you expect it to come with? The quality `goog.structs` package speaks to how easy it is to create very high-level data structures. Are you perhaps thinking of the baroque and once-very-inconsistently-implemented DOM API? Regarding your other points, JS is an extremely object-oriented language. I really don't think you need more "working with obejcts" things out-of-the-box. Iteration is very straightforward in all cases, unless you find hasOwnProperty confusing. The Node.js project has demonstrated well how easily Async maps to JS outside of the browser model (where Async has always reigned). JS is a strange beast in certain ways, but it is a featureful language.
    - 14y ago
tosh 14y ago
Hey TJ, thanks for your work on component.io, Stylus (we use Stylus) and in the node community. I applaud every effort to improve the JavaScript ecosystem. I feel that Dart having a solid foundation make it hard to bike-shed over simple things that just should work out of the box. This is where I see Dart helps, where CoffeeScript didn't (because it was not its design goal).
basch 14y ago
Isn't that the point of http://requirejs.org/ http://requirejs.org/ and the AMD API - http://requirejs.org/docs/whyamd.html http://requirejs.org/docs/whyamd.html ? Why is there not more of a push for frameworks and libraries to be AMD compatible? The Dojo Toolkit is, and thus lets you load just what you need.
- munificent 14y ago
  Don't forget npm, and bower, and jam, and component, and ender, and volo, and... Really, it's only a matter of time before someone creates a JavaScript package manager manager so you can manage your package managers.
  - basch 14y ago
    i think of it more as systemd than apt. calling it a package manager isn't all that accurate. Scroll down to the "Module Loaders" section at http://todomvc.com/ http://todomvc.com/ I don't see any of the products listed you mentioned. Notice that require.js works with Backbone.js, Ember.js, Knockout, AngularJS, Ember.js, Knockout, AngularJS, CanJS. TroopJS uses require.js. The only major competition it has is Thorax + Lumbar or Twitter's Flight. http://requirejs.org/docs/whyamd.html#amdtoday http://requirejs.org/docs/whyamd.html#amdtoday jQuery 1.7, Dojo 1.7, EmbedJS, Ender-associated modules like bonzo, qwery, bean and domready, Firebug 1.8+, and the BBC all use it or work with it.

munificent 14y ago

> JavaScript is not the problem, it's how terrible our community is at sharing/creating modular things. Classes and shitty syntax wont help you there How would you switch communities without switching languages? As far as I can tell, it's actually much easier to switch tech than it is to convince a million existing users to change their culture to something different.

tjholowaychuk 14y ago
Not really just stop using/promoting bad design like jQuery plugins, eventually people catch on.
- michaelwww 14y ago
  I'd like to know how they prevent plugins from colliding and polluting the $ namespace.
  - tjholowaychuk 14y ago
    We shouldn't use a $ namespace haha, that's a big part of the problem, which has nothing to do with JavaScript. jQuery was and always will be poor design. It's a great project and has obviously helped a lot of people but it makes no sense.

michaelwww 14y ago

I think you're wrong. JavaScript has a great community with tons of talent. JavaScript is the problem. You don't see nearly the same level of problems in the Python community for example.

_jmar777 14y ago
The problem here is browsers, not JavaScript. Python has evolved much since the '90s, just like JavaScript has. The problem unique to JavaScript is browsers, and end users running browser versions with a decade span in between them. This is also why the "IE9+" requirement is so relevant to this conversation, because developing with that luxury is entirely different than developing for IE7+ (or, for some poor souls still out there, IE6+).

oinksoft 14y ago

You touch on a good point, but I'm not sure it has to do with this particular piece. Rather, the author seems really confused: There are great projects like Underscore, Sugar, Prototype, jQuery, CoffeeScript and many many more that help to work around JavaScript’s language quirks. Unfortunately they don’t mix and match very well. Also, which map() or forEach() implementation should I use if I have multiple available? That's like comparing barricuda, rubberbands, and bolts. Only one of the projects he mentions has anything to do with "JavaScript’s language quirks," and that's CoffeeScript. Just another person who did not know JavaScript/frontend development, expected it to be like any other programming environment, and bailed rather than stepping back and reconsidering his original assumptions.

tosh 14y ago
I understand what you're saying but I'm humbly disagreeing. I do believe that all the mentioned frameworks (while positioned differently) do offer solutions to work with/around JavaScript language quirks. e.g. simple things like * working with collections * working with objects * extending 'things' * iterating over 'things' * working with async That's one of the main things that I (and probably more) people find confusing about the JavaScript ecosystem even while I'm not new to it.
- oinksoft 14y ago
  JavaScript provides arrays and objects, and also functions for grouping data (via closures). What else would you expect it to come with? The quality `goog.structs` package speaks to how easy it is to create very high-level data structures. Are you perhaps thinking of the baroque and once-very-inconsistently-implemented DOM API? Regarding your other points, JS is an extremely object-oriented language. I really don't think you need more "working with obejcts" things out-of-the-box. Iteration is very straightforward in all cases, unless you find hasOwnProperty confusing. The Node.js project has demonstrated well how easily Async maps to JS outside of the browser model (where Async has always reigned). JS is a strange beast in certain ways, but it is a featureful language.
  - 14y ago

tosh 14y ago

Hey TJ, thanks for your work on component.io, Stylus (we use Stylus) and in the node community. I applaud every effort to improve the JavaScript ecosystem. I feel that Dart having a solid foundation make it hard to bike-shed over simple things that just should work out of the box. This is where I see Dart helps, where CoffeeScript didn't (because it was not its design goal).

basch 14y ago

Isn't that the point of http://requirejs.org/ http://requirejs.org/ and the AMD API - http://requirejs.org/docs/whyamd.html http://requirejs.org/docs/whyamd.html ? Why is there not more of a push for frameworks and libraries to be AMD compatible? The Dojo Toolkit is, and thus lets you load just what you need.

munificent 14y ago
Don't forget npm, and bower, and jam, and component, and ender, and volo, and... Really, it's only a matter of time before someone creates a JavaScript package manager manager so you can manage your package managers.
- basch 14y ago
  i think of it more as systemd than apt. calling it a package manager isn't all that accurate. Scroll down to the "Module Loaders" section at http://todomvc.com/ http://todomvc.com/ I don't see any of the products listed you mentioned. Notice that require.js works with Backbone.js, Ember.js, Knockout, AngularJS, Ember.js, Knockout, AngularJS, CanJS. TroopJS uses require.js. The only major competition it has is Thorax + Lumbar or Twitter's Flight. http://requirejs.org/docs/whyamd.html#amdtoday http://requirejs.org/docs/whyamd.html#amdtoday jQuery 1.7, Dojo 1.7, EmbedJS, Ender-associated modules like bonzo, qwery, bean and domready, Firebug 1.8+, and the BBC all use it or work with it.