3 ms·
Observable is conceptually quite simple. Each cell is a bit of JavaScript, and cells are run reactively, i.e. when their free variables change. That is basicall
by sefwerw 5y ago
Observable is conceptually quite simple. Each cell is a bit of JavaScript, and cells are run reactively, i.e. when their free variables change. That is basically it. It's not actually necessary to know much JS to become productive in Observable and it's fairly close to being orthogonal to D3, believe it or not.
Having said that, Observable is not a mature system and there are some traps for the unwary: https://observablehq.com/@tmcw/observable-anti-patterns-and-code-smells https://observablehq.com/@tmcw/observable-anti-patterns-and-...
This kind of thing would certainly make me think twice about depending on Observable as a platform for a major project. There's a certain confidence in the act of name "anti-patterns" and "code smells" which belies the slightly ad hoc, provisional status of the platform.
And not everything is taken care of elegantly in Observable: making an animation tends to involve more JS control-flow tricks than would be ideal: https://observablehq.com/@mbostock/animation-loops https://observablehq.com/@mbostock/animation-loops
The idea that Observable makes life more difficult for people (in the service of building a profitable platform) doesn't ring true to me, though. To return to what I said in the first paragraph: Observable is conceptually simple (and most parts of it already have third party open source implementations). D3 is as intimidating as it's ever been, but I think the complaint "now I seem to have to learn Observable as well as D3" is not based on a good faith assessment of the complexity of learning Observable, and shouldn't be seriously entertained. It's in the "petulant" category of complaints about software.
- deleted 5y ago[deleted]
- tvst 5y agoActually, Observable is not JavaScript: https://observablehq.com/@observablehq/observables-not-javascript https://observablehq.com/@observablehq/observables-not-javas... I think it's an amazing piece of technology, hosting some of the best interactive stories on the internet — but I too find it hard to use.
- gjm11 5y agoIt seems particularly unfortunate for most of the documentation of something that is supposedly a Javascript library to assume you are using something that is not actually quite Javascript.
- tmcw 5y agoHi! I wrote that article. Basically… the anti-patterns stuff is really not that different from "React anti-patterns". JavaScript supports mutability, a lot of frameworks embrace immutable patterns (like Observable, and React). Using the mutability will lead to bad situations, like mutating in Observable or mutating some state in React. The same with selecting elements, too. Like - if you're in React (or Vue, or… most component libraries) doing a document.querySelector is no good. You break modularity and the ability to add multiple copies of a component to a screen. Same with Observable. Selecting elements from a necessarily-global DOM is bad. The gist is: Observable isn't JavaScript but is really close to JavaScript. We could either make it mostly-JavaScript and have some gotchas around mutability and such (but make it a lot friendlier to JS devs, use existing libraries, etc) or make it something stricter and do a 'clean break.' If Observable was way different than JavaScript, this thread about Observable "having lock-in / being too hard" would be 10x bigger :) Such is the balance between practicality and purity. You can see plenty of other things trying to do this balance. Like React (not quite JavaScript, because of JSX), Svelte (very much not vanilla JavaScript), Elm (pure, idealistic, also its own island because of its purity). Unfortunately you can only really do a pure system with those drawbacks, a practical system with those drabacks, or some combination of the two.