Hacker News new | comments | ask | show | jobs | submit login

Oh, you just want to add a class to the element? \adds whole jQuery\ That's what's wrong with the web.

Oh, and you need a loop? \adds underscore.js\




Well, not that adding the whole of underscore.js is reasonable, but maybe if Javascript had provided proper enumeration of their data structures earlier like all decent programming languages do, that wouldn't be an issue.

To this day, you still can't enumerate an object literal, yielding each key/value pair. You still can't properly enumerate a NodeList and Object.values is still "experimental technology".

I understand that people just abuse libraries in and out, but come on, let's not forget the reason those humongous libraries exist in the first place (and why they're having success success), it's because JS has long been crippled in terms of abstractions and people needed something to alleviate the pain.

EDIT #1: Regarding enumeration of object literals, it turns out it's actually possible, though Object.entries is still marked as "experimental" and returns an array of [key, value] pairs, as arrays, which doesn't exactly scream great design. I just wish I could do something like someObject.forEach(function(key, value) {}) (and same for map, reduce, filter, some, every, etc).

EDIT #2: The latter in my previous edit is actually possible if you're willing to create a Map from Object.entries, which you can call forEach on. Quite convoluted, but possible, so my bad.


Yeah, there will be Object.keys/Object.values/Object.entries and you can use it in an for of loop.

for (let [key, value] of Object.entries({a: 1})) { console.log(key, value); }


var obj = {...}

// native JavaScript

Object.keys(obj).forEach(function(key){ console.log('obj.', key, ' = ', obj[key]) })

// Lodash

_.forEach(obj, function(value, key) { console.log('obj.', key, ' = ', value) })

Object.keys(obj) creates an array that contains the keys of the object, which makes it pretty trivial to call filter, map, reduce, etc. And getting the value from an object's key is also pretty straightforward...


Ruby: obj.each{|k,v| ...}

