Posted
by
Soulskill
on Friday February 15, 2013 @11:51AM
from the somebody-else-will-fix-it dept.

An anonymous reader writes "It's not everyday that we get to hear about the potential downsides of using WebKit, but that's just what has happened as Dave Methvin, president of the jQuery foundation and a member of the core programming team that builds the widely used Web programming tool, lamented in a blog post yesterday. While most are happy to cheer for IE's demise, perhaps having three main browser engines is still a good thing. For those that work in the space, does the story ring true? Are we perhaps swearing at the wrong browser when implementing 'workarounds' for Firefox or IE?"

I hate to say it but web developers need to stop using "frameworks" and "libraries" to do simple things.

There's so many websites that load jQuery or TinyMCE for no good reason other than the developer was lazy.

I code everything by hand, if it doesn't work in some browser, then that browser's implementation is broken. There should be no need to write against jQuery and assume that the underlying browser isn't braindead or futureproof. If you're writing against the standards for HTML5, CSS3 and the DOM, then you're better off writing your own code. If you're just a code monkey who can be replaced at a moments notice, then by all means write against stupid frameworks so that you're easily replaced.

Must admit, although I primarily use Firefox or Chome; I have no problems at all with IE. I don't understand why people would "cheer for its demise". IE9 is a good browser, and I'm all for competition. Less competition in any space is generally bad for users, if things swing too far toward one engine we'll be in the same position we were when IE6 was the "standard" and people ended up only bothering to test on that browser. That causes stagnation.

Frameworks to do simple things may be stupid, but it's just as stupid to write your own code every time too. It's hard to say which one is worse, but I'm going to say it's worse to never use a framework than to always use one unless your time has no value and you always write perfect code.

That my webkit browsers have been very poorly behaved; maybe it's just me... but images flicker, forms appear and disappear, sometimes pages just stop loading at random... each patch for mountain lion seems to repair it BRIEFLY... but it always comes back.

Desktop Chrome used to be a breath of fresh air a year or two ago, but now, my experience with every new release has been worse than with the previous version. I feel probably they are ignoring it for the Mobile Android and Chrome browsers because they feel it's more important to keep their lead there.

According to the author, Opera should spend their time and money to fix old edge-case bugs in WebKit, but he shouldn't have any obligation to contribute patches himself.

Sorry sir, but that's not how open-source development should work. If you're going to spend time rebuilding your own codebase, evaluating whether a ton of old workarounds are still necessary because of missing "half-line fix[es]", you should consider spending some of that time contributing such simple patches upstream to improve the situation. With IE, that was never an option, but it is with WebKit. In an open-source stack, the only workarounds that should be accepted as the regular course of business are ones that are prohibitively difficult to implement in the dependency, or where the patches have been submitted and rejected.

What's most entertaining is the reference to the "tragedy of the commons" in TFA's title. Tragedy of the commons is not something being so commonly used that it's improved in places you don't like. Rather, it's where everybody using the common property thinks that maintenance is someone else's problem. Mr. Methvin, WebKit's maintenance is as much your problem as it is Opera's.

It's inertia. IE6 was a terrible browser. IE7 and 8 were better, but not markedly so. IE9 was a total turnaround for Microsoft, and IE10 is keeping with that trend.

However, the damage is already done. On top of it being a Microsoft product and thus being automatically terrible, dangerous and likely to cause the death of a few Linux whackjobs, its bad reputation in the past has stuck to it like a skunk's stink. Is it deserved? Not anymore, no. But you probably have noticed by now that for all our claims of technology being a fast moving sector, a lot of the people working in it are old men shouting at you to get off their lawn;)

Opera's shift to WebKit should concern everyone. It's likely a good decision for them, but it consolidates WebKit's position as the dominant rendering engine, and having any dominant engine is bad, as you go from standards directing engines to the dominant engine imposing "standards".

Ironically, it's Firefox which is still doing its job: never the dominating browser, but always a significant enough force to stop any one browser from entirely dominating. Those who think Mozilla's outlasted their welcome should think again.

