5 ms·

Metaphysics and JavaScript

95 points by chambers 7y ago

chambers 7y ago
Context here: https://www.swyx.io/writing/svelte-metaphysics https://www.swyx.io/writing/svelte-metaphysics
- _bxg1 7y ago
  Really sad there's no recording, I feel like it would be twice as entertaining
marknadal 7y ago
And more Metaphysics & JS: https://youtu.be/5BuoDqVxvOM https://youtu.be/5BuoDqVxvOM
nikolaplejic 7y ago
It might be worth pointing out that this presentation comes with speaker notes (keyboard shortcut: S, or click on the gear icon at the bottom and find the link). They contain much more content (and context) than the slides alone.
- mythz 7y ago
  Definitely worthwhile, thanks. I had viewed this presentation before but didn't know about the Speaker notes.
  - hitekker 7y ago
    Same here. Thank you for the tip, GP.
- halleonard 7y ago
  The associated speaker notes are A+
ng12 7y ago
I'm not sure I understand. Yes, there are some pitfalls to React Hooks (and, honestly, they're really slick but definitely require more cognitive overhead than React.Component) but he doesn't really describe how Svelte solves these problems. In fact, looking at the demo code it looks pretty similar to how I'd built it in React. My trepidations concerning frameworks like Svelte come from things like this: `<input type="radio" bind:group={current} value={filter.fn}>` What does `bind:group` do? What kind of magic is going on behind the scenes to make this work? At least with React it's always easy to grok what is happening (it's all just JavaScript, after all). Of all the front-end frameworks React has the fewest magical invocations and that's one of the most important things I look for in a framework or library.
- nemothekid 7y ago
  You're missing his actual walkthrough of Svelte, that he likely did in the demo. I've seen Svelte enough times on HN that I'm vaguely familiar with it. Svelte, to me, at a very high level, is "Angular 1, but fast" - which might be easier to develop for, but doesn't provide the same "rails" that React does (and why I prefer it). At the end of the day, all the hang wringing about hooks and purity is about making it simple to reason about a program locally. I haven't used Svelte so I can't say for sure, but the problem Svelte (and that the Virtual DOM) solves is an issue I don't think I have. In any case his presentation was interesting enough from a FP/Programming theory POV.
  - kjksf 7y ago
    For what it's worth: to me Svelte is, for the lack of a better word, "better" React. It's another evolutionary step in the same direction. I wouldn't compare it to Angular. Svelte is both easier to use (productivity) and generates faster code. To me React is 2 things: components (reusable pieces that combine state with rendering logic in JavaScript / HTML / CSS) and reactivity (rebuilding UI from state). Virtual DOM is an implementation detail that makes rebuilding UI from state fast enough in React. Svelte also provides components and reactivity but with less typing (for me, the programmer). While I know some people complain about more magic, my experience is opposite: Svelte maps more intuitively to the final JavaScript / HTML / CSS than React. And it has CSS that is scoped by default to the component which removes the need for CSS-in-JS solutions.
_bxg1 7y ago
This is a very good take. DOM as a function of state has real tradeoffs but also real benefits; state as a function of state just gets out of hand. IMO React Hooks are where React jumped the shark. setState and Redux were already clunky and felt too rooted in unhelpful ideals, but hooks just took the cake. My company's codebase uses MobX for all state and I highly recommend it. It embraces mutability and imperative code where they make sense: in your actual app state. React is there to do what it's best at: rendering DOM. That's it. Rendering remains functional and real, meaningful state is allowed to be what it is.
- Tade0 7y ago
  To add insult to injury it's fairly easy to use hooks wrong - and used wrong they are, which suggests that their learning curve is not as friendly as proponents of this pattern would wish.
  - nezygis 7y ago
    Could you share some examples of hooks used wrongly in code?
    - Tade0 7y ago
      useCallback used as something else than a provider of callback functions, e.g. for rendering. Example: const renderItem = useCallback(() => <Item />, []); And then: return renderItem(); What should have been used here is useMemo.
