This was maybe true five or six years ago. Most of the newer frameworks I've seen are trying to get developers to stop using jQuery. A lot of developers are building alternatives to jQuery as well.
Take for example AngularJS. AngularUI just built a set of Boostrap directives so its not dependent on jQuery:
To try and answer your question, most jQuery apps have the business logic, the model and the UI all together. React (as I understand it) abstracts each of these out separately. This makes debugging, and maintaining a large scale app a lot easier. Also, jQuery is all about manipulating the DOM. React uses other methods to stay away from directly interacting with the DOM.
This isn't exactly true either. Taking the points line by line:
Angular has a version of jQuery embedded, and replaces that with the full version if it is included in the page. AngularUI was not there to reduce dependencies on jQuery (UI, which is different than jQuery Core), but rather to provide the UI patterns in Angular directives so that developers didn't need to write their own over and over. That said, if you are new to Angular, my recommendation is to try not to use jQuery as that will force you to consider the "Angular" way of doing things rather than the "jQuery" way.
The guy who wrote You Might Not Need jQuery has also said that he was looking more at framework developers who don't need to make jQuery a dependency, not the average joe building a website. RWaldron, a jQuery contributor, put together a list of quite a few of the bugs that jQuery fixes for browser compatibility.
Don't get me wrong, Vanilla JS is great, and I love the site. But there are quite valid reasons for using jQuery and many of them are just as valid now as they were in the past. You can write "good" jQuery, it doesn't have to be "js soup".
The vast majority of JS apps use both jQuery and a framework like React. Frameworks are for handling logic and interactions between "things," jQuery is for manipulating the UI.
Not true in directives where the point is to do DOM manip. The only reason you can "avoid" jQuery is because they provide a poor man's replacement in their jqLite implementation. To this day I still don't understand why they made that decision.
We ended up using SmoothScroll on Windows (https://gist.github.com/salipro4ever/35ba6d9e61cade99a0c2), which helps us demonstrate the effect a lot better on the project page. It captures the mousewheel event and adds some tweening to make it scroll smoothly.
It does break easily if you have a non-standard mouse config, however, so I can't quite recommend the library unless there's a really good reason for it.
The use of the word "header" here was a little confusing. When I read the (HN) title I thought it was referring to HTTP headers (I know it doesn't make sense...thought maybe I was missing something). Then when I first looked at the page I figured it was referring to the h[1-6] elements (and thus thought the library was pretty dumb). Only after that did I figure out what it was actually referring to.
That said...I don't really have a better word to use. Also at least some of the confusion may have been due to the HN headline not having the word "fixed" in it (the actually project does, but I didn't re-read the title).
The effect works by creating multiple copies of the header (one for each design/section), which are then wrapped in two clipping masks (.midnightHeader and then .midnightInner inside that).
When you stop between two sections (let's say we need a blue header on the top one and a white one on the bottom one), we grab .midnightHeader.blue and place it exactly above the border. We then place .midnightHeader.white exactly below the border.
That nets you two headers, a blue one on top and a white one below the border, which isn't quite that we want. To fix it, we then grab the .midnightInner inside those and move the blue one towards the bottom (so it gets chopped in half right at the border, showing only the top part), and do the opposite with the one of the bottom (moving it upwards so it also gets chopped in half, but showing only the bottom part).
By doing this, the design looks continuous and all events work as they should, so the effect doesn't cause any usability issues.
We did a subtle implementation of Midnight at https://xapo.com/ (it's particularly noticeable in the vault/security part of the landing page). If you check it out with the Chrome Dev Tools it's easier to see how the masks work together, since it's a more realistic use case.
16 comments
[ 2.9 ms ] story [ 37.0 ms ] threadTake for example AngularJS. AngularUI just built a set of Boostrap directives so its not dependent on jQuery:
http://angular-ui.github.io/bootstrap/
This guy says, "You might not need jQuery" and gives some good examples:
http://youmightnotneedjquery.com/
I have a co-worker that will go to his grave thinking VanillaJS is much much better than jQuery. .
http://vanilla-js.com/
To try and answer your question, most jQuery apps have the business logic, the model and the UI all together. React (as I understand it) abstracts each of these out separately. This makes debugging, and maintaining a large scale app a lot easier. Also, jQuery is all about manipulating the DOM. React uses other methods to stay away from directly interacting with the DOM.
Angular has a version of jQuery embedded, and replaces that with the full version if it is included in the page. AngularUI was not there to reduce dependencies on jQuery (UI, which is different than jQuery Core), but rather to provide the UI patterns in Angular directives so that developers didn't need to write their own over and over. That said, if you are new to Angular, my recommendation is to try not to use jQuery as that will force you to consider the "Angular" way of doing things rather than the "jQuery" way.
The guy who wrote You Might Not Need jQuery has also said that he was looking more at framework developers who don't need to make jQuery a dependency, not the average joe building a website. RWaldron, a jQuery contributor, put together a list of quite a few of the bugs that jQuery fixes for browser compatibility.
Don't get me wrong, Vanilla JS is great, and I love the site. But there are quite valid reasons for using jQuery and many of them are just as valid now as they were in the past. You can write "good" jQuery, it doesn't have to be "js soup".
It does break easily if you have a non-standard mouse config, however, so I can't quite recommend the library unless there's a really good reason for it.
That said...I don't really have a better word to use. Also at least some of the confusion may have been due to the HN headline not having the word "fixed" in it (the actually project does, but I didn't re-read the title).
When you stop between two sections (let's say we need a blue header on the top one and a white one on the bottom one), we grab .midnightHeader.blue and place it exactly above the border. We then place .midnightHeader.white exactly below the border.
That nets you two headers, a blue one on top and a white one below the border, which isn't quite that we want. To fix it, we then grab the .midnightInner inside those and move the blue one towards the bottom (so it gets chopped in half right at the border, showing only the top part), and do the opposite with the one of the bottom (moving it upwards so it also gets chopped in half, but showing only the bottom part).
By doing this, the design looks continuous and all events work as they should, so the effect doesn't cause any usability issues.
We did a subtle implementation of Midnight at https://xapo.com/ (it's particularly noticeable in the vault/security part of the landing page). If you check it out with the Chrome Dev Tools it's easier to see how the masks work together, since it's a more realistic use case.