181–190 of 201 posts
I started to use Angular instead of jQuery. It comes with jqlite and a lot of the stuff I would use jQuery for (e.g. form validation) can still be easily done.
An if you care for performance, you shouldn't use jquery. It is very slow: http://stackoverflow.com/questions/11503534/jquery-vs-docume...
The last step isn't usually necessary.
Earlier quoted context omitted.
The second function is broken for an element with multiple classes. DOM fail.
That makes the site a pretty good illustration of one of the reasons why, although you don't have to use jQuery, you maybe should. With jQuery you benefit from years of development and testing, which your own code probably hasn't undergone.
Although, I do occasionally use jQuery, I'm more comfortable and productive when not using it. Also, if I shamelessly take a peek at jQuery's source now-and-then to see how they implement certain features so I can make a helper for it.
Earlier quoted context omitted.
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…
We could have an actual discussion about the evolution of front-end tools if you could leave some of your hyperbolic rhetoric at the door. 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.…
"We suddenly need 73 different tools and templates and scaffolds and packages and boilerplates just to start a simple project"
That's the problem here. You certainly don't need any of them for a toy project. Of course, you don't need a test suite either. Or a build process. Or any kind of automation.
But guess what, I incorporate them anyway because I've built up a discipline over the years. I don't feel overwhelmed by all the different libraries and tools out there because I actually take some time on a regular basis to catch up with the state of the art. It's part of the profession. Any profession, really.
Earlier quoted context omitted.
So when those new native api functions arrive, jQuery will start using them and gain some performance boost (using native vs. custom js code) while at the same time remaining backwards compatible (by doing feature detection). No one wants to write their own feature detection code so this whole page about using native apis is instead of jQuery is ridiculous. If the point of that website was to educate people on the ap…
Or you could use the class list polyfill.
Earlier quoted context omitted.
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…
We could have an actual discussion about the evolution of front-end tools if you could leave some of your hyperbolic rhetoric at the door. 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.…
I’m sorry you saw my posts that way. My intent was simply to challenge the specific post to which I responded, where you appeared to be claiming quite clearly but without any particular argument or evidence that projects today should be using Browserify, React and a bunch of NPM modules instead of jQuery. I stand by that challenge and my comments here, but please don’t read more into them than is there.
If you are interested in one more concrete example of where my opinions come from and why I still hold them, you might like to read a post I made a few months ago[1], in which I described the rather disappointing results of a recent experiment in using a few modern tools.
By the way, you and certain other posters here also seem to be assuming I’m the new guy who doesn’t know modern tools or understand the state of the art. I have no interest in getting into anatomical measurement competitions over this — I’d rather debate the merits of an argument objectively — but just so you know, I’ve been building web sites for going on 20 years and software generally for longer than that. I am not cautious about certain modern tools because I don’t know the current state of the art. I’m cautious because I do know the current state of the art, and after considerable research and experimentation, I don’t think it’s healthy.
Earlier quoted context omitted.
good luck ranking in google and explaining your self to your md when your major publishing site takes 20 seconds to load I wont mention any names but I know of two cases of this.
if it takes 20 seconds to load, you have bigger problems than jquery.
Earlier quoted context omitted.
We could have an actual discussion about the evolution of front-end tools if you could leave some of your hyperbolic rhetoric at the door. 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.…
I definitely don't need you lecturing me about software tools and pretending like I don't question my process. I’m sorry you saw my posts that way. My intent was simply to challenge the specific post to which I responded, where you appeared to be claiming quite clearly but without any particular argument or evidence that projects today should be using Browserify, React and a bunch of NPM modules instead of jQuery. I…
If you don't want to be misinterpreted you might want to limit the amount of sarcasm and hyperbole in your statements and instead focus on clearly defined criticism of these tools.
You can chalk all the issues that you've had to growing pains.
In the last 5 years the web browser has changed immensely. It is now capable of running incredibly complex applications. These kinds of applications need sane module and build systems. Once you're familiar with these tools they do not get in the way even when building simple weekend projects.
The jQuery way of handling DOM manipulation comes from an era where the majority of HTML was being processed on the back-end and Javascript was used for light-weight modification of state.
Using jQuery for building complex interactive web applications is a difficult task because state becomes incredibly hard to reason about.
There are a number of declarative front-end frameworks but I feel that React is the clear winner.
One big issue with Angular and Ember is when it comes to rendering HTML on the server. They're also very slow especially on mobile.
Yeah, the last 2 years have been a mess. We're not out of the clear yet. State and identity management is gearing up to have it's foundations rattled to the core by cryptographic systems that introduce PKI. Because React is just a view layer it'll remain agile enough to work with any sort of upside-down state and data management. Clients keep getting more and more power.
Within the node community the foundations for a decentralized package management system are being built. One that will be just as capable of publishing, loading and building modules from WebRTC as it is from a centralized server.
Yeoman, Bower, Gulp or Grunt don't really solve anything that isn't solved better by other tools.
I urge you to take another look at this stuff. I understand your frustrations but the solution should not be to give up and just go back to jQuery.
Articles like this make me thankful that I've done my 10,000 hours of web development learning the ins and outs of the DOM and it's interactions with JavaScript (mostly topics covered in Crockford's book). Admittedly, about 9,950 of those hours were making it work in IE6. jQuery is a framework, like many others. Programming is not about learning frameworks, it's about learning the language, it's runtime behaviours an…
after 10,000 hours you're still calling jQuery a framework?
better?