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.

That is a bit annoying, but it's significantly less annoying than having a single huge componentShouldUpdate function that deals with everything a complicated component uses.

Hooks don't really change the work a component does. The logic is essentially the same. They just break it down in to smaller, more reusable, more declarative units. That's usually nicer to work with and a lot more "React-y".

Microsoft forcing Windows on mobile devices in the 2000s is an easy example of that kind of failed leadership.

This subject matter is covered extensively in: https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma

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?

You end up with code like this at the bottom of your files

    myCustomHOC1(
      myCustomHOC2(
        withRouter(
          reduxForm({ form: 'filters', initialValues, destroyOnUnmount: false })(
            connect(mapStateToProps, mapActionsToProps)(MyComponent)
          )
        )
      )
    )

In the new project I started last week, I'm using only hooks/context and a few libraries like react-router (useHistory, useParams), react-query (useQuery, useMutation), react-hooks-form (useForm)… and it has been a breath of fresh air. react-query is definitely another "big shift", it completely changed the way I used to think about fetching data and centralize it. It's very good, I highly recommend to try it.

[1] https://medium.com/@dan_abramov/smart-and-dumb-components-7c...

Over-splitting things only makes them worse to read and understand, even though each sub-component is prettier to look at.

Also notice there's a disclaimer on your linked article here the author retracts the recommendation.

That's pretty bad if you need "glue".

> Over-splitting things only makes them worse to read and understand, even though each sub-component is prettier to look at.

React is a UI technology, and only your view layer should know about the React stack. The model layer should be UI-technology agnostic (includes avoiding Redux etc.) and so should most of the controller layer. If something better than React comes along (and it will) only the view layer should need to be rewritten.

These functions are not part of what would be a controller or model layer in MVC. This code is not dealing with routing, fetching, managing state or rendering. They are merely gluing complex data coming from these other parts of the system into what is the view layer here. The logical separation still exists!

Sure OP could reimplement all of them by hand, but ultimately it doesn't matter: the code is still properly separated in the way you're mentioning. Libraries like those are free to have functions operating in multiple concerns, as long as the logical separation still exists, which it does.

If your app needs to show, say, a menu bar, you need those things. Maybe some apps don't, but most of them do.

How would you implement this communication in your ideal system?

Let's see:

This component lives around two or three levels down from the entry point of your React tree (the part which communicates with the router). Which way is simplest way to connect this to the router indirectly? One way is by passing values and callbacks via props, from layer to layer, until it reaches the menubar. This works and is completely isolated, you basically have plain-simple-Javascript-objects "injected" from the top level, or instances of an interface, if you're doing Typescript! This follows the I of SOLID: Interface Segregation Principle. It also provides you with the S, Separation of Concerns.

But the "prop-drilling" is way too cumbersome. Let's maybe use the Context API, which is a way of replacing prop-drilling? It's still properly isolated.

Congratulations, you just re-invented the wheel and re-implemented exactly what withRouter does.

Sure you could have your own homegrown interfaces. Or maybe you could have no menu at all in your app! It's your choice. But it doesn't matter: this is still following the rules you are calling for.

And you are talking about MVC but that's kinda what is going on here: a bunch of smart components are injecting data ("model") and methods ("controller") into a dumb component ("view"), which displays them and calls them when some events are triggered (e.g. mount, change, clicks, submit, etc).

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.

And now that the genie is out of the bottle anyone can do as they please with this fairly small rendering library and Facebook can't stop them. So I'm still not sure what the concern about Facebook is?

1. They chose to insert the clause and refused to use standard MIT license despite complaints from community and their own developers

2. They are the kind of company who chose to do shady stuff despite complaints from community and their own developers

#1 was fixed. #2 is still the case and may come to bite back in future. That is the concern

Well, I'm pretty happy using it and I certainly don't lose any sleep over Facebook having built it. Quite the opposite - I thank them for it! Nobody can take away my rights to freely available MIT licensed code.

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.

