Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
147315 stories
·
32 followers

Atari’s resurrecting the Intellivision, one of its biggest competitors in the ‘80s

1 Share
The Atari Intellivision Sprint console against an illustrated background.
The Intellivision Sprint features the same unique controllers as the original, but they’re now wireless and rechargeable. | Image: Atari

Atari has announced yet another retro console revival, but this time it’s launching hardware from an old competitor.

Atari and Plaion, a company that develops, publishes, and distributes games, have collaborated on the new Intellivision Sprint that blends ‘80s console aesthetics with modern gaming conveniences. It’s a new take on Mattel’s Intellivision, which initially went head-to-head with the Atari 2600 when it was released in 1979.

The Sprint looks a lot like the original Intellivision with a gold and black case and a wood-grain panel on the front, but there are a lot fewer cables. It connects to a TV using a single HDMI cable, and while it still includes two controllers featuring dials and number pads instead of joysticks, they’re both wireless and charge when docked to the console.

A close-up of the Atari Intellivision Sprint controller with several overlays next to it.

The Sprint has the original Intellivision’s number pad overlays, but with new designs and updated artwork to make it easier to know what buttons you need to press to play different games. It comes with 45 built-in titles, including classics like Boulder Dash and Astrosmash, plus a collection of sports games that helped popularize the original version of the console. It lacks support for cartridges, but there’s USB-A ports that can be used to play additional titles or to connect original Intellivision controllers with an adapter.

It’s available for preorder starting today for $149.99 and is expected to ship on December 5th, 2025.

Read the whole story
alvinashcraft
3 hours ago
reply
Pennsylvania, USA
Share this story
Delete

Microsoft releases PowerToys 0.95 with speed improvements and new Light Switch

1 Share
Microsoft has unleashed PowerToys v0.95, and it is an impressive one. This is a release cycle which is billed as offering “new features, stability, optimization improvements, and automation”, and that’s very much what this particular release is about. The first thing to ask about any new PowerToys release is whether there are any new modules. And this time around the answer is a resounding “yes”. In addition to a raft of changes, improvements and optimizations across the suite of utilities, there is also the new Light Switch module. While you might think that Light Switch is somehow connected to home… [Continue Reading]
Read the whole story
alvinashcraft
3 hours ago
reply
Pennsylvania, USA
Share this story
Delete

Accelerate developer productivity with these 9 open source AI and MCP projects

1 Share

With the emergence and rise of Model Context Protocol (MCP), developers are discovering revolutionary ways for AI and agents to interact with tools, codebases, and even browsers.  

Building on top of the core technology, we are seeing projects, such as browser extensions and tools within code editors, enabling AI-native workflows and unlocking a new category of agentic tooling: innovative ecosystems and new projects focused on MCP-powered capabilities are changing the way we work. 

In partnership with the Microsoft Open Source Program Office (OSPO), the GitHub Copilot and VS Code teams sponsored nine projects to accelerate innovation, security, and sustainability within open source. Below you’ll find the projects and the three major themes we’re seeing across their work.

Framework and platform integrations: Ecosystem integrations for real-world use cases  

These projects integrate bring MCP capabilities into popular frameworks and ecosystems for AI-native tooling and help MCP with widely used platforms, and enable agents to interact with real-world apps and workflows: 

  • fastapi_mcp: Expose secure FastAPI endpoints as MCP tools with minimal setup, authentication, and limited configuration—all with a unified infrastructure. 
  • nuxt-mcp: Nuxt developer tools for route inspection and SSR debugging make it easier for your team to make models understand your Vite/Nuxt app better. 
  • unity-mcp: Unity MCP allows you to interface with game engine APIs for AI-assisted game development and gives your AI tools to manage assets, control scenes, edit scripts, and automate tasks within Unity 

Developer experience and AI-enhanced coding: AI-first developer productivity  

