7 ms·

First, I think anyone using React solely because of the virtual DOM implementation is largely missing the point. IMHO, the real win of React is the functional a

First, I think anyone using React solely because of the virtual DOM implementation is largely missing the point. IMHO, the real win of React is the functional and composable way components can be designed and implemented. Second, no disrespect to Svelte, but I think there's a huge trade-off between the React approach and the Svelte approach that developers should be aware of. React is a pretty unopinionated library, all things considered. The only compilation step necessary is JSX to Javascript. JSX maps pretty directly to React's API. This means compilation is pretty simple. So much so that you can do it by hand really easily if you really wanted to. Svelte, on the other hand, is pretty compilation-heavy. There's a lot of what I'd consider to be non-trivial transformation going on between the code you pass to the Svelte compiler and what comes out of it and runs in the browser. Personally, I'm less comfortable with that compared to React's runtime library approach. But if you are comfortable with that trade-off, that's perfectly fine. It is worth being aware of it, though.

kabes 7y ago
Virtual dom is an implementation decision for performance a developer shouldn't even be very aware of. The main upside to react is that it has a huge ecosystem.
- Waterluvian 7y ago
  You should at least be aware of the gist, lest you obsess over premature optimization. 1. Changes to the DOM cost a ton more than executing JS code. 2. So don't feel too bad when a render() gets called that doesn't change anything because the virtual DOM swallows that.
  - spankalee 7y ago
    > 1. Changes to the DOM cost a ton more than executing JS code. The point of the article, and of the performance problems that people actually have with React is that this might be true for a small number of JS operations, but that 1) Tree diffs are computationally complex operations that add up for real-sized apps 2) The diff is actually unnecessary if you simply take into account the structure of templates, so diffs are pure overhead. So _do_ feel bad when you have a no-op render() in React at least, because the resulting VDOM diff just chewed up CPU and battery for no reason.
adzm 7y ago
Note that even jsx is not technically required, and on occasion I've clenched my teeth and written non-jsx react code for some one-off demos.
- toastal 7y ago
  Weird. I feel like clenching my teeth using JSX and a compilation step when a function suffices.
- acemarke 7y ago
  Jason Miller's `htm` library is a great alternative: nearly-JSX syntax via template strings, with no compilation needed: https://github.com/developit/htm https://github.com/developit/htm
  - thatswrong0 7y ago
    I know that in concept not needing compilation is nice because it’s one less thing to have to worry about, but I don’t think I’d want to use JavaScript without any compilation. Just curious what the use case for not doing compilation is?
    - acemarke 7y ago
      Some folks simply don't want to use a build system, whether it be for experimentation or not wanting to deal with the overhead of tooling. Others are looking for options that might minimize overall script / JS size (which is a hallmark of Jason Miller, author of both Preact and HTM). Another might be to make this easier for beginners. For example, the React docs link to an example HTML page that uses the `babel-standalone` build [0] as a way to try out JSX syntax. However, that's a hefty piece of JS, and it's not at all advisable for real use. HTM might be a good alternative to that. [0] https://reactjs.org/docs/add-react-to-a-website.html#quickly-try-jsx https://reactjs.org/docs/add-react-to-a-website.html#quickly...
    - revvx 7y ago
      I think you have answered your own question: it's one less thing to worry about in your stack. If you're targeting modern evergreen browsers you already have a lot of modern features at your disposal, including ES6 modules, async/await, string interpolation, but we're not using them. In fact, I'd say that it's way more than "one thing" that you can stop worrying about: you won't need Webpack/Rollup/etc, Babel, NPM/Yarn, Node.js itself, etc.
jordache 7y ago
>functional and composable way components can be designed and implemented. Ughh.. that's the point of all modern FE frameworks... You are putting that description on a pedestal as if that is a unique property of React.
- munchbunny 7y ago
  Composable, yes, but functional as in functional programming, no.
  - drcode 7y ago
    Functional programming folks love React- Pretty much every clojure web framework is built on React. But yes, with some effort you can come up with a definition for "functional" which React will fail to meet.
    - munchbunny 7y ago
      I'm confused, I wasn't being pedantic about React. I was talking about frameworks like Angular that don't try to be purely functional.
- somerando7 7y ago
  Currently trying to find a new framework to do a front-end with because the company I'm currently interning doesn't allow React :^) Looking at angular code, it's pretty ugly. What would be the next best thing to look at? Vue?
  - antjanus 7y ago
    I personally enjoy using Angular, but yeah, Vue is your best bet!
  - brobdingnagians 7y ago
    I love Vue.js. I've never really caught onto the JSX stuff. If you have ".Vue" files then you get nice separation of the template html, methods, and the scoped styling. The Javascript syntax is pretty straightforward, and the templates just add nice directives like v-if, v-for, etc. I think it look pretty clean and is fairly easy for JS developers to pick up. Integration into a project is pretty straightforward as well. We have a webpack installation that pulls in the Vue files and bundles everything and it is quite clean.
