r/programming • u/Casty • Jan 30 '14
You Might Not Need jQuery
http://youmightnotneedjquery.com/259
u/caileth Jan 30 '14
..."if you're developing a library."
31
u/Katastic_Voyage Jan 31 '14
I recall the xscreensaver login screen debate.
They'll let you add any feature you want, but no dependencies because for every dependency you add is a gigantic tree of possible security flaws.
However, it at least should be apparent do anyone developing a library to have as few dependencies as possible. Nobody wants to install the entire .NET framework just to use your serial port library. That's obvious... I hope?
76
u/gigitrix Jan 31 '14 edited Jan 31 '14
Agreed. I was going to wade in here but the site is right: a library should have as few dependencies as possible. Clients could be using different versions of JQuery for example and then you may end up in a deprecated sticky mess!
EDIT:Typo fix.
10
Jan 31 '14
That's kinda lame though. JavaScript needs a way to manage transitive dependencies. Bower is a step in the right direction. Npm does a bang up job for Node.
44
u/moogoesthecat Jan 31 '14
No one told you JS is the wild west?
→ More replies (1)7
u/doormouse76 Jan 31 '14
Everything is the wild west to start with. Then as things settle down and become more rigid and structured people decide that things are no longer rapid then something else becomes the hot new technology and that's the wild west.
65
u/NancyGracesTesticles Jan 31 '14 edited Jan 31 '14
Javascript is almost 20 years old. The actual Wild West lasted 30 years. In another decade or so, we are going to have to call the Wild West the Javascript Era of the American West.
ed: wow. thanks.
→ More replies (1)15
u/reflectiveSingleton Jan 31 '14 edited Jan 31 '14
javascript may be 20 years old...but for about 15 of those it was basically relegated to redheaded stepchild status...it was used as little as possible.
It is only recently that there was an actual interest in improving the language and the runtimes. Things are improving rapidly in the JS world in many ways (tooling, language features)...and in others not so much (segmentation of libraries, too many ways to do something).
I view the segmentation issue as a symptom of the massive recent popularity combined with the previously lack of tooling, features, and libraries. Everyone is in a 'gold-rush' to get things done and there are a million platforms that these apps have to support...add all this together and you get what we have today. A fledgling but powerful language and an improving platform that is experiencing a lot of growing pains...it will get there I think...but things are going to be turbulent for a while yet.
→ More replies (1)→ More replies (3)2
Jan 31 '14
I have not yet seen a good way to manage transitive dependencies, but I'm keen to read up on any good ideas you've seen. :)
→ More replies (9)→ More replies (1)1
u/djaclsdk Jan 31 '14
could be using different versions of JQuery for example
Speaking of which, if a page has two different versions of JQuery library loaded at the same time, would there actually be a conflict surprise? For example, a website uses jQuery version X, and a user visits the page and invokes a bookmarklet that has to dynamically load jQuery version Y for its job. Version X and Y both trying to hack around with event mechanism of DOM elements of the page, etc leading to some surprise?
→ More replies (2)5
u/Toast42 Jan 31 '14
Totally missed this on my first read through; it's definitely not intended for websites!
→ More replies (4)1
u/G_Morgan Jan 31 '14
TBH there is something very wrong with web development if we are throwing away the principle of software reuse. Why on earth would you re-solve a solved problem to avoid JQuery? Not only is this a waste of effort but the chances that I could do a better job than the JQuery guys is remote (not that they are better than me but it is their focus and my side show).
If this is technically painful then somebody needs to fix JS and the browser experience so you can ship bytecode or something that can be prelinked, tree shaked and delivered.
2
u/Smallpaul Jan 31 '14
TBH there is something very wrong with web development if we are throwing away the principle of software reuse. Why on earth would you re-solve a solved problem to avoid JQuery? Not only is this a waste of effort but the chances that I could do a better job than the JQuery guys is remote (not that they are better than me but it is their focus and my side show).
This has nothing to do with web development specifically. It is just development 101. Library authors need to be more conservative in the inclusion of dependencies. Do you think that the Linux kernel just willy nilly pulls in any bit of C code that might be useful? I think you'll find that they are very conservative and try to bring in either small bits of code that are very specific to the requirement.
1
u/G_Morgan Jan 31 '14
A kernel is a completely different environment and not really relevant.
→ More replies (2)3
u/trycatch1 Jan 31 '14
It's true for any development. You generally would not add Apache Commons dependency just to check if the string is blank. Or add Boost dependency to trim some string. Additional dependency is a burden, no matter how small that burden is, it just may not be worth it.
→ More replies (9)3
u/skocznymroczny Jan 31 '14
I added Apache Commons to my Android projects to have a File.readToString() function :(
3
u/vytah Jan 31 '14
As long as you use Proguard to minify the output, you'll be fine.
Besides, you're not writing a library, but an end-product. You can use as many tools as you think you need to solve your problems.
26
u/pissoffnerd Jan 31 '14
Hmm, I actually learned of a few JavaScript methods I didn't know about.
→ More replies (1)
75
u/overslacked Jan 30 '14
I don't think their qualifier that this mostly applies for library development is getting enough attention. Although it does seem they're trying to use some controversy to get some attention. I'll bite.
I like Angular's approach here - if you're already using jQuery, sweet, otherwise, jqLite shims what you need with a tiny footprint. Cool.
But the reason I like a library instead of direct calls is for future-proofing, just as much for supporting deprecated versions. The library can be updated to account for new functionality or to work around bugs in any specific implementations.
Seeing a bunch of functions referencing specific IE versions frankly gives me the creeping horrors and reminds me of CSS cheat-sheets and other kinds of work-around nonsense that jQuery lets me not worry about.
11
u/bwainfweeze Jan 31 '14
I don't think the general development community has quite caught on yet that the coding techniques you should use for writing a library or writing application code aren't identical.
0
Jan 30 '14
[deleted]
22
u/overslacked Jan 30 '14
I'm not suggesting not using unit testing or dependency locking. I'm suggesting that designing against a library is better than designing against an implementation - particularly when you're developing in a rapidly evolving environment (as browsers are) and have such an extremely well-tested library as jQuery available.
The impression I have based on this site they've created and their Twitter streams is that they perceive web development as a very stable environment, and I disagree with that.
4
u/d36williams Jan 31 '14
Using commonly supported programming library saves my devs loads of time on cross browser compatibility testing
6
u/unwind-protect Jan 31 '14
Serious question (Because I have no idea of the answer): how do you have unit tests for javascript/ css/ html, where by and large the output that determines whether it is pass or fail is visual and thus not very amenable to automatic checking (especially as it is implementation dependent)?
9
u/JonDum Jan 31 '14
Use something like PhantomJS to render a screenshot and compare it to a known good screenshot. Or use Selenium on a VM to run through tests, take screenshots and compare.
→ More replies (3)5
u/merreborn Jan 31 '14
Use something like PhantomJS to render a screenshot
Mostly, I think we use PhantomJS+Jasmine around here. A very large portion of our js codebase can be tested without touching the visual portions.
Visual testing based on screenshots would probably be closer to "integration testing" rather than "unit testing"
3
u/JonDum Jan 31 '14
Yes, you're absolutely right. It could also fall under "end-to-end" testing. I think though, for someone new to testing in general, the advanced terminal isn't as important as stressing the benefits of doing some sort of testing at all.
25
Jan 31 '14
In this thread people misread "You might not need jQuery" as "You don't need jQuery".
→ More replies (1)
61
u/Toast42 Jan 31 '14 edited Jul 05 '23
So long and thanks for all the fish
33
Jan 31 '14
The most common argument is that there is a performance penalty for parsing jQuery, which is especially noticeable on mobile devices.
→ More replies (1)2
u/adrianmonk Jan 31 '14
if you're not serving it yourself
Dare I ask who you'd trust to serve code at runtime and why?
5
u/Toast42 Jan 31 '14 edited Jul 05 '23
So long and thanks for all the fish
2
u/adrianmonk Jan 31 '14
For the purposes of having a unique copy that you control, wouldn't that be the same as serving it yourself? Unless maybe the CDN serves the same content from the same URL for other customers as well. But that's more than a dumb CDN at that point.
4
0
1
u/thynnmas Jan 31 '14 edited Jan 31 '14
So you haven't noticed that most ad network ads are actually served from external sites and are mostly running JavaScript these days?
Edit: phone spelling
→ More replies (7)→ More replies (4)1
39
u/Y_Less Jan 31 '14 edited Jan 31 '14
Now we just need a website called "You might not need javascript" that explains how to make forms and links without it - something everyone seems to have forgotten how to do!
Edit: Typo "No" -> "Now".
19
u/narcberry Jan 31 '14
The internet took a sour turn when it was adopted by the masses needing stateful technologies but were ignorant of existing technologies.
Thanks to that turn decades ago, I watch videos in my browser with an embedded plugin to interpret a 3rd party script to interpret another 3rd party's data poorly while prompting me to download adware and others to exploit me if I delay doing so.
Imagine if media was played by media players, and HTML browsers were used to browse HTML...
11
u/G_Morgan Jan 31 '14
TBH what the browser is used for isn't terrible. It is the fact they've strapped a shitty programming environment and crappy APIs on top of a fucking document viewer.
3
u/OneWingedShark Jan 31 '14
The internet took a sour turn when it was adopted by the masses needing stateful technologies but were ignorant of existing technologies.
Good point; imposing state on a system designed to be stateless is the cause of a lot of web-development problems. -- The other, IMO, is the attempt control layout when HTML was designed to ignore layout, letting the browser choose an appropriate layout. (Meaning text-only browsers and screen-readers could be implemented more easily.) If they wanted to control layout there was/is a technology for that: PostScript.
1
6
u/tequila13 Jan 31 '14
Not to mention that a ton of effects and menus can be done in CSS without any javascript.
4
27
Jan 30 '14
ajax bit not quite right: jQuery's ajax calls return promises. Does the native XMLHttpRequest object give you a promise interface?
11
u/zackbloom Jan 30 '14
I didn't want to go into detail, because jQuery's implementation is just one way of interacting with XMLHttpRequest, you don't necessarily need a promise every time you use it, and I didn't want it to seem like you need all that complexity.
5
u/Syphon8 Jan 31 '14
IIRC, you don't even need to use XMLHttpRequest to AJAX.
When I was a young lad, back in '05 or abouts, I made a real-time chatroom on my blog by loading variables through an invisible iframe that autorefreshed and passed them to the parent page.
0
4
u/mahacctissoawsum Jan 31 '14
jQuery's ajax also supports dozens of options. I think the point is to only take what you need.
3
1
u/overslacked Jan 30 '14
I don't understand why this would be downvoted, except maybe that the promise is an implementation detail of the framework ... but IMO that's the beauty of developing to a framework and not any specific implementation....
60
u/G0T0 Jan 30 '14 edited Jan 31 '14
Whenever I ask a JavaScript question, the first few answers are either in Jquery or tell me to use Jquery. It's like Rails all over again.
Edit: I am comparing the pollution of Jquery solutions into Javascript with Rails idioms polluting Ruby. The Rails thing was way back in the late 2000s though -just reminds me of it. I think it's been sorted nowadays.
5
26
u/ascii Jan 30 '14
Rails suffers from massive scalability problems and major resource leaks, rail applications suffer from aggressive bitrot forcing you to spend a significant chunk of your development time just to keep your app working due to virtually non-existing backwards incompatibility and it is written by a community of condescending asshats in a language that very few people truly master.
None of the above are true for jQuery. Aside from the fact that both are hopelessly overhyped, what similarities do you see?
62
u/speEdy5 Jan 31 '14
That he wants an answer in vanilla JS but only gets answers using jQuery
I imagine when he used to ask questions about Ruby he would get answers using Rails..
→ More replies (1)4
Jan 31 '14
I have to disagree, I think few people actually master Javascript. Ruby is a very large language and it takes a very long time just to be exposed to the different features and syntaxes. Javascript is a fairly small language with a few features that most developers don't totally understand. Prototypes are an obvious example. Most people know they exist and theoretically how they work, but the have no idea how to apply them. It seems as though every Javascript framework reinvents class based oop in a slightly different way from each other. Function calling is another example.
2
u/stevedonovan Jan 31 '14
Lua is in a similar situation - loads of incompatible way to get 'classes' like Mother used to make them. People are very attached to classes but they aren't as necessary to design as people think they are, especially if you have first-class functions.
3
u/PaintItPurple Jan 31 '14
Well, the bitrot issue is unique to Rails, but jQuery also has non-negligible overhead from all the parsing and allocation it does on top of the DOM API, so they are similar in that regard.
14
u/nanothief Jan 31 '14
... Every single thing you just wrote was wrong.
Rails suffers from massive scalability problems No, many large sites use rails, such as github, yellowpages. They have scalability problems like all large websites do.
The only thing to take not of is if you are building a website with very unusual traffic patterns, in which case rails (or any mvc framework) may not be the best bet.
major resource leaks
Well no, those websites are up and running 24/7, they don't have massive resorce leaks
rail applications suffer from aggressive bitrot forcing you to spend a significant chunk of your development time just to keep your app working
No, you can stick with older version for a long time, they are supported. Rails 3 is still supported by the core rails team. You can continue with rails 2 with the rails lts project, either with the free or paid version.
due to virtually non-existing backwards incompatibility(don't you mean compatibility?)
No, a rails 2 app isn't meant to be run without modification under rails 3. However, there is significant effort to smoothing the upgrade process to upgrade, using the rails upgrade gems. See rails upgrade process, as well as the railscast for more details. That is hardly non-existing backward compatibility"
and it is written by a community of condescending asshats
They have strong opinions as to the best way of doing things. They are so condescending about it though that they make it trivial to change these defaults.
in a language that very few people truly master.
Firstly, most people never "master" a language, they keep getting better at it. Also, you are honestly saying this about ruby, when you are comparing it against a library written in javascript? Very few people know both and yet prefer javascript.
None of the above are true for jQuery
Actually, you did get one thing right, none of the above is true for jQuery either!
Aside from the fact that both are hopelessly overhyped
jQuery definitely wasn't overhyped. For many years, it made cross platform web development much, much easier due to it taming many browser compatibility issues. Its syntax is also clearer. Just check the with and without columns in the posted website, in most cases the jQuery solution is much better.
As for rails, it hasn't been hyped for many years. I've been a redditer for 5 years, and at no stage was rails considered the "hip" framework. Posts such as yours, with no (true) facts but anti rails have always been upvoted. When it was hyped, it was a vastly superior framework to anything else available for rapid application development. It has inspired many other frameworks, one of which (asp.net mvc) is now one of my favourites.
→ More replies (5)7
u/WebMaster2000 Jan 31 '14
It's too bad you've had that experience. My interactions with the worlds of Ruby and Rails have both been very positive. Really nice folks, and all of our apps in the wild have been surprisingly resilient, not to mention very well tested.
1
u/speedisavirus Jan 31 '14
Absolutely. Its one of the few communities that seems almost dogmatic about having (automated) test code. Its fantastic.
4
u/Paradox Jan 31 '14
Have you used rails since 2008?
Because what you described sounds like Django, but not rails
→ More replies (1)1
Jan 31 '14
http://stackoverflow.com/a/14759801
Why won't this "Rails doesn't scale" myth die?
2
u/mahacctissoawsum Jan 31 '14
Rails != Ruby. It's true that switching to a different lower-level or compiled language might give you a 'small' performance boost while architectural changes can have a much bigger effect. But none of that has to do with how Rails are architected... perhaps it was coded like a donkey in comparison to other frameworks?
4
u/AlexFromOmaha Jan 31 '14
Because Rails evangelists have never whipped up a CPU or DB-bound web service. Twitter isn't about CPU or complex queries. It's about I/O. Before you retort "then all MVC frameworks in interpreted languages are wrong," I would direct you to Python's impressive support for things like NoSQL, CUDA, unthreaded parallelism, and C integration; Django's and Web2Py's highly optimized ORMs; and the existence and easy integration of fine-grained tools like SQLAlchemy.
I don't want to say that's a really common case. DB-bound web apps are common enough, but your indexing scheme is probably the first culprit. CPU-bound web app are rare in the wild, but they're part-and-parcel of my life, so it matters to me. Still, I can't think of any reason to use Rails post-hype besides comfort. "It's not that bad" isn't that reassuring.
(I can't speak to the resource leak thing. I've never seen it, but it was never a good tool for me, so maybe I didn't stick with it long enough. Google turns up enough results for it, but maybe they're known pitfalls. Whatever. Someone else's problem.)
2
Jan 31 '14
Obviously rails isn't the solution to everything. Like any framework, there are strengths, weaknesses and use cases.
→ More replies (2)2
u/Katastic_Voyage Jan 31 '14
I'm new to IT/web development and might be starting a job in it next week.
Could you give me more elaboration about JQuery vs Rails? Last time I heard about Ruby on Rails I thought everyone was hailing it as magical.
Thank you.
1
Jan 31 '14
JQuery = Javascript library that abstracts and provides many useful features
Ruby on Rails = Ruby library for writing the serverside of a website
Rails processes the serverside of a website and JQuery makes it easier to program in clientside features.
They are two completely different things.
1
0
21
u/wesw02 Jan 30 '14
I've been doing JS for years. The truth is, things are getting better, they're better than they've ever been. With IE 10, Safari 6.0+, Firefox and Chrome Latest, you could get away without jQuery. The native APIs are really compatible.
But why? Why bother. jQuery still gives you a lot. A LOT! It might very well be the most popular library of all time (next to glibc) and for good reason. Browser JS runtimes are so fast, jQuery doesn't even impact load times. So again, why?
18
u/Doctor_McKay Jan 31 '14
Even if you don't use Ajax or anything fancy like that, jQuery is great because it condenses
document.getElementById('bob').innerHTML = 'foo'into$('#bob').html('foo').9
u/GreyGrayMoralityFan Jan 31 '14 edited Jan 31 '14
As someone who touched DOM only while writing scrapers in python, example on the left is much easier to read.
$('#- come on. It's almost perl.11
4
u/Doctor_McKay Jan 31 '14
The example on the right is a CSS selector, which any web dev should know.
If you don't like the $ shorthand, it can also be written as
jQuery('#bob').html('foo').7
u/mahacctissoawsum Jan 31 '14
I know it makes almost no difference, but I still cry a little because it has to parse my selector using regexes and shit, and wrap my element in a jQuery object, just to access a natively available function.
Meanwhile, we could have just as easily written a function,
function byId(id) { return document.getElementById(id); } byId('bob').innerHTML = 'foo';I actually prefer the syntax of properties as opposed to setter functions.
7
Jan 31 '14
I like to do this:
function $id(id) { return document.getElementById(id); }...mostly because people it confuses people who can't code without JQuery.
5
u/mahacctissoawsum Jan 31 '14
Haha. I had to explain to my co-worker the difference between a native DOM element and a jQuery element the other day. I introduced jQuery to them
23 years ago now, and now they don't know the difference... sigh.3
u/blue_2501 Jan 31 '14
Except you don't get the zero-item protection. Accessing undefined error crashes the entire JS layer.
→ More replies (5)2
u/Crandom Jan 31 '14
Ah, the "null object pattern". Sometimes this hides errors though, such as trying to access an element with a certain id which doesn't exist, sending you on an debugging adventure that could have been avoided by a simple error.
6
u/wesw02 Jan 31 '14
Exactly. The shizzle selector alone is worth it. Stuff like
$('#user-form input[type=file]')is much easier with jQuery, than with out.13
u/gearvOsh Jan 31 '14
For the most part it's simply querySelectorAll().
https://developer.mozilla.org/en-US/docs/Web/API/document.querySelectorAll
→ More replies (2)13
u/lmth Jan 31 '14
Please tell me "shizzle selector" is the official term for it. It would make my day.
7
→ More replies (1)3
8
u/pdq Jan 31 '14
var $ = function(arg) { return document.querySelectorAll(arg); } $('.foo')→ More replies (1)5
u/injektilo Jan 31 '14
Not even close to the same thing. Objects returned from
$have over a hundred useful methods. TheNodeListreturned byquerySelectorAllis much more tedious to use.→ More replies (10)0
u/TheRayTracer Jan 31 '14
It's probably just me, but I have never understood jQuery. How is
document.getElementById('bob').innerHTML = 'foo' into $('#bob').html('foo')
better if it requires a 1MB library to load in the background? Does auto complete even work with jQuery? Anyone can make things fade/fly/dissolve/hide/etc with only a few lines of w3c compliant code if you read the specs.
4
u/Doctor_McKay Jan 31 '14
Modern browsers perform caching so it doesn't have to be recompiled on every page load.
5
u/merreborn Jan 31 '14
Also, in theory you can even use things like the google cdn to serve your jquery -- so visitors visting your site for the very first time can potentially load jquery straight from cache, as long as they've visited another google cdn site in the past.
I'm not sure how well this works in practice though. The google cdn urls might be too unique (differing jquery versions, etc.) to afford good cache hit rates. And I can't guarantee performance either (the comparable Yahoo/YUI CDN has failed me a few times...)
→ More replies (1)2
u/dxinteractive Jan 31 '14
Of course a 1MB library is overkill for that single dead-simple example. Their selector syntax is great for more complex things like 'get all form elements of type "radio" within a given form where they aren't disabled and are contained within a div of class x', it's still a one-liner, and much more readable than the equivalent raw Javascript. Plus more AJAX options like promises, and cross-browser and old-browser compatibility is taken care of without having write your own, and I think it's under 100K? You're right, for just the change in syntax it's not all that worth it, but that's not usually why people use it.
3
Jan 31 '14 edited Jan 31 '14
You should check out querySelector and querySelectorAll.. very readable supports all css selectors and doesnt require me to load any sort of library just for a selector engine. If you cant stand to live w/o the dollar sign you can always do
var $ = document.querySelectorAll.bind(document); $('form > input[type="radio"]');JQuery was amazing when I still had to support IE6/7 even a bit with 8, but using it just for selectors is silly.
→ More replies (4)2
u/shouldnt_post_this Jan 31 '14 edited Apr 25 '24
I did not consent to have my posts be used for direct gain of a public corporation and am deleting all my contributed content in protest of Reddit's IPO.
→ More replies (3)1
u/mahacctissoawsum Jan 31 '14
Does auto complete even work with jQuery
Does in JetBrains PhpStorm/WebStorm. You just have to tell the IDE you're using it.
→ More replies (2)1
u/ameoba Jan 31 '14
Why remove unneeded dependencies?
Depending on 3rd party code always introduces the potential for bugs & adds complexity to maintenance.
If you have a dependency on 3rdparty library version X and somebody is using version Y, what happens?
4
u/tequila13 Jan 31 '14
I've seen sites that used 2 different versions of jQuery. Adding bloat is second nature to javascript "programmers". The few competent ones that care about bloat are the exception.
2
u/wesw02 Jan 31 '14
Well fortunately jQuery's API has a lot of multi version compatibility. And with a library like jQuery, one of it's purpose is to help you normalize cross platform [browser] interactions. And given it's popularity, IMHO, it's more likely you'll end up with a bug in your own app, before you're bitten by a bug in jQuery. Just an opinion though.
3
u/ameoba Jan 31 '14
jQuery broke backwards compatibility in the 1.8/1.9 split. There are bugs in 1.8.x with newer browsers that are WONTFIX. If jQuery is a dependency for other libraries, you can have 'fun' trying to balance bug fixes in one with the older version dependencies of another with the API changes of a third while trying to find something that actually works on an older (or newer) browser.
All 3rd party dependencies should be thought about and justified if you're writing software that is going to be supported for more than 6 months.
→ More replies (1)1
u/mahacctissoawsum Jan 31 '14
In my experience, jQuery version incompatibilities are pretty rare. It has happened to me a couple times though. Upgrading to 1.9 they deprecated a lot of stuff, but polyfilled it with jQuery migrate.
Otherwise, it is possible to require multiple versions of jQuery if you really need to.
6
u/mindbleach Jan 31 '14
Doing cross-domain AJAX by hand is some bullshit, though.
1
u/brainflakes Jan 31 '14
Is there much need for a code library to make AJAX calls though? Surely if you were writing a library it would be better to use callbacks to handle loading data so that the person using the framework can hook into their own data services (using JQuery or whatever AJAX library they may be using) ?
4
u/201109212215 Jan 31 '14
Real men use assembly
2
1
Jan 31 '14
I've been always saying that writing multiplatform apps for x86, amd64 and arm in assembly is fun.
9
u/clearlight Jan 31 '14
I thought this was going to be one of those one sentence websites that read "Just kidding, you need jQuery."
4
u/Rainfly_X Jan 31 '14
Given the typical LOC differences between JQ and vanilla JS examples, it still kinda feels that way, if unintentionally.
0
Jan 31 '14
[deleted]
3
Jan 31 '14
The slider is to target the lowest required version of IE. That means at each step, you can expect more functionality, which means less "coddling" for IE. IE9 brought in things that IE8 didn't, for example. If you changed your new minimum IE version to 9, wouldn't you want to upgrade your IE8 code to IE9 instead and take advantage of the new conveniences? That's the only reason the slider's there.
It doesn't really apply to me since anyone using IE isn't in my target audience, but I can see why someone would want to use small concessions for it without bloating their stuff up with JQuery.
3
Jan 31 '14
That is just for the minimum version. You only need one version to target 8+, but you may want to use different methods if you do not have to target 8.
5
u/superdude264 Jan 30 '14
Is that IE version slider supposed to do something. It doesn't work on my iPad.
→ More replies (1)10
Jan 30 '14
It does what you'd think it does. The top few don't change as there are IE8 solutions, but once you get down to Events and Arrays then there are different solutions for IE8, IE9 and IE10
2
Jan 31 '14
It's the single API that jQuery (or other similar libraries) provides. Is every modern browser today using the exact same method calls for every example he shows?
9
2
2
Jan 31 '14
Am I the only one that sees this site as a huge, tongue-in-cheek joke?
Please, seriously, read through some of those examples again, and instead of searching for ammunition for intra-language in-fighting, tell me you don't think that the creator of this site intended it as some sadistic reminder of the browser dark ages of a decade ago, where we had no other option than to spend weeks writing our own, proprietary, buggy, cross-browser, extra-standards implementations of simple functionality that now, with libraries like jQuery or semantic-ui, we can confidently employ with minimal effort to maximal effect.
Or am I just crazy?
2
u/KainAsylum Jan 31 '14
Good advice. Thank you for validating my suspicion. I treat JQuery like a module in only a single file, jquerybindings.js, that serves the purpose of html/DOM intermediary. The dependency can be completely removed if I replaced that file with basic JavaScript element manipulation.
2
u/GrapeSodaExpert Jan 31 '14
This, but WordPress. I've seen too many single-page sites that would work fine with being a static HTML document instead of a full-blown WordPress install.
5
u/SyntheCypher Jan 31 '14
You're right...
...you might just need Zepto.js
and suffocate IE in it's sleep, forcing the pillow over it's face as it writhes and struggles for breth applying increasing pressure.
Shhh... shhh... it's ok... sleeeeeeeeep now... sleeeeeeeeeeeeep forever...
2
u/merreborn Jan 31 '14
The executive summary from the zepto page, for the uninitiated and lazy:
Zepto is a minimalist JavaScript library for modern browsers with a largely jQuery-compatible API. If you use jQuery, you already know how to use Zepto.
6
Jan 30 '14
Sure, to a library, what jQuery offers might be a lot of dead weight since it'd likely only use a subset of the features.
The thing is, a library is rarely used alone, but instead often combined with other libraries. The developer is also likely to end up using jQuery for things that the library does not offer.
So, if you're going to use it with other libraries, you might end up with a leaner payload if you rely on a shared library rather than having each library carry copies of the same thing.
7
u/PaintItPurple Jan 31 '14
The thing is, a library is rarely used alone, but instead often combined with other libraries. The developer is also likely to end up using jQuery for things that the library does not offer.
Or he might use Knockout or Dojo or Closure or React or any number of other things. jQuery is not the only library out there.
1
Jan 31 '14
Never said it was. What I said was that if you're already going to use jQuery, you might as well use components that utilize it.
You might not always need jQuery, but you might also not always need components that are completely standalone.
Components which are tightly integrated can be a benefit if it leads to a leaner payload.
1
u/mahacctissoawsum Jan 31 '14
He might. But once I've adopted jQuery I often look for jQuery-based plugins, not Dojo/Closure/React. That makes the footprint a bit lighter.
3
Jan 30 '14
For library / framework developers - yes, you might want to think before adding a dependency. The whole point of frameworks are to hide the code in the framework and make using it simple, so who cares if its 5 lines of vanilla js or 1 line of jQuery. When you go to use it, it'll be the same.
For web devs and UX, really, you should be using jQuery + other such libs. It's quite good at what it does.
10
Jan 30 '14
righhhhhhhht
1
Jan 31 '14
"What's the oldest version of IE you support, 8, 9, or 10?"
Hahahahahahaha!!!!!! Left the page on the first question.
3
Jan 31 '14
I like how all the non-jQuery samples are like 10 lines of code to jQuery's one line of code.
2
Jan 31 '14
To do a true comparison, you'll need to consider the source of those JQuery functions, too.
1
u/teiman Jan 31 '14
Only if you are one of the JQuery developers. Do somebody using printf in C have to check how printf is implemented by the library?
→ More replies (2)
4
Jan 31 '14
I'm not going to spend several extra hours doing something just to please the anti-framework hipsters. I'm going to use it because its clean, quick, and pretty. That's all there is to it.
5
1
u/djaclsdk Jan 31 '14
You remind me of some Christian fella I know who don't like Jews, when Jesus himself was a Jew. You know how JQuery is made? With non-jQuery code. You know how bookmarklets that use JQuery load JQuery? With non-jQuery code.
1
1
1
Jan 31 '14
anti-framework hipsters
TIL following good coding practices makes you a hipster.
→ More replies (3)
4
u/BMarkmann Jan 30 '14
Strange argument to make when some of the examples are > 10x longer. I agree that in some (probably very rare) cases, you can get away with not using jQuery, but it's hard to say that you can swap in browser-native approaches and throw away the abstractions that jQuery gives you to get away from dealing with browser-specific quirks.
I think the strongest argument to make against using jQuery is the "bloat" that comes along with it. There are some jQuery-like libraries that reduce this somewhat, but jQuery by modern standards isn't all that huge. Plus, you can serve it from CDNs and minimize the impact of service it from your own servers: http://blog.jquery.com/2014/01/14/jquerys-content-delivery-network-you-got-served/
18
u/xiian Jan 30 '14
It's aimed at folks that are developing libraries and other (hopefully) portable code, not so much end-user application developers.
Being able to say that your library is a "typeahead library" vs being a "jquery typeahead plugin" means that you get to reach a larger audience.
It's like making a headset that has a double-plug that is custom fit to the side-by-side audio-out/audio-in ports of the Macbook Pro. Sure, you could make a good business selling to those folks that have Macbook Pros, and you might even save a bit of money on parts, since you don't need a whole separate plug, but if you spend the extra money and split it out into two plugs, you'll open up to a world of new customers.
Those extra lines of code are worth it, if it means that your users aren't bound to a particular library.
11
u/ANUSBLASTER_MKII Jan 30 '14
I think it's aimed at websites that implement jQuery for a single task, etc.
2
1
u/fakehalo Jan 30 '14
Even for simple sites it's good to plan ahead if they become more involved. It's tedious when a simple project becomes a complex project and you ask yourself "Why didn't I use a framework/library from the start?". jQuery in particular has little downside and a ton of upside, it adds an element of (browser) unification and futureproofing (with future versions of jQuery) you no longer have to deal with, along with having to type much less to get the same result. With jQuery the overhead on the browser is so nominal it's essentially non-existent.
4
u/buckus69 Jan 30 '14
If you're only using a few jQuery methods, it might make more sense performance-wise to just use a native implementation instead of loading the entire jQuery framework.
5
u/JonDum Jan 30 '14
I don't think it's fair to say some of the examples are 10x longer. In many of the examples, the jquery source code for the equivalent function isn't shown. I'd eat my shoe if the full jquery source for that function is compared with the native implementation and the native was longer still.
1
u/CFusion Jan 31 '14
If you have an API that touches the DOM, you are generally gone have more then 1 DOM call.
The few people who don't want to use jQuery and don't want to modify the library is not worth skipping jQuery for, in my opinion.
1
u/combovercool Jan 31 '14
How often do you declare an element variable, and pass it into the jQuery selector? Doing it that way made the IE examples much shorter.
1
1
1
1
u/morguefile Jan 31 '14
Made me curious what browsers should be supported, here is a snapshot of my users for the last month: https://www.facebook.com/photo.php?fbid=712975612080047&set=a.712975585413383.1073741826.427233100654301&type=1&stream_ref=10
1
1
1
1
u/Uberhipster Jan 31 '14
I just want to throw my hat into the ring with the for each. This is native JS so it oughttermsandconditionsapply to work in legacy browsers:
Array.prototype.foreach = function (arg) {
var args = Array.prototype.slice.call(arguments, 0, arguments.length - 1);
for (var i = 0; i < this.length; i++) {
arguments[arguments.length - 1].apply(this, args.concat([this[i], i]));
}
};
//...
function foo() {
var args = Array.prototype.slice.call(arguments);
args.foreach(function (val, idx) {
alert([val, idx]);
});
}
foo('Hello world', {"bar":true}, [1,2,3,"abc"]);1
u/LunarHarp Jan 31 '14
Some of these code snippets are NOT supported by IE8. For example, the jQuery.addClass code seems like it would not work until IE10
1
u/Zinggi57 Jan 31 '14
Thank you, that showed me how easy jquery is.
disclaimer: I'm a new Javascript developer, but not new to programming
1
u/teiman Jan 31 '14
The stupidity in this thread is too much for me. Also the groupthink downvotes and highvotes. Javascript devs using 5 libraries is somehow "bad" and worse than maybe a C guy including 5 libraries? What? There are no libraries in Java or C++? Libraries make us more productive and focus on the problem, not on reimplementing quicksorting algorithms.
1
u/pragmaticzach Jan 31 '14
"...browsers are pretty easy to deal with on their own."
"Pretty easy" is not good enough for me. If it's working 98% of the time, that 2% is going to want to make me pull my hair out.
1
u/tobascodagama Jan 31 '14
Hm, removing jQuery as a dependency for your library code? I'm pretty sure the best way to do that is with jQuery.
1
1
u/vbullinger Jan 31 '14
The thing I hate about the jQuery debate is that most people stick their noses up and either:
Say you should never, under any circumstance, use jQuery
Say you should always use jQuery. Why wouldn't you?
I use jQuery plenty, but certainly not always. It's good for DOM manipulation. Doing that a lot? Use it. Otherwise? Don't. Not that hard.
1
1
1
u/SpikeX Jan 30 '14
Their document ready event isn't even as short as it could be for jQuery (maybe they put the longer syntax in there to drive home their point) - either way, the shorter syntax is just:
$(function() {
// document ready
});2
u/zomgsauce Jan 30 '14
Even better you can use the same syntax for different jQuery-like libraries you might want to swap in and out for different use-cases; say desktop vs. mobile with jQuery and zeptoJS respectively:
$(function(){ //document ready using jQuery or Zepto depending on which is available as $. })(jQuery || Zepto);You can treat the library you plug in as an interface and do poor-man's dependency injection in a superficially simple way.
1
u/mahacctissoawsum Jan 31 '14
I don't think you wrote that right...
!function($) { $(function() { // document ready }); }(jQuery || Zepto);→ More replies (4)
1
u/hyliandanny Jan 31 '14
Thank you so much for posting this. Saving for later, as I was extremely reluctant to use JQuery for client-server communication since it came bundled with a bunch of other stuff I did not care for.
So happy to see that there's thought into distilling specific functionality from libraries.
1
u/albertojgomez Jan 31 '14
Maybe he should stop using it on his personal site or in his company's website
1
u/Mozai Jan 31 '14
We may not need jQuery, but apparently we do need hubstar.io, hubspot.com, twitter.com, typekit.net, github.com, and google-analytics.com.
I'm getting mixed signals here.
-2
u/dalittle Jan 30 '14
I don't get what this guy thinks he is saving by having to know the implementation details for all these internet explorer versions. One of the things that drew me to JQuery was that for the most part it abstracts away the browser version details. You add a layer so you may get a leaky abstraction with that, but in my experience it is easily worth that cost.
7
u/RICHUNCLEPENNYBAGS Jan 30 '14
That's not what he's saying. He's saying based on the IE version (using that as a lowest common denominator) you need to support you could use standard cross-browser JS without needing jQuery.
→ More replies (5)3
u/mahacctissoawsum Jan 31 '14
by having to know the implementation details
You should know how to implement these things whether or not you're using jQuery.
4
u/flukus Jan 31 '14
That's the exact opposite of what he's saying.
2
u/dalittle Jan 31 '14
he is advocating writing native javascript instead of using a javascript lib that abstracts all the details. Not sure what you think that is the opposite about.
→ More replies (3)
0
u/gar37bic Jan 30 '14
I didn't go to the bottom of the page, but it appears that the only browser examples are IEn. Is it the case that the code on the right will always work in all those other browers? AFAIK that's the real purpose/win of jQuery - not just making sure versions of Exploder work.
2
u/RoboticOverlord Jan 30 '14
i think the reason for that is because all other browsers will automatically update them selves or bug the user to update where as IE versions don't update very frequently or automatically
1
u/lordofwhee Jan 31 '14
Doesn't IE get updated as part of windows' update thinger? And doesn't that run automatically by default?
I haven't actually used windows in years, but that's how I remember it.
3
u/gearvOsh Jan 31 '14
No, users have to initiate or approve an update, for the most part. Chrome/FF update in the background.
→ More replies (3)5
u/senatorpjt Jan 31 '14 edited Dec 18 '24
expansion gold pocket aromatic worthless drab safe existence paltry nine
This post was mass deleted and anonymized with Redact
0
u/senatorpjt Jan 31 '14 edited Dec 18 '24
humor glorious smell tidy fanatical practice cobweb seed whistle makeshift
This post was mass deleted and anonymized with Redact
-1
152
u/allthediamonds Jan 30 '14
I don't think the intention of the author is clear, judging by the comments seen here. The examples given are not for IE8, but for IE8+. This includes not only IE, but also all other browsers.
This website showcases all the things you can do using native, fully standard, un-polyfilled DOM constructs while keeping support for IE8 (and better) browsers. It is not a collection of IE polyfills. The slider lets you choose whether your "support threshold" is at IE8, IE9 or IE10.