These projects empower AI,  LLMs and agents to act as intelligent IDE assistants and code editors by improving developer workflows, semantic code understanding, and safe code execution.

  • context7: Context7 pulls up-to-date, version-specific documentation and code examples straight from your code and plugs them directly into your AI and LLM prompts LLM’s context.  
  • serena: Semantic code editing and retrieval for agent-driven coding agent toolkit providing semantic retrieval and editing capabilities.  
  • Peekaboo: Swift code analysis that turns what’s on your screen into actionable AI context to create full GUI automation, and can be used for AI assistants.  
  • coderunner: Coderunner turns LLMs into an instant, local execution partner that writes and runs code in a preconfigured sandbox on your machine, auto-installs tools, directly reads files, and returns outputs and generated artifacts. 

Automation, testing and orchestration: Reliability and quality assurance for MCP infrastructure 

These projects help extend MCP infrastructure into production grade tools for automation pipelines and providing robust testing, and debugging tools. These help ensure you can run MCP at scale. 

 MCP server evaluation: 

  • n8n-mcp: n8n-MCP is an ultra-optimized platform that enhances n8n’s workflow automation by streamlining workflow creation and orchestration. It integrates AI models to help users better understand and work with n8n nodes.
  • inspector: A tool for testing and debugging MCP servers by inspecting protocol handshake, tools, resources, prompts, and OAuth flows. It offers a built-in LLM playground and lets you run eval simulations to catch security or performance regressions.  

AI workflows and agentic developer productivity with MCP and open source 

Developers are building at incredible speed with the power of AI and MCP. These projects represent some of the fastest growing developer tools within the MCP ecosystem and community. They are tools that developers use and care about. GitHub Copilot and VS Code teams are excited to sponsor more open source projects that drive new innovations like MCP for agent-native development. 


Sign up for GitHub Sponsors today to join us in sponsoring these projects (and more!) and help support the MCP ecosystem. You can also start exploring MCP with VS Code and GitHub Copilot today!

The post Accelerate developer productivity with these 9 open source AI and MCP projects appeared first on The GitHub Blog.

Read the whole story
alvinashcraft
3 hours ago
reply
Pennsylvania, USA
Share this story
Delete

CSS Finally Gets Inline Conditional Logic With New if() Function

1 Share

Inline conditional processing is coming to CSS.

Those who have felt boxed in by the web’s universal style sheets’ declarative nature are about to enjoy a bit more freedom to mix it up a bit.

For years, devs and designers have asked in Stack Overflow and elsewhere if CSS had any conditional logic, finding only workarounds as a possibility. Now, the technical committee behind the style standard has ratified a new function for the style sheet, if(), which opens up a whole new world of choice for designers.

“This is the first time, that I’m aware of, that you can do this logic inline and not have a dedicated code block on the bottom of your file,” said Mark Adkins, a principal user experience designer at financial firm Fidelity Investments, in a talk about some of the latest developments with CSS at the AllThingsOpen 2025 conference earlier this week.

Managed by the World Wide Web Consortium (W3C), CSS is the standardized way of specifying the presentation, styling and layout of web pages, working alongside HTML for the layout of the pages and JavaScript for their logic.

CSS is a mature technology, so it doesn’t get updated as much as it used to. Once a year, W3C issues a snapshot that aggregates all the latest developments across different parts of the specification (2025’s edition was posted last month). It is then up to the browser makers to see these specs get implemented, the progress of which has been dutifully tracked by the Can I use site.

What Is the CSS if() Function?

The new function, arriving in the 2025 snapshot, is unprecedented for CSS.

“This one really caught me off guard,” admitted Adkins to the audience.

While most of CSS is about the shading and coloring and various other details of presentation, the spec has not offered much in the way of logic processing.

If() builds from previous work to allow developers to specify variables, or “custom properties,” Adkins said. The properties, defined in the browser’s Document Object Model (DOM), can then be changed with JavaScript.

The new functionality extends logic properties into the inline code itself.

