I know you're wrong. If only it wasn't so hard to find a link somewhere pointing to an article about Amazon fighting to get the supreme court to take their fight against sales taxes online...
You need some external agency to give you lots and lots of money. This is genius! Who would have thought! Carry on with the research! Who knows, perhaps we can also solve world hunger with a similar solution.
I think it would be much more efficient to harness the power of the atom to create superheroes who can build flying solar tesla broadcast power for us.
Win phone 7's IE browser is using IE7's rendering/CSS engine I believe. IE7 was only a very slight upgrade over IE6. Not sure about wp8. IE8 was a lot closer to modern browsers in CSS but still had plenty of BS to worry about so probably IE8.
Is this just some sort of metaphor for all of us that need to rise up or something, or is it potentially helpful if I point out that at week 2 of the whole van thing, I'd be looking into finding a cheaper place to live and raise a family. Don't get me wrong. I like San Francisco a lot but that doesn't sound worth it.
Well, to be fair, it is bordering on useless at this point. IE>=9 support makes the vast majority of x-browser issues go away and even IE8 has query selectors. All that's left is the event system which does more than most people realize it can do and the convenient auto-looping of a lot of methods.
Paying Microsoft for a tool is only in part distasteful to me as a JS developer because of their 20 years of anti-competetive practices many of which has made life as a client-side UI developer a pain in the ass. It's also distasteful because I can read the history of my most negative working experiences in the end results of all their products. It positively reeks of design committees with no firm hand at the helm and clueless upper management that weighs success in terms of quantity of bullet points on feature lists.I certainly get the sense that there's something of a sea-ish change going on with MS lately but I'll believe it when it sticks and they start acting like a tech company again.
My rule is that if you crash when I type CSS too fast, you have 3 more versions to go before I start taking you seriously again. One more version to go now.
1. Learn how to write maintainable code in a dynamic type system and I guarantee it will improve your code quality in static languages. The most common fail I see in Java and C# is a total failure to understand and appreciate how critical encapsulation is to separating OOP languages from procedural.
2. Implicit type coercion allows for a lot of convenient shorthand that's easy to understand and that involves a lot more than just === vs ==. When there's no reason not to go with explicit comparison I favor it but I like having the option a lot.
3. Scope is function-based. 'use strict'; indirectly solves any hoisting problem you would otherwise be unlikely to run into barring really sloppy code. As a legibility practice I typically declare all but counter vars at the top.
4. Yes. As var or property shadowing could in a lot, I dare say most popular languages.
5. See point 4. But also the right text editor or IDE can help you with this.
6. It doesn't even make sense as a criticism of JS in the browser where code comes together via script tags. People use require.js for SPA-style apps which IMO are over-implemented.
7. So as legit of a criticism as say comparing C#, Java, or Python to C, all of which I would say modern browser and JS execution environment JITs are competitive with even before you consider the architecture advantages of being able to do more with less of a mess.
Browsers have been supporting JavaScript the language quite evenly since IE5, although IE naturally drags behind on having more recent version features. You're getting JS twisted with IE refusing to correct their proprietary DOM methods, the DOM being a language independent API for interacting with HTML and CSS.
You have to actually know a language and its execution environment(s) to optimize for it.
Given type systems are a design tradeoff, not a valid criticism.
I'd like to see you try to write something in a static typed language that's smaller than popular JS approaches to normalizing the DOM API.
Given what people were doing with HyperCard in the late '80s and the fact that HTML's predecessors at CERN were called things like scriptGML and GMLguid (not sure if guid relates to unique id or related to gui - but I only see reference to docs for SGMguid), I don't think it totally escaped their notice that there might be other applications of HTML and they added forms in '93 when it was only just starting to hit critical mass in academic circles.
HTML/CSS/JS have nothing to do with the fact that web app security is tricky. That's more to do with the stateless nature of TCP/IP which I assume was conceived as such because it would have been too much work to track state across redundant packets. Serving an app from a server to a client in any context requires not trusting the client and it wasn't any different on the internet before it was confused with the web. The technologies in use on the client-side change nothing in that regard and the onus of security falls on the server to not trust data from a client blindly.
Although we can do things that help in terms of damage control on the client-side like vetting data that comes from the server before injecting it anywhere just in case it's been compromised.
As an approach to creating GUIs for apps, I think the trio was revolutionary and it's no coincidence that CSS-style presentation is emulated in other contexts. Before the DOM era of web development, nobody was building GUIs of equivalent complexity with the speed and flexibility in the face of design changes that a typical web UI dev is expected to.
JS's single-threaded blocking model in conjunction with an event loop running in C is the design win.
In a typical Node scenario you might tell something to write to a file and provide a callback when its finished. The handler is registered and the file I/O is handled in a multi-threaded context. When the first file operation is complete, that JavaScript handler gets called back in single-threaded land where we can be assured nothing else will happen in JS-land until the callback is done. The second I/O operation keeps going and may even complete which would put its callback in line to fire at the next available window.
All thread-handling is essentially buried and there's a clean no-interference separation of application logic from File I/O and other lower-level tasks. There's no risk of two JS operations trying to write to the same value at the same time in JavaScript-land since JS functions can only execute one at a time and on the flip-side nothing in the file I/O operations will hold up app logic in JavaScript-land until callbacks fire or be blocked by anything happening in the JS themselves. You'll never have to lock a thread in Node.js or write a queue for the purpose of making sure two things don't try to hit the same value simultaneously.
The caveat is that you have to think about what's going and have the good judgment to not do things like write your high-resolution calculation-intensive photo processing in JavaScript. That's handled by writing it in C/C++ and then binding to a JS call.
I'm not completely hopeless at other languages. I spent much of the last year debugging and tweaking Java and C# and while I have no idea why you'd spend the money with so many good open source solutions available.NET MVC is an entirely tolerable solution compared to most things Java and.NET. I might even prefer it over Rails if I wasn't paying for it. But with Node I can have the framework up and running and be ready to start writing and executing code in 5-10 minutes on any OS. If somebody waved a wand and it suddenly became Scala or Python or any other dynamic language, I would still prefer it over MVC for never getting in my way by trying to "help" me, being stupid painless to implement, and for allowing me to do a lot more with a lot less code. The JavaScript is just gravy for me.
Knitting a fine silk scarf with a randomly misfiring rusty bazooka?
Sculpting a statue by ramming a block of marble with a Pinto?
How else do I express writing JavaScript in a tool written by the people who have made UI work a pain in all of our asses for the entire decade leading up to IE9 with a giant bloated IDE that has crashed on me on multiple occasions because I typed too fast, for a platform that is far more powerful in its elegant simplicity than anything Microsoft in all its quantity of bullet point evaluating design-by-committee glory will ever be able to offer.
You're either trolling or talking out of your ass.
jQuery's selector engine actually does a lot of selections faster than the native querySelector API does, owing to the fact that so far, browsers are just plugging into what they use for actual CSS which reads from right to left, which makes it impossible to take advantage of IDs and other selectors to isolate the query to a smaller subset. Also misuse by the DOM ignorant. No native methods for getElementsByClassName before IE8 so $('.someClass') would hit every single element in the document and check its class attribute if you didn't narrow down first.
The only thing that ever slowed it down in the past other than not having the best selector engine available, was the internals being a bit function-call-heavy. This is trivial, possibly actually perf-enhancing in modern JavaScript JITs.
jQ's utility as a DOM normalization tool is actually starting to become questionable, especially if you've dropped IE8 support but it's still very useful for drastically reducing kruft in the DOM API so I'm not sure where you're getting that it's somehow become less adept at cross-browser handling when IE itself is finally supporting DOM spec methods that it's been ignoring for a decade. I've also recently used 1.8 in a Phonegap app supporting iOS and Android and didn't run into x-browser issues relating directly to jQuery.
As far as quality of code, I haven't looked under the hood of recent versions as much but it's pretty much a textbook on how to write something that finds or builds objects of a certain type and then wraps them in method/object chaining adapter/decorator objects for normalizing an API that varies across platforms. The vast majority of "internal" methods and properties are actually trapped via function closure which drastically reduces the memory footprints of JQ objects while still effectively achieving encapsulation where it matters. Not a pattern I duplicate often but it's pretty damn useful when use cases come up.
I'm not aware of any severe performance issues with JQ in browsers or mobile at this time. IIRC it did have issues in Android way back.
I do agree that the constant edits on the API are getting beyond old but it's not like you have to update to the latest versions every time a new one comes out. The general trend is in browsers getting better at following spec and only varying in new stuff they add by way of experimenting. IE>=9 will tend to be behind the latest but they've at least ditched all their old proprietary methods for the DOM API. So it's not like there anything forcing you to upgrade for newer browsers.
If you want to rant about jQuery, rant about the quality of the modules written for it. Even the official subset libraries have been pretty weak. That and the buried or useless errors. But as someone who's equally comfortable working the raw DOM and selector APIs and who's been using jQuery since a year-long gig at a major ecommerce company where 200 idiot offshore Java devs were basically jumping up and down on the HTML without source control, and the team of 30 UI devs I was on basically spent half the week putting humpty back together again (supporting IE6 at the time), jQuery's had a nice run and it's not completely useless just yet but I'm about ready to write my own lighter-weight version of it.
It also does what I like best in a tool. It enables rapid DIY and it steps out of your way any time you want it to.
I think the trick is to write something that helps you build objects with methods that fire off events on themselves so internals can listen and respond and outside observers can too. Gives you a much more pleasant/legible interface to work with and the debug/testing/decoupling wins are huge if you're also passing data in event objects.
I beg to differ. I've ran into people who've been working with Java and C# for years who haven't learned a damned thing about the craft of writing decent code since leaving school. The protectionist paradigm might make it easier for them to produce working apps but it doesn't make their shite-code any more maintainable in the long haul. In JS, it doesn't take long to realize you're going to need to do better than spraying jQuery at every problem when you run into something like a SAAS app that has a lot of complexity and needs to be maintained and modified over time.
For one, you definitely learn to appreciate the value of encapsulation better than devs who just auto-attach getters/setters to absolutely every property, completely nullifying one of the most critically useful aspects of OOP or drop interfaces on every single class because they know test-first TDD is the only way they can feel confident their shit-architecture won't go to pieces on them at any given moment.
And I'm sorry but what language doesn't have lowest-common denominator programmers. I've seen offshored Java code that looked something like this:
someObject.doSomething(i); i++; someObject.doSomething(i); i++; someObject.doSomething(i); i++;//repeat 16 more times
I've never seen a web designer working on a disposable throwaway app for some interactive or ad agency do something that lame. If anything, the worst JS I've ever seen has tended to be authored by people from stricter protectionist paradigms who have never learned to write code that was legible without the aid of IDE crutches. Not that there's anything wrong with IDEs when you don't let them get in the way of having a clue. I just think people should start with languages like C and JS via text editor before they're allowed to touch an IDE.
Strict mode solves the implicit global issue. 'use strict;' at the top of the file isn't what I'd call a particularly painful workaround but I can't say I ran into a lot of implicit globals back when we just avoided them out of convention. By 'we' I mean professional developers who take the language seriously. Not like dynamic drive or some web designer just plugging in the jqueries for some disposable throwaway web app at an interactive agency.
On the type thing, if you mean, with code, there's typeof. If you get 'object' you can hit it with.constructor.name, which would be useless if it had an anonymous function as a constructor but then why would you? That would be stupid and worthy of shaming the team member responsible.
If you mean just reading the code, it's a silly gripe unless you're in the habit of using var names that are meaningless to anyone but yourself but even then it doesn't take long to see what's expected of a var when there's a lot less code in play in the first place due the fact that it's not statically typed.
Slashdot Mirror
I know you're wrong. If only it wasn't so hard to find a link somewhere pointing to an article about Amazon fighting to get the supreme court to take their fight against sales taxes online...
The bald eagle is also an opportunist and a scavenger.
We'd become like insanely socialist Japan.
You need some external agency to give you lots and lots of money. This is genius! Who would have thought! Carry on with the research! Who knows, perhaps we can also solve world hunger with a similar solution.
I think it would be much more efficient to harness the power of the atom to create superheroes who can build flying solar tesla broadcast power for us.
Yeah, but if we beat China we get to clear all our debts! That's how it works, right? Guys?
This is precisely the reason why I want to kick programmers who piss and moan about having to help interview. I want to be at every single one.
Win phone 7's IE browser is using IE7's rendering/CSS engine I believe. IE7 was only a very slight upgrade over IE6. Not sure about wp8. IE8 was a lot closer to modern browsers in CSS but still had plenty of BS to worry about so probably IE8.
Not sure if DarwinSurvivor is serious or making fun of people. Either way, this post is hilarious because it makes no sense.
Is this just some sort of metaphor for all of us that need to rise up or something, or is it potentially helpful if I point out that at week 2 of the whole van thing, I'd be looking into finding a cheaper place to live and raise a family. Don't get me wrong. I like San Francisco a lot but that doesn't sound worth it.
You'd have to pay me a lot more than that to write properly learned JavaScript for a defense contractor in DC.
Well, to be fair, it is bordering on useless at this point. IE>=9 support makes the vast majority of x-browser issues go away and even IE8 has query selectors. All that's left is the event system which does more than most people realize it can do and the convenient auto-looping of a lot of methods.
Paying Microsoft for a tool is only in part distasteful to me as a JS developer because of their 20 years of anti-competetive practices many of which has made life as a client-side UI developer a pain in the ass. It's also distasteful because I can read the history of my most negative working experiences in the end results of all their products. It positively reeks of design committees with no firm hand at the helm and clueless upper management that weighs success in terms of quantity of bullet points on feature lists.I certainly get the sense that there's something of a sea-ish change going on with MS lately but I'll believe it when it sticks and they start acting like a tech company again.
My rule is that if you crash when I type CSS too fast, you have 3 more versions to go before I start taking you seriously again. One more version to go now.
1. Learn how to write maintainable code in a dynamic type system and I guarantee it will improve your code quality in static languages. The most common fail I see in Java and C# is a total failure to understand and appreciate how critical encapsulation is to separating OOP languages from procedural.
2. Implicit type coercion allows for a lot of convenient shorthand that's easy to understand and that involves a lot more than just === vs ==. When there's no reason not to go with explicit comparison I favor it but I like having the option a lot.
3. Scope is function-based. 'use strict'; indirectly solves any hoisting problem you would otherwise be unlikely to run into barring really sloppy code. As a legibility practice I typically declare all but counter vars at the top.
4. Yes. As var or property shadowing could in a lot, I dare say most popular languages.
5. See point 4. But also the right text editor or IDE can help you with this.
6. It doesn't even make sense as a criticism of JS in the browser where code comes together via script tags. People use require.js for SPA-style apps which IMO are over-implemented.
7. So as legit of a criticism as say comparing C#, Java, or Python to C, all of which I would say modern browser and JS execution environment JITs are competitive with even before you consider the architecture advantages of being able to do more with less of a mess.
Browsers have been supporting JavaScript the language quite evenly since IE5, although IE naturally drags behind on having more recent version features. You're getting JS twisted with IE refusing to correct their proprietary DOM methods, the DOM being a language independent API for interacting with HTML and CSS.
You have to actually know a language and its execution environment(s) to optimize for it.
Given type systems are a design tradeoff, not a valid criticism.
I'd like to see you try to write something in a static typed language that's smaller than popular JS approaches to normalizing the DOM API.
Given what people were doing with HyperCard in the late '80s and the fact that HTML's predecessors at CERN were called things like scriptGML and GMLguid (not sure if guid relates to unique id or related to gui - but I only see reference to docs for SGMguid), I don't think it totally escaped their notice that there might be other applications of HTML and they added forms in '93 when it was only just starting to hit critical mass in academic circles.
HTML/CSS/JS have nothing to do with the fact that web app security is tricky. That's more to do with the stateless nature of TCP/IP which I assume was conceived as such because it would have been too much work to track state across redundant packets. Serving an app from a server to a client in any context requires not trusting the client and it wasn't any different on the internet before it was confused with the web. The technologies in use on the client-side change nothing in that regard and the onus of security falls on the server to not trust data from a client blindly.
Although we can do things that help in terms of damage control on the client-side like vetting data that comes from the server before injecting it anywhere just in case it's been compromised.
As an approach to creating GUIs for apps, I think the trio was revolutionary and it's no coincidence that CSS-style presentation is emulated in other contexts. Before the DOM era of web development, nobody was building GUIs of equivalent complexity with the speed and flexibility in the face of design changes that a typical web UI dev is expected to.
What prevents you from writing something large with it?
JS's single-threaded blocking model in conjunction with an event loop running in C is the design win.
In a typical Node scenario you might tell something to write to a file and provide a callback when its finished. The handler is registered and the file I/O is handled in a multi-threaded context. When the first file operation is complete, that JavaScript handler gets called back in single-threaded land where we can be assured nothing else will happen in JS-land until the callback is done. The second I/O operation keeps going and may even complete which would put its callback in line to fire at the next available window.
All thread-handling is essentially buried and there's a clean no-interference separation of application logic from File I/O and other lower-level tasks. There's no risk of two JS operations trying to write to the same value at the same time in JavaScript-land since JS functions can only execute one at a time and on the flip-side nothing in the file I/O operations will hold up app logic in JavaScript-land until callbacks fire or be blocked by anything happening in the JS themselves. You'll never have to lock a thread in Node.js or write a queue for the purpose of making sure two things don't try to hit the same value simultaneously.
The caveat is that you have to think about what's going and have the good judgment to not do things like write your high-resolution calculation-intensive photo processing in JavaScript. That's handled by writing it in C/C++ and then binding to a JS call.
I'm not completely hopeless at other languages. I spent much of the last year debugging and tweaking Java and C# and while I have no idea why you'd spend the money with so many good open source solutions available .NET MVC is an entirely tolerable solution compared to most things Java and .NET. I might even prefer it over Rails if I wasn't paying for it. But with Node I can have the framework up and running and be ready to start writing and executing code in 5-10 minutes on any OS. If somebody waved a wand and it suddenly became Scala or Python or any other dynamic language, I would still prefer it over MVC for never getting in my way by trying to "help" me, being stupid painless to implement, and for allowing me to do a lot more with a lot less code. The JavaScript is just gravy for me.
A Node.js app written with Visual Studio...
Knitting a fine silk scarf with a randomly misfiring rusty bazooka?
Sculpting a statue by ramming a block of marble with a Pinto?
How else do I express writing JavaScript in a tool written by the people who have made UI work a pain in all of our asses for the entire decade leading up to IE9 with a giant bloated IDE that has crashed on me on multiple occasions because I typed too fast, for a platform that is far more powerful in its elegant simplicity than anything Microsoft in all its quantity of bullet point evaluating design-by-committee glory will ever be able to offer.
You're either trolling or talking out of your ass.
jQuery's selector engine actually does a lot of selections faster than the native querySelector API does, owing to the fact that so far, browsers are just plugging into what they use for actual CSS which reads from right to left, which makes it impossible to take advantage of IDs and other selectors to isolate the query to a smaller subset. Also misuse by the DOM ignorant. No native methods for getElementsByClassName before IE8 so $('.someClass') would hit every single element in the document and check its class attribute if you didn't narrow down first.
The only thing that ever slowed it down in the past other than not having the best selector engine available, was the internals being a bit function-call-heavy. This is trivial, possibly actually perf-enhancing in modern JavaScript JITs.
jQ's utility as a DOM normalization tool is actually starting to become questionable, especially if you've dropped IE8 support but it's still very useful for drastically reducing kruft in the DOM API so I'm not sure where you're getting that it's somehow become less adept at cross-browser handling when IE itself is finally supporting DOM spec methods that it's been ignoring for a decade. I've also recently used 1.8 in a Phonegap app supporting iOS and Android and didn't run into x-browser issues relating directly to jQuery.
As far as quality of code, I haven't looked under the hood of recent versions as much but it's pretty much a textbook on how to write something that finds or builds objects of a certain type and then wraps them in method/object chaining adapter/decorator objects for normalizing an API that varies across platforms. The vast majority of "internal" methods and properties are actually trapped via function closure which drastically reduces the memory footprints of JQ objects while still effectively achieving encapsulation where it matters. Not a pattern I duplicate often but it's pretty damn useful when use cases come up.
I'm not aware of any severe performance issues with JQ in browsers or mobile at this time. IIRC it did have issues in Android way back.
I do agree that the constant edits on the API are getting beyond old but it's not like you have to update to the latest versions every time a new one comes out. The general trend is in browsers getting better at following spec and only varying in new stuff they add by way of experimenting. IE>=9 will tend to be behind the latest but they've at least ditched all their old proprietary methods for the DOM API. So it's not like there anything forcing you to upgrade for newer browsers.
If you want to rant about jQuery, rant about the quality of the modules written for it. Even the official subset libraries have been pretty weak. That and the buried or useless errors. But as someone who's equally comfortable working the raw DOM and selector APIs and who's been using jQuery since a year-long gig at a major ecommerce company where 200 idiot offshore Java devs were basically jumping up and down on the HTML without source control, and the team of 30 UI devs I was on basically spent half the week putting humpty back together again (supporting IE6 at the time), jQuery's had a nice run and it's not completely useless just yet but I'm about ready to write my own lighter-weight version of it.
It also does what I like best in a tool. It enables rapid DIY and it steps out of your way any time you want it to.
I think the trick is to write something that helps you build objects with methods that fire off events on themselves so internals can listen and respond and outside observers can too. Gives you a much more pleasant/legible interface to work with and the debug/testing/decoupling wins are huge if you're also passing data in event objects.
Really? Cuz I sure thought Python was in the Ubuntu building.
I beg to differ. I've ran into people who've been working with Java and C# for years who haven't learned a damned thing about the craft of writing decent code since leaving school. The protectionist paradigm might make it easier for them to produce working apps but it doesn't make their shite-code any more maintainable in the long haul. In JS, it doesn't take long to realize you're going to need to do better than spraying jQuery at every problem when you run into something like a SAAS app that has a lot of complexity and needs to be maintained and modified over time.
For one, you definitely learn to appreciate the value of encapsulation better than devs who just auto-attach getters/setters to absolutely every property, completely nullifying one of the most critically useful aspects of OOP or drop interfaces on every single class because they know test-first TDD is the only way they can feel confident their shit-architecture won't go to pieces on them at any given moment.
And I'm sorry but what language doesn't have lowest-common denominator programmers. I've seen offshored Java code that looked something like this:
someObject.doSomething(i); //repeat 16 more times
i++;
someObject.doSomething(i);
i++;
someObject.doSomething(i);
i++;
I've never seen a web designer working on a disposable throwaway app for some interactive or ad agency do something that lame. If anything, the worst JS I've ever seen has tended to be authored by people from stricter protectionist paradigms who have never learned to write code that was legible without the aid of IDE crutches. Not that there's anything wrong with IDEs when you don't let them get in the way of having a clue. I just think people should start with languages like C and JS via text editor before they're allowed to touch an IDE.
Strict mode solves the implicit global issue. 'use strict;' at the top of the file isn't what I'd call a particularly painful workaround but I can't say I ran into a lot of implicit globals back when we just avoided them out of convention. By 'we' I mean professional developers who take the language seriously. Not like dynamic drive or some web designer just plugging in the jqueries for some disposable throwaway web app at an interactive agency.
On the type thing, if you mean, with code, there's typeof. If you get 'object' you can hit it with .constructor.name, which would be useless if it had an anonymous function as a constructor but then why would you? That would be stupid and worthy of shaming the team member responsible.
If you mean just reading the code, it's a silly gripe unless you're in the habit of using var names that are meaningless to anyone but yourself but even then it doesn't take long to see what's expected of a var when there's a lot less code in play in the first place due the fact that it's not statically typed.