Maybe they need to come up with some kind of "use sanity" mode to build on the existing "use strict",
That's the idea. You'll be able to set "application/ecmascript-6" or something similar to the type attribute of the script tag.
I think in the context of a discussion related to a (not even published) new language that aims to fix front-end development, the future of JavaScript is more relevant than its present.
Global-by-default-unless-declared for variables is a recipe of disaster.
ES5 strict mode already disallows that.
If I declare a "var" inside a pair of curly braces, it should only be visible in those curly braces
The "let" keyword will fix that. It has block scope. Eventually all variables should be declared with "let".
Syntax for lambdas is overly verbose
There is still no agreement in the ECMAScript comitee about which option to take, but there are two very good proposals:
- Arrow function syntax taken from CoffeeScript: (x) -> x * x;
- Block lambdas, which allow you to treat chunks of code as data
Personally, I love arrow functions.
"new Boolean(false)" is considered true in a conditional expression..
I never heard of that particular example and trying "true == new Boolean(false)" always evaluates to false in a console. But yes, the == type coercing operand is the worst part of JavaScript. The === operator solves 99% of cases. For the 1% that it doesn't help with, ECMAScript 6 will have an "is" operator, and before that probably an Object.is() function.
While we're at it, what's up with the whole separation into primitives and objects?
I agree with you, everything should've been an object from the start. That's probably because of the Java legacy.
Maybe the question should be how to promote policies that prevent software engineers from going to the evil dictator side.
I can't believe I found out first on Slashdot.
I'd like to thank my very smart representatives, courts, lawyers and public prosecutors who made this happen. Apparently Google will be investing in solving the situation, otherwise those of us technologically not challenged will be doing what we can.
The functionality is awesome. But the API is too Java-like. Someone make it more JavaScript friendly please!
This week the online community managed to get the attention of the lawmakers in Argentina and paused the approval of a law that would instate a private copy levy on MP3 players, CDs, DVDs and even hard drives. This law would be similar to the ones already in place in Europe and that are being contested by the Court of Justice of the European Union.
Those of us who got informed in time were able to watch the session of the Congress during which the proposed law was presented and different groups that represent copyright holders (record labels, filmmaking producers, etc) expressed their views about it. Many representatives of these groups were over 70 years old. By repeating phrases such as "artists have a right to make a living" they were continuously showing that they have no grasp of the current market. It was clear that most of them were there to be shown in camera and to be certain that their groups got included as recipients for the levy. There were no dissident voices, not one member of Congress or representative of technology groups that expressed arguments against the approval of the law. In fact, the only congressmen present were "ready to approve the law tomorrow" as one said.
Lobbying at its finest.
Right, so they put a language designer (a theorist), a developers relations manager (a PR guy) and an infrastructure engineer (someone who talks wires and servers) to talk about front-end development. How about calling actual front-end engineers to talk about their craft? How about asking the guys behind the Aves game engine what can be done realistically with HTML5?
Personally, I'd rather use a slow dynamic scripting language to glue the fast compiled language code together, (see: Perl), not write the whole damn server in slow JS.
That is the whole idea. Write processor intensive tasks in a fast compiled language (C or whatever) and glue them with a server that is good at handling asynchronous requests. That's what Node.js is about and JavaScript is actually a good fit for it because of closures.
The floating URL in Firefox does need a little more work to avoid getting in your way, yes. Fortunately Mozilla changed its release cycle for Firefox, so we won't have to wait 2 years for the next update.
This is just an experiment by the community. It doesn't mean Mozilla is going in any direction. Mozilla Labs is a place for breaking the web and learning from the broken pieces. Sometimes, interesting ideas arise, like the Awesome Bar HD (which still needs a lot of work). Other times, they go too far (Home Dash).
Anyway, Mozilla's motto for Firefox is to keep it being completely customizable, so you'll still be able to have the browser look any way you want, even if they change the standard UI.
A much better way to implement this unnecessary cookie law would be to put the responsibility on browser vendors instead of website owners.
This needs modding up.
Of course, this has the problem that too many people don't update their browsers - but those people bring it on themselves and should therefore not be "protected" by this law.
It actually shouldn't matter but not because "they bring it on themselves", but because sooner or later everyone updates, at most when they change computers.
Yup, further analysis is needed to confirm it is the Higgs or something completely new. The Resonaances blog has good speculation cover as usual.
JavaScript is fun. Embrace it! Get a book like Secret of the JavaScript Ninja instead.
Yeah except if the situation had been reversed and Microsoft had done what Mozilla did. Then there would be pitchforks about how Microsoft was being evil. But, no, this time it was Mozilla and they can just do no wrong.
If Microsoft had been honest and reflected openly about its mistake, then there wouldn't have been any pitchforks. Although it is true that lots of developers are partial against Microsoft, it is also true that they have been welcoming when MS made good decisions. Take a look at the response from the community about IE9. It was critical in specific aspects, but overall very happy with the change in relationships (they started with very early previews) and product quality.
ExtJS sucks.
Yes, it has a lot of features. But no, it doesn't scale well when what you need is granular control of how javascript loads and executes, and it doesn't help multiple developers working on different modules. Lots of hardcoded references to global objects, long namespaces, HUGE file downloads. It just doesn't add up. Sencha needs to really step up if it wants to stay competitive with a paid product.
Way better alternatives are YUI3 and GWT. Even ideas such as Wijmo perform better.
What this country needs is a good five dollar plasma weapon.
