Metaphysics and JavaScript
docs.google.com
docs.google.com
My trepidations concerning frameworks like Svelte come from things like this:
`<input type="radio" bind:group={current} value={filter.fn}>`
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.
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.
The following comment by the author sounds hopeful, that they've been working in that direction, and eventually it will happen:
https://github.com/sveltejs/svelte/issues/1639#issuecomment-...
Also, what "rails" does React provide?
I haven't used Svelte so take my comparison surface level. templates, directives and the prop names all remind me of Angular.
>Also, what "rails" does React provide?
The "rails" that react provided that I found useful where more around opinionated data flow with props (especially with Flux).
Yes, but those are commonplace in any library/framework that uses templates. Like you said, this is just a very superficial comparison. Angular is framework that comes with lots of abstractions, modules, dependency injection, etc. It's a very different beast than Svelte.
> The "rails" that react provided that I found useful where more around opinionated data flow with props (especially with Flux).
Right, but React is only the rendering part. You are probably refering to Redux.
It's not about being able to learn a framework without reading the documentation, it's about how many distinct concepts you have to read the documentation for to use the framework. React is extremely conceptually light, by design, which is something I love about it.
> In this example, note how `group` does different things depending on what kind of input you're dealing with. That's the kind of stuff that sounds great in a demo but quickly becomes a pain in a large application.
I really don't see how. It is relevant to exactly two kinds of inputs (radio and checkbox) and does exactly what you would expect with each (given the different behaviors of radio and checkbox inputs).
> It's not about being able to learn a framework without reading the documentation, it's about how many distinct concepts you have to read the documentation for to use the framework.
Sure, but looking at the right menu in the React documentation (https://reactjs.org/docs/getting-started.html), there are actually quite a lot of concepts and API details to understand in order to become proficient in writing React apps. I would be hard pressed to say that looks any lighter or simpler than Svelte (I would actually argue the opposite -- Svelte seems simpler and more straightforward).
Right, but the difference is in the API design. React gives you a small set of tools to implement whatever functionality you need. Svelte gives you specially-crafted tools which to handle specific scenarios. Svelte gives you a command to bind input groups to a stateful value, React gives you the tools to do it yourself. The difference is subtle but experience has lead me to vastly prefer the latter, mostly because you're less reliant on the framework designer getting everything "right".
Here's a good talk which helps explain the difference: https://2014.jsconf.eu/speakers/sebastian-markbage-minimal-a...
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.
Example:
const renderItem = useCallback(() => <Item />, []);
return renderItem();
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.
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?
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.
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.