fouc 7y ago
Isn't it possible to skip the compile step in react, by using hyperscript instead of JSX?
- blotter_paper 7y ago
  Hyperscript isn't necessary. React's jsx is just getting transformed into React.createElement() calls which you can do manually: https://reactjs.org/docs/react-without-jsx.html https://reactjs.org/docs/react-without-jsx.html
namelosw 7y ago
It always bugs me when I'm using a framework with custom HTML templating language (Angular, Vue or possibly Svelte), it's never clear what's the differences between them. It's almost a new language but similar every time, with different pitfalls -- an ad-hoc, informally-specified, bug-ridden, sometimes slow implementation of half of HTML and half of JavaScript. For example, a framework Foo does not have the concept 'else' at all in HTML template. Another framework Bar has an 'else' like <div bar:else="expr" />, but the scope of else is totally different from another framework Baz or JavaScript itself. JSX on the other hand, is straightforward -- when you open a curly bracket, it's just JavaScript expressions -- map, condition, lexical closure, everything works out of the box.
- preommr 7y ago
  > It always bugs me when I'm using a framework with custom HTML templating language (Angular, Vue or possibly Svelte) This is the most ridiculous thing I hear when people compare frameworks. I don't know about angular anymore, but with vue you can use jsx if you wanted to. It's in the official docs, so it's not some random third party support either. Also, my dude, there's like half a dozen rules when it comes to vue templates. Jsx has lots of small rules about component names and things like class vs classname as well. As for putting javascript expressions in your templates... Each to his own I guess, because imo it's a pretty bad anti-pattern to put an extensive amount of procedural code in the template code. Again with vue, using things like computed properties in single file components (SFC) makes it very easy to read and maintain code.
  - namelosw 7y ago
    You can't expect most code bases use JSX as template. It's not even praiseworthy if the framework provide every possible choices. Just like you can do anything in C++, but in practice it's a terrible language to work with. For class part I'm sure it's just whatabouism... And for expressions it's not praiseworthy to put in the template, but my point is why not reusing JavaScript semantics rather than implementing you own that differs from JavaScript?
    - 7y ago
nailer 7y ago
> Svelte, on the other hand, is pretty compilation-heavy. Personally, I'm less comfortable with that compared to React's runtime library approach. Svelte compiles, React runs at runtime, that's true. I've spent the last week (and weekend) doing the UI for a new project in Svelte. The compiler approach is pretty rad as it seems to catch more errors before I test them in browser. You can download any project from the https://svelte.dev/ https://svelte.dev/ tutorial / online REPL and it'll have a rollup file, watching files, compiling them and telling about broken code. vscode also has a plugin for Svelte components that shows pretty underlines while you work. The compiler approach means I see more warnings faster and save time.
dahfizz 7y ago
> There's a lot of what I'd consider to be non-trivial transformation going on between the code you pass to the Svelte compiler and what comes out of it and runs in the browser. Personally, I'm less comfortable with that... How is this different than the "non-trivial" transformations that V8 makes to actually compile and run your code? Does svelte do unpredictable / unexpected things? Don't you make runtime calls to the react lib where they can do whatever they want? I'm genuinely confused. I don't care one way or the other - I'm not a web dev. It seems from this comment that you're just scared of compilers, which is strange. No matter what you're relying on third party libs in your code. Why is it somehow safer for that third party code to be used at run time rather than compile time? I would probably argue the opposite. Why the strong aversion to compilers?
- Lowkeyloki 7y ago
  I don't actually have a strong aversion to compilers. I use tools like Babel and Webpack regularly. However, I've seen the types of transformations the Svelte compiler does and they tend to hide complexity, making it harder to trace and debug code at runtime. Source maps can only do so much. It's much harder to debug code that doesn't resemble what you wrote in the first place.
  - robocat 7y ago
    On the other hand, VDOM is a type of transformation that makes it extremely difficult to debug events sometimes.
  - atan 7y ago
    > However, I've seen the types of transformations the Svelte compiler does and they tend to hide complexity, making it harder to trace and debug code at runtime. Are you saying the original source code hides complexity that is present in the generated code? If so, I guess that's the whole point, but then a runtime framework also hides lots of complexity that your code doesn't have to manage (which, again, is the entire point of using a framework). > It's much harder to debug code that doesn't resemble what you wrote in the first place. With a runtime framework, there's lots of code running that isn't your code, which can also make debugging difficult. With Svelte, at least the generated code is fairly straightforward and easy to step through. In many case, I think it's actually easier, not harder to debug.
