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

observable-slim

Observable Slim is a singleton that utilizes ES6 Proxies to observe changes made to object graphs. Originally built to assist with state management, one-way data binding, and any situation where an application must be reactive to data store changes.

2Distinct people
7Mentions
0Explicit recommenders
306GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Observable Slim is a singleton that utilizes ES6 Proxies to observe changes made to object graphs. Originally built to assist with state management, one-way data binding, and any situation where an application must be reactive to data store changes.

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, 3:56:07 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 month7 dated mentions

Observed mentions: 2018-07-07 21:11:26 UTC to 2019-09-15 16:16:26 UTC.

0122018-07-01 00:00:00 UTC to 2018-08-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 commentsJul 20182018-08-01 00:00:00 UTC to 2018-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2018-09-01 00:00:00 UTC to 2018-10-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2018-10-01 00:00:00 UTC to 2018-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2018-11-01 00:00:00 UTC to 2018-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2018-12-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-01-01 00:00:00 UTC to 2019-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-02-01 00:00:00 UTC to 2019-03-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 commentsFeb 20192019-03-01 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-05-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019-05-01 00:00:00 UTC to 2019-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-06-01 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-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-08-01 00:00:00 UTC to 2019-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-09-01 00:00:00 UTC to 2019-10-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsSep 2019

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
Jul 20182018-07-01 00:00:00 UTC2018-08-01 00:00:00 UTC110
Aug 20182018-08-01 00:00:00 UTC2018-09-01 00:00:00 UTC000
Sep 20182018-09-01 00:00:00 UTC2018-10-01 00:00:00 UTC101
Oct 20182018-10-01 00:00:00 UTC2018-11-01 00:00:00 UTC000
Nov 20182018-11-01 00:00:00 UTC2018-12-01 00:00:00 UTC000
Dec 20182018-12-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
Jan 20192019-01-01 00:00:00 UTC2019-02-01 00:00:00 UTC000
Feb 20192019-02-01 00:00:00 UTC2019-03-01 00:00:00 UTC202
Mar 20192019-03-01 00:00:00 UTC2019-04-01 00:00:00 UTC101
Apr 20192019-04-01 00:00:00 UTC2019-05-01 00:00:00 UTC101
May 20192019-05-01 00:00:00 UTC2019-06-01 00:00:00 UTC000
Jun 20192019-06-01 00:00:00 UTC2019-07-01 00:00:00 UTC000
Jul 20192019-07-01 00:00:00 UTC2019-08-01 00:00:00 UTC000
Aug 20192019-08-01 00:00:00 UTC2019-09-01 00:00:00 UTC000
Sep 20192019-09-01 00:00:00 UTC2019-10-01 00:00:00 UTC101

What Hacker News says

7 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
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
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
Their decision to switch to a Proxy-based observer is very much welcomed. Other libraries ( https://github.com/ElliotNB/observable-slim ) have shown that Proxy-based observers are robust and performant, but do have some polyfill restrictions for IE11 users. The ability to monitor for properties added dynamically at runtime will allow for a lot more flexibility. Proxies still behave unusually with more complicated Objects (e.g., Date), but they work brilliantly with plain objects. Implementing an observer with Object.defineProperty is a lot more complicated IMHO.
In Plans for the Next Iteration of Vue.js

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.