Last night, I was working on a side project. For the front-end, I'm using React, React-Route, and I'm working on figuring out Fluxible. superagent to wrap XmlHttpRequest. browserify to compile what I serve to the front-end. I don't run a reverse-proxy with a node backend since the API is in PHP, I just served the minified JS files.
Honestly, it's a huge pain. And every module I toss in there seems to limit compatibility with the next one. The barrier of entry to doing things right is HUGE. Also, if you disable JS the site would be useless, 100%.
If I were to go with angular it would be even worse. I honestly may go back to jQuery on this project yet. I don't expect it to be huge, and since most Foundation plugins use jQuery anyway it should work. I honestly loathe how much crap I'm loading for two pages: sign-up / register.
You may have a look on VueJs as a lightweight alternative to React/Angular when you need simple apps to create like the one you mentioned , it is like jQuery but with very exciting features https://vuejs.org/
I hear you on this. A lot of that stack is very new and still changes quickly enough that I have a hard time finding good examples to work from.
I've had a very hard time getting things like react+react-router+reflux to all work together as expected. It's not been super fun as a way of working.
And I dunno if your situation is the same as mine, but all the "contemporary" JS stuff I work with (react, etc) is for side work, that is, stuff that I am building explicitly because I want to play with the stack.
So the reaction that "you don't need all that" is probably missing the point (at least if your situation is like mine): I do things like that because I want to see how stuff works, and it's better than doing it on my $$$ projects.
> I honestly loathe how much crap I'm loading for two pages: sign-up / register.
Sorry, but this is entirely your fault. You don't need any of what you mentioned to do this. You can just use jQuery if that works for you. No one except really bad junior devs on here or Reddit will say you are doing things "wrong".
You're right, the over-engineering is entirely my fault. I love the re-usability of HTML components that I get with React. I'll work this week on removing all other dependencies and server-side rendering and see if it's something I can live with.
I tried fetch, the polymorphic-fetch module that builds on this github one and found it doesn't support .finally(), or work with the promise.finally polyfill (yes I know it's not in the spec, but seriously).
Also sinon.js couldn't mock it, and dealing with error cases is inelegant (it doesn't look like much extra code, but is hard to justify if you're just writing a small component that hits one endpoint, in terms of weird new code to explain to your teammates that is).
I have gone back to $.ajax for now, though I do mean to try out qwest [1] when I get the chance. Seems to be both tiny and also have a sane promise-y API.
Because needing to do something regardless of success or failure is incredibly common (e.g. stop a progress bar, re-enable form inputs & buttons).
The (promises) spec is lacking w.r.t. this use-case, and most ajax libraries (and a lot or promise libraries) recognise this by implementing a 'finally' equivalent.
Honest question, what is wrong with request (and superagent)? Is it just size or something more? I am only asking because yesterday I was looking for a promise supported library and I was comparing superagent (with its promise wrapper), request-promise, axios and node-fetch. I have narrowed it down to axios and fetch but I would like to hear your opinion on the matter.
The size. For a Node app, maybe not so bad (though I'd use node-fetch or got[1] which are smaller). For a browser app, loading all of superagent (which is almost 2 megabytes) just to make a few GET and POST calls is silly.
Never used axios but I've heard good things about it and its creator is awesome. I just use fetch because it does what I want.
Wow, had no idea that request was so bloated. And thanks for mentioning got. I just checked it out and I think that is the lib I will be going with on the backend. I love the stream support, very cool.
Curious - why are you using React and all of that for a simple 2 page project? Is it for the learning experience? Seems like way overkill unless its for the learning experience.
"doing things right"... by whose standards? It blows my mind how convoluted everything has become due to "doing things right" and "best practices". It's a side project, keep it in perspective. The faster it gets done, the sooner you can refactor IF you need to refactor.
If you know the site is small why do you do the pain and go react, router and fluxible etc. etc. ? The investment in this (huge) toolchain will be beneficial when you start making things more complicated... then you may hit a wall with normal jQuery/JS. But not every project needs a big React based toolchain. This is definitely a JS platform problem. I'm currently looking at Elm because it makes life easier in comparison... but there you have other gaps like not good jQuery plugin interaction.
This sounds like a big deal but that is effectively what you have to learn either way. The difference is that one is built in a competitive landscape and the other is done in a big god object.
jQuery.Deferred was such a convoluted api for me. I polyfilled a Promises lib and felt bad having multiple libraries that on the cover said they did the same things.
The notes say it is computationally expensive and bad for performance.
Using this selector heavily can have performance implications, as it may force the browser to re-render the page before it can determine visibility. Tracking the visibility of elements via other methods, using a class for example, can provide better performance.
I did at one point in time for flagging links to show a "leaving site" prompt. Now the JS simply checks any link when you click it (no more custom selector for flagging).
I'm not surprised, JavaScript is compression-friendly. Usually minification brings the file size down by about a x3 ratio, and gzipping does the same.
What always impresses me with jQuery is the amount of features they're able to pack in 250 Mb of uncompressed code. They've got browser events, ajax and a crapload of selectors. Compatible with most browsers. Oh and performance is nice as well. Kudos to the jQuery developers!
1. A few other libraries still depend on jQuery in turn, so I find that I still usually have it available in every app I work on anyway, so I might as well use it.
2. It "just works" and I already know it, and since it's already there, anyway (see (1) above) it just makes sense to use it. IOW, I don't feel enough pain from using jQuery to justify going off and learning what combination of new ecmascript (es6? es7? es9037253223252??? ???) features and/or libraries du jour that I would need to do everything jQuery does for me now.
That said, I mostly just use it for the selectors - which I understand can be easily replaced with native features now - and the ajax method. So in reality, yeah, I probably could ditch jQuery without too much pain, excepting for (1) above, but... why bother? I don't care too much about the size, since I don't typically link in tons of javascript libraries, ad networks, etc. to kill page load times, and page bloat seems to be the biggest argument I hear against using jQuery.
And, why should a new developer on fresh projects use it? It seems ES6 and latest CSS specs should cover everything JQuery used to be used for.
Plus, wouldn't actually using Vanilla JS be faster?
Right now it looks like people use JQuery for legacy code. But, they give no reason to use it for new projects, except if they need it for other libraries they're going to use. (based on legacy code anyways...)
JQuery looks redundant in the modern Javascript era on evergreen browsers.
jQuery is still much more pleasant to use than native methods when working with collections of DOM elements. If you do much DOM manipulation, you'll end up writing helpers that replicate aspects of jQuery to grease your workflow. The real issue is that trying to manage state by directly manipulating the DOM becomes a nightmare as the project grows, and newer frameworks can mostly take care of that for you.
So jQuery is still wonderful at what it does, but there isn't much reason to be directly manipulating the DOM now that there are alternatives.
agreed, if you want to keep things simple jQuery is still a nice tool and ES6 only makes it nicer to type, ES6 does not improve native DOM manipulation
For quick mock up / temporary pages sometimes regular JS is quite verbose, and a full framework or whatever like react/mithril/angular/ember/whatever is too much extra hassle. When writing 20 lines + 2 plugins in jQuery is enough to make a 'static site' feel much more interactive / responsive (UI, not screensize) then sometimes it works great.
It's a bit like the perl of web page JS for me. I wouldn't recommend writing a full complex application in it - although that is possible and by people who know what they're doing can be done cleanly and organised... but for super quick hackery, it's hard to beat.
I'm surprised you're asking for "reasons people still use it" when that is already quite obvious. How about telling us why you don't need the most popular JS library?
Our company still uses it a bunch. Higher powers enjoy the "benefits" of using bootstrap themes which are bundled with a mess of random jquery plugins from around the internet. Our dev team has actually been quite successful at wrapping many of these plugins into react components to abstract away plugin details.
Since I used d3.js for one project a few years ago, I have not touched jQuery ever since. d3 offers key jQuery features, but goes much more beyond that.
I've often head this and it would probably be in my next-side project. Do you have an AJAX API bundled with D3 or are you using some custom functions ?
eq() is equivalent to selecting an item from an array and can be replaced by using bracket notation (e.g., arr[1]).
In D3 you can do selection.classed('active', false). This is equivalent to toggleClass().
According to jQuery's API, show() "... is roughly equivalent to calling .css( "display", "block"), except that the display property is restored to whatever it was initially." Instead of show, you can just do selection.transition().duration(300).style(display, 'block').
The length method? You can just use JavaScript's native .length.
"jQuery and its cousins are great, and by all means use them if it makes it easier to develop your application.
"If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency. Maybe you can include a few lines of utility code, and forgo the requirement. If you're only targeting more modern browsers, you might not need anything more than what the browser ships with."
Last night, I was working on a side project. For the front-end, I'm using React, React-Route, and I'm working on figuring out Fluxible. superagent to wrap XmlHttpRequest. browserify to compile what I serve to the front-end. I don't run a reverse-proxy with a node backend since the API is in PHP, I just served the minified JS files.
Honestly, it's a huge pain. And every module I toss in there seems to limit compatibility with the next one. The barrier of entry to doing things right is HUGE. Also, if you disable JS the site would be useless, 100%.
If I were to go with angular it would be even worse. I honestly may go back to jQuery on this project yet. I don't expect it to be huge, and since most Foundation plugins use jQuery anyway it should work. I honestly loathe how much crap I'm loading for two pages: sign-up / register.