
We Removed jQuery - joegahona
https://www.outsideonline.com/2353261/how-we-removed-jquery-our-drupal-7-site
======
pixelmonkey
Legitimate question (I am not trolling), but is there truly a good reason to
stop using jQuery? I get that there are now standard ways to do DOM lookups
and so on, but what if you simply like jQuery's API? Can't we recognize that
as one of the web's most widely installed libraries, it's practically a
standard library module for the DOM and for x-browser JavaScript? Why are we
so eager to get rid of it?

~~~
verisimilidude
You're right, the dogmatic opposition to jQuery tends to be unconvincing.

The reason I don't use jQuery these days is because other libraries serve
jQuery's functions a little better for me.

* If I want a more robust interface for my XHR requests, there are a ton of nice libraries out there. Superagent is a good example.

* If I need utility belt stuff, I can get more out of Lodash, Ramda, etc.

* If I want animations, there are much better ways to do that nowadays, even with just basic CSS3.

* If I need distinct DOM lookup and manipulation...well, this might not be needed at all if I'm doing an SPA (in React, etc.). That said, there are compelling alternatives that I like, such as bonzo.

And then there's just the fact that you can now do an awful lot with bare
Javascript.

So my argument against jQuery is less "jQuery sucks" and more "I prefer using
all these other tools that cover the same surface". jQuery is still a marvel
for all the conveniences it provides, and I don't think anyone should stop
using it just because the cool kid says so.

~~~
ravenstine
That pretty much sums it up. jQuery animation can be pretty atrocious.
Granted, CSS transitions/animations can also be atrocious if certain
properties are being changed at the wrong times.

jQuery is going to select and manipulate elements, but it's not going to
compensate for when the developer does moronic things like creating DOM
elements a bajillion times with HTML strings in jQuery every time something
changes, animating things in improper ways(like animating dimensional
properties that cause extra redrawing before postrender), etc.

There's nothing wrong with using jQuery. I just find that I don't even need it
and would much prefer to just use existing APIs in its place. If there's a
compatibility issue, I can install a polyfill that's much smaller than jQuery
ever will be.

------
js4ever
Removing jQuery is a curious and unproductive goal to have. You should focus
on things that really matter to your users. You should also remove drupal
(bloated and low security cms based on php), that's making your site ways more
slow than jQuery

~~~
untog
Your users care about page load time. If you can remove jQuery then the page
will load faster. Users do not care if your CMS is bloated and written in PHP.

~~~
js4ever
Bloated cms means slow server response time. So users will care

~~~
untog
Not if you have a caching layer, which any site of reasonable volume does.

~~~
js4ever
How do you cache POST actions? Login, create account, search, purchase, ...?
All those actions go through the bloated cms It's not unusual to see 1000 to
3000 ms response time on drupal, joomla and wordpress

~~~
Kimitri
Umm... Well, you obviously can’t cache POST actions but you usually can cache
a lot of the stuff in the response. The cache system in Drupal 8 is pretty
awesome - especially when backed by Memcache or Redis.

I’d say it’s quite easy to build slow sites on any platform. I also know it’s
very well achievable to build truly perfomant sites on Drupal. Also, with the
sites built on top of these CMSs, performance very rarely actually becomes an
issue. The number one worry with the sites is their unmaintained codebase and
all the security implications that come with it.

I really like Drupal 8 and I certainly wouldn’t call it bloated. It’s
extremely modular and you can enable just the things you need. What I really
want, though, is that people would take better care of the sites they build on
it.

------
winningcontinue
Disclaimer 1: We actually didn't totally remove jQuery as we have a few custom
features and pages that use it, but for ~99.7% of our pages, it's gone!

Disclaimer 2: The following method isn't something we recommend if you rely
heavily on front-end contrib modules, authenticated traffic, or parts of
Drupal 7 core that depend on jQuery.

~~~
yjftsjthsd-h
> but for ~99.7% of our pages, it's gone!

Really, _mostly_ getting rid of something is an effective optimization; 80-20
rule applies.

------
vilius
I always wonder - is it really worth removing jQuery. Idealistic side of me is
envious of their feat. However pragmatic me says that I have 99 features in
the pipeline and removing jQuery is not one of them.

The mentioned 150GB bandwidth saving surely sounds good however when I
contemplate about ROI somehow I still endup thinking: it’s not worth it. Or
maybe I’m just too old.

