Comment Re:How about giving some examples, son? (Score 1) 407
Sadly, the best you can do is get them to drop down. At least it takes very little JavaScript to make your CSS menus work on touch screens, and less code is always a good thing.
Sadly, the best you can do is get them to drop down. At least it takes very little JavaScript to make your CSS menus work on touch screens, and less code is always a good thing.
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.
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.
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.
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!
Learning a flaky, inconsistent language
JavaScript is "flaky" and "inconsistent"?
What on earth are you talking about?
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!
Not quite what I meant -- see my other reply. Apparently I can't communicate ideas today.
So does using the "but everyone else is doing it" argument.
That's not the argument I'm making
PHP is ubiquitous. That's certainly an advantage as far as maintaining it's share of the web. However, that didn't happen overnight. PHP is ubiquitous today because it did the job it was designed to do better than competing languages. This is still true today, as evidenced by several "superior" fad-languages failing to gain any ground. If PHP was garbage that no professional would touch, it couldn't have possibility achieved such an astonishing share!
You can criticize any language you want. With enough effort, you can make C appear to be the worst language ever improperly designed. (Just poke around the usenet archives and you'll see what I mean.) PHP has it's share of warts, no question, but it's not the worthless pile of garbage that language snobs have made it out to be.
Really the biggest problem with PHP is not the language itself, however, it's all the bad information out there about how to use it.
You'll find that's true of all popular programming languages. (You should see the nonsense out there about JavaScript -- written by respected professionals!) Though I'll admit that it might be a bit worse for PHP due to the large number of beginners the language attracts due to it's astonishing ease-of-use.
Really, I think that ease-of-use is exactly why we see so many "PHP is garbage" comments on forms like this. Developers are (undeservedly) considered by the general public to be brilliant-- a bit like MD's. The difference, of course, is that anyone can become a computer programmer in their spare time -- even children. Hell, I'll bet that the majority of Slashdot users were writing games for their home micro before the age of 12. It's an easy skill to learn -- and everyone developer knows it. Being insecure, the last thing they want is some easy language out there that's easy to learn and use. If their little secret got out, no one would think they were brilliant! They'd just be another nobody -- their worst fear!
Languages like PHP are a huge threat to those insecure developers. I'm not surprised that they bash it at every opportunity.
Yeah, only idiots use PHP -- that's why it's only used by 80% of the web.
Language snobbery benefits no one. Unless you're Chuck Moore, it also makes you look like an idiot who can't form their own opinions.
Indeed. GOTO is not inherently evil. You'll find it used appropriately in some surprising places -- including the Linux Kernel.
When describing a process, the oft-maligned GOTO certainly comes in handy. The over 30 crowd might remember seeing GOTO's in any number of guide books from auto repair to taxes. (The word wasn't always used, sometimes "skip to
That's right: GOTO can actually make things easier to read and understand.
Even in software today, I'm willing to bet even the most ardent anti-GOT zealot has used a GOTO -- and recently at that -- cleverly disguised as a break or return statement.
You claim OOP isn't defined when it is
No, I said that there was no consensus on the definition. That is true. Indeed, it's indisputable! You seem to like wikipedia, so you can check there. I did a quick google seach for you and found a few neat discussions that may be helpful for you.
, you claim it's just how closures work and C# works the same whilst demonstrating how Microsoft have fixed the very problem because it is a language problem
Pay attention. Microsoft changed how foreach works, not how for works. Your example deals with for loops. You'll find that my statement is correct.
Additionally, you should consider what a similar "fix" for the non-problem in for loops would entail, and why the behavior of for remains the same.
That's all irrelevant, however, as the problem the poster had in the example you gave was a simple misunderstanding of how closures work. It's not a language design issue.
the fact you're entirely unaware of the problems in it's equality operators shows how painfully little knowledge you have.
Pray tell, then. What are the problems? (I've explained why NaN!=NaN already. See IEEE 754 if you forgot) If you're talking about things like intransitive equality, you're just confused. You'll find identical behavior in virtually every other language. Not just those with dynamic typing -- recreate the examples you found in some blog post in Java or C, applying relevant type casts. Look at that! The behavior is the same!
Now, you're welcome to list which type conversions you find irrational, though once you look, you'll find they're all perfectly sane. It behaves exactly as you would expect from experience with your exemplar languages.
you don't understand why unnecessarily verbose code leads to more bugs
Check my post again. I agreed with that specifically. I also challenged you on Java (one of your exemplars) as it is unnecessarily verbose! JavaScript and PHP are positively terse in comparison.
I will offer, for your consideration, that unnecessarily terse code also is less readable, often leading to more bugs and making maintenance difficult.
Moving on. I find it odd that in response to evidence that directly contradicts your claims, and which support my own, you offer only bold assertion.
I asked you some very simple questions so that you could make a stronger case. (Well, to let you actually make a case!) If I'm wrong about something, I like to know. I'm disappointed that you'd rather insult me than actually discuss the issues.
This whole dialog started with your objection to some simple advice I offered another user: don't use JavaScript like it's a class-based OO language. I still don't know why you found that unreasonable, as JavaScript is prototype-based. (There's a paper you might find instructive here: D. Ungar & R. B. Smith (1987) "Self: The Power of Simplicity", OOPSLA '87 Conference Proceedings, pp. 227-241)
Anyhow, with this post I've left you with some reading and experimenting to do. Give it a go and let me know the results. I expect that you'll be unpleasantly surprised.
No it isn't indisputable fact, and where it's "established" in literature that literate is rather old and dated
So we should toss out relativity and quantum mechanics as well, eh? (Old doesn't mean invalid.) Put that ACM DL subscription to good use. You shouldn't have too much trouble finding more modern if that's important to you.
The arguments made a bit more sense when keywords like protected weren't implemented, or were implemented poorly
Again, you don't understand the problem. It's a fundamental problem, not something that can be fixed by adding a few language features!
Compare and contrast this to the original argument that Javascript does not properly implement OO and is badly designed as a result
A couple things: 1) There is no such thing as "proper" OOP. There is no consensus on the definition. 2) You have not established that JavaScript "does not properly implement OO" As I explained earlier, it's prototype based, not class based -- like several other languages. It's not bad simply because you don't like it.
I've explained twice why inheritance doesn't inherently have to break encapsulation in well designed languages
The problem is that your explanations don't actually address the issue at all! Again, it's fundamental -- this is very well established in the literature. It's not magically changed simply because a book you found on wikipedia and the paper I offered were older. Put that ACM DL subscription to use and find something to make your case -- you'll find that it's indisputable: Inheritance breaks encapsulation.
An example of a design flaw is PHP's === equality operator not working consistently and it's == operator not being transitive. There's not excuse for this
Assuming you're talking about the NaN thing from before, you'll find that it's a natural consequence of IEEE 754 -- and that that behavior is correct and expected in all languages. (Seriously, it's in the damn standard.) If you're speeking more generally, you'll find that PHP's == and === operators do indeed work consistently, behaving like similar dynamically typed languages. (Go ahead and try out some of the examples you found of "inconsistency" online in C, with explicit casts and you'll find the behavior is identical. Don't like C? The same will hold for Java as well.)
One language is better than another if it has less design flaws
That's not an answer to the question. What are these "design flaws"? How can they be identified?
The required additional syntax to create a new scope to make this work is nonsensical and a result of the lack of foresight in the language's design
No, the problem was that the stackoverflow posted doesn't understand closures. You'll find the EXACT same behavior in C# -- one of your exemplar languages. In fact, this confusion over closures lead Microsoft to change the behavior of foreach loops!
It's not an issue of language design, it's just how closures work. (Imagine how bizarre and unexpected the behavior of for loops would be if MS decided to change their behavior to match that of foreach!)
Surely you must at very least understand that simplified and more readable syntax to solve an identical problem is both better for developer efficiency and is better for supporting less buggy software.
Readability is important. I couldn't agree more. However, in the example you gave, C# behaves just like JavaScript. It's not a language design problem. It's not a problem at all. It's just how closures work.
I hope you can finally grasp why unnecessarily verbose code to solve simple problems resulting from lack of foresight during language design is a bad thing.
Now we've got to the meat. Is this what constitutes bad design in your eyes? Simply unnecessarily verbose code to solve simple problems? Should we all switch to Forth? Java is particularly verbose -- is it badly designed? You held it up earlier as an exemplar.
That's a relief. I was worried about lamp-wielding caddies terrorizing the back nine.
"Conversion, fastidious Goddess, loves blood better than brick, and feasts most subtly on the human will." -- Virginia Woolf, "Mrs. Dalloway"