Hacker News Reader

> jQuery is ≈30k gziped and most likely already cached from CDN.

This part isn't so true in reality anymore, due to revised browser caching systems[1]. Doesn't mean you shouldn't use jQuery, just that part of the benefits of a centralized CDN are no longer a factor and it's a lot more sensible to self-host.

1: https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...

Right you are. But jQuery is around the same size as Vue, and that's the lean alternative to React. So the “jQuery is bloat” argument still doesn't make much sense.

A single retina hero banner is larger than most JavaScript libraries/frameworks.

A lean alternative to React would be preact.

Or mithril

Or Inferno

something something framework of the week

> and that's the lean alternative to React.

Ahem https://preactjs.com/

oh look, another one. lol

> another one

Preact [0] came before Vue [1].

[0] https://github.com/preactjs/preact/commits/master?after=605b... [1] https://github.com/vuejs/vue/commits/dev?after=5255841aaff44...

vue.js came before preact, it was first released february 2014 https://blog.evanyou.me/2014/02/11/first-week-of-launching-a...

Vue is the lean alternative to Angular.

And you can swap Zepto for jQuery which is like 10k and has pretty much all the functionality apart from some ancient browser support.

Well, you are still getting less server load and faster response times across the globe, right?

> …and faster response times across the globe, right?

Unfortunately not. There is no benefit to leaving your critical files on anyone else’s infrastructure: https://csswizardry.com/2019/05/self-host-your-static-assets...

As someone who is well experienced in web dev, that was a great article! Not so easy to find online, keep up the good work and I’ve become a fan

Thank you!

We used to use google.com for hosting jquery for us. Then when google.com started being blocked by the great firewall our site broke (it was pretty popular in China). It took a while to find out what went wrong, especially with the language barrier.

Back then we decided it's just better to self host. Less things can go wrong.

One thing that doesn't help jquery's case is that it and its plugin ecosystem isn't modular, making it impossible to trim the code size below the minified size via dead code elimination or even es6 partial imports. It would be nice to see more fluent DOM apis like jquery, but having 1st class support for es6 modules so you can import only the functionality you need in your final bundle

ZeptoJS has a modular build tool, allowing you to select only the desired modules

https://zeptojs.com/

So does jQuery by the way; you can use some flags to grunt to enable/disable parts you don't want. The README has some docs on this.

Cash supports partial builds:

https://github.com/fabiospampinato/cash/blob/master/docs/par...

Thanks for the article. I was just telling someone that jQuery was most likely already in the browser cache so don’t worry about it. Guess I need to go back and say I was wrong...

The reality was you where almost never getting a cached version anyway. There are so many versions of jQuery in use over so many CDNs that the chance of a user already having the exact version and cdn that you use is almost nothing.

We looked into this several years ago and found that most of our users had likely encountered and cached the several most popular versions on CDNs. There was a power law distribution in effect.

In the last five years, the release schedule has slowed, so there was a convergence onto fewer versions in the wild, but at the same time, users were visiting fewer sites that used CDN versions (and fewer sites in general.)

considering the size of frameworks like react, it's basically a "nothing" download. I've seen people spend more bandwidth on rounded corners.

React with react-dom is like ~35kb gzipped

There's still a huge benefit to using CDNs, despite caching being dead - they are almost certainly faster then whatever is hosting your site. If your site is relatively light and has a lot of traffic (especially international), pulling libs from a CDN could significantly increase the amount of requests you can process on the same server hardware and regardless of that, decrease the load latency for your users.

> IMO, React doesn't bring much to the table in this regard while adding a lot of complexity and heft.

Strongly disagree with this. In any complex web application with a lot of components, specially ones where a lot of fixed components can live for a while, React is definitely a massive improvement over vanilla JS or something like Backbone which allows wild west.

Imagine state coming from sockets, rest APIs etc with updates being either pull or push. A user might do an action which changes the state in some other component, keeping track of the components gets hard if the state is distributed. Also, centrally managed state with things like Redux allows for good caching of API data which can make a SPA considerably fast.

While I love plain HTML pages which need little or no JS, a lot of applications are better as SPAs.

That's more like redux and company...

Yeah, but redux etc gained traction with React, and together they make SPAs good.

SPAs were perfectly good before with ExtJS and similar, and more easily extensible too.

ExtJS = "What if JSX, but in JSON" ;)

For me, ExtJS redefined what's possible on the web a full decade before React/Angular & co, and it's sad that Sencha is now part of a heartless corporate graveyard.

SPAs were never good, the entire notion of them or shoehorning full apps into a browser is a farce. But, as parent says, that ship has long sailed

Native apps definitely have advantage in some areas.

