But a lot of databases have to deal with people's names. To paraphrase an old saying, "I don't care why I'm in the database, as long as they spell my name right."
2,736 karma · joined February 19, 2010
I always have wished that the script inside the tag would be executed if the `src` couldn't be loaded, which is something John Resig suggested years ago [1].
Since web servers are most reliably logged even on poorly maintained systems, I'm guessing at least part of the attack hinged on that. It's really common to have servers that end up with no disk space because web logs aren't being rotated and archived/pruned properly.
It was a blind spot for Gates and Microsoft in the 1980s. He wasn't alone, of course. People like Marshall McCluhan had laid out a vision for it years before but Gates was really focused on software for devices and not the network. It wasn't until the late 1980s that Microsoft turned its attention to Novell which was making a killing in PC networking. (Gates recruited Jim Allchin from network company Banyan in 1990.) By the mid-1990s there wasn't much left of Novell, but Microsoft's interest and strategy there was purely driven by business and not vision. That was clear when they were clobbered again by the Internet.
http://technet.microsoft.com/en-us/scriptcenter/dd919274.asp...
Again, not true. For example, the `this` in an event handler is the actual DOM element, not a jQuery object. Whether you handle that directly with DOM methods or wrap it with `$(this)` is up to you. Many people prefer the latter but the former is often smaller and prettier.
> For example converting a wrapped node to a native DOM node requires an extra call that, in my opinion, is ugly: $('.something').get(0); and could be considered to be an anti-pattern.
How common is that, really? Your example assumes a single element with that class name. Why not chain a jQuery method behind it and handle the 0 or N cases as well?
Not true at all. You can do a custom build and leave out things you don't need. You can even leave out stuff you DO need and replace with your own simpler shim. See the README file.
Not true, and has never been true; maybe you confused jQuery with Zepto? "#id" uses getElementById, ".class" uses getElementsByClassName, more complex selectors go through querySelectorAll, and custom selectors through Sizzle.
> And like others said, people mostly use like 1% of the API, which has as easy native browser support.
Hard to argue with that statistic since it's made up!
Remember, however, that many of your "comparable" test cases are making assumptions that jQuery can't make. For example, .show() sets the display property back to what it was before a previous .hide(), to do that it has to query the display property when hiding. If you try some ideas for fixes, the unit tests should indicate whether you've run afoul of such problems.
Is the performance of .show()/.hide() causing issues? Under what conditions?
I'll put in a plug for jQuery, see http://contribute.jquery.org for some guidance. There are plenty of things to do in every project besides hardcore coding as well, such as documentation or build systems.
I've profiled a lot of web pages/apps and this hasn't usually been true in my experience. Occasionally JavaScript is the culprit but that is more often to be due to really bad O(n-squared) algorithms and script that forces layout. In contrast, the rendering engine combined with complex CSS is often the cause of "janky" page behavior. Do you have some profiler runs that show a JavaScript bottleneck on a webview that doesn't exist when using Nitro or some other browser?
I'd like to see what assumptions famo.us has made and whether they could have just been addressed at the CSS level. An example of that would be things like overlapping elements with rounded corners and drop shadows, which are very expensive for the rendering engine. So perhaps it was a lack of understanding of CSS jank factors that led them to decide a total circumvention was in order? We'd really need to see a side-by-side of the two and understand where the conventional solution was bogging down.
The key to understanding the architecture is to realize that you are not writing assembly language as much as microcode. I think the architecture would have lasted longer if it had chosen to have registers be a multiple of 8 bits rather than 6. As important as number crunching was to that machine, the limit of 64 characters per 6-bit "byte" was really annoying and made interoperability a mess.
I'm not sure I understand the value of a system like that though. In the systems I've used and built, most customers see their service as an annual thing that renews on a particular date every year, for which they pay an annual fee. Doing it as a daily fee simplifies the special cases like converting between plans but makes it harder to deal with "your annual plan always renews on this date".
I can't speak to Google Shopping, but Amazon requires a high-quality image before you can list a product. So if you spend money on the shot you don't want others stealing it. EXIF data and other non-watermark solutions are easily removed.
Even big and influential media may not escape. Apple doesn't need to cooperate with the normal reporters on the New York Times who ask hard questions about conditions in Chinese factories, they just need to court David Pogue.
Big companies want technologies they can invest in that will remain stable and supported for a decade or more. Hell, many of them are upset that XP isn't being supported for longer than that.
If as a big company you had been a leader and built a web-based app in, say, 2005, it would most likely be a mess of hand-built DOM libraries that sniffed for specific browsers and most likely were wired to IE6 or IE7 (remember, jQuery didn't even exist yet). The "good options" that corps are choosing to use today mainly involve forcing newer versions of Internet Explorer into IE7 or IE5-Quirks mode so they don't have to lift a finger to change that festering pile of custom JavaScript.
I'm not convinced that any technology exists today that will be so set-it-and-forget-it wonderful that companies should plan to build it now and leave it the hell alone for a decade. But that's what they've demanded of the last generation of apps they built.
http://clicky.com/marketshare/global/web-browsers/internet-e...
This is exactly the position Microsoft was in during the mid-1990s, even before they went after Netscape. The article is saying that Google is even applying some of the same strong-arm tactics to keep OEMs in line. Fortunately, Google can point to Apple and say they're not a monopoly the way Microsoft was in its market. Plus, Android still looks really open compared to iOS.