^[1]: https://v3.vuejs.org/examples/commits.html

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>

I'm like 60% sure that your "string' example is never run in production. So I believe that it gets compiled before vue even sees it (at build time, or dev-server compile time) into the standard method that vue is used to... a vue component:

    Vue.component('button-counter', {
      data: function () {
        return {
          count: 0
        }
      },
      template: '<button v-on:click="count++">You clicked me {{ count }} times.</button>'
    })

I guess my remaining alien issue is that the DSL for Vue is a mish-mash of JS, custom syntax, dom attribute context and possibly more?

All these frameworks try to solve what you're mentioning in different ways.

Obviously people have different opinions, but after seeing the way things are done from all these different frameworks, Vue is extremely "clean" and minimal feeling, while remaining extremely flexible. I have built multiple very complicated apps and there's nothing that I'm not absolutely DELIGHTED how it's solved, especially with the new composition API. It feels extremely elegant compared to the other ones I've mentioned.

Perhaps consider the alternatives, and you most certainly will have a much worse development experience if you're not willing to play ball with 2-way data binding (ie use html attributes to bind things, etc). As I said, other frameworks have tried other methods to minimize attribute use and they're excruciating to use. Ember is literally one of the most painful frameworks I've ever used to do even the most simple of things.

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.

Again, it’s all just text in different syntax. Programming languages are just a very large and well defined syntax compared to a template language, but that’s all it is.

Vue’s directives offer just enough control to handle 99% of scenarios while remaining within HTML.

All of these JS frameworks (React+JSX, Vue+HTML, Angular, Svelte, etc) require template compilation into an actual JS render function before a browser ever runs it, but compilation is the same fundamental process regardless of language or environment: https://en.wikipedia.org/wiki/Compiler

So yes it's all just text following a different syntax, and Vue's documentation already describes exactly what you can run: https://v3.vuejs.org/api/directives.html

Yup

> What actually does the compilation is irrelevant.

Nope. It is relevant. For the stuff you put between script tags there's at the very least https://github.com/tc39/ecma262 that you can look at and tell exactly what's going on with your code.

With Vue (and, yes, React and Svelte and Angular): who knows? It might very well evalueate strings at runtime for all we know.

> All of these JS frameworks (React+JSX, Vue+HTML, Angular, Svelte, etc) require template compilation into an actual JS render function before a browser ever runs it,

Yup. It's an additional, different step before it can even get to the browser. The problem with this step is that for most of this code there's not even a coherent specification of what it is, and how it's compiled.

> and Vue's documentation already describes exactly what you can run

It really doesn't. For example, here's the "documentation" on v-for:

    Expects: Array | Object | number | string | Iterable

    <div v-for="{ a: 1, b: 2 }"></div>

What are you even arguing at this point? This isn't about compilation or strings anymore. You don't like Vue's specific DSL? Or you don't understand it? Or you found a problem with the documentation? Or do you need a full grammar and syntax definition before you can do anything?

It's basically any valid `for..in/of` expression but you can always solve your mystery of "who knows" by just looking at the source code: https://github.com/vuejs/vue-next/blob/master/packages/compi...

That Vue isn't "the same as text between script tags". Because "text between script tags" is fully specified, and known to the browser.

Vue's ad-hoc mish-mash of DSLs has to go through an unspecified series of transformations before it can even become a "text between script tags". And that's the issue not just with Vue, but with any other templating layers.

> but you can always solve your mystery of "who knows" by just looking at the source code

Ah yes. The good old "code is the source of truth" fallacy. Can you point to me where exactly in code it specifies this: `Expects: Array | Object | number | string | Iterable (since 2.6)`?

I'm not sure why you're stuck on this. Templates are just a more simplistic programming language. That's how so many IDEs can still provide help with them.

This isn't true at all though, because `for x in y` is invalid JS.

   for (variable in object) {
     statement
   }