atan 7y ago
> There's a lot of what I'd consider to be non-trivial transformation going on between the code you pass to the Svelte compiler and what comes out of it and runs in the browser. Personally, I'm less comfortable with that compared to React's runtime library approach. I initially had a similar concern, but so far, the opposite appears to be true. The Svelte compiled code is quite readable and easy to follow, and because there is no runtime, it's much easier to walk through exactly what is happening. With a complex runtime, it can sometimes be difficult to figure why something isn't working as expected without having a deep understanding of the runtime codebase.

kabes 7y ago

Virtual dom is an implementation decision for performance a developer shouldn't even be very aware of. The main upside to react is that it has a huge ecosystem.

Waterluvian 7y ago
You should at least be aware of the gist, lest you obsess over premature optimization. 1. Changes to the DOM cost a ton more than executing JS code. 2. So don't feel too bad when a render() gets called that doesn't change anything because the virtual DOM swallows that.
- spankalee 7y ago
  > 1. Changes to the DOM cost a ton more than executing JS code. The point of the article, and of the performance problems that people actually have with React is that this might be true for a small number of JS operations, but that 1) Tree diffs are computationally complex operations that add up for real-sized apps 2) The diff is actually unnecessary if you simply take into account the structure of templates, so diffs are pure overhead. So _do_ feel bad when you have a no-op render() in React at least, because the resulting VDOM diff just chewed up CPU and battery for no reason.

adzm 7y ago

Note that even jsx is not technically required, and on occasion I've clenched my teeth and written non-jsx react code for some one-off demos.

toastal 7y ago
Weird. I feel like clenching my teeth using JSX and a compilation step when a function suffices.
acemarke 7y ago
Jason Miller's `htm` library is a great alternative: nearly-JSX syntax via template strings, with no compilation needed: https://github.com/developit/htm https://github.com/developit/htm
- thatswrong0 7y ago
  I know that in concept not needing compilation is nice because it’s one less thing to have to worry about, but I don’t think I’d want to use JavaScript without any compilation. Just curious what the use case for not doing compilation is?
  - acemarke 7y ago
    Some folks simply don't want to use a build system, whether it be for experimentation or not wanting to deal with the overhead of tooling. Others are looking for options that might minimize overall script / JS size (which is a hallmark of Jason Miller, author of both Preact and HTM). Another might be to make this easier for beginners. For example, the React docs link to an example HTML page that uses the `babel-standalone` build [0] as a way to try out JSX syntax. However, that's a hefty piece of JS, and it's not at all advisable for real use. HTM might be a good alternative to that. [0] https://reactjs.org/docs/add-react-to-a-website.html#quickly-try-jsx https://reactjs.org/docs/add-react-to-a-website.html#quickly...
  - revvx 7y ago
    I think you have answered your own question: it's one less thing to worry about in your stack. If you're targeting modern evergreen browsers you already have a lot of modern features at your disposal, including ES6 modules, async/await, string interpolation, but we're not using them. In fact, I'd say that it's way more than "one thing" that you can stop worrying about: you won't need Webpack/Rollup/etc, Babel, NPM/Yarn, Node.js itself, etc.

jordache 7y ago

>functional and composable way components can be designed and implemented. Ughh.. that's the point of all modern FE frameworks... You are putting that description on a pedestal as if that is a unique property of React.

munchbunny 7y ago
Composable, yes, but functional as in functional programming, no.
- drcode 7y ago
  Functional programming folks love React- Pretty much every clojure web framework is built on React. But yes, with some effort you can come up with a definition for "functional" which React will fail to meet.
  - munchbunny 7y ago
    I'm confused, I wasn't being pedantic about React. I was talking about frameworks like Angular that don't try to be purely functional.
somerando7 7y ago
Currently trying to find a new framework to do a front-end with because the company I'm currently interning doesn't allow React :^) Looking at angular code, it's pretty ugly. What would be the next best thing to look at? Vue?
- antjanus 7y ago
  I personally enjoy using Angular, but yeah, Vue is your best bet!
- brobdingnagians 7y ago
  I love Vue.js. I've never really caught onto the JSX stuff. If you have ".Vue" files then you get nice separation of the template html, methods, and the scoped styling. The Javascript syntax is pretty straightforward, and the templates just add nice directives like v-if, v-for, etc. I think it look pretty clean and is fairly easy for JS developers to pick up. Integration into a project is pretty straightforward as well. We have a webpack installation that pulls in the Vue files and bundles everything and it is quite clean.

fouc 7y ago

Isn't it possible to skip the compile step in react, by using hyperscript instead of JSX?

blotter_paper 7y ago
Hyperscript isn't necessary. React's jsx is just getting transformed into React.createElement() calls which you can do manually: https://reactjs.org/docs/react-without-jsx.html https://reactjs.org/docs/react-without-jsx.html

