Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×

Comment Re:That's just not a viable option. (Score 1) 407

Then can the browser vendors at least look at the fucked up work arounds they had to do to get jquery to even work and fix them?

The problem is that jQuery is so poorly implemented -- and so badly broken that there no value can be gained from its examination!

It's pretty obvious that Resig et al. don't have a clue. The "work arounds" are "fucked up" because they were written by rank amateurs who *still* don't know what they're doing!

As far consistency between browsers, I agree that things have improved. Even IE. So much so, in fact, that a few polyfills is often more than adequate to take care of the differences between browsers. (Just be careful with them. Some are great, while others are total garbage.)

Read the links I posted and dig around comp.lang.javascript for a little bit. If you're still advocating the use of jQuery after that, I don't know what to tell you!

My view on the matter is anyone who is criticizing Jquery / Dojo / and is suggesting vanilla javascript is completely ignoring the fact that the reason allot of these frameworks exists is the base implementations are horribly, horribly broken and the effects of a piece of javascript can be inconsistent even within the same browser.

But neither jQuery or Dojo actually solved the problem! (Sometimes they'd even make the problem worse...) The myth from years ago was that jQuery took care of all your cross-browser concerns. That was never even a little bit true. jQuery was, and still is, inconsistent across even the few browsers it claims to support. That's to say nothing of it's ever-shifting API!

Things are not nearly as broken as you seem to think they are. The differences between browsers can easily be managed by knowing what features to avoid -- and you don't need to avoid very much at all! Usually a small and simple polyfill or two will take care of any features you need -- even if you need to support antique versions of IE.

Comment Re:That's just not a viable option. (Score 1) 407

Yes, that's correct. Now ask yourself why JavaScript need enter in to it at all? (Are you going to advocate browser detection? You'll find more than enough on comp.lang.javascript about that bad practice!)

I don't know, dynamically change the element's CSS depending on the resolution and orientation?

If that becomes a need, chances are you've already failed. When it makes sense, which is rare, you'll find mobile browsers more than capable thanks to long-standing and broad CSS3 support across the major platforms.

As for the handheld media type, your article is woefully out-of-date. CSS3 Media Queries are far from "non-standard" in case you didn't know. (I should also point out that for mobile devices, in virtually all cases, it's not necessary to change your CSS at all. If you found some bizarre case where that was necessary, using the outdated handheld media type wouldn't make sense anyway!)

And you want to use a heavy-weight JavaScript library to "fill in the gaps" (that likely don't exist) on a subset of antique devices where you might find a minor layout problem? That's insane. I'll take it a step farther and guarantee that you'll find more "gaps" using JavaScript for layout on old mobile devices than you will with CSS.

Anyhow, I'm not going to argue with you about this. It's clearly going to be a huge a waste of my time. Unless your incompetent, you'll figure this out on your own eventually.

Good luck.

Comment Re:That's just not a viable option. (Score 0) 407

Do you actually need to ask? I don't even know where to begin! Do a google search, you'll find much more that I could possibly jam in to a forum post.

(Other users who are not completely floored by the question: feel free to chime in.)

Learn to use CSS. In the context of this discussion, pay particular attention to @media

I wonder if you use tables for layout as well...

Comment Re:That's just not a viable option. (Score 0) 407

I don't think there is a competent programmer alive who does not use libraries.

Read my post again. I'm not arguing against all libraries, just their unnecessary use. In the case of jQuery, jQuery Mobile, and jQuery UI their use is not only unnecessary it's actually harmful -- particularly on mobile.

What if you're developing a website that needs to be responsive for all orientations, both desktop and mobile?

If you're using JavaScript for layout, you've already failed.

Comment Re:That's just not a viable option. (Score 0, Troll) 407

You keep claiming jQuery is slow and crappy because a few frameworks that exist on top of it are slow.

No, I've been claiming that jQuery is slow and crappy all on it's own. jQuery UI and Mobile just happen to be even slower.

jQuery is not a performance killer.

Actual data suggests otherwise. This is completely objective. You can test this for yourself. You pay a VERY steep price for using jQuery even for very simple things.

What it does do, however, is cut development time considerably.

Have any metrics? From what I've seen, it adds significant development time over the life of the application. Do you know how common it is to see multiple versions of jQuery loaded on the same page? (jQuery even has features to help allow that to happen!) Do you have any idea how difficult is is to dig someone out of a mess like that?

The only way jQuery could possibly "cut development time" is if you never maintain your code -- and only then if typing speed is your biggest bottleneck.

I won't claim that jQuery is faster than every native solution. But it is probably faster than your native solution. And infinitely more maintainable.

Have you looked at the jQuery codebase? It's like a group of amateurs that didn't understand either JS or the DOM wrote a library. Oh, wait, that's exactly what happened! (Seriously, check the Usenet archives. It's a riot.)

No surprise, the developers are still less than competent. How on earth did this abomination get so popular? It's a complete mystery to me.

Or do you mean code written using jQuery? Now that's impossible to maintain! (For reasons mentioned earlier and later.) Add to it that jQuery code is mostly written by amateurs who don't know any better (or professionals that don't want to face the simple fact that JavaScript is not C# and they'll need to learn some new concepts). When you see jQuery, you can safely assume that the code is a mess anyway.

Provides a consistent experience across most browsers and gracefully falls back when browsers don't provide native solutions.

Nonsense. jQuery has *never* been cross-browser -- and never really did well across the few browsers it claimed to support! The word "consistent" is a bad joke. when paired with "jQuery". How long has it been around now? It still doesn't have a stable API!

Oh, and did you hear? They're dropping support for IE8 and below. Not that it did a great job of supporting those browsers anyway, but it's yet another reason that jQuery has LONG outlived its utility.