You said "strings are magic and not code" to which I said "all code is text so there are no magic strings". Now you and the other poster keep saying "well this string isn't the same syntax as JS" but I don't see what the point is. Why does it have to be valid JS?

Again, you can embed syntax within each other just fine. JSX has HTML tags inside JS. HTML has tags like <style> and <script> for other languages (regardless of what the default language is or what parses it).

So, for the last time, what's the actual argument?

   for (variable in object) {
     statement
   }

   item in items
   (item, index) in items
   (val, key) in object
   (val, name, index) in object

   v-for="item in items" :key="item.id"

for...in iterates over the keys of an object, but for in in vue iterates over the elements of an array.

It is you who doesn't think that loop does what it actually does.

Please read the spec and verify with your favorite JS runtime before continuing this argument.

    for (x in [6,1,6,2,6,3]) {
      console.log(x);
    }

Also Vue's directives are not JS. It's a separate DSL. I've repeated this enough so I'll end this discussion here.

This is not true for javascript at all.

    for (x in [6,1,6,2,6,3]) {
        console.log(x);
    }

Either way it's entirely consistent: an iterator that works on both objects and arrays and prints the keys without guaranteeing order. Does that clear up the confusion?

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.

The lodash example is the main critique because that is not JS, but it involves evaluating JS - it's created its own programming language with its own rules -- when one was right there from the beginning!

The scary underscore expression you're referring to can easily just be written as a reversedList variable in "normal" JS and get referenced plainly in the template. So the template expression syntax never has to be as messy as you might think it is.

    v-for="x in console.log('hello world!') && fetch('/') && [1,2]"

My point is that when your templating language starts doing things like this (and inevitably, all of them do) - you've created a new programming language that is generally less thought out as one than deliberately made programming languages. Although the above for loop is evaluating JS, the syntax is decidedly not JS.

Its not, though. JSX-based solutions (not just React, but Solid and others) don't (actually, neither do many frameworks with more traditional-looking templates, including, AIUI, Vue, actually compile templates to render functions, so it just looks like old school “string with embedded code which is evalled” ttemplates)

In any case the implementation details aren't important it's what it appears to be that is apparently the problem.

Yep, Someone mentioned in another part of this thread that Vue compiles most of this out before production, so my remaning confusion pretty much stems from the DSL being a mishmash of html attribute context, vue custom syntax, and evaluated JS.

You can write React without using JSX, and I assume Vue without templates, but unless the components system has a declarative layer so thin it might as well be templates (e.g. elm, or clojure’s hiccup) and it is entirely expression based, they’ll want templates.

Wicket looks like absolute nonsense of the worst kind. It completely reminds me of Struts and Spring and friends, and that is not a positive comparison.

You don't get that clear correspondence if you can have logic in your templates, and even supposedly simple expression languages in templates somehow always end up growing ifs, looping constructs and so on. Plain HTML fragments are good, but they need to be kept absolutely simple.

> Wicket looks like absolute nonsense of the worst kind. It completely reminds me of Struts and Spring and friends, and that is not a positive comparison.

I don't understand your position at all. The problems of Struts and Spring are the problems of templates only more so - if I were to make a spectrum I'd have Struts (and Tapestry) at one end, Wicket (and hiccup) at the other, and traditional templates somewhere in the middle.

You absolutely do.

> I don't understand your position at all. The problems of Struts and Spring are the problems of templates only more so - if I were to make a spectrum I'd have Struts (and Tapestry) at one end, Wicket (and hiccup) at the other, and traditional templates somewhere in the middle.

The struts I got to use was full of "smart JSP custom tags" because "components are the right way" and subclasses all the things, it looked exactly like the examples I see of Wicket: keep bouncing through layers and files of useless nonsense because all the logic has to be out of the markup but all of the markup has to be out of the code, and formatting a list takes you through 3 templates and 5 classes.

> Wicket (and hiccup) at the other, and traditional templates somewhere in the middle.

That makes no sense whatsoever. Wicket and hiccup have nothing in common.