Probably also worth mentioning that the OSX version of Safari doesn't render exactly the same as it does on Windows. It's also not any more available for Linux than IE is. Maybe that's "untestable" too, eh?

First website I built was around 20 years ago. Last website I built completed a couple of weeks ago.

I've been through pretty much every version of IE, Netscape, Firefox, Chrome, Opera, Safari, (and Mozaic). If you're not charging clients extra now for IE6/7 support, then you really need to look at your business practices. I don't "hate" any platform; I just charge clients if they need a platform supported. Of course, you're free to go on some religious or idealogical crusade in your spare time if you like, but getting emotional about a browser doesn't make much sense.

It's funny to me to hear people claiming IE6 is incapable of rending content etc, when we were making arcade style games, windowing systems, AJAX style requests (piggybacking data in cookies from image src requests) back with IE4 and NS4.

tl;dr Charge clients for the extra work, or get new clients. Don't work for free and then moan about it.

Frameworks to do simple things may be stupid, but it's just as stupid to write your own code every time too.

Being that the reason that old school programmers make their own frameworks?:-)

There's something very wrong when you spend less time building your own framework than learning a well known and stablished one to do your task.

You can argue that a well known and stablished framework will save time on the long run. But I will counter-argue stating that this is only true if the guy knows the framework by heart - otherwise he will be screwed up on every single mistake did by someone's else.

It's better to "waste" a little time now and in every project in the future, than to waste a huge one now and then in the hope that somewhere the future I will be able to throw up a new system every week without hassle - what's is not going to happen anyway, because in less than a year everything is changed, and things will start to break, and the cycle starts again.

Here's a few reasons to use libraries and frameworks:1) Development speed.2) Browser support and testing.3) Maintenance.

I'll let you figure out how they help in those situations - and there are many other reasons, on top of those.

developers need to stop using "frameworks" and "libraries" to do simple things.

Seriously, this is a really fucking stupid thing to say. Imagine telling a C developer to re-implement printf() for every application (and every platform it will run on) that needs to print a line of output.

Loading a 80KB library and adding yet another layer of interpreted code for something that takes five lines of javascript is also stupid.

What's worst is libraries that require jQuery to do stupid stuff like cross-fading. The browser doesn't support it? Screw it and just switch the images. If the browser is too old, the hardware is probably too old to do a smooth cross-fading too anyway.

I hate to say it but web developers need to stop using "frameworks" and "libraries" to do simple things.

People using the wrong tools for the wrong jobs is the problem - not frameworks in general.

There's so many websites that load jQuery or TinyMCE for no good reason other than the developer was lazy.

Laziness is one of the hallmarks of a good programmer. It's also an incredibly useful trait for aligning with management and/or a client. A programmer who saves himself having to reimplement tedious and repetitive things is a programmer that is saving money.

I code everything by hand, if it doesn't work in some browser, then that browser's implementation is broken. There should be no need to write against jQuery and assume that the underlying browser isn't braindead or futureproof. If you're writing against the standards for HTML5, CSS3 and the DOM, then you're better off writing your own code.

Eight years ago for an internal project, I wrote all my own DOM wrappers from scratch. It was fast, I knew every inch inside and out, and it worked in all DOM compliant browsers. It took a bit of foresight and prep work to get there, but the payoff was sound. There weren't a lot of options out there at the time, so this was pretty much the only option.

A year ago I started a contract job for a client. I elected to use jquery as a standardized DOM manipulation tool. The actual application code from a developer/client perspective all worked roughly the same as the hand-tooled code from before - except I didn't have to write, and more importantly bill the client, for any of that time. The jquery element traversal utilities alone will save you so much time you won't even believe it.

In the end, both projects ended up with chunk of code being loaded by the browser to make fiddling the DOM in a cross platform manner easier and more reliable for the application code. In the first case, that cost the company money. In the second case, it was 'free'. In both cases, the browser is downloading a dependency 'framework' in order for the application to function.