- lioeters 7y ago
  Glad to see there's a vocal minority who disagree with the way React Hooks are implemented. I raised my objections when it was announced (even got super kind feedback from Dan Abramov himself) - but it was too late, they "jumped the shark", as you put it. I looked up the meaning of the phrase, not sure it's totally suitable for this situation - but I feel that React crossed a threshold with its release. I started considering alternative view libraries from that point, and continued to resist against using Hooks in my own React-based projects. The thing is, I love how React transformed web development, it's got huge mind share in the community, and there's nothing better out there yet. I just wish it had stayed small and simple, kept other concerns out of it and focused on doing its one thing only.
pier25 7y ago
I've tried Svelte and while I don't love some of the dev ergonomics it's a damn fine project. React was a great alternative to Angular back in 2015 but it's not even close to being objectively the best solution in 2019 except for its popularity. Preact or Inferno are so much faster/lightweight and are pretty much drop-in replacements for React. BTW is there a video of this presentation somewhere?
- _bxg1 7y ago
  We pretty much only use React for rendering and lifecycle (still rocking class-based components). Does Preact offer material improvements other than bundle size? If so I might look into switching.
  - pier25 7y ago
    Preact is considerably faster, but maybe React is good enough in your use case. I also prefer using mostly class based components and some functional components for lightweight dumb components. I use Inferno for rendering and vanilla + MobX for everything else.
    - _bxg1 7y ago
      We certainly have performance bottlenecks in our rendering, so if a different library is faster we're definitely interested
bionhoward 7y ago
I built a knowledge graph editor in react, then svelte, and while svelte is good in theory, React was much easier to debug, had better tools and components, and eventually I just switched back to react (Preact, actually, but I like Ant Design so much I might use vanilla React)
dakerfp 7y ago
That's the QtQuick approach.
deleted 7y ago
[deleted]
olingern 7y ago
It’s exhausting that the author of Svelte has to continually compare his project to React. It’s a huge red flag when someone can’t substantiate why something is worthwhile without criticizing adjacent projects. I understand that React is the front-end framework du jour, but React nor any other successful project got where it is by continually criticizing others’ work.

95 points by chambers 7y ago

chambers 7y ago

Context here: https://www.swyx.io/writing/svelte-metaphysics https://www.swyx.io/writing/svelte-metaphysics

_bxg1 7y ago
Really sad there's no recording, I feel like it would be twice as entertaining

marknadal 7y ago

And more Metaphysics & JS: https://youtu.be/5BuoDqVxvOM https://youtu.be/5BuoDqVxvOM

nikolaplejic 7y ago

It might be worth pointing out that this presentation comes with speaker notes (keyboard shortcut: S, or click on the gear icon at the bottom and find the link). They contain much more content (and context) than the slides alone.

mythz 7y ago
Definitely worthwhile, thanks. I had viewed this presentation before but didn't know about the Speaker notes.
- hitekker 7y ago
  Same here. Thank you for the tip, GP.
halleonard 7y ago
The associated speaker notes are A+

ng12 7y ago

I'm not sure I understand. Yes, there are some pitfalls to React Hooks (and, honestly, they're really slick but definitely require more cognitive overhead than React.Component) but he doesn't really describe how Svelte solves these problems. In fact, looking at the demo code it looks pretty similar to how I'd built it in React. My trepidations concerning frameworks like Svelte come from things like this: `<input type="radio" bind:group={current} value={filter.fn}>` What does `bind:group` do? What kind of magic is going on behind the scenes to make this work? At least with React it's always easy to grok what is happening (it's all just JavaScript, after all). Of all the front-end frameworks React has the fewest magical invocations and that's one of the most important things I look for in a framework or library.