But web apps give the ability to ship an app to more platforms and not be restricted by app store border control. Spotify had an Ubuntu client which never worked well, but as their web app improved I got almost the same experience as I would have on OS X or Windows web app. This gives equal chance to other platforms and to app developers as well as they don't have to play by rules like 30% cut.

As long as we can ensure web browsers can be kept open on major platforms(the only exception right now is iOS), it gives more freedom and choice to non platform developers. I would be really happy if PWA support in web browsers keeps improving going forward and need for dedicated apps gets eliminated for most things.

I'm exactly arguing against this Webpack, Typescript, React, etc approach to web development. I'm more productive in PHP + jQuery, a lot due to familiarity, of course, but I'm also a huge believer in a simple stack.

If you've 20+ mutually dependent inputs, maybe you need a better UI, not a complex state management framework.

If your browser is ultimately executing an untyped crazy dynamic language, is it worth trying to shoehorn types into it, only to later transpile it back? Not to mention JSX.

It all seems so crazy to me, but this ship has long sailed.

> It all seems so crazy to me, but this ship has long sailed.

Nope. And it's why Svelte is something that I've been hard adopting because it looks the closest to old-school JS/CSS/HTML while still bringing some of the same capabilities over that I love from React and VueJS. It also runs without a VDOM or a constantly running event loop - both things are incredibly attractive to me.

Although it's not a perfect solution (nothing is) I would strongly suggest you checking into Svelte as it looks more like traditional web development vs. highly complex Webpack + TS + React + eslint + Babel etc etc-based development.

The ship hasn't sailed. Your instincts to be weary of such a complex, constantly re-invented toolchain to get traditional development tasks accomplished are a natural response to the craziness that these tools bring to the table.

Svelte has been on my list to try, thanks for the reminder. I've also liked htmx (from intercooler) for keeping complexity managed. Any comparisons?

I saw the Svelte presentation a few years ago when it was released and my jaw hit the floor hard. That was some cool radical thinking. I haven't used it beyond playing with a few examples, so I can't really tell for sure if it holds up. Everything looks great on the demos.

Unfortunately it hasn't caught on, though it maybe be too early to call.

Too early to call.

Wait until Typescript is properly supported.

That happened like half a year ago[0]

[0] https://svelte.dev/blog/svelte-and-typescript

Definitely too early to call, but it is making waves already:

https://2020.stateofjs.com/en-US/technologies/front-end-fram...

I really, really hate the JS toolchains like "Webpack + TS + React + eslint + Babel etc etc" that you mentioned.

I rather like Svelte.

But honesty requires that we recognize that Svelte also uses Webpack/Rollup + TS + Svelte etc etc.

I like the idea of Snowpack. But if A.svelte and B.svelte both use C.svelte, Snowpack has to do a lot of redundant work to provide A.js and B.js with Svelte.js and C.js all converted again and again from ts then baked into both A.js and B.js. That's a lot of server work and a lot of client work and a lot of network work.

So you still want a webpack or rollup or what have you to bundle and tree-shake and codesplit for production. I don't know why this irritates me more than running any of my other code through a compiler. But it always has.

I've been running Svelte with esbuild and it's incredible, and doesn't bring along all of the above overhead. I get to target modern browser stacks which is a huge plus that keeps a large amount of complexity out of my toolchain.

Mileage will vary =)

what runs with a 'constantly running event loop' exactly?

I can't think of a single framework that does this, (its neigh impossible, actually, it'll just lock up your browser)

Svelte is cool, but this statement needs some serious proof

I'm on the same boat, super productive with php/twig/jquery. But recently my boss gave my a side project without any specific requirements, 10 charts and 2-3 tables with their associated crud. I made everything with react + php, and oh my god that site is super fast. It's eye opening!

Make Postbacks Great Again.

At Work, we‘re building web applications that need to be accessed by hundreds of editors with thousands of pages. Most of them share an essential bundle of components. Are you telling me a project that complicated can be built using just jquery?

Also, what‘s bad about typescript?

Do you need SPA for everything there? Because if server side rendering/logic is “allowed” with only a few interactive bits here and there written in jquery, than it can be absolutely done as that was/is the case a “few” years back.

I work on an app that is half react and half rails templates. Every time something has to change on one of the rails templates it becomes a process of explaining to the project manager that we can't easily make this change which would have been trivial elsewhere because this specific page is using server side rendering.

Its become such a large obstetrical that we have scheduled in a task this year to remove all server side rendering from the app.

I work on an app that is half react and half rails templates. Every time something has to change on one of the rails templates it becomes a process of explaining to the project manager that we can't easily make this change which would have been trivial elsewhere because this specific page is using server side rendering.

Its become such a large problem that we have scheduled in a task this year to remove all server side rendering from the app.

Server side rendering almost always means implementing the same feature twice, once on the server so it loads correct, and then a second time on the frontend so it changes as the user modifies it.

