141–150 of 201 posts
Earlier quoted context omitted.
This is about more than just a build process. jQuery's imperative DOM manipulation is a horrible way to manage state compared to React. These tools aren't just "cool things". They were designed to solve really pressing issues related to managing complexity in front-end web applications by eliminating global state in both the DOM or the JS runtime environment. They tend towards a more declarative and functional approa…
This reads like a parody.
Earlier quoted context omitted.
.classlist() [1] is coming [2]. It'll allow you to do: document.getElementById('foo').classList.remove("bold"); Sure, it's still more verbose. But a lot of what jQuery does is slowly being obsoleted by better native javascript apis. [1] https://developer.mozilla.org/en-US/docs/Web/API/Element.cla... [2] http://caniuse.com/#feat=classlist
The day I can drop support for IE <10 will be a good day.
I do need JQuery because I want to focus on the application and not nuances of different js implementations. And I want to use the simple selector mechanisms. Then there's plugins, I use those too and many assume/require JQuery. So no, I disagree. Stupid article.
Earlier quoted context omitted.
.classlist() [1] is coming [2]. It'll allow you to do: document.getElementById('foo').classList.remove("bold"); Sure, it's still more verbose. But a lot of what jQuery does is slowly being obsoleted by better native javascript apis. [1] https://developer.mozilla.org/en-US/docs/Web/API/Element.cla... [2] http://caniuse.com/#feat=classlist
`$(".foo").removeClass("bold")` becomes the wonderfully concise [].map.call(document.querySelectorAll(".foo"), function(node) { node.classlist.remove("bold"); })
[...document.querySelectorAll('.foo')].forEach(node => node.classList.remove('bold'));Earlier quoted context omitted.
Just use the CDN copy of jquery and it will be cached in the users browser already since so many websites already use it.
Not really, the cache-hit benefit is a myth. Too many CDNs, too many versions of jQuery in use, cache's too small... So ..using jQuery via a CDN, depending on which you use you have a 1 in 119, or 1 in 833 chance of the user having a cached copy. http://www.i-technology.net/2013/11/the-myth-of-cdn.html more data: http://www.stevesouders.com/blog/2013/03/18/http-archive-jqu... There are valid reasons to use a CDN (get…
That statistics has assumptions on what's the most popular jQuery versions being used. It would make sense if there was real data to support that.
Earlier quoted context omitted.
make building your site more complicated than compiling an entire Linux distribution from source http://browserify.org/ Browserify is not at all complicated. spend days choosing between a bunch of almost identical micro-libraries for every little thing you need to do Just search npm and pick the one that is being used the most. lock yourself into a proprietary framework that will be considered legacy code as soon as…
The problems that npm and browserify solve are at the level of builds and package management. You could use any number of trendy frameworks and tools on top of this. Right. But last week it was RequireJS, not Browserify. Today, as well as NPM, we have Bower and gem and pip and however many other package managers. Last week it was Angular, this week it’s React, and next week maybe it will be Web Components. Last week…
But last week it was RequireJS, not Browserify.
I used RequireJS for a number of projects before being introduced to browserify and npm.
I had reservations at first because I didn't want my front-end code to be reliant on a back-end environment even if the language was Javascript.
However, after having my reservations answered by people in the node community and seeing how they were using it and seeing the incredible volume of front-end code that was being published to npm, I came around to it.
Today, as well as NPM, we have Bower and gem and pip and however many other package managers.
Bower really doesn't make any sense to use and seems to be falling completely out of favor. Gem and PIP are not Javascript module repositories so they don't make sense in this conversation.
Last week it was Angular, this week it’s React, and next week maybe it will be Web Components.
I spent a year with Angular and I found it suffered from a good many issues. It is slow. It is bulky. It does too much.
React's virtual DOM and expressive JSX are fantastic. It is fast. It works on the front-end and the back-end.
Last week it was Grunt, this week it’s Gulp, and next week who knows?
I agree with you here. I use Make. It works just fine.
Most web projects aren’t large and complicated, and many don’t need elaborate build processes and package management schemes at all.
Can you please backup your claims that browserify and npm are an "elaborate build process"?. Like anything there it takes a little time to become familiar with something but it is a very straight forward process that makes development and starting new projects much quicker and easier.
Perhaps you just need to work with these tools a bit more so you can understand what they do?
I mean, if you're using SASS, you've already got a build process.
But I get it. The gulp thing and grunt thing was always totally insane. Here's a little template and a bit of a joke I made a few months ago:
https://github.com/williamcotton/makeify
It's a build process that uses good ol' Make. I've been using Make for a long time. It works just fine.
Lemme just sum up with this: I've been writing web applications since the mid-90s. I started with perl scripts and cgi-bin. I moved on to J2EE and Tomcat. I worked with Rails for years.
I've seen Javascript go from a bunch of random functions strewn throughout an HTML file to what it is today. In between I've used Prototype.js, mootools, jQuery, and who even knows what else.
The web has been evolving. The power of the Javascript engines in browsers has been evolving. The world is in a constant state of flux and I am ALWAYS looking for better tools. I personally feel that I've been doing this for long enough to recognize what is really an advancement and what is just some flash-in-the-pan idea.
I definitely don't need you lecturing me about software tools and pretending like I don't question my process.
Oh the eyes of Microsoft shine gracefully upon us, we are so blessed. First, get a spell checker. Second, abandon jQuery at you peril. Browser makers should be required to embed jQuery. jQuery makes JavaScript almost bearable to deal with. That says a lot.
Earlier quoted context omitted.
Yes, why use a tried and tested tool that can be incorporated into your site and served efficiently with just a single extra line, when instead you could make building your site more complicated than compiling an entire Linux distribution from source, spend days choosing between a bunch of almost identical micro-libraries for every little thing you need to do, and lock yourself into a proprietary framework that will…
make building your site more complicated than compiling an entire Linux distribution from source http://browserify.org/ Browserify is not at all complicated. spend days choosing between a bunch of almost identical micro-libraries for every little thing you need to do Just search npm and pick the one that is being used the most. lock yourself into a proprietary framework that will be considered legacy code as soon as…
And that's fine, if writing a framework per project is something you have time for. But make no mistake -- you're writing a framework.
>> In fact, this is completely unneccsary with the existence of forEach and Object.keys() (both available in IE9+). Oh the eyes of Microsoft shine gracefully upon us, we are so blessed. First, get a spell checker. Second, abandon jQuery at you peril. Browser makers should be required to embed jQuery. jQuery makes JavaScript almost bearable to deal with. That says a lot.