~~~
nitramavfank
I actually don't fully understand how they came to the 150GB conclusion. They
write:

> Before our jQuery removal refactoring, the bundle file on our most popular
> content type, article.min.js, was 139kb minified (gzipped 47kb). After our
> refactor, our jQuery-free code comes in at 50kb (gzipped 15kb).

So it sounds like they bundled jquery into article.min.js. But then they go on
to write:

> This might seem trivial, but when you consider that we have over 5 million
> pageviews to the article content type in any given 30 days, it translates to
> roughly 150GB of bandwidth saved.

This then indicates that no request to their most popular javascript will be
cached by clients, which seems odd. I don't think people typically mean
"unique visitors" when they say "pageviews", or?

I clicked on ~5 pages on their site and my browser downloaded about 10MB.
Their JQuery optimization saved them 30kB. From a bandwidth perspective, it
doesn't seem so significant.

Edit: Actually I almost get upset when I browse their site. My laptop screen
is 1920x1080, and their content doesn't really fit on the screen. I'm thinking
about for example the "Dispatches" section on the / page. I can't even see the
complete frigging boxes without scrolling. The font size of the header is
crazy 150px and then the boxes underneath. Wtf. Now, this blog article reminds
me of those from Netflix about how they improved some "blablabla-engine" and
then they can't even be bothered to do a somewhat user friendly site.

------
invalidusernam3
I wonder if they considered decoupled Drupal, where Drupal functions as the
CMS and API, and you can use anything you want for the front-end. I've done 3
sites this way, using Angular for the front-end, and it's been a pretty good
experience.

~~~
tannhaeuser
I don't get "headless" CMSs. If you remove the front-end and write a custom
one, you could as well use something different on the backend alltogether. The
appeal for Drupal and WP is that it's possible for a layman to get a working
generic web site running, isn't it? If you're developing a custom UI using
JavaScript, then you're already knee-deep into webpack, asset pipelines, git,
node, etc. and should be able to put together a lightweight backend using node
and will prefer one where page templates are managed as files under version
control, rather than via mysql.

~~~
invalidusernam3
A lot of clients won't accept a custom CMS due to security concerns. Every
line of code I write on the projects I mentioned before go for a security scan
with a third party. Scans already cost tens of thousands of dollars, using a
custom backend would drive that price up even higher. In terms of PHP CMS's
for enterprise, you're very limited, and a lot of companies are moving towards
Drupal.

The other major benefit is that it's (fairly) easy to swap out either the
frontend or backend. If we need to migrate to another CMS, we don't have to
change anything on the frontend as long as the new API confirms with the old.
And vice versa for migrating to another frontend. Also if you need to create
an app or any other application you already have an API.

I wouldn't necessarily use this same architecture for smaller sites, but for
enterprise it's a pretty good option.

------
noncoml
> We wanted to be one of the first major consumer-publishing websites to be
> jQuery-free!

That’s the exact opposite of a technical reason. Actually sound like following
the hype.

~~~
ZoomStop
> Our quest for greater page-speed optimizations reached a point were we
> considered jQuery as unnecessary overhead.

Their 'conditions for removal' are half made up of reasons they want to remove
jQuery. Makes no sense.

~~~
bvoran
Which one of the 4 reasons were "made up"? The last reason may not be
technical but it's a reason we wanted to exploit. Looks like it worked ;)

------
KayL
They have to remove all redundant, not just jQuery.

It's almost a static site without any interactive functions. 46.9KB unzip JS
still seem too much.

On another side, they have more than 30KB preloaded articles data on every
page. That could be a 2nd Ajax call or a better data structure. CSS is another
place I think that can be optimized.

Obviously, the Drupal settings and few JS functions are added twice and debug
mode for JS bundle is enabled I bet.

------
schrodingersket
jQuery itself is rarely a problem. It's a tool, just like any other library,
and it's very effective at solving the problems it sets out to. But at the end
of the day, it's still just a tool - and tools aren't solutions by themselves.
Good application architecture usually points to the right tool for the job.
I've developed on projects where jQuery, requireJS, AngularJS, Angular 2+, and
React have each provided the best tool (and sometimes in conjunction with each
other!) for what we needed.

------
intellix
Surprised to be reading about this 5 years later

------
rustcharm
I like DruPal’s TV show on MTV

