Not relevant to this package in particular, but this line of reasoning baffles me every time I see HN comments about JQuery. So many posters argue against the use of JQuery because of its package size and bandwidth constraints, while simultaneously advocating for SPA frameworks that use orders of magnitude more bandwidth. Absolutely ridiculous cargo cult reasoning.
IMHO the way to achieve this is to pay the upfront cost of building out a small framework for your application, which has lightweight abstractions for common patterns. With some design, a small internal API can be as nice to work with as the kitchen sink abstractions. (Much nicer, too, when it comes to maintenance and debugging.)
> IMHO the way to achieve this is to pay the upfront cost of building out a small framework for your application
And then 5 years down the line it has grown into a worse version of the popular alternatives, the original developers are gone and the ones who currently maintain the mess have to pay the price. In corporate or professional contexts, you probably just should pick whatever is popular.
When you’re working on something others won’t have to maintain years down the line, thankfully your hands aren’t tied then and you can have a bit more fun.
For everything else? Svelte, HTMX, jQuery, Vue, React, Angular or whatever else makes sense.
That said, sometimes I wonder what a world would look like, where the browser would have the most popular options pre-packaged in a way where you wouldn’t need to download hundreds of KB in each site you visit, but you’d get the packages with browser updates. It’d probably save petabytes of data.
> And then 5 years down the line it has grown into a worse version of the popular alternatives, the original developers are gone and the ones who currently maintain the mess have to pay the price.
Isn't that true for using the popular alternative too? At some point the original devs have moved on from $FRAMEWORK v1 to $FRAMEWORK v2 and now you're going to have to do a migration project and hope it doesn't break.
> When you’re working on something others won’t have to maintain years down the line, thankfully your hands aren’t tied then and you can have a bit more fun.
I think the implication is, with the in-house library, that the in-house library would be a lot easier to replace or update than a deprecated external alternative.
No one's forcing you to upgrade when the framework does. We still have a Vue 2.7 codebase chugging along just fine and won't upgrade it unless truly necessary.
> There is probably a tickbox for satisfying some regulation that says "Don't use versions that aren't getting security fixes anymore"
In theory, yes, that would be bad. But we're talking about JS frameworks here, not C++ libraries. Go look at the CVEs for React and you will find 2-3 in the past 10 years that were patched out in minor version upgrades.
There is a difference between updates due to security and updates due to wanting to use the newest shiny tool. JS is a slow moving language and browsers are excellent sandbox environments. This combo means browsers still support old versions of a lot of libraries and they are completely secure, save a few examples.
So if you're telling me a company is forcing everyone to upgrade to the latest Angular/React/Vue for security reasons, I would say they unfortunately don't know what they're talking about.
The thing is that while your application is working well, the library authors would have moved on and it's up to you to upgrade your application and fix breaking changes. At least with an in-house framework, it's always morphing into something that the company needs. Not saying that there aren't nicer framework, but it's always someone agenda that has aligned with yours at the time of selection.
> The thing is that while your application is working well, the library authors would have moved on and it's up to you to upgrade your application and fix breaking changes.
AngularJS is actually a pretty good argument to support your point, I had to migrate an app off of it (we picked Vue as the successor) and it was quite the pain, because a lot of the code was already a bit messy and the concepts don't carry over all that nicely, especially if you want something quite close to the old implementation, functionality wise.
On the other hand, jQuery just seems to be trucking along throughout the years. There are cases like Vue 2 to Vue 3 migrations which can also have growing pains, but I think that the likes of Vue, React and Angular are generally unlikely to be abandoned, even with growing pains along the way.
In that regard, your job as a developer is probably to pick whatever might have the least amount of surprises, the most longevity and the lowest chance of you having to maintain it yourself and instead being able to coast off of the work of others (and maybe contributing, if you have the time), with the project having hundreds if not thousands of contributors, which will often be better than what a few people within any given org could achieve.
Sometimes that might even be reaching for something like SSR instead of making SPAs, depending on what you can get away with. One can probably talk about Boring Technology or Lindy effect here.
I think, in view of my previous comment which was made prior to reading this refinement of yours, that it all very much depends on whether you are choosing something that is designed to be replaced vs something that is not.
Sorta along the lines of the mantra "Don't design your code for extendability, design it for replaceability" (not sure where I read that).
> with the project having hundreds if not thousands of contributors, which will often be better than what a few people within any given org could achieve.
The upside of "what a few people within the org could achieve" is that a couple of devs spending a few weeks on a project are never going to make something that cannot also be replaced by a different couple of developers of a similar timeframe.
IOW, small efforts are two-way doors; large efforts (thousands of contributors over 5 years) are effectively one-way doors.
> Sorta along the lines of the mantra "Don't design your code for extendability, design it for replaceability" (not sure where I read that).
I agree in principle and strive to do that myself, but it has almost never been my experience with code written by others across bunches of projects.
Anything developed in house without the explicit goal of being reusable across numerous other projects (e.g. having a framework team within the org) always ends up tightly coupled to the codebase to a degree where throwing it away is basically impossible. E.g. other people typically build bits of frameworks that infect the whole project, rather than decoupled libraries that can be swapped out.
> The upside of "what a few people within the org could achieve" is that a couple of devs spending a few weeks on a project are never going to make something that cannot also be replaced by a different couple of developers of a similar timeframe.
Because of the above, this also becomes really difficult - you end up with underdocumented and overly specific codebases vs community efforts that are basically forced to think about onboarding and being adaptable enough for all of the common use cases.
Instead, these codebases will often turn to shit, due to not enough people caring and not being exposed to enough eyes to make up for whatever shortcomings a small group of individuals might have on a technical level. This is especially common in 5-10 year old codebases that have been developed by multiple smaller orgs along the way (one at a time, then inherited by someone else).
Maybe it’s my fault for not working with the mythical staff engineers that’d get everything right, but so don’t most people - they work with colleagues that are mostly concerned with shipping whatever works, not how things will be 5 years down the line and I don’t blame them.
We're using jQuery on our sites which score 100% on all Google Lighthouse pagespeed tests. A smaller version of jQuery really wouldn't matter to us, our pages are already extremely fast to load and score amazingly well on any page speed/SEO test.
About the only place I could see a benefit from this library is maybe in embedded, where space really is an issue. I've created a few IoT devices with web interfaces that are built-into the tiny ROM of the device. A 6KB library is nice, but I'm using Preact with everything gzipped in one single .html file and my very complex web app hosted in the IoT device is about 50KB total size gzipped - including code, content, SVG images and everything, so jQuery or a JQ substitute isn't going to be a better solution for me, but maybe it fits for someone that doesn't know how to set up the tooling for a react/preact app.
To add, I really try to minimize external deps but if first-load speed were absolutely critical loading from jQuery CDN would increase odds of it already being cached..
We don't make any external HTTP requests for any library code. jQuery is embedded into the page HTML file, along with all other required library code necessary for the page to start functioning, in one bundle. Nothing that runs below the fold is executed until the page is scrolled. All scripts are deferred, except the required libraries, one of which is jQuery and is loaded in-line in a <script> block in the page <head>. There's a ton of tricks we use to get to a perfect Google Lighthouse score - we also score perfect 100% on mobile too. This isn't a complex web application but we do a lot of cool front-end stuff.
That's great and fair. Some places are NUTS about first page load speed(and I mean first time someone has ever visited the site) though and it really could matter across all deps depending on a ton of other factors..
Serving super common libs, like jQuery, from the lost likely CDN location could maximize the likelihood it's already cached.
I have never personally worked anywhere this mattered.
We provide a website among many other services to our clients. Our clients are very SEO focused, and they will go to Google's Lighthouse (or another testing site) to test their site's page speed, and then they will put in the URL for their competition's website to see how their site compares to their competitors. If they see their page speed score is 1/2 as fast as their competition, they have a reason to leave us and find a better host (whoever their competition is using). We have thousands of clients, so I am managing thousands of individual customized websites based on core "white-label" template code. Page speed matters to us very much, because it matters to our clients.
Google Lighthouse will complain about every HTTP request, and it doesn't care about CDN caching, because none of the external code will be cached when the test is run. It will tell you to minimize external HTTP requests. This is the same way every page speed test works, not just Google. So including any external dependency will cause the page speed score to go down a bit. Have enough of them and your page speed score ends up being very poor (many other factors can affect this, all of which are detailed in the Lighthouse report). It doesn't matter what the average site visitor experiences if their cache has jQuery in it from some random CDN. The only thing that really matters is that Google is telling our client that their site is performing badly compared to their competitor's site.
So, my job is to make sure our clients never, ever think about leaving us because of page load speed as measured by Google or any other testing site. Our clients pay us hundreds of dollars every month, some of them pay 10s of thousands depending on their needs (we don't just provide websites). So there is a lot of money at stake. Page speed scores matter very much to us. When our client sees their site is scoring perfect 100% on all Lighthouse tests, and their competitor is scoring a 70%, then we win, and the client has one less reason to leave. We even use this as a selling point to bring on new clients, because we have an absolutely untouchable page speed score compared to our competitors in this space.
I'm not sure what to say, I believe you but you seem to be talking past my point that other companies may prefer to go a different route based on their needs and what they are optimizing for. There are real situations a CDN may be preferred.
Companies that are using CDNs to load commonly used libraries aren't actually interested in page load speed scores. They're pursuing a tech trick that was always somewhat of a red herring, and frankly a bit risky. We've experimented with CDNs and they have actually added stuff to the libraries that shouldn't be there. Trusting a 3rd party to load library code from isn't great for security.
Using jQuery CDN might have helped with cross-site caching in the past, but now all major browsers have cache partitioning by origin for privacy reasons.
A. You're assuming they are largely the same people by extrapolating from your observations. It's impossible to actually know.
B. Your two examples provide different things. This is like saying it's OK to include any old multi-megabyte dependency if a site loads a couple mb worth of images. There's no reason to stop considering the size of the small parts just because you decided you need some large parts. Things add up - that will never stop being a useful thing to remember, in any context.