Which is very much the opposite of how Wicket does things: there are no custom tags, the templates are inert HTML and there's a very small, non-customizable set of wicket tags/attributes (IMO the right way to do it is just IDs).

> That makes no sense whatsoever. Wicket and hiccup have nothing in common.

What they have in common is that all your logic is in code, not markup.

  {{ for item in items | orderBy 'field' -1 }} ?

To be clear, I vastly prefer Reacts approach of putting HTML into JS, rather than Vue/Angulars approach of putting JS into HTML.

Both approaches are valid, and each comes with its own set of tradeoffs.

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.

They're way, way overengineered for the very limited use cases they're designed for.

If you're going to ditch the browser API's and re-write the world in Javascript, why not take into consideration all of the history of GUI development and do it right? I.e., make a real layout engine, proper widget hierarchies, real encapsulation, etc.

Instead there's some sort of frankenstein in-between state where you've ditched all the benefits of native browser API's but haven't arrived anywhere that's a true paradigm shift.

TL;DR - yeah, they make some things easier to reason about, but for any sort of non-standard webapp you'll still need to write an equivalent mountain of hacks and framework adaptors.

You answered my questions with a bunch of theoretical non-answers that comes off like a tech purist who hasn't actually used the technologies but has a lot of opinions about them. Do you have a lot of experience designing non-trivial/complicated web apps with very heavy front-end features? "layout engine", "widget hierarchies" what _exactly_ does that mean in the context of designing something as complicated as Google Analytics/FB Biz Manager using javascript. If you are proposing not using primarily JS logic but rather server logic, or not as a SPA (or isometric hybrid like nuxt/next), then that makes me want to hear your answer even more.

Answer the question of: how would you do it?

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.

TSX support, and frankly JSX is the future of VueJS IMHO, also only really started working well with the addition of attribute namespaces to TypeScript.

So while these things have improved recently I would say language tooling has been really lackluster compared to the React ecosystem even 4+ years ago..

I do agree that Vue 3 was rather badly released though, as everything from the websites and docs to the plugins and devtools were all at different stages.

In fact, many Vue projects are using composition Api in Vue2 via a plugin because it is so good.

I used Vue 2 for some projects a year or two ago, and recently have been comparing React hooks & Vue's composition API. Composition is definitely better than mixins, but as a new React user, hooks are feeling more intuitive right off the bat. With Vue 3, I feel like I have to decide for every component whether to stick with the options API or use the setup method, or end up with some awkward in-between.

I was always a big fan of Vue though; I'd appreciate any insight you can give on the Vue 3 additions.

I'm a fan of how Vue's composition API executes exactly once during a component lifetime (during `setup()`), whereas React hooks get set up again on every render. I find it I find Vue's approach easier to mentally model, and thus easier to write correct code (especially when doing something complicated where state changes / effect executions trigger each other). Since `setup()` is only run once, I can also do things like store non-reactive state in closure variables without wrapping those variables in hooks.

It is kinda nice making reactive state really explicit like that; I like Svelte's approach for similar reasons.

React hooks require manual dependency tracking and mistakes in this can lead hard to identify bugs

Vue has automatic dependency tracking, so that entire class of issues do not occur.

"It's not semantic"

They will stay or they will go but I think they are useful more than they are not but I don't think its the final form we'll all adopt.

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...

[3]: https://mrman.gitlab.io/services-as-dom-elements

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.

Example: object oriented programming was THE WAY the write code a few years ago. Now functional programming is all the rage even though it has existed for decades. In fact, idiomatic react code just recently made the same switch.

I think it’s important to think critically and frankly having a discussion about the efficacy of contemporary design choices is the starting point.

In practice I've never seen anyone capable of writing clean vanilla js except for myself.

Of course that's just me jerking off to my own standard. "Vanilla" is an useless approach when it comes to finding a common ground to work in a professional context. It's in-efficacy in that sense.

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.

https://htmx.org/

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.

I was the "go to" guy for when React didn't want to do something.

