tmcw

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.

> Font rendering and layout can all easily be accomplished by embedding libraries like freetype.

Whoooah no. This stuff is way, way, way harder than dropping in freetype.

Book data is scarce and expensive. Goodreads gets it for free because of Amazon, Amazon gets it subsidized because of Amazon's chokehold on book publishing. Any Goodreads competitor needs to license paid data and sort through the duds and the duplicates, and struggle to match up book with only ASINs that are on Amazon Kindles and nowhere else.

And Kindle integration. When you finish a book on a Kindle, it asks you to review it on Goodreads. If you want to add an option to review it on $otherstartup website, your best bet is a supreme court antitrust case.

Basically writing some code that tests whether "a website is currently online or offline" is much, much harder than you think, because, yep, the only company that can do that is Google.

In truth, if I factor in the establishment of the United States and several hundred years of money policy, it'll be higher. But for a fair comparison with Bitcoin, that'd be unfair, right? Because the US's money policy is obviously historically tied to Britain's, so I should include that too. And Britain was adapting the system that was established in feudal times. A lot of work went into making fiat currency real.

So a fair comparison would be Bitcoin versus the cost to print money, plus the history of the US currency system, UK, and all of monetary history before that. This is starting to look pretty bad!

None of these things will bridge that gap, unveiling a missing data point that somehow makes VISA less efficient by six magnitudes that somehow researchers were missing all this time. But constantly asking for more detail is a good way to stay in denial about Bitcoin's terrible numbers.

I appreciate Haskell's power in this domain, and apparently sum types are life-changing (they get mentioned in so many language conversations).

That said, I'm mostly concerned with types like columns, rows, tables, colors, urls, documents, or images. These are implementable in lots of languages, but many languages just have a lot of ad-hoc implementations of them, of the same concept but with slightly different tilts on it. I'm saying that it would be interesting if a language focused on that part of the ecosystem, so that things could connect together.

Haskell might have a very nice type system, but it does not seem like it has many universally-accepted standard types for everything to use. For example, as soon as it gets up to the complexity of a "text" type, there are lots of slightly-different flavors of text.

https://github.com/osmlab/show-me-the-way/blob/gh-pages/js/s...

OSS, we hoped, was about enabling people and unlocking people's ability to collaborate. It turns out that in 2020, it's mostly helping companies and getting nothing in return. That's not a dynamic you can build a sustainable business on.

iframes are cruddy, but they are designed for this - the long era of iframe-based embedded advertisements caused vendors to double-down on those security policies.

Observable doesn't use WebWorkers, duktape, or a custom JavaScript interpreter. If you had sandboxed JavaScript that didn't need access to the DOM, those might be options, but if you want people to write JavaScript like usually, they don't do any good.

Trains, streets, cops, hospitals, public works, 31k employees, and so on.

In other languages, the data kind of object - dicts in python, hashes in ruby - allows you to associate any key with any value. In JavaScript, the hybrid kind of object that's used for both, allows you to associate keys with values, but has some keys that are special, like __proto__, that override language constructs and cause chaos and vulnerabilities.

You'll see prototype pollution CVEs in such libraries as jQuery, Lodash, handlebars, ajv (and transitively, request). A pretty good set of modules that are heavily used.

Scroll through the latest vunerabilities in the database and you'll see prototype pollution popping up very reliably https://snyk.io/vuln?type=npm