Sebastian Markbage: Minimal API Surface Area | JSConf EU 2014
Why Hacker News recommends it
HN cites it as a statement of React's early design philosophy of keeping APIs small and understanding JavaScript itself.
What it is
Sebastian Markbage explains how React is moving toward a minimal API surface by leaning on language features and patterns instead of dedicated framework APIs. He also touches on JSX and syntax proposals for future JavaScript.
Recommended by 2 HN commenters across 2 different months, 2015 to 2024.
What Hacker News said
Recommends smhg · 2015-07 · on “Why Underscore is awesome”
While underscore is indeed widespread, don't let libraries keep you from thoroughly understanding JavaScript: [this video]
Recommends msangi · 2017-02 · on “Id Software Programming Principles”
That's indeed a very good advice. All abstractions have a cost and no abstraction is better than the wrong abstraction. I found this talk on the topic very interesting [this video]
Cites danabramov · 2015-01 · on “React v0.13.0 Beta 1”
They're not investing in OOP in any way. In fact, they're doing the opposite: deprecating proprietary pseudo-OOP `React.createClass` helper and let people use whatever they fancy. This makes it easier to write React components using idiomatic constructs from different languages, whether it is TypeScript, ClojureScript, CoffeeScript, or whatever. Also lets you use any mixin system, if you need it at all. React's stance on inheritance: [LINK] “Minimal API surface area”: [this video]
Cites danabramov · 2015-01 · on “React v0.13.0 Beta 1”
>I'm disappointed with the implementation in this case (no mixins??) The point is moving mixin handling to userland (and eventually some sort of standard?), if I understand correctly. It's not really React's concern. See also: Minimal API Surface Area [this video]
Cites smhg · 2015-07 · on “Don't use || to set default values in JavaScript”
I don't agree either. The first part of the argumentation is indeed based on the author's feelings. The second part I don't think is an issue for most real world use-cases (Objects, Strings and, to a lesser extent, Numbers). On the underscore (_.defaults) recommendation: let's set our goals straight [1]. Aim for a good level of JavaScript understanding. Instead of library knowledge to make up for the lack of the former. [1] [this video]
Cites iansinnott · 2020-12 · on “React's UseRef Deep Dive”
I'm a bit torn on the hooks feature since it seems like a great example of something that's easy but not simple [1], as well as going against React's prior principle of minimizing the API [2]. I'm glad the article also shows how to use the more traditional API as well, even if it is a bit more verbose. [1]: [LINK] [2]: [this video]
Cites swyx · 2024-09 · on “From Gatsby gridlock to Astro bliss: my personal site redesign”
I am still not over the collapse of Gatsby (for reference i nearly joined the company in 2017, was saved only by my own character flaws). They rode the highs - being the default docs tool for React, and building a massive ecosystem of integrations you could install out of the box. But too many abstractions, divided goals between cloud and OSS, and the better stewardship/design of Nextjs brought it down. There were the simple lessons ( [LINK] ). its easy to say in hindsight that graphql was too much for gatsby. i also believe the company went too hard for number of integrations over quality of them, an issue I had even in my interview. this was a poorer expression of the better insight that s