3 ms·
Hi! I wrote that article. Basically… the anti-patterns stuff is really not that different from "React anti-patterns". JavaScript supports mutability, a lot of
by tmcw 5y ago
Hi! 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.