In the world of programming, the if() function itself is nothing new — most imperative languages have a version of the function. The if() function is based on the JavaScript if … else function, and provides a way for the programmer to set different values of a property depending on the result of a conditional test. If a then x, if b then y, and so on.

You can also supply an else statement if none of the conditionals are met.

In the case of CSS, the test can be based on a style query, a media query or a feature query.

How the if() Function Works in CSS

According to the specification, the statement consists of an ordered semi-colon-separated list of statements, each specifying a condition and a value, separated by a colon.

The function’s syntax, as purloined Mozilla Development Network docs, can be seen here:

MDN also provides an example of how if() could be used: Below, you will find that one of two background images can be deployed on a web page depending on which theme is chosen (“ice” or “fire”):

The function can be built into any property of a class, or as part of a selector, Adkins said.

Current Browser Adoption and Support

Currently, the if() function is only partially supported across browsers.

test results

Browser support of the CSS if() function, as of October 2025. Source: Can I use.

Chrome and Edge support the function, while Safari and Firefox still lag behind. Mobile development lags even further, with only Chrome for Android and the Android browsers recognizing the statement.

Test results

Mobile browser support of the CSS if() function, as of October 2025. Source: Can I use.

New Possibilities With CSS Conditionals

“The addition of if() provides a new architectural opportunity for CSS developers,” wrote Google Web UI DevRel Lead Una Kravets in a blog post describing the ways the new conditional could be used.

The function could be used to create inline media queries, Kravets suggested. As an example, a website could change designs based on the user’s preference for light or dark mode. It could also be used to do inline support queries, checking to see if the hardware supports the design, and switching to an alternative design if not. It could be a handy way to visualize the state of a running process, with different images designating whether the job is finished or not.

The post CSS Finally Gets Inline Conditional Logic With New if() Function appeared first on The New Stack.

Read the whole story
alvinashcraft
3 hours ago
reply
Pennsylvania, USA
Share this story
Delete

How to Disable WordPress File Editing for Better Security (Complete Guide)

1 Share

Being able to access your WordPress files directly within your dashboard is handy. You can jump in, tweak code, and save changes instantly. However, this convenience has a downside: If a hacker ever gains admin access, the file editor becomes an easy way for them to inject malicious code.

This is why many site owners choose to turn off file editing altogether.

In this guide, you’ll learn how to disable file editing in WordPress, why it’s crucial for protecting your site, and what to check afterward to keep everything running smoothly.

Why WordPress file editing is a security risk

WordPress includes two built-in editors that let administrators open and edit PHP files right from the dashboard. Depending on the type of theme you’re using, you’ll find them in slightly different places:

Classic Editor:

  • Appearance → Theme File Editor
  • Plugins → Plugin File Editor

Block themes ( Site Editor):

  • Tools → Theme File Editor
  • Tools → Plugin File Editor

At first glance, this seems convenient — you can tweak code without leaving your site. But here’s the catch: the same power is available to anyone with administrator access. If an attacker breaks into an admin account, they can inject malicious code, create backdoors, or even take the site offline.

Disabling the editors doesn’t mean you lose the ability to make changes. You (or your developer) can still access all theme and plugin files directly through your web server, SFTP, or hosting control panel. All you’re doing is removing an unnecessary shortcut that poses a significant security risk.

Disable file editing via wp-config.php

The wp-config.php file stores settings that control how WordPress runs. Any changes you make here will remain in place, even after WordPress updates. Plus, if you ever need to restore the in-dashboard editors, you can simply remove the code you added.

To edit this file, you’ll need access to your WordPress root folder using SFTP, SSH, or your host’s file manager. This folder is usually named public_html, or it may be a subfolder inside. If you’re unsure where your installation is, check your hosting dashboard or ask your web host.