namelosw 7y ago

It always bugs me when I'm using a framework with custom HTML templating language (Angular, Vue or possibly Svelte), it's never clear what's the differences between them. It's almost a new language but similar every time, with different pitfalls -- an ad-hoc, informally-specified, bug-ridden, sometimes slow implementation of half of HTML and half of JavaScript. For example, a framework Foo does not have the concept 'else' at all in HTML template. Another framework Bar has an 'else' like <div bar:else="expr" />, but the scope of else is totally different from another framework Baz or JavaScript itself. JSX on the other hand, is straightforward -- when you open a curly bracket, it's just JavaScript expressions -- map, condition, lexical closure, everything works out of the box.

preommr 7y ago
> It always bugs me when I'm using a framework with custom HTML templating language (Angular, Vue or possibly Svelte) This is the most ridiculous thing I hear when people compare frameworks. I don't know about angular anymore, but with vue you can use jsx if you wanted to. It's in the official docs, so it's not some random third party support either. Also, my dude, there's like half a dozen rules when it comes to vue templates. Jsx has lots of small rules about component names and things like class vs classname as well. As for putting javascript expressions in your templates... Each to his own I guess, because imo it's a pretty bad anti-pattern to put an extensive amount of procedural code in the template code. Again with vue, using things like computed properties in single file components (SFC) makes it very easy to read and maintain code.
- namelosw 7y ago
  You can't expect most code bases use JSX as template. It's not even praiseworthy if the framework provide every possible choices. Just like you can do anything in C++, but in practice it's a terrible language to work with. For class part I'm sure it's just whatabouism... And for expressions it's not praiseworthy to put in the template, but my point is why not reusing JavaScript semantics rather than implementing you own that differs from JavaScript?
  - 7y ago

nailer 7y ago

> Svelte, on the other hand, is pretty compilation-heavy. Personally, I'm less comfortable with that compared to React's runtime library approach. Svelte compiles, React runs at runtime, that's true. I've spent the last week (and weekend) doing the UI for a new project in Svelte. The compiler approach is pretty rad as it seems to catch more errors before I test them in browser. You can download any project from the https://svelte.dev/ https://svelte.dev/ tutorial / online REPL and it'll have a rollup file, watching files, compiling them and telling about broken code. vscode also has a plugin for Svelte components that shows pretty underlines while you work. The compiler approach means I see more warnings faster and save time.

dahfizz 7y ago

> There's a lot of what I'd consider to be non-trivial transformation going on between the code you pass to the Svelte compiler and what comes out of it and runs in the browser. Personally, I'm less comfortable with that... How is this different than the "non-trivial" transformations that V8 makes to actually compile and run your code? Does svelte do unpredictable / unexpected things? Don't you make runtime calls to the react lib where they can do whatever they want? I'm genuinely confused. I don't care one way or the other - I'm not a web dev. It seems from this comment that you're just scared of compilers, which is strange. No matter what you're relying on third party libs in your code. Why is it somehow safer for that third party code to be used at run time rather than compile time? I would probably argue the opposite. Why the strong aversion to compilers?

Lowkeyloki 7y ago
I don't actually have a strong aversion to compilers. I use tools like Babel and Webpack regularly. However, I've seen the types of transformations the Svelte compiler does and they tend to hide complexity, making it harder to trace and debug code at runtime. Source maps can only do so much. It's much harder to debug code that doesn't resemble what you wrote in the first place.
- robocat 7y ago
  On the other hand, VDOM is a type of transformation that makes it extremely difficult to debug events sometimes.
- atan 7y ago
  > However, I've seen the types of transformations the Svelte compiler does and they tend to hide complexity, making it harder to trace and debug code at runtime. Are you saying the original source code hides complexity that is present in the generated code? If so, I guess that's the whole point, but then a runtime framework also hides lots of complexity that your code doesn't have to manage (which, again, is the entire point of using a framework). > It's much harder to debug code that doesn't resemble what you wrote in the first place. With a runtime framework, there's lots of code running that isn't your code, which can also make debugging difficult. With Svelte, at least the generated code is fairly straightforward and easy to step through. In many case, I think it's actually easier, not harder to debug.

atan 7y ago

> There's a lot of what I'd consider to be non-trivial transformation going on between the code you pass to the Svelte compiler and what comes out of it and runs in the browser. Personally, I'm less comfortable with that compared to React's runtime library approach. I initially had a similar concern, but so far, the opposite appears to be true. The Svelte compiled code is quite readable and easy to follow, and because there is no runtime, it's much easier to walk through exactly what is happening. With a complex runtime, it can sometimes be difficult to figure why something isn't working as expected without having a deep understanding of the runtime codebase.