Sure you can do it in JS, but calling Object.keys then forEach (in whose closure you'll still have to reference obj[key] by the way) still doesn't feel optimal.


In which case, if you really can't live without it, just attach it to the prototype.

Object.prototype.each = function(k,v){ //... }


I would argue that automatically adding methods to a user-created object isn't optimal either.


Element.classList doesn't work in IE9 or below.

Array.forEach doesn't work in IE8 or below.

Fetch API for ajax isn't in any version of IE or Safari, or any mobile browser apart from Chrome for Android.

And so on.

It's not so much that front end devs are lazy, but more a case that building a set of polyfills for each and every browser support problem is actually hard. "just use jQuery" gets around the problem. I think most developers want to write better code, but most projects don't have the development bandwidth for them to do things better.


It would help if the basic javascript api's were even vaguely useful

I recently tried to force myself not to use any libraries for a simple site. After a while I realised I had so much re-invention of stuff (AJAX in particular is madness without a library) that I ended up adding Zepto

With all the crap they're adding in ES6 you would have hoped they would add an ajax function at least


it's called the "fetch" API. Not sure if it's in ES6


ah awesome.

Now we just have to wait 5+years until it has 95% browser share :)


Neither XMLHttpRequest, nor the Fetch API mentioned in a sibling comment are part of the JavaScript language. They are both web platform specs maintained by the WHATWG. The JavaScript committee (TC39) does not control these platform APIs.


A lack of skills, a low barrier to entry and low budgets are causing this.

I hoped with page performance becoming a ranking factor, this would change, if only for a tiny bit. But I see very slow brand websites still ranked higher then the highly optimized indie website, so that didn't work.


The community is the worst. The adds whole jQuery comes from every single js topic on SO in the past five+ years being answered by "just use jquery". Many times they are not even web related at all.

> "How do you do something in javascript?"

> "With jQuery you do it like this..."

I had the worst time ever when I had to work with jscript. I really wonder if my dislike of the language comes from the language itself or the community around it.


A long time the web was like this:

In IE6, you do it like this.

In IE8, you do it like this.

In Firefox, you do it like this.

Then jQuery came along. And it was like 'Now you do it like this, and jQuery handles it for all browsers perfectly'.

Just because some tasks are now performed easily in native javascript on all browsers, doesn't mean it was always that way.


There are lots of legitimate reasons to not use jQuery. Not being in a browser might be one of them. So if someone asks about javascript, one should answer the question (and perhaps suggest that there are libraries such as jquery that handle it better).


SO feels more like a race to answer fast rather than to answer with quality. I think the best way to learn about the language is through the Mozilla Developer Network. I can't speak for everyone but I feel incredibly productive when programming in javascript.

I'd argue that jQuery was great, but now most (if not all) of it can be replaced by native javascript features (e.g. document.querySelector). Today I wouldn't recommend jQuery to anyone.

I suggest learning a functional language (in my case it was Haskell) in parallel, as it opens up new ways of thinking about javascript and problem solving.


correct! reminds me of: http://i.stack.imgur.com/ssRUr.gif

I think SO has gotten a little better about this, but not much, IME


Imagine how fast the web would be if browser manufacturers could "approve" frameworks, and store them as a "standard library" of sorts. A global cache. Then you have ONE copy of jQuery for all sites on your machine.

Wanting to use a framework shouldn't be discouraged. The issue here isn't developers trying to save time, the issue is the shitty tools.


Yeah, javascript historically lacks a stdlib and now it's so big that nobody could probably agree on one. Chalk another one for "the road to hell is paved with good intentions".


Look how long it took for browsers to kinda agree on how to interpret Javascript and HTML. Do you really want to add another way for browsers to behave differently?


This is basically what [Decentraleyes](https://github.com/Synzvato/decentraleyes) does. It helps especially on mobile, though it's not exactly life-changing IME.


I wish this could be possible.

Eventually you'll have to track every minor version of every library when not every site stays up to date. At that point it's (almost) effectively a CDN.


I totally agree - I love raw JS too, and I hate seeing underscore used instead of stdlib - but the stdlib and DOM API has been getting better very slowly:

- element.classList is relatively recent

- NodeLists still don't have .forEach()

- string.includes() and array.includes() was only added in ES6 and ES7

- As of a Chrome 50 a few weeks ago you can now see the values inside FormData.


jQuery is not that large and very likely to be cached an a users machine. So, it's IMO disingenuous to harp on it.

If your playing with larger and less 'standard' library's then that's a different story.


There are approximately 5 million different CDNs hosting different versions of jQuery. Cache hits are actually quite low.


I have a small website that uses jQuery, but I by default point to the Google-hosted version (with a fallback to my own site if that fails), but I also use an older version that's a little over half the size of the current version.

What I'd like to see, however, is a way of trimming down jQuery to only include the functions I actually use. I only use two functions out of the whole library IIRC, so I really don't need to load the whole thing. Maybe one day when I have some spare time and other projects out of the way I'll try stripping those functions out of jQuery and just hosting them locally.


Three popular ones is not "approximately 5 million": Google, cdnjs, MaxCDN.


even the sites using one of these 3 CDNs probably specify aa specific minor version of jQuery from this list http://code.jquery.com/jquery/

(OK, so I doubt many sites are specifying the beta or uncompressed versions, but there's still a pretty good chance that somebody hasn't downloaded the relevant version from the relevant CDN recently enough for it to be in their cache, especially if they're browsing on their phone)


Source? And even then it's ~83KB vs the average page of ~2250K.


If instead of JavaScript a more fitting domain language was used for scripting web apps, this would be less of an issue.


I am not JS dev, but... At this point there should be tree shaking / dead code removal for JS widely deployed. Why it is not? I know that dynamic nature of JS causes some of it, but most code out there is not that dynamic. How good is Google's Closure compiler?


rollupjs.org as well as webpack2 are doing this. As you said, the dynamic nature will prevent this from being native. Using a build tool isn't terrible though.


These days, for simple interactions, youmightnotneedjquery.com is a good resource for those trying to curb that sort of behavior.

On the framework end of the spectrum, we have efforts like Mithril.js that try to provide a minimalist set of tools for more ambitious web applications.

So all is not lost :)


I don't think jQuery is the problem. jQuery is not 1.2 MB. It's not even 0.1 MB.


But shouldn't the browser have those libraries cached?


Given the number of combination of CDNs and jQuery versions out there I'm guessing the chances of already having the 'right' jQuery in cache the first time you visit a site is quite low. Would be interesting to see some numbers though.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: