Reading through the RFC is really interesting. They specifically call out the dependency on Facebook as effectively being React's Single Point of Failure, citing their negative experiences with HHVM.
And for all of the love that people give React's big shifts (like hooks), the RFC specifically counts this against them, given that best practices have shifted so drastically in the last few years.
Oh boy I was wrong.
Hooks are way more easier and intuitive than what I thought. It makes code so much more readable and easier to reason about. Especially when before you had to wrap your components into x number of HOCs to inject the props your component needed, risking props collision, making it really hard to debug and use with TypeScript, and eventually making it a nightmare to understand and maintain your component. I'm not surprised that every React library added a hook API to its core.
At the end of the day it makes me more productive, so I guess that big shift was also a big win.
Forget a dependency in the dependencies array, forget an useMemo or a useCallback and your application will rerender like crazy.
Yes, it looks nice from the point of view of understanding the code, but what actually happens at runtime and the amount of miss steps they can produce is astounding.
Nowadays I'm using Vue and it is way, way easier to deal with due to the reactivity model.
What kind of application are you developing? Do you have complex UI? Or just lots and lots of pages where you reuse components a lot?
And then just being the larger community, I just feel like all there's more examples in general for everything. Most things default to React as the guiding implementation.
Now, the original reason I chose Vue was mostly around a small client side package size, but all the SPA frameworks have some version that prides itself in small client side package side now, and they mostly reach parity on similar concepts.
But I can't imagine modern technology being where it is without big shifts. Perhaps that is not good for very long term projects. We'll see how Vue fairs in the long run if they never make any big shifts, I suppose.
Then again, none of the big shifts in React broke anything permanently, did they? I could be wrong about this, I haven't been paying attention since the very beginning…
Looks like you are remembering things differently. Facebook doubled down on public outcry and even react maintainers gave up on it.
Then wordpress chose to stop its adoption of react in its new editor. And that caused Facebook to change the licence.
The fact a big org was needed for this change, is a major factor for Facebook's distrust.
Vue 2 to Vue 3 has felt like a big shift. Big enough to leave most libraries incompatible with Vue3 and a lot of community forks spread around while library authors work out how (and if) to support both versions.
Vue 3 is an improvement to work with IMO but it's a rewrite your code kind of upgrade.
The Github Commits[1] example on their documentation has a load of stuff that just doesn't sit right with me.
Things like
v-for="record in commits"
Similarly, accessing properties like
:href="record.html_url"
Maybe I'm just the odd one out here, but vue (and angular) love to use strings as a makeshift programming language, which to me is a major smell.
Code is just a string too, treating the 'code' inside the string literals after the v-for is just an extra level of syntax handling - The IDE I use (Intellij) can handle it just fine.
Also as a side note: I'd say the best thing about Vue isn't it's templating system, but the fact that it's truly reactive. In react, only rendering is truly reactive. If you have reactive variables that depend on each other, then you have to manually mark those dependencies. Vue can deduce that dependency graph automatically, which makes coding much easier. It's like a giant spreadsheet.
You won't ever have more than 10 characters at most in an attribute, and if you do you make a method for it and call the method.
The other alternative is JSX type stuff in react where you are injecting full JS into the templates which is like committing seppuku to me. Vue is so much nicer to use than react IMO, and I've used both extensively.
This is the part I don't really follow, though. Technically:
<a href="print(1//3)"></a>
Also modern component-based JS frameworks all work the same way. The UI definition is a template that's compiled into a render function which produces the final output during runtime. Each framework uses different syntax: React uses JSX which is a domain specific language (DSL) that mixes HTMl-like tags into Javascript. Vue uses HTML with directives on top. Angular, Svelte, etc all use their own formats.
You can even mix and match (use JSX with Vue) or write your own render function if you want, but it's the same text->parsing->lexing->compilation cycle that every language goes through before turning into actual CPU instructions.
It is different. Because "text inside script tags" is Javascript. Vue's templating syntax is a weird and inconsistent mishmash of custom DSL, Javascript subsets and Javascript expressions.
And it also depends on when it's parsed.
You get type checking, linting, syntax highlighting etc.
Let's say we want to iterate over commits in reverse. A google shows that we can do something like this:
v-for="item in items | orderBy 'field' -1"
v-for="item in _.reverse(items)"
Maybe I'm missing something though - I don't use Vue and if something is this big with this approach, I'm definitely missing something.
EDIT: A search for *new Function(` calls in the vue github repository shows quite a lot of code that essentially evals strings.
Webstorm has zero problems letting me refactor it, because it can parse vue code in .vue files. This is seriously a non-issue.
WebStorm and its bigger brother IntelliJ IDEA can handle this.
another dsl? mind-blowing! where haven't I seen that.
If only the Vue team could understand, we don't want React features. We'll use React when we want them. We want Vuejs.
It's just a little bit more coherent platform than React. There are core Vue projects, and they go in lockstep with Vue releases.
Second, Vue understood how fragile, and the same time important tooling is. There are many very mature Vue packages to scaffold, and manage your Webpack, or other build system setup for you. This saves a lot of hours because if this setup fails on you, it will also fail on tens of thousands other developers, and will get fixed quickly.
Vue itself been less tooling dependent at the start, and it played a role it its early popularity, vs React, which was superglued to Webpack or something similar from the start. Now, the situation has reversed I think, and it is a pain point.
I think there is a good sense of direction with Vue, with Evan being better at keeping focus on objectives for the next release than a lot of other frameworks developed by companies. I had few silent breakages during updating projects to new version.
Lastly, Evan is a very decent person, and this helps the project getting more contributors.
It's pretty interesting to read through.
I guess everyone’s been busy, what with a pandemic and all. :)
But this announcement makes things more official.
Polymer 2.0 with its HTML imports still offered a better DX in my opinion.
Svelte offers a better DX than both of those frameworks.
I don't even bother with FE anymore, more focused on BE/infra - but Svelte is always a pleasure to work in.
Until I met Svelte…Vue, minus the BS. A clean template system, less boilerplate, no Virtual DOM, nice Typescript support, intuitive state mgmt.
10/10 my goto for any frontend project.
It has a less "proven" ecosystem around state/async action management and some other concerns (i.e. there's no redux/vuex), but the controller paradigm[1] looks pretty fresh and interesting. I'm of the belief that most of the time doing an async request or two and some caching and good architecture is enough for most app (not everyone needs the flux pattern).
Lit is by the best implementation and standards-compliant component-centric library IMO. Tried a bunch of them back when I was trying to figure out if there's a better way to handle state in a component-centric world[3].
[0]: https://lit.dev/
[1]: https://lit.dev/docs/composition/controllers/#building-contr...
This is why lit-element is nothing compared to Polymer with HTML imports: https://lit-element.polymer-project.org/guide/templates
DOM in JS is an anti-pattern from a DX perspective.
Maybe it’s just my use cases, but every time I try to use a high level framework like vue or react I am immediately bogged down by unnecessary abstraction and complexity.
Again, I’m no UI dev so please correct me if I’m wrong! I have pretty simple needs for web app UI usually…I’m not trying to build Facebook. Why do I need react/vue/whatever?
This can of course be countered by pair work, extensive reviews, creating best practices, etc. However, there's a value in adopting something that already comes with those, instead of inventing them from scratch. The correct answer really depends on your situation and team size, I guess.
you either:
1. write spagetti
2. make your own abstractions, utilities, structures etc
No comment on 1.
On 2. I know you think your code is so elegant and blows people' mind away or whatever, but trust me, give it to someone else to have a read. They'd probably disagree with you more than they would ever disagree with a framework.
At least the frameworks have tests and documents for their functions
A lot of people just blindly build everything they write with their framework of choice. I argue that react is overkill for 9/10 web apps.
BTW, Vue 3.0 uses Typescript, but you can still programm with plain Javascript. That it what I am doing (I may be part of a minority).
Jquery had wonderful composability through its plugin system. If I want a tree widget, I just go to the jquery website and find one. (And of course you can do the same thing with vanilla js, but where are you going to go to find a tree widget if you don't want to build one yourself?)
The problem with jquery was that the "glue" was procedural javascript. That made it very difficult to use it from an html editor. With newer frameworks, the templating system is the glue. Where angular/react/vue/others differ is what that glue looks like.
So yeah, you can do all the same stuff with vanilla js that you can do with a framework, but you lose composability of widgets out of the box, and if you have composability, then you've just built a framework.
Been following Vue and Evan’s work since 2015, before it even reached 1.0. I think it strikes a good balance between the freedom of React and the rigidity if Angular. (Interpret the terms “freedom” and “rigidity” as you please.)
My only problem with Vue 2.x was the bad TS support, but I trust 3.x solves that.
I stopped using React specifically because it was so incredibly limiting. And my life has been a lot better without it.
Vue doesn’t have that. And yet it doesn’t lock you down the way Angular does.
Now, what that “area” is, remains up for discussion
Vuex, the goto state manager just wasn't built for it (I ended up using vuex-module-decorators). Type safe templates were only partially possible with Vetur (vs code extension) but it was slow and resource hungry. I'm sure in Vue 3 this is much better now, but while evaluating to migrate to v3 this wasn't the case.
I became interested in React, because I was looking for a way to generate type safe email templates. Started using .tsx files with a library called typed-html and loved it so much that I end up migrating to React (now rendering email templates with ReactDOMServer.renderToString(element).
Still miss Vue's simplicity at times but having rock solid TypeScript support is something I value more.
And Pinia is a vuex alternative which has good typescript support. Vuex 5 will have similar api as pinia
https://news.ycombinator.com/item?id=22625556 (March 2020)
For almost every topic on HN, a lot of people will go out of their way to criticize it.
The fundamental idea behind most modern FE frameworks remain the same. View is a function of state. The hardest problems in FE are state management and CSS/dom layout.
So as long as someone knows what they are doing any of the modern frameworks do a decent job. I have seen bad code in every framework.
So if the Wikipedia team knows Vue very well and yield its powers, may the force be with them.
Use the framework your team knows best. It’s really about the players more than the instrument.
I personally like React. It solves many of the pain points I’ve experienced over 10+ years. I’ve invested a lot of time learning it in depth. If someone told me to write react from scratch with hooks api, I know how to do it.
Seems Wikipedia chose Vue because folks knew Vue in depth. That’s a good way to move forward.
> Svelte, Inferno, and Preact are aggressively optimized for performance but have much smaller communities of users (Preact suffers from this issue to a lesser extent, but only as long as it maintains a very high level of compatibility with mainstream React, which may not be the case forever).
React, Angular, Vue.js are the most popular, in that order.
I hate to say might=right, but for a project like Wikimedia, choosing a mature, popular framework is important.
- facebook used to maintain CSSTransition for animation but dropped support for it and gave it to a dude who broke not only the public API but also some features I was relying on. I'm left having to recreate all the animation in a different lib, meh
- lifecycles related deprecation: componentWillMount, componentWillReceiveProps, componentWillUpdate. My app used to have a lot of these but that's the easy part to migrate, the problem comes when third party libraries use those and nobody support those anymore
- method deprecation which brake third party libraries: findDOMNode. The 2 one I've used that relied on it: dnd and csstransition. There's no clear path forward that would take less than a few days to migrate my code, meh
- upgrading webpack to whatever your config should look like in 2021 and what new plugin for x is named
Nothing very specific to react in particular but for simple use case jquery or plain javascript tends to create less problems to maintain things over longer period of time
As far as the community is concerned, hooks has been a positive change when used correctly but it's not because you can do something using hooks that you should, some of those abstraction are over-engineeringly absurd (eg: https://react-native-aria.geekyants.com/docs/useCheckbox#exa..., https://react-table.tanstack.com/docs/api/useExpanded, ...)
Vue's deprecation process is still a big problem in my view. Migration from Vue 2 to 3 is a painful one, while React doesn't have this problem. You can argue that component writing practices have changed over the past years in React, but the old ones all still work, while Vue 2 components just don't work in 3.
EvanYou's comments about a future "compatibility build" for 3 that works with 2 is honestly still a bit worrying. I'm glad it exists but it just so easily convinced them. Is there going to be a performance penalty? Will it all work out of the box?
Am I the only one here who absolutely hates Vue 2? No TypeScript support and no type safety at all (neither for props, nor for events, nor for provide/inject); many identifiers and references are hard-coded strings, making it very hard to discover dependencies between different parts of the code; `this` gets implicitly populated with props, data, computed, methods all at the same time and in some order that still escapes me; refactoring support even in IntelliJ/WebStorm is full of bugs (hardly a surprise given the missing type safety); horrible documentation ("Here's an example" != documentation); no proper two-way binding (i.e. one that doesn't produce change detection cycles). I could go on and on and on…
Most JS frameworks consider the SPA use-case to be the "happy path". There are a few outliers like the Stimulus family or Alpine (which I don't think existed at the time of the RFC) that expect to be sprinkled in to server-rendered HTML, but scaling these tools to full-blown apps may prove difficult.
I think Vue can operate in between these two use-cases better than some of the alternatives. Being able to compile templates at runtime is also a useful feature in a legacy environment, where you can't just transpile all the things ahead of time. You have to ship some extra code for this, but it's nothing compared to the cost of shipping (and running) all of Babel, which you'd need to compile JSX.
* More complex, slower build process.
* Increased barrier for development.
* ECMAScript has been evolving so quickly lately that it will probably supersede Vue in the near future anyway. The true "futureproof" choice is to continue evolving with the latest ECMAScript spec.
Some of this code may change or get moved around based on the outcome of these tasks: https://phabricator.wikimedia.org/T286946
Reminds me of Backbone.js' views: https://backbonejs.org/#View
Rather have Facebook as a single point of failure than some random dude who has other things that consume his interest.
Without making any judgement as to which is better, I'm afraid that's all in your head, bro.