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
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.
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.
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.
JavaScript is extremely poor at expressing OOP, it requires so much un-intuitive boilerplate to express your intent that many don't bother and will just hack together the simplest thing that works. Which causes the current situation of having so many different libraries to declare classes and they all do it their own unique way which are not compatible with each other.
It's the same for iteration, the hasOwnProperty is mostly omitted because it works most of the time without it and specifying it adds un-necessary boiler plate.
Same with async, there's a zillion async libraries that try to manage async in different ways and they aren't interchangable either. By standardizing on Futures/Streams it means all libraries can build on consistent and composable foundations and build higher-level functionality.
> 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.
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.
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.
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+).
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).
Isn't that the point of http://requirejs.org/ and the AMD API - 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.
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/ 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.
