Hacker News new | ask | show | jobs
by monk_e_boy 3676 days ago
As a web dev for the last 15 years or so, this is amazing news. The browsers are finally getting to a point where the pain jQuery solved, is going away.
3 comments

Which means that in 10 years, that's true for enterprise software, too.
jQuery helps with browser quirks, though. Search the below file for the string "// Support" to see what I mean. Yes, there are a lot of entries for older browsers, but there are also a lot of entries for relatively recent browsers too.

https://github.com/jquery/jquery/blob/3.0.0-rc1/dist/jquery....

It does help with browser quirks, but if you aren't supporting <IE10, then you really don't need it. I've made it a point to pull out jQuery from every project I have. Nowadays, I can test in Chrome as I develop and then test any other browsers at the very end and I rarely have any browser specific bugs. Crazy how far web dev has come.
You do really need it, at least for me. I'd rather write $ sign calls instead of getElementByID or querySelector just to start with. The sizzle library in jQuery is so advanced, that you can't do complex queries on the dom yet with today's browser.
There are small libraries that help with making native DOM operations more jQuery-like. We opted just to write our own since we didn't need a good portion or even the smaller libraries.
the industry is moving away from direct DOM mutation and towards v-dom, so this isn't an issue for a lot of devs.
Reading the Jquery source code is fun. It seems like they're doing some really clever stuff there. For example, look at isEmptyObject in the code you linked.
What's the particular cleverness in that? It seems it would also fail for objects with non-enumerable properties and properties with ES6 Symbols for names.
Is this a legacy thing?

I'm a web dev for 10 years now and never used jQuery directly. (I used Ember for half a year, which seems to have jQuery as dependency)

If you've been a web dev for 10 years then you'll know that the most fundamental tool for scripting is a pain point (document ready), jQuery did a good job of abstracting the nuances away, see: http://stackoverflow.com/questions/799981/document-ready-equ...
And the incompatible ajax interfaces. And the inconsistent element selection. And the...

I'm also not sure I'd call document ready the most fundamental as a lot of people (including me) used to use onclick='' and onload='' directly on elements back then when we all loaded script tags in the head.

I know these problems, yes.

But I didn't hit them, because I mostly did everything on the server side.

When I switched to SPAs, I used ExtJS.

Document ready is hardly the most fundamental “tool” for scripting, and it has always been easy to resolve in a cross-browser way: stick your scripts before </body>.
I would say no. It's everywhere. Even as you mention it's a common dependency or comes bundled with a lot of stuff. I have not sat down and written logic that "does the same thing in more than one browser" in a very long time but I'd venture to guess the part of jquery that is browser javascript api abstraction is still very relevant today.
Interesting :)

To me it always felt kinda strange seeing all these jQuery Stackoverflow questions and answers.

When I switched from server side rendering to SPAs, I had the impression everyone was already hating on jQuery and avoided it. I read "Pro JavaScript Techniques" and "JavaScript the good Parts" and started my JS career :)

ExtJS 4 came out and I did my first SPA with it.

Later I did some university projects with Ember, which seems to use jQuery, but I never had to call one of its functions directly.

After that I started freelancing and ended up in a React project, which I found kinda nice to work with.

So did you do JS development back in 2006 without jQuery?
I started with Prototype. Not sure if it came out before or after the first jQuery, but it was the cool kid for a while. Then the world realized it was a disaster and started moving to jQuery...
Too bad Magento devs missed that newsflash. Nowadays it still bundles Prototype.js, and every theme and 50% third-party modules you install carry their own copies of jQuery, all at different versions, placed in random locations, and embedded into the page differently.
I know a bunch of devs who always preferred Mootools and never did jQuery.
I did, then Safari 1.0 happened, and we all went screaming for a solution. Praise jQuery.
The first few years I did PHP without much client side scripting.

Then ExtJS, then a short stint with Ember and after that React.

Ah, ok, so you're not a 10 year JavaScript developer, that's very different thing. If you were doing DOM manip 10 years ago without jQuery / MooTools / Dojo / YUI you would be someone that loves pain.
Yes.

I started with learning vanilla JS and doing my professional stuff with ExtJS.

But as you say, jQuery wasn't a requirement. I knew a few people who hated it with passion back then, they were all using MooTools. That's probably why I avoided it...

What was your experience with Ext? I had to use it for a few years, and was never a huge fan. We ran into a lot of obscure bugs in their code which resulted in a number of hackaround "Ext.Overrides," and their support forums (Mitch Simmeons in particular) is a joke.
Which version did you use?

I only used ExtJS 4 and 4.1

I liked their API documentation and the xtypes that allowed for declarative Views. React reminded me of this later.

I started on 3(.5?) and helped with a migration to 4 (which was a disgusting mistake of a process on our end). I like the format of their docs -- JSDuck was my favorite docset for a quite a while. I also enjoyed their methodology for constructing views and view hierarchies. Ultimately, I'd say I was a fan of what they were doing, I just think the implementation was rather shoddy, and the docs were frequently wrong or outdated, and (as mentioned) support was not good. When I got to React, it actually did bring back some memories of Ext, but without the full MVC hierarchy around views.
Yes