Fear not. I delivered a project for a client a few weeks ago which featured plain HTML, CSS, and "vanilla" JavaScript, with no libraries apart from the venerable jQuery, and not a pre- or post-processor in sight. It was quite liberating!
There's something to be said for that... Even with jQuery today it's often easier to step out of the box a little and use more straight JS. With IE8 finally falling off, and IE9/10s days numberd it's pretty liberating.
That said, I love my ES6/7 syntax sugar, and write a lot of server-side JS too, so the transpiling doesn't really bug me.
Even with jQuery today it's often easier to step out of the box a little and use more straight JS
You mean straight DOM not JS because as a matter of fact, jQuery didn't add a lot to the feature set of JS but contributed immensely to fix/smooth the DOM API.
Yes.. and DOM support across browsers is much better than when jQuery was first developed, also jQuery has a lot of utility methods that are already built into iteratables (Arrays).
[].concat(document.querySelectorAll('#foo > div')).forEach(function(div){
//got my div
})
Isn't too much worse than
$('#foo > div').each(function(){
var div = this;
//never liked this pattern, and even then why isn't "this" a jQuery object?
});
Let alone adding another few dozen k for the library itself... Zepto is about 1/3 the size for modern browsers, without all the extras you generally don't need if you just want some dom sugar around modern browsers. Though, I'm not sure if Zepto has enough for say the Bootstrap components to work against.
`.bind(this)` or an ES6 fat arrow solves the `this` problem in your jQuery example.
As to why... well, it makes more sense with jQuery's event listeners (`$(this)` being much shorter than `$(event.currentTarget)` and usually being what you actually want), and thus I guess in the name of consistency it's good to have all callbacks behave the same way. Why it's not a jQuery object... pass. More often than not that would be what you want, and if it's not, `.get(0)` or `[0]` is hardly a great stretch. Historical reasons, perhaps.
If I'm iterating over collections of elements and I have access to Underscore, I'll just use `_.each($("..."))`, which has the benefits of a more suitable `this` and the callback arguments in a sensible order (element then index).
If I did a `bind(this)` in a jQuery event handler, I could never access the item that was being iterated, or the event was raised for... My problem with `this` in jQuery is that it's context that isn't passed.
The binding/pattern just blows up, and handleFoo can't get to the foo instance... It's just really sloppy in my mind to change the context of functional expressions that way. Don't get me wrong, I really like a lot of what jQuery has done, and it's better than what came before it, I just find that using the this context removes a lot of options.
Heh, yes. I just started using RequireJS in one of my projects for first time (previously was just using script tags). I don't even try to keep up with this stuff, besides being aware of it. I'll leave it to the 100% JS devs and the rock stars. I have a lot of other things on my radar, and web/JS development is less than 30% of my day. I don't have time to keep up with all the changes. If it works, ship it. If it ain't broke, don't fix it.
Once ES6 is well handled by the browsers a lot of these intermediate shims/libraries will go away anyways.
I wouldn't worry as much.. I don't think that jspm will stick in that it really doesn't do much do much over straight npm and I wouldn't be surprised to see git semver matching on tags for versioning as a support route.
As to webpack, conceptually it's awesome... though it just feels a bit alien to me in practice. Just a few layers too much PFM (pure f*ing magic) for my taste, when I am already using ES6/7 syntax more and more in addition to React, BabelJS, Browserify bits.
