Passionate generalist conquering the web one project at a time. Whether authoring libraries for node, JS, PHP, or Rust, I am always on the lookout for better solutions to common problems.
Location
USA
Work
Lead Developer & Co-founder at corpscrypt, CTO at REtech
Uff, a nice write-up, but I so disagree. Professionally I have to work with React way more frequently than Vue, but I highly prefer the latter.
While ultimately it's a question of taste in most scenarios, here are a few rebuttals:
There is no magic in React, you simply return JSX?
Ignoring the fact that JSX itself is "magic", the fact that React's function to pass JSX on is called return doesn't mean it is return. You pass JSX into a function which I believe I don't have to argue is confusing as you seem to have confused it.
Edit: as one if the commentators (Birtles) has made me aware of that paragraph being misleading, let's clarify that you DO use a simple return. The point should have been to point out where you return to.
The same is true for your hooks explanation: saying that you declare callback functions is the same as hooks only being functions is like saying a vue-component is only an object: it's not wrong from a declarative standpoint but of course there is so much more to it.
The complete section about your IDE not being able to be smart enough is not really an argument for the framework itself. I use jetbrain's PHPStorm and it's so helpful that the usefulness of typescript in general is limited to preventing other developers to break code. However, you explain it with a huge community for React which is a solid argument for choosing technologies.
About vuetify
It's indeed a bit tricky to test. What bothers me about this comparison is that you compare it directly with React. If you wanted to compare on that level, you might want to explore something like next.js so can compare apples with apples (or at least fruit to fruit)
Hi Neoan, can you please explain why do you think JSX is magic? (comparing to Vue's magic, i think vue is more magical than jsx) I'm actually planning to write an article about JSX so i wanted to know your thoughts :D
Passionate generalist conquering the web one project at a time. Whether authoring libraries for node, JS, PHP, or Rust, I am always on the lookout for better solutions to common problems.
Location
USA
Work
Lead Developer & Co-founder at corpscrypt, CTO at REtech
I will try:
Vue's markup is valid HTML. In the most primitive form, what Vue does is to create observers for props and data and bind it to HTML. The result is relatively straight forward:
This setup makes the use of .vue-files optional and doesn't even require a development server. One could import Vue via CDN and write components directly in "hard" declaration:
So while there is a lot of magic in Vue, the markup and bindings are pretty straight forward.
React uses JSX (you don't have to use it, BTW, but then React makes little sense). JSX is NOT valid HTML. It cannot render without being compiled. It isn't JavaScript either. The following code snippet is therefore neither valid JS nor HTML markup:
...return<h1>{headline}</h1>
...
Is that bad? No, but it's pure magic, of course. I mean, it has it's own name (JSX) because of that (otherwise it would just be a template)!?
Now, as every React-dev knows, this means that some interpretational oddities arise. For example, we have to use "className" instead of "class" and "onClick" isn't "onclick". But all of that is relatively easy to get used to and not an issue compared to what is offered. What bothered me about React was how state was handled and bound (this got sooo much better with hooks) and that JSX has a very ugly solution to the two most common things in a dynamic template: conditionals and iteration.
Given the following data:
items=[{item:"one"},{item:"two"}]
Let's look at Vue:
...<liv-for="item in item"v-if="item.item != 'one'">{{item.item}}</li>
Passionate generalist conquering the web one project at a time. Whether authoring libraries for node, JS, PHP, or Rust, I am always on the lookout for better solutions to common problems.
Location
USA
Work
Lead Developer & Co-founder at corpscrypt, CTO at REtech
here: (you said "React makes little sense", that's what i'm referring to, JSX is not binded to React elements you can build up any Tree like structures)
Passionate generalist conquering the web one project at a time. Whether authoring libraries for node, JS, PHP, or Rust, I am always on the lookout for better solutions to common problems.
Location
USA
Work
Lead Developer & Co-founder at corpscrypt, CTO at REtech
So, how does it feel? Does it still make sense to use React? Do you think you could actually efficiently read a React app when built like that? What is the remaining advantage over vanilla JS?
My point is: JavaScript is moving to a declarative style. We want a clear separation of view/template and controller/component-logic, even if there is a move towards having these concepts in one file (component based architecture).
So my question was not if it is possible, but if it makes sense. You would certainly use a different solution than React if you couldn't use JSX.
Hey neoan, I appreciate the feedback! I probably ought to be clearer about what I mean by "magic". I could see why someone may think of JSX as magic - what's all this HTML doing in my JS code? One of the most "magical" things I found about Vue but didn't touch on in this article was the properties that plugins attach to this. For example, Vuetify creates the $vuetify property. There have been multiple times when I've been looking at my company's code and had to do a double take when I see global properties like that, unsure if it was native to Vue or coming from some third party or in-house plugin.
I actually am a big fan of Vuetify and think it's a lot more intuitive to get started with than Material UI. But for React in general, I like its lack of "magic" variables. Everything used in a React file is imported. Going back to Vuetify, the $vuetify object has some pretty great methods on it, especially for breakpoints, but I will have to say I prefer Material UI's method of handling breakpoints. It just feels more declarative. That's only one example, of course, but overall I like how I almost never have to guess where any piece of code is coming from in React. This has been a huge plus for me when working with large code bases at the companies I've worked for.
Passionate generalist conquering the web one project at a time. Whether authoring libraries for node, JS, PHP, or Rust, I am always on the lookout for better solutions to common problems.
Location
USA
Work
Lead Developer & Co-founder at corpscrypt, CTO at REtech
To be clear, I am not making the argument that there isn't a lot of magic in Vue. However, at the end of the day a vue-component is valid markup and JSX simply isn't. That is why you will never be able to run a React component using JSX without compiling. It's the opposite of pure JavaScript.
As for vuetify:
Again, I think you shouldn't compare a wrapper like that (shall we call it a framework-framework?) with pure React. React has similar wrappers to simplify (and therefore magicify) loading.
And again, I am not claiming that Vue doesn't dip into the magic cookbook a lot. It is not intuitive to assume that something you declare in data() to be magically available directly in "this". It's something you need to learn/read.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Uff, a nice write-up, but I so disagree. Professionally I have to work with React way more frequently than Vue, but I highly prefer the latter.
While ultimately it's a question of taste in most scenarios, here are a few rebuttals:
There is no magic in React, you simply return JSX?
Ignoring the fact that JSX itself is "magic", the fact that React's function to pass JSX on is called return doesn't mean it is return. You pass JSX into a function which I believe I don't have to argue is confusing as you seem to have confused it.
Edit: as one if the commentators (Birtles) has made me aware of that paragraph being misleading, let's clarify that you DO use a simple return. The point should have been to point out where you return to.
The same is true for your hooks explanation: saying that you declare callback functions is the same as hooks only being functions is like saying a vue-component is only an object: it's not wrong from a declarative standpoint but of course there is so much more to it.
The complete section about your IDE not being able to be smart enough is not really an argument for the framework itself. I use jetbrain's PHPStorm and it's so helpful that the usefulness of typescript in general is limited to preventing other developers to break code. However, you explain it with a huge community for React which is a solid argument for choosing technologies.
About vuetify
It's indeed a bit tricky to test. What bothers me about this comparison is that you compare it directly with React. If you wanted to compare on that level, you might want to explore something like next.js so can compare apples with apples (or at least fruit to fruit)
Hi Neoan, can you please explain why do you think JSX is magic? (comparing to Vue's magic, i think vue is more magical than jsx) I'm actually planning to write an article about JSX so i wanted to know your thoughts :D
I will try:
Vue's markup is valid HTML. In the most primitive form, what Vue does is to create observers for props and data and bind it to HTML. The result is relatively straight forward:
This setup makes the use of .vue-files optional and doesn't even require a development server. One could import Vue via CDN and write components directly in "hard" declaration:
So while there is a lot of magic in Vue, the markup and bindings are pretty straight forward.
React uses JSX (you don't have to use it, BTW, but then React makes little sense). JSX is NOT valid HTML. It cannot render without being compiled. It isn't JavaScript either. The following code snippet is therefore neither valid JS nor HTML markup:
Is that bad? No, but it's pure magic, of course. I mean, it has it's own name (JSX) because of that (otherwise it would just be a template)!?
Now, as every React-dev knows, this means that some interpretational oddities arise. For example, we have to use "className" instead of "class" and "onClick" isn't "onclick". But all of that is relatively easy to get used to and not an issue compared to what is offered. What bothered me about React was how state was handled and bound (this got sooo much better with hooks) and that JSX has a very ugly solution to the two most common things in a dynamic template: conditionals and iteration.
Given the following data:
Let's look at Vue:
And JSX:
Looking at the above example: it there more magic in Vue? Yes. But you tell me which is more straight forward and approachable.
Hmm i see, good points, thanks!
one thing, why react makes lesser sense when not using JSX? It's just pretty straightforward createElement calls.
"you don't have to use it, BTW, but then React makes little sense"
Really? Please try writing the following JSX with createElement-calls and surprise me:
And BTW, since we have a template here. Compare the following valid markups:
VueJS
Or even more native and including the complete logic in declarative form:
AlpineJS
here: (you said "React makes little sense", that's what i'm referring to, JSX is not binded to React elements you can build up any Tree like structures)
So, how does it feel? Does it still make sense to use React? Do you think you could actually efficiently read a React app when built like that? What is the remaining advantage over vanilla JS?
My point is: JavaScript is moving to a declarative style. We want a clear separation of view/template and controller/component-logic, even if there is a move towards having these concepts in one file (component based architecture).
So my question was not if it is possible, but if it makes sense. You would certainly use a different solution than React if you couldn't use JSX.
Hey neoan, I appreciate the feedback! I probably ought to be clearer about what I mean by "magic". I could see why someone may think of JSX as magic - what's all this HTML doing in my JS code? One of the most "magical" things I found about Vue but didn't touch on in this article was the properties that plugins attach to
this
. For example, Vuetify creates the$vuetify
property. There have been multiple times when I've been looking at my company's code and had to do a double take when I see global properties like that, unsure if it was native to Vue or coming from some third party or in-house plugin.I actually am a big fan of Vuetify and think it's a lot more intuitive to get started with than Material UI. But for React in general, I like its lack of "magic" variables. Everything used in a React file is
import
ed. Going back to Vuetify, the$vuetify
object has some pretty great methods on it, especially for breakpoints, but I will have to say I prefer Material UI's method of handling breakpoints. It just feels more declarative. That's only one example, of course, but overall I like how I almost never have to guess where any piece of code is coming from in React. This has been a huge plus for me when working with large code bases at the companies I've worked for.To be clear, I am not making the argument that there isn't a lot of magic in Vue. However, at the end of the day a vue-component is valid markup and JSX simply isn't. That is why you will never be able to run a React component using JSX without compiling. It's the opposite of pure JavaScript.
As for vuetify:
Again, I think you shouldn't compare a wrapper like that (shall we call it a framework-framework?) with pure React. React has similar wrappers to simplify (and therefore magicify) loading.
And again, I am not claiming that Vue doesn't dip into the magic cookbook a lot. It is not intuitive to assume that something you declare in data() to be magically available directly in "this". It's something you need to learn/read.