Most of my wrestling came in the form of:

- recycling html-elements

- "tweening" state. a friggin nightmare to have inbetween states

- performant animation stuff

- stateless node-to-node communication for stuff that would have not fit well in state

- keyboard navigation (think game ui)

Ugh. The more I learned about how it actually works, the more I came to hate it. And it kills me to see so many people who love it... like I'm an alien amongst the people (developers) who I once felt understood me.

I dunno, every time I see someone hating React they’ve been kind of stuck in doing things the jQuery way, and their components become this horrible frankenstein of modifying HTML both through React and directly.

And you are right that React is not a good fit for these things. That's why I say it's very limiting.

Also, for what it's worth, you might be mistaking "the jquery way" with "the vanilla way." As in:

- working with HTMLElements

- vs working with a superset (tsx) of a superset (ts) of javascript meant to look like html (sometimes), that creates js components that then create html that is then diffed with last html and finally applied to the appropriate innerHTML (and don't forget about all the hooks!).

We already have the DOM, and there's literally nothing that React can do that requires its complexity EXCEPT server side rendering. Which most people never use.

I need to know what the problem is with modifying HTML inside a browser that knows and expects the HTML to be modified, even providing DOM APIs for this exact reason. What is the benefit of modifying a not the DOM besides the dubious claim of performace++?

I use react everyday now BTW. I needed to do something trivial like use something similar to setproperty to update CSS variable with JS returned values. This was part of a component that gets 3 colors and returns an array of RGB values which I need to change the background into a gradient. The one piece of advice I got from the internet is...

styled components.

FfS.

React is breaking every best practice from ~20 years ago of keeping concerns seperate. Sure Jqeury wasnt perfect but I could get a junior dev fresh out of school up an running in two weeks flat. There was no need to bend the time-space continuum with the black whole density of node_modules for every_single_thing.

React was a dumb idea from the very beginning, and anyone who knew vanilla js well could tell you that.

Nothing. As long as you’re not using React and value your sanity.

Some animations need to be run in javascript though, and doing that through state is a bad idea. You can use ref, and sometimes that's fine, but if the data is changing (hitting a moving target), then you need communication. Think coach-marks and scrolling at the same time.

And "tweening" views means showing the last view fade out while the next one fades in (or scrolls in, etc). This means displaying an old state, and a new state at the same time. The trick is to recycle your html elements, but it'll fight you for it.

No, the trick is not to use React for animations in the first place.

It's simply not a good a idea to use regular React state for very short-lived data (like animation state) as React will end up re-rendering everything all the time, leading to a significant performance penalty. Instead, I would rather decouple the animated DOM elements from React's state & change handling and just use e.g. d3 to control them. (Yes, it's not pretty but animations have never been pretty in the first place.)

Speaking of (not) using React for short-lived data, this reminds me of another common pitfall: Forms. Many tutorials online blindly recommend binding every HTML input's value to a React state variable using onChange, usually causing the entire form to get re-rendered upon every single key press(!) No wonder the Web is so slow these days…

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).

[1] https://phabricator.wikimedia.org/T241180

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.

It didn't go anywhere. Vue.js just became more popular for whatever reason.

It was a hulking, omakase, MVC? based framework at a time when the oppo was Angular 2.0 & Backbone.js and people still used Bower, then React threw everything on its head in favor of component libraries while NPM came into the mix.

They eventually refactored in components and I think repackaged everything for the new js fe ecosystem, but the battle was already lost.

- 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.

* https://htmx.org/

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

I was never confused.

The backward compatibility has a clean plan. For the bits that were complex changes, it was possible to do partial upgrades. From the beginning, the partial upgrade was in consideration. There was always early documentation, and you have access to v3 in alpha and beta all the time with complete documentation and complete guides. You also have standalone packages to start testing migrating bits of v3 to v2, like the composition API, class components, etc. It was one of the most seamless transitions I experience.

Without making any judgement as to which is better, I'm afraid that's all in your head, bro.