SOPA and PIPA are bills are designed to help guys like me (software company owners), and yet I find them pretty distasteful in many ways.
As other have pointed out, a rather large burden is placed on site owners, especially those who run aggregate sites like Reddit and YouTube. My understanding is content/copyright owners can request that sites be removed from the US Internet if they’re found to harbor, support, or link to unlicensed content.
I appreciate competition in the search engine space but Bing simply doesn’t compete at this point. I would like to it, but it simply doesn’t.
In the first post of this series we looked at the common misconception of jQuery being the “lightweight” JavaScript library. In this post we’ll leave the sidelines and jump right into some real-world scenarios. I want to see what makes jQuery tick by comparing it to my beloved Prototype.
One of the hottest JavaScript libraries on the planet is jQuery. It’s opened up a world of web developers to functionality and ease they would not otherwise know, and has done so without stepping on anyone toes. Their are hundreds of great extensions for it made by a first-rate community that’s almost always helpful and supportive. When it comes to getting a job I’d say jQuery knowledge is almost becoming requirement, if not right away then as part of your integration into that job.
Prototype JS is…well…it’s another JavaScript library. But it’s the library I know and love. It’s what drives FormBoss and while not as exciting or popular as jQuery, I swear its day will come (again). Their are many reasons for this belief, but the first is due to what I believe is a fundamental misconception about jQuery vs. other libraries — its payload size.
In this first of a multi-part series we’ll take a look at the physical delivery size of each library. In the next post well dive into practical programming. First though, a bit of background.
References are a feature of the C family of languages, and while not all that common in PHP, can be used and are quite handy in some situations. In this post I want to cover what references are and how we can (and may not want to) use them in our PHP code.
“Stock” PHP has a large number of extensions that cover just about every web-development task you can imagine. From file and FTP operations to database communication, chances are PHP already has you covered.
Their is one area where PHP falls flat however, and that’s intensive data processing. As PHP internally stores all user-space variables in a hash-table, algorithms that require heavy manipulation and lookups of these items will always be slow.
Of course PHP will also fall flat for us if we need some capabilities that no extension provides.
In this post we’ll learn about the solution to both of these issues: building custom PHP extensions. The reason why this post even exists is because of an excellent PHP tool called: ext_skel, as with it we can quickly create our own PHP extensions that would otherwise take many laborious hours of trial and error.
Just a quick spattering of some benchmarks I ran while testing a program I’m developing internally.
The first three are of the fannkuch benchmark found on the sunspider test site, only ported over to C++ and PHP in addition to the JS version. The browser used for all tests was Firefox 5.
The HPHP listing is a compiled Hip Hop PHP version, which is interesting as it shows the relative difference between it and vanilla PHP.
The last item, Benchmark.php, is the same benchmark file you’ll find in a PHP source download.
See the full benchmarks after the jump!
I recently installed Internet Explorer 9, and while the browsers interface seems nice, the JavaScript performance in terms of running FormBoss leaves something to be desired: In short, it’s completely unusable.
This was not at all the case in IE 8, and when you consider IE 9 was supposed to be the release that finally fixed JavaScript this is quite disheartening.
As any serious JavaScript programmer can attest to, the irony of IE has always been that in many ways its been more ‘correct’ in terms of standards than the other browsers. That is, what passes in Firefox in terms of JavaScript code fails in IE not because IE is wrong, but because Firefox is so forgiving (and by extension, wrong). This is doubly true when we add a JavaScript library like Prototype JS into the mix, in that the libraries attempts to smooth over browser differences may expose us to subtitle differences in core JavaScript behavior.
On that springs to mind is how some Prototype JS objects property counts are handled. In Firefox an object may be shown to have a length of 1, but in IE that same object had a length of 2. Another example, if memory serves, had to do with valid names of objects. IE has always been more strict in terms of using names that start with numbers, and so on.
Such differences can be hard to spot in production code, and almost always leads to hours of careful testing and debugging.
Thus, as part of my own production process I’d like to share two links that may help you determine if such issues reside in your code or the browser/library begin used.
http://sputnik.googlelabs.com/
This test is very interesting to me as it confirms, among other things, that IE 9′s JavaScript engine is generally more ‘correct’ in terms of standards that the competition. For example, when run in IE 9 I get 71 failed tests, whereas Chrome Canari generates 136 and Firefox 4 181.
In almost all of the cases that ‘fail’ we see the failed test is something the casual JavaScript author may easily do.
For example, in test s12.5_A9_T1 we check for a function declaration within an ‘if’ statement:
// Copyright 2009 the Sputnik authors. All rights reserved.
// This code is governed by the BSD license found in the LICENSE file.
/**
* @name: S12.5_A9_T1;
* @section: 12.5;
* @assertion: Function declaration within an "if" statement is not allowed;
* @description: Declaring function within an "if" statement;
* @negative;
*/
if (true) {
function __func(){};
} else {
function __func(){};
}
testCompleted();
Have I ever done this? No. Could I see others or even me late at night? Sure. The point being that as you peruse some of the test that say, Firefox 4 fails, it becomes obvious that many of the failures stem from Firefox being ‘fast and easy’ with some of the rules, which ironically, can make creating JavaScript code easier.
http://dante.dojotoolkit.org/taskspeed/
This test highlights the differences in the major JavaScript libraries. Of core importance to me are the functions that manipulate the DOM, such as append, insertbefore, insertafter, and so on.
In this post we’ll cover a topic you’ll no doubt run into when dealing with SOAP web services: parsing XML data that uses namespaces via XPath.
As I’m a PHP guy this will be PHP centric in that we’ll use SimpleXML for our parsing needs. The techniques and general ideas presented herein however, are applicable to almost all XML/XPath processing languages.
The Sunspider JavaScript Benchmark is a popular test of Web Browser performance.
As great as the newest browsers are I though it would be interesting to take a random test and port it to C++ for the sake of comparison.
I decided the rather short fannkuch test was a good candidate. The results:
Not surprisingly the C++ version is 18x faster than Firefox and 8x faster than Chrome. For the curious, the ported C++ code is after the jump.
I should mention one thing changed from the stock Sunspider site (e.g., the link above), is the number of iterations was upped from 8 to 10. At 8 iterations the C++ version was sub-millisecond, meaning I’d have had to roll a custom assembly timer to get a benchmark value. That said, when we lower the iterations down to 9, the stack heavy algorithm starts to benefit the browsers more, with Chrome coming in only 3 times slower and Firefox 11.
Lower the iteration count to the “stock” 8 and Firefox actually catches up to Chrome, with both browsers reporting ~21ms. Interesting.