Styling React components is a huge pain. What I like about Vue is the awesome styles, HTML and js in one file for each component. With React projects I have a completely seperate styles folder.
- Defaults matter; templates as defaults means most examples, support, tools, extensions, etc. will assume templating.
- React without JSX doesn't actually affect the code structure or flow. Looping, conditionals, composition etc. all stay the same; and that shouldn't be surprising since JSX is essentially no more than a slightly different syntax for nested method calls and object literals; which is quite unlike templates in vue; those have actual semantics too.
I've used react without jsx before (some time ago for a coffeescript based project), and it affects little. If you do that, you'll want to introduce some alternative shorthand to avoid all those repetitive "React.createElement" calls, but doing so is trivial - after all, it's just method calls and object literals.
I'm not a huge fan of custom languages like JSX in general, and indeed JSX too (I believe) was a mistake. However, with sufficient support and a small enough target to support, it's less of an issue. Still, even extremely well funded projects like razor are clearly much less well supported by tooling than the language they're based on, even many years later. Vue's templates? Completely hopeless.
There are two distributions of Vue, one in which templates are precompiled (this is the default and recommended build), and one bundling the runtime template compiler. You are most likely thinking of the latter.
I'm still amazed people argue that statically typed languages don't make you more productive compared to dynamically typed languages.
What? You thought dynamic languages were a new fad? They have existed as long as computer science has, exactly like static languages.
For what it's worth, the "productivity value" is demonstrably minimal if we're talking about good coders. And it's not like bad coders wouldn't run into roadblocks with static languages that don't exist in dynamic ones.
I've worked a lot with static and dynamic types, read a lot about both and in my opinion static typing has clear and obvious advantages.
> For what it's worth, the "productivity value" is demonstrably minimal if we're talking about good coders. And it's not like bad coders wouldn't run into roadblocks with static languages that don't exist in dynamic ones.
Why is being a "good coder" a factor? Everyone makes mistakes and teams will always consist of a mixture of skill levels. On large code bases especially, getting compile time errors on basic problems like referring to non-existent variables and calling functions with wrongly type arguments is undeniable time saving in my opinion. Types also enable better refactoring automation and autocomplete. All of these are great for small projects and even better for big projects with lots of team members.
What advantages does dynamic typing have that could outweigh those factors?
You can read on advantages of dynamic languages everywhere, I was just pointing out that your point of view, and the point of view disagreeing with you, isn't anything close to new, making the attempt to start a flamewar in your first post, and trying to continue it here, all the more pointless.
BTW: Good coders are factor because no amount of "you have to write 'string' or 'int' before the name of the variable" is going to save a bad coder from producing bad code.
Still, strong-typing has been with us forever and, in general, I feel like we've solved this problem. I'd like to see a light-weight VM framework that supports Java code compiled down to JS, with an in-browser Swing-like component framework (no, not applets). But a lot of the tenents of async, event-driven Swing style dev (including using workers to keep i/o off the event thread), actually overlay nicely with the challenges that modern JS frameworks are attempting to solve.
I know there's not a lot of Java-love around here, but, pick any language that has modeled out this problem and has a cadre of seasoned developers. Then, rather than re-invent the wheel, just port that to the browser.
Shame it came with such an unwieldy deployment model that it never gained more traction.
Pre-styled, if unremarkable componentry is what I need to deliver business outcomes. Bootstrap is made for people like me, but something like Swing would make it even easier.
But, for me, it's not just the styling, but the architecture and componentry for modeling out async, event-driven web apps in a more natural way. And, I think that's the piece you're referencing that Swing can add to Bootstrap-alone.
With React I get something laser-focused, just does 1 thing well and that's it. With Vue, I have to buy into the entire ecosystem.
I don't want to experience what I did with ember and meteor ever again in my professional life. I think about all the great developers I've worked with and I looked up to, and almost all of them hated all-in-ones. I rolled my eyes when I was younger, but today it's like damn these guys had a point!
Vue is the antithesis of Angular 1 in that sense. No stupid ontology of inane design patterns - no services, no providers, no factories, none of that mandatory crapola.
"Unlike other monolithic frameworks, Vue is designed from the ground up to be incrementally adoptable. The core library is focused on the view layer only, and is very easy to pick up and integrate with other libraries or existing projects."
But as your project grows, and you start to need special, custom things (and you inevitably do), you understand the "Rails" part. You have to move along the rails. This leads to a growing number of ugly hacks, just to keep the whole thing within one framework. The problem is that you can't replace one component you want different. Everything is cross-dependent, aka "integrated".
In the long term, libraries rock, and monolithic frameworks suck. But in the beginning, the lure of a monolithic framework us strong.
I suppose the thinking behind all these services, providers and factories was that they give mediocre developers that don't really know how to program a more common vocabulary and a set of childproof "design patterns" to grok — that's always easier from a management perspective than giving people who don't really know what they're doing the freedom to architect. But it just frustrates the snot out of actual developers who just want to be left alone and resent having to shoehorn their _entire_ application code base into some framework's mandatory structure, by way of which there are still yet more APIs and conventions to learn and with whose changes it is necessary to keep up ...
In this sense, Vue wins very big. It handles data binding and rendering/UI generally, but in no way premeditates how the rest of my JS is going to work.
Vue is really just a component framework that deals with the view, it doesn't do Ajax, it doesn't even do routing and don't force a backend or a database like Meteor.
Specific, narrow focus and it's served me well. Sensing the innate liability, I've never felt the allure of the full fledged framework.
Having a small community means the potential for focus and strong canonical learning resources, as opposed to the mess of poorly written React and Angular posts/"guides" we get every week. The community feels tighter and it may be easier for the maintainer(s) to manage it and the codebase.
Ember is a good example. Ember's community isn't small (sold out conferences every year), but it's not in the spotlight like React or Angular are. That doesn't mean the framework is doing poorly. If anything, their community and meetups are "better" than React's (for my definitions of a good community/meetup).
My point was that Vue doesn't need to be huge. It's fine the way it is and its current size has some benefits.
Well, by "created by giants" in this instance think more of "a small team in Google/Facebook web-devs went ahead and did it, and then it caught on in the company and Google/Facebook decided to give them some more resources".
It's not the kind of "created by a large company" that something like Java or C# etc have, where there were tons of millions spend, huge 100+ person developer teams, documentation writing teams, etc and tons of paid marketing to promote the effort. That, only huge communities can compete against.
Here's from Quora about React for example:
"React was created by Jordan Walke, a software engineer at Facebook. Jordan deserves all the credit for creating React. He was influenced by XHP, a PHP-based component system that is still in use at Facebook, but also by functional programming ideas. Pete Hunt wanted to use React at Instagram, so he helped to extract React from Facebook-specific code. This prepared React to be open sourced. Later, Facebook put a team of engineers behind React and also received great contributions from the open source community. Significant contributors include Sebastian Markbåge and Ben Alpert, among many others."
So basically a one-man show for the beginning -- and similar story I've heard for Angular.
The #2 person contributes only about 1% compared to the #1 person.
Compare to React's same graph: https://github.com/facebook/react/graphs/contributors?from=2...
The #2 person is at about 50% of the #1 person.
Compare to Ember's same graph:
The #2 person is at 75% of the #1 person.
These marketing sites are very often built by contractors, not FB engineers, and tend to be one off efforts.
Not to knock Vue, but it weakens the message when deliberately misleading info like this is used
It's still a Facebook owned site, and a public facing one at that.
Even if they just bought if as is ready from some third party, it shows Vue is mature enough to be accepted for such a use.
Because it doesn't: "not candid or sincere, typically by pretending that one knows less about something than one really does."
There's nothing insincere about saying that newsfeed.fb.com uses vue because it does. It isn't pretending to know less, if it were false, it'd be pretending to know more.
Disingenuous doesn't mean "I don't like that this person said x", or "I like y, so I don't like that this person said a good thing, even if true, about x."
It's becoming a pet peeve.
It's a shame since it's otherwise a well written article
However the reality is so far from that, where a marketing site built by contractors under none of the strict constraints of the product it speaks about uses Vue, that it serves not as an endorsement but instead a needless point of contention in the post.
I'm not saying that you're wrong about Vue not being a "thought-leader" or whatever, just that you really should be more appreciative of developers who release awesome libraries under OSS licensing.
That said, being a "thought-leader" is not necessary in order to make a difference. Software has been, is, and always will be an iterative process. We build upon the shoulders of giants that came before us. We take the best ideas from our predecessors and combine them to create something new and, hopefully, better. Regardless of your opinion on the philosophical aspects of Vue, you have to give credit to its creator and its community.
Vue might be fun to work with, but it doesn't have all the advantages of Angular (or React) I listed above.
Vue.js also has the nice advantage of being able to use HTML, TypeScript and SASS within the same .vue component:
Vue being stewarded by Benevolent Dictator is why it has an elegant design that's more pleasurable to use. Angular2+ has morphed into another design by committee complex monstrosity requiring much more code, conceptual and cognitive overhead to achieve the same result.
Reading the article, I was surprised at this part:
"Wait, did I just write Facebook? Check Facebook’s newsfeed."
I did checked facebook's newsfeed and certainly, the Vue Devtools lit up on my Chrome browser, which detected VueJS being used on that page. Given that FB has heavily leaned on React, I wonder why they would be using Vue on one of their premiere pages? Is it because they are also trying to analyze what's being offered by Vue and integrate it with React in the future?
I love react and have always been super impressed with the ecosystem FB created - just wanted to give Vue credit for being an enjoyable framework.
Angular was the first framework I used, and I liked working with it well enough, even if I wasn't a big fan of many of its idiosyncrasies. But then Google announced they were going in an entirely different direction so I decided to try new things.
I tried liking react (gods, I tried, many, many times) but I just can't like how the code looks when using it or the structure it ends up forming, or the boilerplate it requires.
Vue, however, feels like doing plain JS, which I actually like, as each component is rarely more than a few objects and functions. Well, that and html templates, which I'm fine with and would have to use anyway as a backend developer.
: JS has always been my second favorite language, after python, and the new versions are just so nice to write.
I'm building a prototype of one of our actual landing pages in each framework to get a bird's-eye view of what works and what doesn't. So far I've been really impressed with Vue, but my team has a couple of objections from the outset:
1) Most mid-level developers haven't heard of or used Vue, so the pool of candidates we can hire as our company grows will be smaller if we switch from a common denominator like AngularJS to something relatively unknown like Vue. I personally love to learn new tech, but not everyone does and a "Vue developer" job posting may not get a lot of hits.
Then again, if (e.g.) 15% of devs want to use Vue and only 10% of companies use it, that's a clear advantage over 75% of devs wanting to use Angular and 80% of companies using it. I wouldn't be surprised if the numbers worked out like that.
2) Vue is kind of a one-man band, whereas Angular and React are backed by large cap companies. This is the weaker argument IMO, since there's no law stating that Google and Facebook can't run up on hard times and decide to drop support for their open source projects. And after seeing how sloppy Angular's documentation is, I've lost a lot of confidence in the "bigger is better" argument. However, in a rational universe, it may be fair to say that Vue would die more easily than Angular would.
My view on the situation is that it's better to use the right tool for the job and have less developers/support than to use the wrong tool for the job and have more developers/support. But I'm more technically-minded than business-minded, so I understand that I might need to be open to business concerns outside of my normal decision-making criteria.
I'm keeping detailed notes as I compare frameworks, so I may do a write-up when I'm done if anyone's interested. (Although the "battle of the frameworks" genre has been done to death...)
In web development more than anything else, the chances are higher that whatever keyword you hire for will be sidelined in 1-2 years. Even compared to other fast-moving tech niches, the web front-end arena is a batshit insane ADHD chipmunk in this regard. A DBA or a networking guy's current keywords are going to have at least five years of shelf life in some fashion. You can't count on those kinds of lifespans in the web world anyway. Yes, I also think that's ridiculous.
And so, "all-around competent JS developer experienced in a variety of frameworks and tools" might be the only viable hiring selector here.
Also, the barriers to entry to Vue are much lower. The simplicity is one of the main selling points. I'm not even a web developer by trade, but I picked up most of the essentials in a day or two. Admittedly, I did have a [kind of amateur] AngularJS background, which made that process much simpler, but I gather a React background equally predisposes one to rapid assimilation of Vue.
The thing that sold me on Preact is its compatibility layer with React, which provides a kind of de facto standard API for components. One day I just replaced React with Preact, with the only difference being a happily reduced app size -
and have been using it since. I don't plan to keep up with React's latest developments - I'm satisfied with the rendering performance of Preact, and want to stick to a stable API which lets me focus on actually building things with it.
I feel the same about client-side routers, the build process with Webpack, etc. - I'm fatigued of keeping up with breaking changes, and have started transitioning to smaller, individual libraries that just do their modular jobs, with minimum API surfaces that are reliable over long-term.
So large companies are more open to using it because it's less risk and has higher chance of being around in 5 years than a framework without a huge backer.
That's my theory on how 'biz' people make I.T. decisions.
They're solid, non-arbitrary reasons. Given a choice between the most common tech on the market and a niche offering, you need to have a good reason to choose the niche offering, because it comes with real downsides to a development team (as opposed to an individual developer).
I'm not a web developer at all by trade, but it took me only 1-2 days to pick up the essentials of Vue. That's not because I'm brilliant, it's because the barriers to entry really are that low. It's simple. They've nailed that part well, and it's a very seductive differentiator in a JS front-end world that just keeps getting more and more Byzantine.
Admittedly, I did have some Angular 1.x background, but it was really just dabbling in the grand scheme of things. And I gather that a React background is equally advantageous in picking up Vue.
More generally, given the insane ADHD pace at which front-end web technology moves, I'm not sure hiring developers for any particular framework experience is viable. People sometimes say that about tech hiring in general, and I don't necessarily agree, but web front-end work is really the one area where I think it holds true and you just have to hire competent JS developers experienced with a variety of tools and frameworks in general. There's just no telling how different the landscape will be in 1-2 years.
What is not is the next step when these groups become extremely invested and endlessly hype their choice and rubbish others in places like here never mind any technical merits or demerits. The prevents proper technical scrutiny of hyped technologies and allows a lot of bad ideas to gain traction.
(The implementation is quite clever. Very similar to React in nature but with less boilerplate.)
Preact offers a similar experience.
So React doesn't compare to any of the others.
Webassembly needs it's own UNIX. A simple abstraction library for browser IO that scales.