nemothekid 7y ago
You're missing his actual walkthrough of Svelte, that he likely did in the demo. I've seen Svelte enough times on HN that I'm vaguely familiar with it. Svelte, to me, at a very high level, is "Angular 1, but fast" - which might be easier to develop for, but doesn't provide the same "rails" that React does (and why I prefer it). At the end of the day, all the hang wringing about hooks and purity is about making it simple to reason about a program locally. I haven't used Svelte so I can't say for sure, but the problem Svelte (and that the Virtual DOM) solves is an issue I don't think I have. In any case his presentation was interesting enough from a FP/Programming theory POV.
- kjksf 7y ago
  For what it's worth: to me Svelte is, for the lack of a better word, "better" React. It's another evolutionary step in the same direction. I wouldn't compare it to Angular. Svelte is both easier to use (productivity) and generates faster code. To me React is 2 things: components (reusable pieces that combine state with rendering logic in JavaScript / HTML / CSS) and reactivity (rebuilding UI from state). Virtual DOM is an implementation detail that makes rebuilding UI from state fast enough in React. Svelte also provides components and reactivity but with less typing (for me, the programmer). While I know some people complain about more magic, my experience is opposite: Svelte maps more intuitively to the final JavaScript / HTML / CSS than React. And it has CSS that is scoped by default to the component which removes the need for CSS-in-JS solutions.

_bxg1 7y ago

This is a very good take. DOM as a function of state has real tradeoffs but also real benefits; state as a function of state just gets out of hand. IMO React Hooks are where React jumped the shark. setState and Redux were already clunky and felt too rooted in unhelpful ideals, but hooks just took the cake. My company's codebase uses MobX for all state and I highly recommend it. It embraces mutability and imperative code where they make sense: in your actual app state. React is there to do what it's best at: rendering DOM. That's it. Rendering remains functional and real, meaningful state is allowed to be what it is.

Tade0 7y ago
To add insult to injury it's fairly easy to use hooks wrong - and used wrong they are, which suggests that their learning curve is not as friendly as proponents of this pattern would wish.
- nezygis 7y ago
  Could you share some examples of hooks used wrongly in code?
  - Tade0 7y ago
    useCallback used as something else than a provider of callback functions, e.g. for rendering. Example: const renderItem = useCallback(() => <Item />, []); And then: return renderItem(); What should have been used here is useMemo.
lioeters 7y ago
Glad to see there's a vocal minority who disagree with the way React Hooks are implemented. I raised my objections when it was announced (even got super kind feedback from Dan Abramov himself) - but it was too late, they "jumped the shark", as you put it. I looked up the meaning of the phrase, not sure it's totally suitable for this situation - but I feel that React crossed a threshold with its release. I started considering alternative view libraries from that point, and continued to resist against using Hooks in my own React-based projects. The thing is, I love how React transformed web development, it's got huge mind share in the community, and there's nothing better out there yet. I just wish it had stayed small and simple, kept other concerns out of it and focused on doing its one thing only.

pier25 7y ago

I've tried Svelte and while I don't love some of the dev ergonomics it's a damn fine project. React was a great alternative to Angular back in 2015 but it's not even close to being objectively the best solution in 2019 except for its popularity. Preact or Inferno are so much faster/lightweight and are pretty much drop-in replacements for React. BTW is there a video of this presentation somewhere?

_bxg1 7y ago
We pretty much only use React for rendering and lifecycle (still rocking class-based components). Does Preact offer material improvements other than bundle size? If so I might look into switching.
- pier25 7y ago
  Preact is considerably faster, but maybe React is good enough in your use case. I also prefer using mostly class based components and some functional components for lightweight dumb components. I use Inferno for rendering and vanilla + MobX for everything else.
  - _bxg1 7y ago
    We certainly have performance bottlenecks in our rendering, so if a different library is faster we're definitely interested

bionhoward 7y ago

I built a knowledge graph editor in react, then svelte, and while svelte is good in theory, React was much easier to debug, had better tools and components, and eventually I just switched back to react (Preact, actually, but I like Ant Design so much I might use vanilla React)

dakerfp 7y ago

That's the QtQuick approach.

deleted 7y ago

[deleted]

olingern 7y ago

It’s exhausting that the author of Svelte has to continually compare his project to React. It’s a huge red flag when someone can’t substantiate why something is worthwhile without criticizing adjacent projects. I understand that React is the front-end framework du jour, but React nor any other successful project got where it is by continually criticizing others’ work.