If it was you wouldn't see it on nearly every website more complicated than "hi my name is

See my earlier post. Take the challenge and see how various websites actually use jQuery. If you're not completely disgusted, I can't help you.

Here's why see jQuery used everywhere: JavaScript is difficult to learn. Well, that's not quite right. It's really easy, actually, but it's not at all like Java, C#, or any other popular language. It just looks a lot like popular languages. That causes a lot of confusion from developers who are used to picking a new language by reading a few code samples and hitting google a few times. You simply can't learn JavaScript that way.

jQuery came with false promises like cross-browser compatibility and a myth of ease-of-use. Developers who never touched JavaScript before took jQuery as an "easy way out" -- never mind that none of the promises it made were ever true, that's what they were told and that's what they believed. They were told that JavaScript is difficult or full of pitfalls. That wasn't true, of course, it's just that the language was so different from what developers were used to from language's with similar syntax that they made those assumptions.

The ONLY reason you see jQuery used today is that those same developers never bothered to learn JavaScript. They assume jQuery saves them time and effort (it does not, it costs them time both early and in the long term) because that's what they were told years ago.

They recommend it over vanilla JavaScript not because it's better (they don't actually know, having never learned enough JS to comment!) but because it's what they know.

It's as simple as that. All because there's so much more to JavaScript than meets the eye. Fortunately, developers are starting to realize that they've been fooled and are actually starting to learn JavaScript. I thank the recent popular discovery of SICP and new features in C#. With any luck, by 2015 we might not have jQuery bogging down the web.

Comment Re:That's just not a viable option. (Score 1, Insightful) 407

It's pretty well-known that jQuery is an absolute mess. A lot of effort has gone in to improving it, sure, but that sort of makes the point, doesn't it? Take a look through the code yourself. It still isn't pretty.

To call it "memory-lite" is just absurd. (Get a profiler and run some tests if you have trouble believing that.)

It's also hard to argue that a complex generalized solution to some problem will be faster than one written with a specific case or set of cases in mind. The abysmal performance of jQuery for even simple operations is evidence enough of that. (See any one of a zillion tests, or run a few of your own if you can't find one to your liking and you'll see what I mean.)

jQuery isn't stellar, obviously, but it makes jQuery UI and jQuery Mobile look positively light-weight in comparison! jQuery has often been blamed for PhoneGap's performance problems. Again, this is something you can see for yourself.

Even the most ardent jQuery fan will acknowledge that jQuery (expecially jQuery UI and Mobile) is a performance killer, they'll just say "it doesn't matter because computers are getting faster every year" or something equally silly in defense of their favorite library. To claim that jQuery is actually *faster* than a native solution is just crazy.

Just for fun

Comment Re:That's just not a viable option. (Score 0) 407

Sure, I could write native applications for every device listed under the supported devices section, but why is it smart to do that when I can write a single codebase that I can package for multiple devices?

Here's what you don't realize: You don't need a giant library or framework to do that. If you know what you're doing (and it doesn't take much knowledge or skill) you can deploy your mobile app across various platforms and devices from a single codebase -- without any platform or device specific code save what's necessary for packaging. You can effortlessly deploy from the same code base to BlackBerry, Android, and iOS -- no framework needed.

Now, if you want to use something like PhoneGap to make it easier to use features like accelerometers, gps, etc., that's much more reasonable. There's an actual benefit to libraries that offer specific functionality (three.js, for example). You'll find, however, that things like jQuery mobile *will* kill your performance.

Comment Re:How about giving some examples, son? (Score 1, Insightful) 407

I clicked on the first link and scrolled a down a bit.

The answer appears to be "most of them" and "most of the remainder if you know how to write for loop".

Like I said earlier: do the web a favor and just learn JavaScript.

You'll find that it's not only easier, but your code will be significantly faster. If you're dropping jQuery, you'll find that your code is also significantly easier to read and maintain. No need to make giant chains just to get your performance from "horrible" to "terrible" -- you get "acceptable" automatically, and "good" or "fantastic" once you have a better understanding of the language.

Yeah, we know about document.querySelector()

Apparently not. Take a look around the web. You'll find that the bulk of jQuery use can be replaced by querySelector and querySelectorAll -- often just by getElementById and getElementsByClassName.

Really, I've seen lot's of sites and code samples that use jQuery just to select a single element by id! All because the author either didn't know about getElementById or was too lazy to type it out. It's horrifying.

There are other stupid uses as well. Dropdown menus built with jQuery, like the popular superFish menu. What makes this particularly crazy is that it's trivial to build a dropdown menu without jQuery, or any JavaScript code at all! All you need is a little CSS. (Just a few lines, as it turns out.) If you don't have the 10 minutes it takes to figure it out yourself the first time, there are several websites that will generate a cross-browser pure CSS dropdown menu for you with just a few simple clicks!

Comment Re:That's just not a viable option. (Score 0, Troll) 407

Since JavaScript is so damn lacking, those libraries are ESSENTIAL for anything beyond the smallest JavaScript app.

That's because you're not familiar with JavaScript. Remember: all those "essential" libraries are written in JavaScript. You'll find that tons of features in those bloated libraries are just useless wrappers!

It's not 2006 any more. If you're still using jQuery, or some other goofy library, you're just wasting everyone's time.

You'll find that just about every feature your "essential" library provides has a native equivalent that works across browsers -- even as far back as IE 8.

Do the web a favor and just learn JavaScript. You'll find that it's more than capable. Your users will undoubtedly appreciate the performance boost!

Slashdot Top Deals

The only possible interpretation of any research whatever in the `social sciences' is: some do, some don't. -- Ernest Rutherford

Working...