Sebastian Markbage: Minimal API Surface Area | JSConf EU 2014

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”: [VIDEO]

>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 [VIDEO]

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] [VIDEO]

While underscore is indeed widespread, don't let libraries keep you from thoroughly understanding JavaScript: [VIDEO]

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 [VIDEO]

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]: [VIDEO]

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 seb markbage had; just have a small api surface area bro ( [VIDEO] ) But the bigger lesson is bitterer. Frontend tooling isnt worth that much. the fact that vercel is pretty much the only successful frontend startup of its generation makes it an exception to the rule (there are plenty of smaller companies that are thriving, like tailwind, but it is not a venture scale startup and thats fine). People dont pay for frontend tooling. they expect it to be free, expect it to do everything, get into internicine squabbles between frameworks when they are all basically doomed compared to just betting on React sponsored by Facebook and now Vercel (and a little bit of Shopify), or going back to fullstack frameworks like Django/Rails/Laravel. all frontend tooling, nextjs included, is just leadgen, loss