HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
ElliotNB
nimbly
JavaScript2019–2019
ElliotNB / nimbly

nimbly

Nimbly is a JavaScript component framework for single page applications.

3Distinct people
9Mentions
0Explicit recommenders
24GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Nimbly is a JavaScript component framework for single page applications.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by week9 dated mentions

Observed mentions: 2019-02-13 06:33:28 UTC to 2019-09-15 16:16:26 UTC. Weeks start Monday, UTC.

0122019-02-11 00:00:00 UTC to 2019-02-18 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsFeb 112019-02-18 00:00:00 UTC to 2019-02-25 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2019-02-25 00:00:00 UTC to 2019-03-04 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-03-04 00:00:00 UTC to 2019-03-11 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-03-11 00:00:00 UTC to 2019-03-18 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-03-18 00:00:00 UTC to 2019-03-25 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-03-25 00:00:00 UTC to 2019-04-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019-04-01 00:00:00 UTC to 2019-04-08 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-04-08 00:00:00 UTC to 2019-04-15 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2019-04-15 00:00:00 UTC to 2019-04-22 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-04-22 00:00:00 UTC to 2019-04-29 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-04-29 00:00:00 UTC to 2019-05-06 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-05-06 00:00:00 UTC to 2019-05-13 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-05-13 00:00:00 UTC to 2019-05-20 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2019-05-20 00:00:00 UTC to 2019-05-27 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-05-27 00:00:00 UTC to 2019-06-03 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsMay 272019-06-03 00:00:00 UTC to 2019-06-10 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-06-10 00:00:00 UTC to 2019-06-17 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-06-17 00:00:00 UTC to 2019-06-24 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-06-24 00:00:00 UTC to 2019-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-07-01 00:00:00 UTC to 2019-07-08 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-07-08 00:00:00 UTC to 2019-07-15 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-07-15 00:00:00 UTC to 2019-07-22 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-07-22 00:00:00 UTC to 2019-07-29 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-07-29 00:00:00 UTC to 2019-08-05 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-08-05 00:00:00 UTC to 2019-08-12 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-08-12 00:00:00 UTC to 2019-08-19 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-08-19 00:00:00 UTC to 2019-08-26 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-08-26 00:00:00 UTC to 2019-09-02 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-09-02 00:00:00 UTC to 2019-09-09 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-09-09 00:00:00 UTC to 2019-09-16 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsSep 9

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Feb 112019-02-11 00:00:00 UTC2019-02-18 00:00:00 UTC101
Feb 182019-02-18 00:00:00 UTC2019-02-25 00:00:00 UTC202
Feb 252019-02-25 00:00:00 UTC2019-03-04 00:00:00 UTC000
Mar 42019-03-04 00:00:00 UTC2019-03-11 00:00:00 UTC000
Mar 112019-03-11 00:00:00 UTC2019-03-18 00:00:00 UTC000
Mar 182019-03-18 00:00:00 UTC2019-03-25 00:00:00 UTC000
Mar 252019-03-25 00:00:00 UTC2019-04-01 00:00:00 UTC101
Apr 12019-04-01 00:00:00 UTC2019-04-08 00:00:00 UTC000
Apr 82019-04-08 00:00:00 UTC2019-04-15 00:00:00 UTC202
Apr 152019-04-15 00:00:00 UTC2019-04-22 00:00:00 UTC000
Apr 222019-04-22 00:00:00 UTC2019-04-29 00:00:00 UTC000
Apr 292019-04-29 00:00:00 UTC2019-05-06 00:00:00 UTC000
May 62019-05-06 00:00:00 UTC2019-05-13 00:00:00 UTC000
May 132019-05-13 00:00:00 UTC2019-05-20 00:00:00 UTC211
May 202019-05-20 00:00:00 UTC2019-05-27 00:00:00 UTC000
May 272019-05-27 00:00:00 UTC2019-06-03 00:00:00 UTC000
Jun 32019-06-03 00:00:00 UTC2019-06-10 00:00:00 UTC000
Jun 102019-06-10 00:00:00 UTC2019-06-17 00:00:00 UTC000
Jun 172019-06-17 00:00:00 UTC2019-06-24 00:00:00 UTC000
Jun 242019-06-24 00:00:00 UTC2019-07-01 00:00:00 UTC000
Jul 12019-07-01 00:00:00 UTC2019-07-08 00:00:00 UTC000
Jul 82019-07-08 00:00:00 UTC2019-07-15 00:00:00 UTC000
Jul 152019-07-15 00:00:00 UTC2019-07-22 00:00:00 UTC000
Jul 222019-07-22 00:00:00 UTC2019-07-29 00:00:00 UTC000
Jul 292019-07-29 00:00:00 UTC2019-08-05 00:00:00 UTC000
Aug 52019-08-05 00:00:00 UTC2019-08-12 00:00:00 UTC000
Aug 122019-08-12 00:00:00 UTC2019-08-19 00:00:00 UTC000
Aug 192019-08-19 00:00:00 UTC2019-08-26 00:00:00 UTC000
Aug 262019-08-26 00:00:00 UTC2019-09-02 00:00:00 UTC000
Sep 22019-09-02 00:00:00 UTC2019-09-09 00:00:00 UTC000
Sep 92019-09-09 00:00:00 UTC2019-09-16 00:00:00 UTC101

