Need advice about which tool to choose?Ask the StackShare community!
Closure Library vs jQuery: What are the differences?
1. Architecture: The Closure Library uses a modular architecture where components are organized in namespaces, providing a more structured approach. On the other hand, jQuery is based on a monolithic architecture with all functions and plugins in a single library, making it easier to get started but potentially leading to larger file sizes. 2. Performance: Closure Library tends to have better performance in terms of speed and memory usage due to its optimized code and static type checking. jQuery, although easy to use, may sometimes face performance issues depending on the complexity of the script. 3. Dependency Management: Closure Library has built-in dependency management, allowing developers to specify dependencies between modules and load only what is needed. jQuery relies on script loading mechanisms for handling dependencies, which can sometimes lead to conflicts or inefficient loading sequences. 4. Browser Compatibility: Closure Library puts a strong emphasis on cross-browser compatibility and handles browser quirks and inconsistencies efficiently. jQuery also provides cross-browser compatibility, but it may require additional plugins or workarounds in certain cases. 5. Community and Support: jQuery has a larger community and more extensive resources readily available, making it easier for developers to find solutions and plugins. Closure Library, although backed by Google, has a smaller community and fewer third-party plugins or extensions available for use. 6. Learning Curve: Closure Library requires a more significant learning curve due to its structured approach and complex concepts like namespaces and modules. In contrast, jQuery is relatively easy to learn, making it a popular choice for beginners or projects with tight deadlines.
In Summary, Closure Library and jQuery differ in architecture, performance, dependency management, browser compatibility, community support, and learning curve.
I have made an extended effort to drop frameworks completely if they are not actually needed. While I still use JS Frameworks like Vue, Angular and React ( if I have too ), I see far too often devs / teams deciding to build a single page site entirely in a framework, rather than just using HTML, CSS and a little JS.
I personally feel it's important to know when a framework is a good solution, and maybe when it's overkill.
The project is a web gadget previously made using vanilla script and JQuery, It is a part of the "Quicktext" platform and offers an in-app live & customizable messaging widget. We made that remake with React eco-system and Typescript and we're so far happy with results. We gained tons of TS features, React scaling & re-usabilities capabilities and much more!
What do you think?
I've an eCommerce platform building using Laravel, MySQL and jQuery. It's working good and if anyone become interested, I just deploy the entire source cod e in environment / Hosting. This is not a good model of course. Because everyone ask for small or large amount of change and I had to do this. Imagine when there will be 100 separate deploy and I had to manage 100 separate source. So How do I make my system architecture so that I'll have a core / base source code. To make any any change / update on specific deployment, it will be theme / plugin / extension based . Also if I introduce an API layer then I could handle the Web, Mobile App and POS as well ? Is the API should be part of source code or a individual single API and all the deployment will use that API ?
When I started TipMe, I thought about using React frontend. At the end, plain, simple jQuery won.
I had to build this iteration of the site fast and by using jQuery I could keep using Django as a full stack development tool. One important point is Django form (combined with Django Bootstrap3) means that I don't have to reinvent form rendering again, which will be the case with React.
Over time, more interactivity seeped into the site and React components start making its way into the codebase.
I now wish the site is built using React so that I could add more user friendly interfaces easier (no more fuddling with server states) but I would still say jQuery helped me get past those early days.
Pros of Closure Library
Pros of jQuery
- Cross-browser1.3K
- Dom manipulation957
- Power809
- Open source660
- Plugins610
- Easy459
- Popular395
- Feature-rich350
- Html5281
- Light weight227
- Simple93
- Great community84
- CSS3 Compliant79
- Mobile friendly69
- Fast67
- Intuitive43
- Swiss Army knife for webdev42
- Huge Community35
- Easy to learn11
- Clean code4
- Because of Ajax request :)3
- Powerful2
- Nice2
- Just awesome2
- Used everywhere2
- Improves productivity1
- Javascript1
- Easy Setup1
- Open Source, Simple, Easy Setup1
- It Just Works1
- Industry acceptance1
- Allows great manipulation of HTML and CSS1
- Widely Used1
- I love jQuery1
Sign up to add or upvote prosMake informed product decisions
Cons of Closure Library
Cons of jQuery
- Large size6
- Sometimes inconsistent API5
- Encourages DOM as primary data source5
- Live events is overly complex feature2