I understand why people feel overwhelmed with the whole React/Redux/Router/Saga stack but you really don't need most of that when you're just getting started and React itself is quite simple and elegant.
They are supremely useful. Ultimately, it's knowing how to use them to their maximum potential.
I've been coding since '02-ish. When I code with Vue, I have an App Developer mindset, rather than a web developer jQuery mindset.
When I use an attribute, it's just referencing a variable. It reacts to its own state in real-time.
I'm not the best at explaining. But with a legacy mindset, you have to interact with the DOM in some way. Whereas with HTML attributes in Vue, you can use the state in the local component to determine whether something is shown or even if a particular class is shown depending on what the state is of a variable.
Even better, that could be a computed variable or one that's watched. This functionality allows a bit of logic to then be run to determine how that variable behaves. This alone minimises the code I need to write in terms of legacy applications. Which also leads to less bugs.
Using if, for, show, and binding classes are very very powerful. I rarely interact with the DOM now and everything in state that is complex is an array. I can write way more complex apps with Vue, than I ever could with jQuery.
About the examples given here by the developer. You can still see that he's coding with a legacy mindset and that he hasn't internalised a lot of what Vue offers.
Some minor nitpicks:
- No need for this.$parent.$emit. There is a better way to use $emit.
- this.$on. <- What is this? An Event Bus? This should really have been a method.
- No need to use id attributes at all.
- Why not pass in the index attribute (which he is not using) to the delete function and then he can simply splice the array?
If he wanted to be real flash. He could have written the ToDo component as a JSX render function and taken the array from the parent and looped out the list. I know the Vue community looks down on it, but would have been a better way of going.
I don't really want to seem like I'm crapping over this. I'm not. I've only been using Vue since April myself. But there seems to be a lot of mistakes here and it's just not idiomatic.
As an aside, I thought I'd let you know that I've been a developer for just under one year, so admittedly do not have anywhere near the level of expertise that you have. I've also only been using Vue since April, but I guess that my level of overall experience, relative to yours, is lacking somewhat.
I got ambitious and tried to do with Vue.js and learn the framework in the process. Magic state updates were nice when it worked but with deeply nested models it always failed and I had to hack around to force it to update. I spent a ton of time fighting vue magic. I was ambitious. I wanted to make a generic NxN sudoku game where N was a url param.
Overall vue was like angular, done slightly well but it still had angular like problems where the magic failed and you had to dig very deep in code. It was also very slow to update the Dom. I had to revert to DOM element mangling just to speed up initial shuffle algorithm. I believe vue2 got on the vdom bandwagon so that’s nice.
I finally got it done, with two loooong nights.https://github.com/nojvek/uber-sudoku/blob/master/README.md
Uber did meet with me face to face but I didn’t want to move SF at the time and they didn’t have a Seattle office.
Overall vue has great ideas, probably good for a small project, but if you want to do a big SPA, I would not recommend unless you are really prepared to learn the internal magic.
Nowadays I really prefer preact. It’s the React api, it’s small, fast (has a better license - before Facebook got its shit together). One can read the entire source code in an hour or two.
It does one thing, it does it really well. This is what I like to see in libraries.
> They are supremely useful. Ultimately, it's knowing how to use them to their maximum potential.
Supremely useful for a typical full stack developer -- yes. Supremely useful for a dev team with members who specialize in web design (plain HTML, CSS, etc) -- not necessarily.
When your source code mixes a bunch of different web technologies it limits the types of developers who can effectively work on it.
Many commenters here regard React and Vue as "easy", but for many designers it's not easy. There are plenty of talented web designers who are just not interested or not capable of working efficiently with React/Vue.
Our company built an in-house JS component framework that is heavily inspired by React and Vue but that doesn't suffer from the intertwining of disparate web technologies. HTML, CSS and JavaScript stay separate from one another. As a result, our designers can independently iterate on UI without needing to touch a bit of JavaScript or quasi-JavaScript constructs.
Edit: not sure why this is being downvoted, I am genuinely curious.
We do plan to eventually open source it, but there's a lot of work to be done before a public release: better documentation, better tutorials, remove some constructs specific to our company, etc. We've open sourced some of our internal JS libraries before and it's worked out well -- the contributions submitted and bugs reported by others have been very helpful.
There are global styles, and there are styles that are relevant only to a particular component. Hoist styles up to a global (or more general) layer whenever you can, but I really appreciate the fact that I know the important styles I need will be in the same file/folder.
I absolutely agree with you on that.
It's important to point out that grouping and intertwining are two very different things. If you are building a large client-side rendered JavaScript web app, then it is very beneficial to group together the JS, HTML and CSS for a particular component. That's what we do too. However, it is highly debatable whether the JS, HTML, and CSS should be intertwined together (i.e., literally mixed within the same lines) and controlled using framework-specific quasi-JS syntax. As I mentioned above, when you do the latter, you will unquestionably limit the types of developers who are able to work effectively with the code base.
If your team is comprised of a bunch of full stack developers, then you won't face much limitation. But if you're like us and your dev teams include web designers who are JS 'lightweights', then it's a problem.
Reading your other comment from above:
> I hate seeing code syntax mixed with markup syntax. You can end up with hard to parse views (reminds me of PHP and Rails), and abstracts the final HTML structure from the developer.
You hit the nail on the head -- I couldn't agree more.
Full disclosure: I'm a founder of Pagedraw, which lets designers make UIs as easily as they draw them in a design tool, but are production ready. The designers don't need any code, but programmers can connect it to Javascript data bindings/event handlers as needed.
No one has to write HTML/CSS by hand any more.
Ease of use is a feature.
I think a much nicer way to work with templates is to see your markup with the same structure it will have once rendered, and attributes that describe those elements (just like real HTML attributes).
When it comes to accessibility, and creating predictable interactions without elements snapping around, I find it easier to visualize the end result when the markup isn't littered with text that won't be rendered.
HTML-in-PHP wasn't PHP. HTML-in-JSPwasn't Java. JSX in JavaScript is JavaScript. And that is a whole world of difference.
I haven't tried it yet but I'm definitely going to investigate mobx for my next react app.