We can’t front-load complexity and let people sort it out. That way lies madness. We must distill the rules down so that people can be effective, and help them along their journey towards JavaScript mastery. It’s a learning curve, not a learning cliff.
;
I’ve participated in the love themed 4th edition of js1k. My submission is a static image, a procedurally generated 3d rose. You can take a look of it here.
It is made by Monte Carlo sampling of explicit piecewise 3d surfaces. I’m going to try to explain all a bit in this article.
Excellent tutorial. Yes, it gets technical.
Dynamic analysis is a great complement to static analysis: unfortunately, it is not a replacement. An ActionScript program that has been optimized to death by an AOT compiler can, almost trivially, beat a JavaScript program that is optimized on the fly by the JIT compiler. The only way out would be to let the JIT compiler work till death, but that is not an option! Checkmate.
So yes, you will hear about all the great things in V8 (JavaScript VM), including type inference. The fact is, there is no way a JIT compiler can afford to do the kind of modular analysis that an algorithm implemented in an AOT compiler can.
Regardless how arrogant it sounds, it's true. Numbers do follow in the article.
Now is the time to do the same thing for classes. From a language extension point of view, classes have much less impact on the language than modules. Yet, they have a huge impact on code compatibility and language adoption, by lowering the barrier to entry for “non-native” JavaScript programmers.
Classes in JavaScript, the subject of most heated debates in the community, is back. People behind Cloud9 are considering adding support for it in the their IDE.
initial = extractVariables(req.body);
The article should be titled “How Not Using jslint Ruined our Launch”.
Classes will give us a humane, interoperable inheritance syntax, but it leaves composition unaddressed by syntax. I’m hopeful that we bless traits in future versions, removing the use of inheritance in most cases. Similarly, I think we can find a way to repair “this” binding foot-guns with softly-bound “this”. Repairing the shared-prototypes issue, either through DOM or through something like Scoped Object Extensions, can and should be done. And once we have all of this, the stage will be set for a flexible, advanced type system that does not need to be all-or nothing and does not need to be hobbled by the ghost of C++/Java’s inflexible nominal-only types. That’s the dream, and we’re not shying away from it.
Alex Russel's ideas are at least controversial (Dojo comes to mind), but he is for sure influential and it's interesting to see what he thinks about the direction JavaScript should take in the future.
Pointers are a powerful part of C, and they're so simple that it's not too hard to replicate them in other (powerful) languages. I made a pointer system not unlike C's in just a few lines of javascript.
Pointer implementation in JavaScript. Reminds me of an interview I did 2 years ago when an interviewee said that “pointer operations are difficult in JavaScript”. Maybe he wasn't a loon, after all?
If you take The Guardian as an example, the current average visitors per day is around 2,200,000. 1.3% of that is 28,600 users browsing without Javascript. Per day.
While I had always believed in progressive enhancement and the need to ensure that my sites work without JavaScript, this article almost convinced me to change my mind, by using weak argumentation.
While it still makes sense for content websites, providing a non-JavaScript and usable fallback for modern web apps is really a significant effort. For what benefit? Support for 1.3% users (I hope that this number excludes bots). With such a small number it really becomes a business decision: is it worth spending extra money (usually much more than 1.3% of the cost of development) to support that group?
Ability to link to a page and letting crawlers in are worth extra effort, though. But optimization of user experience for 1.3% of users who disable JS, sometimes for misguided reasons? Show me the money from that investment first.
We’ve already seen what this means for JavaScript as a language: it was years after JavaScript’s debut before we really started seeing conversations about what a module should look like in JavaScript, and we’re still fighting over it today. Without a solid dependency management system — something you can take for granted in any 15-year-old community-driven language — dependency management often means sticking another script tag on the page, and even the most popular JavaScript library on the planet struggles with how to participate in a fledgling ecosystem. With no arbiter of common, tested, community-approved, community-vetted solutions — see Perl’s CPAN — it’s an environment that’s ripe for fragmentation, and shining examples of Not Invented Here (NIH) litter the JavaScript landscape. Lacking even an agreed-upon method of expressing dependencies, the findability of good solutions is low, and coalescence only occurs around tools with extremely low barriers to entry and extremely high near-term reward.
Thoughtful post on the current state of JavaScript and the future it should be heading to.
In February the second stable release, v0.4, will be made. This includes improved memory usage and a new SSL/TLS system, a built-in debugger, faster timers, many wart removals, and the new version of V8. Hopefully in the next 6 months we’ll release a 1.0 version of Node. The idea is to constrain what goes into “core” and not allow it to grow too big – so there will not be endless stream of feature additions. 1.0 will look pretty much like Node does now. There are a lot of bugs to fix still.
For node.js fanboys. Yours truly is just becoming one.