Here’s how to turn off file editing:

  1. Locate the file called wp-config.php in your site’s root folder.
  2. Open it and look for the line that says: /* That’s all, stop editing! Happy blogging. */
  3. Just above that line, add: define(‘DISALLOW_FILE_EDIT’, true);
  4. Save the file (and re-upload it if you used SFTP).

That’s it! You’ve disabled file editing from the WordPress dashboard.

Using the DISALLOW_FILE_MODS constant

If you want an even stricter setup, WordPress also supports DISALLOW_FILE_MODS. This setting is handy for high-security production sites where stability is more important than convenience.

This constant goes beyond removing file editing from your dashboard. Once added, it blocks the installation and updating of plugins, themes, and WordPress core from the admin dashboard.

Add this line to your wp-config.php file instead:

define('DISALLOW_FILE_MODS', true);

As with the DISALLOW_FILE_EDIT constant, you can still update everything manually via SFTP or your hosting control panel. These settings give you complete control while protecting your site from accidental or unauthorized changes.

How to check if file editing is disabled

After adding the code to your wp-config.php file, log in to your WordPress dashboard and check the location of the Theme File Editor and Plugin File Editor, depending on your theme (see above.)

If both links are gone, your changes were successful.

If the editors are still visible, try these troubleshooting steps:

  • Clear your browser and site cache.
  • Make sure you edited the correct file.
  • Double-check your syntax — a missing semicolon or incorrect quote can break the code.

Once everything is correct, you won’t be able to access these editors from the WordPress dashboard.

Re-enabling file editing

One advantage of removing file editing with the wp-config.php file is the ease of re-enabling it. If you ever need to restore file editing, you can simply remove your constants. 

