Skip to content
HomeVideos
AllLongsCategoriesPlaylists
BooksBlogsPodcasts
HistoryListsWatch laterLiked videosFollowing

The videos, books, blogs and podcasts Hacker News keeps recommending, all in one place.

VideosBooksBlogsPodcastsAboutPrivacySettings

Data from Hacker News, HackerTube, HackerBooks, HackerBlogs and Open Library. Credits · Not affiliated with Y Combinator.

HomeVideosBooksBlogsPodcasts
Ctrl K

    Sebastian Markbage: Minimal API Surface Area | JSConf EU 2014

    JSConf

    2 HN recommenders · recommended in 5 months, 2015–2024

    YouTube

    24:28 · 71K views · Oct 15, 2014

    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.

    HN cites it as a statement of React's early design philosophy of keeping APIs small and understanding JavaScript itself.

    Software Engineering & LanguagesWeb developmentSoftware architecture & design
    1. 35:32
      Cheng Lou - On the Spectrum of Abstraction at react-europe 2016ReactEurope63K views • 10 years ago
    2. 29:32
      Pete Hunt: React: Rethinking best practices -- JSConf EUJSConf548K views • 13 years ago
    3. 44:36
      Hacker Way: Rethinking Web App Development at FacebookMeta Developers900K views • 12 years ago
    4. 27:42
      Mark DiMarco: User Interface Algorithms [JSConf2014]JSConf52K views • 12 years ago
    5. 18:55
      [JSConfUS 2013] Tom Occhino and Jordan Walke: JS Apps at FacebookJSConf45K views • 13 years ago
    6. 36:45
      Jordan Walke - React to the FutureReasonConf48K views • 6 years ago
    7. 27:45
      React.js Conf 2016 - Ben Alpert - What Lies AheadMeta Developers50K views • 10 years ago
    8. 25:47
      React.js Conf 2015 - The complementarity of React and Web ComponentsMeta Developers22K views • 11 years ago
    9. 31:11
      React.js Conf 2015 - Immutable Data and ReactMeta Developers159K views • 11 years ago
    10. 33:25
      Dan Abramov: Beyond React 16 | JSConf IcelandJSConf139K views • 8 years ago
    11. 1:35:30
      React Today and Tomorrow and 90% Cleaner React With HooksReact Conf1.2M views • 8 years ago
    12. 36:45
      Rich Harris - Rethinking reactivityYou Gotta Love Frontend334K views • 7 years ago
    13. 52:23
      Nicholas Zakas: Scalable JavaScript Application ArchitectureYUI Library68K views • 15 years ago
    14. 1:00:19
      How To Design A Good API and Why it MattersGoogle TechTalks453K views • 19 years ago
    15. 36:31
      Hey Underscore, You're Doing It Wrong!InfoQ141K views • 13 years ago
    16. 40:55
      "Controlling Time and Space: understanding the many formulations of FRP" by Evan CzaplickiStrange Loop Conference69K views • 12 years ago
    17. 33:52
      Nordic.js 2014 • Douglas Crockford - The Better PartsNordic.js73K views • 12 years ago
    18. 31:48
      Lin Clark - A Cartoon Intro to Fiber - React Conf 2017Meta Developers216K views • 9 years ago
    19. 58:23
      Evan Czaplicki - Let's be mainstream! User focused design in Elm - Curry OnCurry On!82K views • 11 years ago
    20. 31:17
      React.js Conf 2015 - Hype!Meta Developers108K views • 11 years ago

    7 comments from Hacker News

    1. @msangiFeb 2017· in “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

      RecommendsView on HN
    2. @smhgJul 2015· in “Why Underscore is awesome”

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

      RecommendsView on HN
    3. @swyxSep 2024· in “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 seb markbage had; just have a small api surface area bro ( 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 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

      CitesView on HN
    4. @danabramovJan 2015· in “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

      CitesView on HN
    5. @smhgJul 2015· in “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

      CitesView on HN