Skip to content
0:00 / 0:00

#react#javascript#apidesign

Sebastian Markbage: Minimal API Surface Area | JSConf EU 2014

JSConf

286K subscribers • 28 videos on Hallway

YouTube
  • Recommended by 2 people: 2 on Hacker News.
  • Presented by Sebastian Markbåge, React core team member
  • May be out of date. Uploaded 12 years ago, in an area where tools change fast.
  • An opinion. It argues one side of a question engineers disagree on.

Intermediate. Assumes working knowledge.

70K views12 years ago2 recommendations

Web developmentSoftware designReactVue, Svelte, Angular and othersJavaScript

Sebastian Markbåge explains how React aims for a minimal API surface area by leveraging JavaScript language features and patterns.

I’ll explain how React is moving towards a minimal API surface area. Instead of providing many framework features, React is trying to utilize patterns, paradigms and JavaScript language features to accomplish the same tasks that other frameworks have dedicated APIs for. We start out with higher order runtime features and then backport them to use ES6 language features and syntax. How does the JSX syntax extension fits into this model? I will also touch on the syntax proposals we and other framework authors are making to ES7 and future versions of JavaScript. Transcript: 2014.jsconf.eu/speakers/sebastian-markbage-minimal-api-surfa… License: For reuse of this video under a more permissive license please get in touch with us. The speakers retain the copyright for their performances.

Why it's here

2 people recommend this

What people say. Engineers frequently reference this talk when discussing API design, framework complexity, and the philosophy behind React.

smhgon Hacker News • Recommends

On “Why Underscore is awesome”

While underscore is indeed widespread, don't let libraries keep you from thoroughly understanding JavaScript: link to this video

msangion Hacker News • Recommends

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 link to this video

danabramovon Hacker News • Mentions

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”: link to this video

danabramovon Hacker News • Mentions

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 link to this video

smhgon Hacker News • Mentions

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 link to this video

iansinnotton Hacker News • Mentions

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: link to this video

swyxon Hacker News • Mentions

On “From Gatsby gridlock to Astro bliss: my personal site redesign”

…here 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 ( link to this 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 p…