Instead of deleting the line, consider commenting it out. This way, you can easily disable file editing again by simply removing the forward slashes (//), which helps maintain your site’s security. To do this:

  1. Open your wp-config.php file.
  2. Delete or comment out the line you added: // define(‘DISALLOW_FILE_EDIT’, true);
  3. Save the file and reload your WordPress dashboard.

Once saved, the editor links will reappear, allowing you to make necessary changes. 

Man working on his laptop in an office with a lot of natural light.

Other ways to protect your site

Hardening your WordPress site with multiple layers of protection makes it more difficult for hackers to breach it. Disabling file editing is a good start, but it should be just one part of a broader security strategy.

Here are some simple steps that can make a big difference:

  • Use strong passwords: Make them long and unique — consider using a password manager to help you remember.
  • Enable two-factor authentication (2FA): A second verification step makes logins much safer.
  • Keep everything updated: This includes themes, plugins, and WordPress core.
  • Limit admin access: Only give administrator privileges to users who truly need them.
  • Use a security plugin: Scan for malware, monitor activity, and block suspicious logins.
  • Back up your site regularly: This allows you to restore quickly if something goes wrong.

Combined with disabling file editing, these steps give your WordPress site a strong defense.

How Jetpack Security helps you go further

Turning off file editing is just one part of keeping your site safe. To protect your WordPress site comprehensively, you need tools that detect problems early, fix them quickly, and safeguard your data.

That’s where Jetpack Security comes in. It’s a bundle of tools built specifically for WordPress that strengthens your site across the board.

Jetpack Security includes:

  • Jetpack VaultPress Backup, which backs up your site in real time. If something goes wrong, you can restore everything with a single click.
  • Jetpack Scan, which monitors your site for malware, security issues, and suspicious changes. It sends automatic alerts so you can take action before visitors encounter problems.
  • Akismet, which blocks spam in comments and contact forms. Attackers often use spam to inject harmful links or scripts, and Akismet filters it out without slowing your site down.
  • A website application firewall, which blocks suspicious traffic from reaching your site.

These tools run quietly in the background, and you can access them all through the Jetpack dashboard. This lets you handle backups, security scans, and spam protection without juggling multiple accounts or plugins.

If you want a reliable, full-featured security setup that protects your site daily, Jetpack Security brings everything together in one package. It works smoothly with most themes and plugins and gives you peace of mind with minimal effort.

Frequently asked questions

Can I remove the theme editing and leave the plugin editing?

There’s no built-in way to block one while keeping the other. WordPress doesn’t separate the theme and plugin editors. When you use DISALLOW_FILE_EDIT, both editors disappear. 

Can I control this based on user roles?

While possible, it can get complicated. You could create a custom role that removes file editing capabilities using a plugin, but WordPress doesn’t have a capability specifically for file editing.

The editor relies on general permissions like edit_themes or edit_plugins, and removing those may break other admin functions. Disabling file editing via the wp-config.php file is the easiest and safest approach for most sites.

Can I still edit files another way?

Yes. Disabling the dashboard editor doesn’t prevent you from editing files through SFTP clients like FileZilla or Cyberduck, your web host’s file manager, Git deployments, or local development environments. You’re removing a feature that could pose a risk if a malicious actor gains access to an admin login.





Read the whole story
alvinashcraft
3 hours ago
reply
Pennsylvania, USA
Share this story
Delete

Why I Still Use jQuery

1 Share
undefined Imgur

jQuery is a household name among web developers who have been around the block. Initially released in 2006, it took the web development world by storm with its easy and intuitive syntax for navigating a document, selecting DOM elements, handling events, and making AJAX requests. At its peak in 2015, jQuery featured on 62.7 percent of the top one million websites and 17 percent of all Internet websites.

A decade later, jQuery is not the shiny new kid on the block anymore. Most of the original pain points jQuery solved, such as DOM manipulation and inconsistent browser behavior, are gone thanks to modern browser APIs. 

But jQuery is still widely used. According to SimilarWeb, as of August 11, 2025, nearly 195 million websites use it. That means many developers, like me, still use it every day. And like me, you might prefer it in certain cases. 

So, in this article, I’ll share when it still makes sense to use jQuery and when not. Don’t worry: I’m not arguing we should replace React with jQuery. And I’m not here to romanticize 2008. In 2025, I simply still find myself reaching for jQuery because it’s the right tool for the job. 

A Brief History of jQuery

To determine when it makes sense to use jQuery and when not, it helps to know why it was created in the first place and what problems it aimed to solve.

When John Resig launched jQuery at BarCamp NYC in January 2006, the web was a different place. Features we take for granted today were absent from most browsers:

  • No querySelectorAll: Selecting DOM elements across browsers was messy. In the mid-2000s, none of the available element selectors, like getElementById or getElementsByClassName, could select elements using complex CSS queries.
  • Inconsistent event handling: addEventListener wasn’t universal. While browsers like Firefox, Safari, and Chrome supported the W3C event model with addEventListener, Internet Explorer (before IE9) used Microsoft’s proprietary model with attachEvent. These two models differed from each other in almost all functional aspects.
  • Different browsers had different APIs for XMLHttpRequest. While browsers like Firefox and Safari offered the familiar XMLHttpRequest, Internet Explorer (before IE7) used ActiveX objects to give JavaScript network capabilities. This meant you had to use a bunch of if-else blocks to make an AJAX request.
  • CSS manipulation quirks: In the 2000s and early 2010s, many CSS features were implemented inconsistently across browsers, which made it difficult to manipulate CSS with JS.

jQuery solved all of this with a simple, chainable syntax and consistent cross-browser behavior. It offered a streamlined, chainable API for DOM traversal, event handling, and AJAX—far simpler than cross-browser native JavaScript at the time. These features made jQuery become the go-to JavaScript library in the 2010s, powering everything from personal blogs to Fortune 500 sites. In 2012, a W3Techs survey found that jQuery was running on 50 percent of all websites, and by 62.7 percent of the top 1M websites used it.

Where jQuery Still Makes Sense

Although jQuery’s glory days are clearly behind us, it still works well in some situations. Here are the scenarios where I still choose jQuery:

Legacy Projects

Even now in 2025, a W3Techs survey shows that jQuery is used in 77.8 percent of the top 10M websites in 2025. This is mostly legacy usage—old apps that use jQuery because switching to a more modern framework is a costly endeavour. This is clear when you look at the version statistics. In a 2023 survey across 500 organizations, only 44 percent use maintained versions (3.6.0 or newer), while 59 percent run older versions (1.x to 3.5.1)

I maintain a few legacy projects like these that were written with jQuery, and I can tell you why they’re still around: they just work. So as the adage goes, “If it ain’t broke, don’t fix it.” 

Many large enterprises, government sites, corporate intranets, and many WordPress plugins and themes still rely on jQuery. Rewriting these sites to pure JavaScript or a modern framework is a time-consuming, expensive endeavour that can also introduce new challenges and bugs. Most of the time, all that effort and risk aren’t worth the relatively small benefits in the short term.

The truth is this: the codebase I inherited, built in the jQuery era, works. The business logic is robust, the profit margins are healthy, and—most surprisingly—shipping new features feels like slipping into a worn leather jacket: unfashionable, but comfortable. - Marc Boisvert-Duprs

Yes, most jQuery plugins are no longer actively maintained or have been deprecated, so depending on them is a security risk. Abandoned plugins may become incompatible or insecure as browsers continue to evolve. So, legacy projects that use jQuery and jQuery plugins should eventually migrate away from jQuery.

Quick Prototyping without Build Tools

Developers often need to prototype very simple frontend apps, be it for throwaway demos, internal tools, or proof-of-concept pages. Sometimes the spec may even require a very basic frontend with minimal interactivity (for example, a static page with a simple form and a button).

jQuery is a perfect choice for these situations. Simply drop in a <script> tag from a CDN and get animations, DOM manipulation, and AJAX in minutes—no need for npm, bundlers, transpilers, or complicated frameworks with hundreds of dependencies. It’s also great for running quick commands from the DevTools console, especially if you want to experiment with an app. 

But why not use a more modern but lightweight framework like Alpine.js? Personally, I’m intimately familiar with jQuery: I’ve used it since the beginning of my web development journey. I love its simplicity and ease of use. The minor improvements a new framework can make in this scenario don’t offset the time spent learning a new tool.

Complex DOM Manipulation in Different Browser Contexts

Hopefully, you don’t have to support older browsers that lack the standard querySelector, or browsers like Internet Explorer, notorious for their non-standard behavior. Unfortunately, some of us still need to maintain apps that run on these browsers.

While native JS is perfectly fine for modern browsers, if you’re building something that has to run on older embedded browsers (think: kiosk software, older enterprise or university intranets, or web apps inside legacy desktop apps), jQuery’s normalization saves you from manual polyfilling, and its CSS selector lets you perform complex DOM manipulations easily.

Simple Animations without CSS Keyframes

As someone who primarily works with backend apps, I don’t often need to code animations for the frontend. But when I do need to create basic chained animations (fading, sliding, sequencing multiple elements, etc.), jQuery’s .animate()is simpler (and more lightweight) to write than juggling CSS animations and JS event callbacks.

Simple AJAX with HTML Server Responses

I was recently tasked to make some upgrades to an ancient app with a PHP backend. Imagine my surprise when I discovered that the server returns HTML fragments, and not JSON APIs. In this case, jQuery’s .load() and .html() methods can be simpler and more efficient than writing fetch() boilerplate with DOM parsing.

For example, I can extract a DOM element from the results of an AJAX request, and load it into an element like so:

// Replace #comments with just the #comments-list from the server response
$('#comments').load('/article/1 #comments-list');

Whereas the same thing in native JS would be:

fetch('/article/1')
  .then(res => res.text())
  .then(html => {
    const doc = new DOMParser().parseFromString(html, 'text/html');
    const comments = doc.querySelector('#comments-list');
    document.querySelector('#comments').innerHTML = comments.outerHTML;
 })

Yes, while the jQuery syntax is more straightforward, both approaches are doing the same thing under the hood, so there’s not a huge performance gain. In the jQuery version, you also have the added overhead of bundling the jQuery library. So, it’s a tradeoff between simplicity and bundle size.

When You Should Not Use jQuery

While jQuery still makes sense in some situations, there are some cases where I would never use jQuery.

Building a Modern, Component-Driven Frontend

If I’m building a modern frontend app with lots of reactivity and reusable components, I’d use a modern framework like React or Vue with native features for DOM manipulation.

Frameworks like React, Vue, Svelte, or Angular handle DOM rendering in a virtualised way. Direct DOM manipulation with jQuery conflicts with their data-binding approach, causing state mismatches and bugs. 

For example, in React, calling $('#el').html('...') bypasses React’s virtual DOM and React won’t know about the change. This will inevitably lead to bugs that are difficult to diagnose.

When Simple Vanilla JS Is Enough

Most of jQuery’s once-killer features, such as selectors, AJAX, events, and animations, are now native in JavaScript:

  • document.querySelectorAll() replaces $().
  • fetch() replaces $.ajax().
  • element.classList replaces .addClass()/ .removeClass().
  • element.animate() handles animations.

If I’m just toggling classes or making a fetch call, adding jQuery is wasteful.

Targeting Modern Browsers Only

jQuery’s major draw between 2008 and 2015 was its cross-browser compatibility, which was necessary due to quirks in IE6–IE9. It simply wasn’t practical to write browser-specific JS for all the different versions of IE. With jQuery, the quirks were abstracted away.

When IE was discontinued, this usefulness is no longer relevant. 

So if the app I’m working on needs to support only modern browsers, I don’t need most of jQuery’s compatibility layer.

Projects Already Using Modern Tooling

Mixing jQuery and framework code leads to a “hybrid monster” that’s difficult to maintain. 

jQuery can conflict with existing frameworks, which can cause hard-to-fix bugs. If my project is already written in another framework, I avoid including jQuery.

Alternatives to jQuery

Sometimes, I need to use some features of jQuery, but I can’t justify including it in its entirety.  Here are some libraries I use in cases like these. 

DOM Selection and Traversal

  • Native DOM API (most common replacement) using document.querySelector() and document.querySelectorAll()
  • Cash: jQuery-like API, tiny (~10KB), works with modern browsers
  • Zepto.js: lightweight jQuery-compatible library for mobile-first projects

AJAX/HTTP Requests

  • Native fetch() API
  • Axios: promise-based HTTP client with interceptors and JSON handling.

Event Handling

  • Native events using element.addEventListener()
  • delegate-it: small utility for jQuery-style event delegation

Animations

  • CSS transitions and animations (native, GPU-accelerated)
  • Web Animations API
  • GSAP: Powerful animation library, much more capable than .animate() in jQuery.

Utilities

* Lodash: collection iteration, object/array utilities, throttling, debouncing

* Day.js: date manipulation in a tiny package (instead of jQuery’s date plugins)

All-in-One Mini jQuery Replacements

If you still like a single API but want it lighter than jQuery:

  • Umbrella JS: ~3KB, jQuery-like API
  • Bliss: focuses on modern features, syntactic sugar, and chaining
  • Cash: as mentioned above, the closest modern equivalent

 jQuery Still Has a Job

In 2025, jQuery isn’t the cutting-edge choice for building complex, highly interactive single-page applications that it was in the 2010s, and that’s perfectly fine. While modern frameworks dominate the headlines, jQuery remains a reliable, well-understood tool that solves the problems it was designed for, simply and effectively.

In the end, the “right” tool is the one that meets your project’s needs, and for countless developers and businesses, jQuery continues to be that.

Read the whole story
alvinashcraft
3 hours ago
reply
Pennsylvania, USA
Share this story
Delete
Next Page of Stories