I think the best part about Vuejs is that how simple it is and everything just works!
A vue component is still as simple as {template: 'hi'}. You don't need webpack or any transliteration for it to work. Just drop the script tag like the good old jQuery and it's working! No wonder it was so easy to switch to it.
Transition from vue1 to vue2 was really simple. I'm sure the same will be true for v3.
Maybe it's the constant React vs Vue articles that make me suspicious, but if you are referring to React when mentioning webpack / transliteration, i'd like to mention that you don't need them for React neither. It can be resumed to a simple script tag as well.
I hate this misconception and wish it would just go away.
Could you paste the simple script tag that makes React work without transpilation? I always thought you needed Webpack (or an equivalent) to transpile JSX into a vanilla js function the browser can interpret.
If you're referring to Create React App, it uses Webpack - just preconfigured so you don't have to fiddle with it before you start building.
No, I meant simply adding a tag and using react directly, in any context. That's how it was originally designed, btw. It wasn't meant only for SPAs when it was conceived, but as an addon to existing websites.
The other comment gives a perfect example and there are a few tutorials (although I do agree not very mainstream) that teach React without JSX/Webpack/Babel/etc.
edit: You are correct that you need transpilation for JSX but you don't need JSX for React. The confusion of JSX/React sounds eerily similar to how newbies confused jQuery for JS.
I don’t think the comparison with JQuery vs JS is at all similar. JSX was created for React, and nearly every time you see React code it’s using JSX. Technically, each of them can be used separately, but it’s a very reasonable impression to consider JSX one of the main features of React.
JS was not created for JQuery, and you can not used JQuery without JS.
"jQuery was created for JS, and nearly every time you see JS code it's using jQuery." Doesn't that sound like something you would hear a few years ago?
Sure, but that’s a linguistic trick. That sentence implies a completely different meaning for the word “for”.
When I say JSX was created for React, I mean that it was created to be a part of the design of React. Meaning they both first came into broader public awareness at the same time, together, and have continued to be promoted as two independent parts of a single system.
As an aside, is that really a problem these days? All modern browsers now offer comprehensive native ES6 support. Unless you still need to support older platforms like IE or some of the legacy mobile browsers, it's mostly a non-issue.
Like you said, it depends how much you're betting on your JS to work perfectly, and who your intended market is. If all you're doing is hoping for the most optimistic JS runtime (and perfect connectivity, high bandwidth, etc.) and your site is a white screen of death otherwise, then you're not really building a robust piece of software for the web. Of course, that may not be what you're trying to do, then it's a non-issue.
Presumably IE11 will hold out forever, since it's not under meaningful development any more.
What's missing from any recent version of iOS Safari, though? Anything from 10 upwards supports pretty much all of ES6 with very minor exceptions, AFAIK. Even features from more recent versions of ES tend to be supported quite well quite quickly in the era of self-updating "evergreen" browsers.
There's also a babel script that you can drop into a script tag and will transpile stuff in the browser for you if you want JSX.
Not recommended for large projects in production (but then I'd be using webpack or similar for large vue projects too), but it works pretty well (and surprisingly fast) for quick experiments.
Moving the goalpost. I'm only pointing the fact that it is possible, and saying it is impossible is false.
Personally, I don't find the function-call format that "annoying", and I think it presents some advantages neither JSX nor template strings have, along with some disadvantages (it's more verbose, like you pointed out).
And I think GP was saying even if possible it seems rather irrelevant. You could use react without JSX but most likely you will not because you would be throwing away the good things about react.
Technically you can eat soup using a fork, but you won’t because...
When React was new and compilers/tooling wasn't that good it was pretty common to use it without JSX. JSX is pervasive because the tooling is now first class (and you'll need it if you make a non-trivial app sooner or later...at which point might as well use JSX since its there), but it works perfectly find without. My first couple commercial apps for React didn't use JSX and it was quite usable. There's just a lack of examples on how to do it these days because no one bothers.
The only time when you won't really have access to a tool chain is for quick demos with just an html page and a script tag (if you don't want to pull in babel as a script), but most online tool allow jsx too now anyway.
Agreed. When evaluating both of them, it looked like React and Vue implement the same concepts, but React did it in ways that made it more complicated than it needed to be. I specifically didn’t like that Redux and it’s docs were too heady for what it really is (it’s just event triggering and handling, why does it have to be so complicated?), and the fact that React didn’t have any official “here’s is how to build a complete app” docs. It was always “well here are different choices and project layouts you could use”. I don’t want to care about using this templating system or that. I want batteries included. Vue did that well.
If you've got any specific suggestions for improvements, please let us know! I'm always looking for ways we can make the docs better.
As a side note, React is separate from Redux, and Redux is definitely not tied to React. Here's a recent post about a team that opted to use Redux with Vue: https://snipcart.com/blog/redux-vue .
Sorry I just saw this. If you see this comment, yes I know Redux and React are separate and that you can use other state management systems besides Redux with React. However, that doesn’t help when evaluating the React ecosystem at first. I don’t want to play “pick a library, build a framework”. What I do most of the time is pretty common stuff: SPA with login, CRUD data manipulation, etc. I want a a framework that does 80% of that and has flexibility to create the other 20%. Many React/Redux tutorials are happy to oblige. But they are also all incomplete and unofficial. And by the time a large comprehensive tutorial is written by some kind soul, the APIs have changed, and you are back to SO looking for how to make the damn thing run.
Specifically with Redux, I would suggest clarifying stuff around reducers and possibly renaming them. As is, reducers sound like “a monad is a monoid in the class of ...” Vuex specifically does a very nice job of calling their equivalent thing “mutations” which is more intuitive.
My visualization of Redux/Vuex is basically an application of the event system to state management. Instead of manipulating global.state.foo directly, you ask the system to change the value of foo and a callback does it. A simple explanation like that from the start with some examples of benefits of it would be really helpful.
Also, Vuex has a less strict but more usable idea of not having to import actions. You just refer to them as strings.
Also also, examples of XHR/promises handled by Redux especially with error handling all the way from “server returned 404/400/500/etc.” to how to hand that off to a UI element would be helpful. Takes way too long to discover the right pattern for action returning a promise.
Redux is an independent project from React. You could use redux with Vue. Your other points are valid but detracting from one library because people often use another you don’t care for seems outside the scope of React vs Vue.
Which IMO is simpler to understand as a newbie than Redux. Maybe because it had the luxury of coming after Redux/similar projects and underpinning a simpler parent framework.
I’ve yet to build a Vue app that I felt needed external state management (though admittedly none are huge SPAs) but I have felt the pain in React working on a similar sized project. Just something about how the events work out of the box. React I felt like I needed to pass in functions to change parent state through a callback function in props, whereas in Vue I just emit the event and forget about it.
You can still use the function prop pattern in Vue but it doesn’t make much sense when event emission is so much simpler to reason about.
I purposefully avoid Vuex until a) the state becomes large or b) deeply nested objects (which reacitivity handles poorly, as whole trees rerender) or c) when I have lots of deep nested Components with a maze of events.
This is where I've found Vuex is a life saver for reducing complexity, organizing state in a seperate area, and having a consistent interface for accessing/mutating data without a tangled web of events and functions across multiple files/layers.
For me, how vuex works was very very easy to visualize. State, mutations and actions are very intuitive.
On the other hand, redux's reducers are harder to visualize at the beginning. Until you learn how the reducer works, every reference to "reducer" leaves you slightly confused.
I visualized redux's better with a simple example. It helps you to see how state and reducers interact.
Long before learning of React or redux I built a similar system to do IPC between two embedded MCUs.
All state was owned by the master MCU, slave MCU sent messages to the master requesting changes of state, the entire state for the slave CPU was then sent over with the requested changes.
Even what UI screen was shown was handled this way.
I was much more junior then, so the entire system wasn't event driven, all state was transferred every 33ms (iirc).
Redux is moderately more complex than that system, although my system was built in pure C and involved interop between C and C# running in an interpreter.
What I like about react is that it's batteries NOT INCLUDED, allowing me to choose tools best fit to the job. I think it's good that there's a healthy choice between vue and react, however!
"v-model" isn't two-way binding like in AngularJS where both parent and child can modify the same data. It's just shorthand for defining a property and an event handler. Like in React, properties flow down and events flow up. See https://vuejs.org/v2/guide/forms.html
Makes sense, I've done some Angular but I'm not used to Vue.
Not really related but forms really are the most painful thing to handle in all those frontend frameworks, it's driving me insane how much work has to go into them when it's dead simple with a backend framework (eg Symfony/Django)!
I ended up taking over a Vue 1.x codebase and tried to update it to vue2. We used single file components and it was a nightmare trying to upgrade. I spent a good two weeks trying to upgrade and eventually just stopped because it was just taking too long. There were a lot of breaking changes from 2.0 to 1.0, especially with the way events were handled. Now, I will admit that the person who wrote the vue 1.x version did not write idiomatic vue and that caused some problems in updating. A lot of the components we used were also not updated to vue 2.0 and, of course, they were using deprecated features. That meant I had to search for something similar to replicate the existing functionality.
A vue component is still as simple as {template: 'hi'}. You don't need webpack or any transliteration for it to work. Just drop the script tag like the good old jQuery and it's working! No wonder it was so easy to switch to it.
Transition from vue1 to vue2 was really simple. I'm sure the same will be true for v3.