The number of clients accessing the page has no bearing on the best framework to use. The number of pages on the website is also not that relevant.

If 400 people are accessing 10,000 static pages, don't use any js at all.

I couldn‘t disagree more. It‘s a user portal managing thousands of different interactions and workflows, based on the users existing information. Most of them can be edited live with a content-management-system by an editor. These workflows are very hard to reason about with just jquery or nor js at all.

It can, sure, but having coding conventions is essential, which those frameworks/linters help to enforce.

But we've been doing projects with millions of pages way before React :)

Checkout Wikipedia, which, by the way, uses jQuery, of course. And PHP.

>Also, what‘s bad about typescript?

It tries to turn the very dynamic JavaScript into something it will never be and no amount of contortion can hide it. Unless it stops being a superset of JavaScript in the future, but I don't see that coming.

Wikipedia is a largely uniform, read-only, static experience. These days people want app-like experience on the front-end. Can‘t manage them with jquery.

The bit about typescript is true at runtime. However, Typescript is also good documentation for developers.

https://htmx.org

For when I’ve wanted to sprinkle interactivity, this is what I’ve turned to lately. It’s quite brilliant, and more declarative than most solutions.

But React is still necessary in my day to day job, as our web application is incredibly complicated in terms of feature set and customisation. They both have a place.

"The jQuery API is still (and probably aways will be) far superior to the native DOM"

The jQuery API really is so well done. I stopped using jQuery, but implemented a simple script (jSugar.js) that exposes many basic jQuery things but is really just a wrapper for native DOM operations. It only operates on individual DOM nodes. Any looping should be done using your JS loop of choice (forEach, for loop, which, etc).

The script started out really small. I've slowly added more and more as I need more functionality for some projects.

https://gist.github.com/pseudosavant/b86eedd9960ade958d49447...

> The jQuery API really is so well done. I stopped using jQuery, but implemented a simple script (jSugar.js) that exposes many basic jQuery things but is really just a wrapper for native DOM operations.

so... like jQuery?

No, because jQuery normalizes all sorts of DOM stuff. Part of the reason it is 30kb. What I've done is basically syntatic sugar and is only 74loc.

>most likely already cached from CDN.

I don't believe any major browser allows sites to share 3rd party caches anymore.

Previous HN discussion: https://news.ycombinator.com/item?id=24894135

True, there is still a perf win however since CDNs are located geographically closer to a global consumer than keeping the libs on your own box.

But don't modern frontend-oriented sites/apps deploy to CDNs anyway?

Self-hosting is no longer the performance drain it used to be now that HTTP/2 is a thing, as soon as the browser parses the page, the JS file is only 1 RTT away. Using a CDN for a single asset like jQuery requires a DNS lookup, TCP connection and TLS negotiation - that's 3 RTTs plus unknown latency from the user's resolver before the HTTP request is even sent. The performance difference in the single request scenario is likely negligible and the benefits of not relying on a 3rd party can outweigh the latency savings.

I agree with this 100%. Even though "vanilla JS" is more powerful now, JQuery is still much easier to work with.

I used to write a lot of JQuery, and I've switched to Vue three years ago. Occasionally I have to go back and write more JQuery, and it makes my head hurt.

edit: why the dowvotes? are we not allowed to share our experiences now?

I know we're not supposed to discuss voting but people downvoting someone simply because that person said something disagreeable, yet still within the rules of Hacker News, is becoming a serious problem in my opinion. I'd like it just fine we get rid of downvotes altogether.

Trying to write any kind of complex interactivity with JQuery event handlers is a serious pain in the butt, and it's so hard to go back and read.

I did the same as you; moved on to Vue and haven't looked back. My frontend code is so much cleaner and easier to debug. I've built a large library of components, so often times adding a new page only takes a couple hours re-using those instead of writing a bunch of new JQuery from scratch.

JQuery is great when I need to make (non-contentful) changes to the DOM. But I refuse to use it for managing the state of my app or putting content in UI components.

Smaller footprint in my mind doesn't refer to download size which is minimal in either case but the footprint or impact on a project. IMO It is way harder to move off of jquery once it has been fully utilized throughout the project than to swap a single function to/from lodash once a core API has a better way of handling it. Using JQuery demands you buy into the whole ecosystem whereas Lodash is modular.

Also as others have mentioned caches are individually isolated for each domain now to prevent tracking/data leaks.

Firefox and Safari use partitioned caches, and Chrome is following with the feature behind an experiment flag for now. The argument that it's probably cached from a CDN is just about dead.

> If you're building something like Spotify/Slack, I can maybe see the need for virtual DOMs

Heck, even Slack was built with jQuery the first time. Only after a while they migrated to react.