What Hacker News says

9 sources
> There’s a difference in quality between these jQuery and NPM (and react component) things. Yep, you're exactly right, the plugins are from a different era and have less utility today. That said, jQuery itself still has immense utility. It's expressiveness and simplicity are second to none. The author points to youmightnotneedjquery.com as an example of why jQuery is superfluous today, but if you look at the examples a bit more closely, you'll notice problems. I spent all of five minutes glancing through the YMNNJ example list and noticed their `replaceWith` doesn't provide the functionality that jQuery offers -- it doesn't take into account event handlers bound to DOM elements. Also, their `extend` does a shallow merge, not a deep merge. Furthermore, the YMNNJ examples are often much more verbose and less expressive than the jQuery exa
Read the rest
mples. I don't particularly understand the rush to rip jQuery out of everything. It seems like a lot of people are doing it just because it's the trending thing to do. There are some things that jQuery does very well -- even in today's world where modern web dev is dominated by SPA components. jQuery and SPAs don't have to be mutually exclusive. At my work, we've been building SPAs with jQuery long before Angular, React or Vue even existed. Within the past few years we built our own JavaScript SPA framework whose components can be written with vanilla JS or jQuery. Most of us prefer to use jQuery for our components because the syntax is often more expressive and concise than vanilla JS. We open sourced the framework at https://github.com/elliotnb/nimbly and it's state management utility at https://github.com/elliotnb/observable-slim Our framework core uses jQuery to update DOM nodes with `replaceWith`, merge deeply nested objects with `extend`, among other things. Aside from the eliminating the extra 69KB footprint from adding jQuery slim min, we don't see any reason to rush to rip jQuery out of the framework core. On the contrary, using jQuery helped us get the framework built faster and helped us keep the code expressive and easy-to-follow. Long live jQuery :)
In The history and legacy of jQuery
What I think this article does very well is rebut the myth that the DOM is slow. The DOM is not slow -- on the contrary, it is very fast. What is slow is browser reflow, page refreshes, display calculations, etc. In web app development of yesteryear, browser reflow was typically triggered by poorly conceived manual DOM manipulations -- which gave birth to the myth that the DOM itself is slow. Implementing a virtual DOM and VDOM diffing is just one way to manipulate the DOM more efficiently and intelligently. At my work, we've chosen a different path without the overhead and leaky abstraction of a virtual DOM. We built our own component-based SPA framework and recently open sourced it ( https://github.com/ElliotNB/nimbly ). Each component must have a definition of what state mutations should trigger what portions of the component DOM (via
Read the rest
CSS selectors) to refresh. There's no extra overhead for a VDOM and VDOM diffing at all. The only overhead is accrued ahead of time by the developers who must write a definition of how their component should update in response to state changes. When state does change, the framework bundles up the queued DOM changes between all components on the page, identifies/eliminates any redundant changes and refreshes the DOM in one go.
In Virtual DOM is pure overhead (2018)
youmightnotneedjquery.com is often held up as an example of why jQuery is obsolete, but if you look at the examples a bit more closely, you'll notice problems. I spent all of five minutes glancing through the example list and noticed their `replaceWith` doesn't provide the functionality that jQuery offers -- it doesn't take into account event handlers bound to DOM elements. Also, their `extend` does a shallow merge, not a deep merge. Furthermore, the YMNNJ examples are often far more verbose and less expressive than the jQuery examples. I don't particularly understand the rush to rip jQuery out of everything. It seems like a lot of people are doing it just because it's the trending thing to do. There are some things that jQuery does very well -- even in today's world where modern web dev is dominated by SPA components. I'm the maintainer
Read the rest
of https://github.com/elliotnb/observable-slim and https://github.com/elliotnb/nimbly -- the latter of which is an SPA component framework whose core requires jQuery. It uses jQuery to update DOM nodes with `replaceWith`, merge deeply nested objects with `extend`, among other things. Nimbly components are not required to use jQuery -- only the framework core uses it. Aside from the eliminating the extra 69KB footprint from adding jQuery slim min, I don't see any reason to rush to rip jQuery out of the Nimbly core. On the contrary, using jQuery helped us get the framework built faster and helped us keep the code expressive and easy-to-follow.
In JQuery 3.4.0 Released
jQuery and SPAs don't have to be mutually exclusive. At my work, we've been building SPAs with jQuery long before Angular or React even existed. More recently, we've built our own JavaScript SPA framework whose components can be written with vanilla JS or jQuery. Most of us prefer to use jQuery for our components because the syntax is often more expressive and concise than vanilla JS. We recently open sourced the framework: http://github.com/elliotnb/nimbly
In JQuery 3.4.0 Released
I agree. I glanced through the list and noticed a couple problems myself too. Their `replaceWith` doesn't provide the functionality that jQuery offers -- it doesn't take into account event handlers bound to DOM elements. Also, their `extend` does a shallow merge, not a deep merge. I don't particularly understand the rush to rip jQuery out of everything. It seems like a lot of people are doing it just because it's the trending thing to do. There are some things that jQuery does very well -- even in today's world where modern web dev is dominated by SPA components. I'm the maintainer of https://github.com/elliotnb/observable-slim and https://github.com/elliotnb/nimbly -- the latter of which is an SPA component framework whose core requires jQuery. It uses jQuery to update DOM nodes with `replaceWith`, merge deeply nested objects with `exten
Read the rest
d`, among other things. Nimbly components are not required to use jQuery -- only the framework core uses it. Aside from the eliminating the extra 69KB footprint from adding jQuery 3.1.1 slim min, I don't see any reason to rush to rip jQuery out of the Nimbly core. On the contrary, using jQuery helped us get the framework built faster and helped us keep the code expressive and easy-to-follow.
In Native Javascript alternatives to jQuery methods
@omeid2 I think you've distilled the issue very well -- it's all about "what is simpler code?". I hadn't thought of the issue in terms of the three C's you've mentioned, but the criteria also seems accurate. In my opinion, the popular SPA frameworks (Angular, React, Vue, etc) all suffer from similar problems. They build abstractions on top of abstractions, they force you to learn domain-specific languages (e.g., JSX), lots of new concepts to learn before you can be productive, they are fairly opinionated about how your application should be structured, etc. If you have the time, take a look at this JS framework I put together ( https://github.com/elliotnb/nimbly ) and it's state management dependency ( https://github.com/elliotnb/observable-slim ). I built the framework so developers can take advantage of the benefits of modern frameworks
Read the rest
(templating, data binding, state management, no explicit DOM manipulations, automated unit testing, loosely coupled modular components, etc) but without the typical drawbacks of modern frameworks. The framework has far fewer abstractions than React or Vue, requires no domain specific language (i.e., you write in plain HTML, CSS and JS), and does not require compiling/transpiling. The framework embraces the DOM instead of abstracting away from it and still refreshes/re-renders components in a highly performant manner via DocumentFragments. We've used the framework fairly extensively at my work because it plays very nicely with our jQuery-heavy legacy code and allows for much easier re-factors. The observer library has gained a fair bit of interest from other developers (~2k monthly downloads via npm) and it'd be great if I could interest others in trying out the framework too. I'd love to hear feedback from anyone who takes the time to try it out. Other contributors would be fantastic.
In I love React Hooks
@sam0x17 If you have the time, take a look at this JS framework I put together ( https://github.com/elliotnb/nimbly ) and it's observer library dependency ( https://github.com/elliotnb/observable-slim ). I built the framework so developers can take advantage of the benefits of modern frameworks (templating, data binding, state management, no explicit DOM manipulations, automated unit testing, loosely coupled modular components, etc) but without the typical drawbacks of modern frameworks. The framework has far fewer abstractions than React or Vue, requires no domain specific language (i.e., you write in plain HTML, CSS and JS), and does not require compiling/transpiling. The framework embraces the DOM instead of abstracting away from it and still refreshes/re-renders components in a highly performant manner via DocumentFragments. We've use
Read the rest
d the framework fairly extensively at my work because it plays very nicely with our jQuery-heavy legacy code and allows for much easier re-factors. The observer library has gained a fair bit of interest from other developers (~600 downloads per week via npm) and it'd be great if I could interest others in trying out the framework too. I'd love to hear feedback from anyone who takes the time to try it out. Other contributors would be fantastic.
In Bootstrap 5 will remove jQuery as a dependency

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.