Why I Converted from Vue to React

brettfishy profile image Brett Fisher Updated on ・10 min read

EDIT: After receiving a lot of comments on this post, I realized that not all of the information I presented is accurate. I just released an updated version of this article that you can read here. I will keep this article for historical reasons, but note that I don't hold all of the same views that I have presented here.

I've been a long time VueJS fan and still think it's a great framework with a lot of potential. It was the first JS framework I learned and will always have a special place in my heart. In fact, when I first started learning React, I was convinced that I would never leave Vue. It's easy to learn and with the Vue CLI, you can create a functional site in minutes and easily deploy it with something like Netlify (which is what I use for my blog). I liked the organization of the .vue files with their separate HTML, JS, and CSS sections. When I got a job as a React developer, I found it easy to get confused by React files since the logic for rendering JSX could easily get out of hand. I missed Vue files where if I wanted to know what the DOM would look like, I just had to scroll to the top of the file and I would see everything HTML related.

I've been working professionally with React for about 7 months now, and in that time I've gradually seen the beauty of React and have decided that it will from now on be my JS framework of choice (at least, until it's outdated and something even better comes along! Welcome to the front-end world...). I even decided to rewrite this blog with React, having originally created it with Vue. I'd like to explain a few reasons why React won me over.

1. There's no magic in React

One of the things I love most about React is that it is literally just JavaScript. To create a React component, all I have to do is write a regular JavaScript function that happens to return JSX. That's it, it just works! The way I think of it, JSX is basically the one thing that sets a functional React component apart from a normal JS function. Even React hooks are just functions - yes, you would only use them for React, but at the end of the day they're just functions. There's really nothing magical about them.

Since React is just JavaScript, I don't have to guess at all about where the code that's being used is coming from. Compare that to Vue where you have these "magic" functions and directives like $emit or v-for. In React, I don't have to "emit" an event. I just pass a callback function. That's pure JS, no magic there. In React, I don't need to remember some React specific directive to render a list of objects - I just use the JS map function and return JSX.

Let's take the following as an example: a component that renders a list of users with a button allowing you to follow that user. Maybe we could use this in a social media app. Here's the Vue version:

<!-- UserComponent.vue -->
    <li v-for="user in users" :key="user.id">
      {{ user.name }}
      <button @click="$emit('followUser', user.id)">Follow</button>

  export default {
    data: () => ({
      users: [
          id: 1,
          name: 'Rick',
          id: 2,
          name: 'Morty',
          id: 3,
          name: 'Summer',

Pretty simple, right? We have a list of users that we render along with a button next to each of the user's names. When clicking the follow button, a followUser event is emitted along with the ID of the user we followed.

Here's the same idea with React:

// UserComponent.jsx

import React from 'react';

const users = [
    id: 1,
    name: 'Rick',
    id: 2,
    name: 'Morty',
    id: 3,
    name: 'Summer',

export default function ({ onFollowUser }) {
  return (
      {users.map(user => (
        <li key={user.id}>
          <button onClick={() => onFollowUser(user.id)}>Follow</button>

The beauty I find in the React implementation is what I was saying before - this is just JavaScript that happens to be able to return HTML. If I were a new developer, as long as I knew regular JS I would be able to look at the React version and basically know what was going on.

If I were a new Vue developer looking at the Vue version, I'd have to know what v-for is and where on earth $emit is coming from. I would also probably want to know more about that data property in the default export of the Vue file. Those are all things I'd have to go learn from the Vue docs. Of course, there's nothing wrong with that - to master the tools you use as a developer, you must be familiar with the docs. But when I was a Vue developer, I had those docs open every single day. As a React developer, I occassionally look at the Hooks API reference in the React docs when I'm fuzzy on what one of the hooks does. Other than that, I don't need to look at the React docs because I'm just writing JavaScript.

2. React has better TypeScript support

As I described in my last blog post, I've recently become quite fond of TypeScript. One of the things I love most about TypeScript is the Intellisense you get from your IDE when developing. When dealing with dynamic objects such as network or database responses, your editor can't give you any kinds of hints as to what kinds of properties exist on those objects when you're using regular old JavaScript. With TypeScript, however, all you have to do is define a type for such responses, and all of the sudden it's so much easier to manipulate those data since your editor knows what properties you're dealing with. No more accidentally spelling a property name wrong and then wondering why your code is crashing!

The internet is already saturated with articles containing long praises for TypeScript, so I'll stop myself there. At the end of the day, TypeScript scales far better than regular JavaScript, and I've found that React plays a lot nicer with TypeScript than Vue does.

A big part of the reason goes back to the fact that React is pretty much just JavaScript while Vue kind of lives in its own little world. Creating a TypeScript React app is as easy as running npx create-react-app my-app --template typescript, and everything just works.

Now, the Vue CLI also lets you create a TypeScript project. Just run vue create my-project-name, and then you can choose to create a TypeScript project. There are a couple of problems with this, though. As explained in the Vue composition API RFC, the only way to really make Vue play nicely with TS is by using class component decorators, which I am not a fan of. I used TS with the Vue class component decorators for a class project, and I felt like it was hard to find good documentation and that there just wasn't a big enough community using Vue this way such that I could easily find online answers to what I thought would be common problems.

For another project, I actually decided to use the experimental Vue composition API plugin, which meant I didn't have to use the class components I despised and could still enjoy pretty nice TS support. Technically it's not recommended to use this plugin in production code, but I did anyways because I really didn't want to use class components. Also, the project where I used it will only ever be heavily used by a handful of ancient Assyrian researchers, so I wasn't too concerned about massive scalability.

The nice thing is, the composition API will be available by default in Vue 3, so I will give Vue credit for improving its TS support. For me, though, what makes React win the battle is the Intellisense available in the JSX. Vue still has its template section at the top, and even with TS, there isn't a great way for your editor to error check it. On the other hand, linters with React + TS will work just fine with JSX since you're just writing JavaScript inside.

Let's create a simple counter app in Vue and React using TypeScript as an example. Both apps will contain a typo. Here's the Vue version (using the composition API plugin):

    <!-- Typo! But ESLint has no idea! -->
    <button @click="increaseCouter">Click me</button>
    You've clicked the counter {{ counter }} times

<script lang="ts">
import { defineComponent, ref, Ref } from "@vue/composition-api";

export default defineComponent({
  name: "CounterApp",
  setup() {
    const counter: Ref<number> = ref(0);

    const increaseCounter = (): void => {
      counter.value += 1;

    return {

Here's the same app in React:

import React, { useState } from 'react';

const CounterApp = () => {
  const [counter, setCounter] = useState(0);

  const increaseCounter = (): void => {
    setCounter(prevCounter => prevCounter + 1);

  return (
      {/* Typo! But this time, ESLint spots it for us! */}
      <button onClick={increaseCouter}>Click me</button>
      You've clicked the counter {counter} times

export default CounterApp;

In both of the apps, "increaseCounter" is misspelled "increaseCouter". You can set up ESLint in both projects no problem, but it's not going to catch the typo in the Vue project. You'll be just fine in the React project since React is just JavaScript and ESLint will immediately recognize that "increaseCouter" is not defined.

Now, to Vue's credit, it does give pretty good error messages, so for this example when you run your app you will get an error about "increaseCouter" being undefined. However, you may not always get such instant feedback once you start dealing with more complicated code. Of course, just using TypeScript in React is not a guarantee that your code will be bug free. But you can automate error catching silly mistakes like the one above much easier than with Vue.

With some configuration, there actually is a way to use JSX with Vue, so that could solve this problem. But at the moment, there doesn't seem to be a big community doing this, so you might have a hard time finding answers when you run into problems. At that point, you might as well just be using React which supports JSX out of the box.

3. React is easier to test

Back when I worked as Vue developer, I began learning about the importance of test driven development. It took me quite a while to get used to the mindset of writing my tests at the same time that I wrote my application code, but now I'm at the point where I feel like I can't live without a decent test suite even for small side projects.

I began developing this mindset around the same time that I began to embrace TypeScript. I found quite difficult to test my Vue components, even when I got them working with TypeScript. While using the Vue composition API plugin, I found that Vue Test Utils a lot of the times weren't able to correctly render the components I was creating. This probably shouldn't have come as a surprise to me. I doubt the team maintaining Vue Test Utils was too focused on getting tests to work with the composition API plugin when the composition API is going to ship natively with Vue 3 anyways.

Vue Test Utils is actually pretty decent when you're using Vue 2's options API with regular JavaScript. Once I started using Vuetify though, which is a fantastic library, I immediately began running into problems. Getting the Vue test utils to recognize the Vuetify components was a bit of a pain
and I don't think I ever really figured out how to get tests working properly with Vue + Vuetify or Vue + TypeScript. Maybe there's something I was missing. If so, I'd love to learn about it.

With React, I've never really run into super weird errors when trying to set up unit testing, even when using TypeScript or a component library like Material UI. Once again, this all basically goes back to the fact that React is just JavaScript. There's no magic - all of its dependencies are imported in each file, which makes mocking them with Jest trivial. With something like Vuetify, all the components are kind of "magically" available, which is why I was running into so many problems trying to test them. Now, I know that shallow rendering the components would have solved those problems easily, but I agree with Kent C. Dodds that shallow rendering components doesn't really get them tested the way they should be.


The purpose of this post was not to say that Vue is bad - in fact, during the year and a half time span that I worked professionally with Vue, for the most part I was quite pleased with it and still believe it to be a fantastic frontend framework. I think that it is an easy framework to learn and a good starting place for new web developers. I developed the reasons I have for switching to React as a result of my own experiences. As I mentioned, TypeScript is almost a must have for me, and I find it a lot easier to use with React than Vue. But for someone who doesn't necessarily want to use TypeScript, React may not provide such a clear advantage over Vue.

I'll also readily admit that some of the problems I mentioned with Vue almost certainly have solutions that I am not aware of, and I'm willing to learn about them! In my own experience, I just found it a lot easier to solve the problems I was facing with React than Vue. At the end of the day, this post really just represents my own opinion and is shaped by what I consider important as a web developer. Someone with a different set of experiences may prefer Vue, and that's totally fine. But for now, I'll be sticking with React.

Posted on by:

brettfishy profile

Brett Fisher


I'm a full stack web developer originally hailing from Colorado. I'm currently doing an internship with Amazon and study Computer Science at Brigham Young University.


markdown guide

Uff, a nice write-up, but I so disagree. Professionally I have to work with React way more frequently than Vue, but I highly prefer the latter.

While ultimately it's a question of taste in most scenarios, here are a few rebuttals:

There is no magic in React, you simply return JSX?

Ignoring the fact that JSX itself is "magic", the fact that React's function to pass JSX on is called return doesn't mean it is return. You pass JSX into a function which I believe I don't have to argue is confusing as you seem to have confused it.

Edit: as one if the commentators (Birtles) has made me aware of that paragraph being misleading, let's clarify that you DO use a simple return. The point should have been to point out where you return to.

The same is true for your hooks explanation: saying that you declare callback functions is the same as hooks only being functions is like saying a vue-component is only an object: it's not wrong from a declarative standpoint but of course there is so much more to it.

The complete section about your IDE not being able to be smart enough is not really an argument for the framework itself. I use jetbrain's PHPStorm and it's so helpful that the usefulness of typescript in general is limited to preventing other developers to break code. However, you explain it with a huge community for React which is a solid argument for choosing technologies.

About vuetify

It's indeed a bit tricky to test. What bothers me about this comparison is that you compare it directly with React. If you wanted to compare on that level, you might want to explore something like next.js so can compare apples with apples (or at least fruit to fruit)


Hey neoan, I appreciate the feedback! I probably ought to be clearer about what I mean by "magic". I could see why someone may think of JSX as magic - what's all this HTML doing in my JS code? One of the most "magical" things I found about Vue but didn't touch on in this article was the properties that plugins attach to this. For example, Vuetify creates the $vuetify property. There have been multiple times when I've been looking at my company's code and had to do a double take when I see global properties like that, unsure if it was native to Vue or coming from some third party or in-house plugin.

I actually am a big fan of Vuetify and think it's a lot more intuitive to get started with than Material UI. But for React in general, I like its lack of "magic" variables. Everything used in a React file is imported. Going back to Vuetify, the $vuetify object has some pretty great methods on it, especially for breakpoints, but I will have to say I prefer Material UI's method of handling breakpoints. It just feels more declarative. That's only one example, of course, but overall I like how I almost never have to guess where any piece of code is coming from in React. This has been a huge plus for me when working with large code bases at the companies I've worked for.


To be clear, I am not making the argument that there isn't a lot of magic in Vue. However, at the end of the day a vue-component is valid markup and JSX simply isn't. That is why you will never be able to run a React component using JSX without compiling. It's the opposite of pure JavaScript.

As for vuetify:
Again, I think you shouldn't compare a wrapper like that (shall we call it a framework-framework?) with pure React. React has similar wrappers to simplify (and therefore magicify) loading.

And again, I am not claiming that Vue doesn't dip into the magic cookbook a lot. It is not intuitive to assume that something you declare in data() to be magically available directly in "this". It's something you need to learn/read.


Hi Neoan, can you please explain why do you think JSX is magic? (comparing to Vue's magic, i think vue is more magical than jsx) I'm actually planning to write an article about JSX so i wanted to know your thoughts :D


I will try:
Vue's markup is valid HTML. In the most primitive form, what Vue does is to create observers for props and data and bind it to HTML. The result is relatively straight forward:

<element :my-prop="bound-value" another-prop="hard-coded-value"> ...

This setup makes the use of .vue-files optional and doesn't even require a development server. One could import Vue via CDN and write components directly in "hard" declaration:

const template = `<h1>{{headline}}</h1>`;
   data: function (){
      return {headline:"test"}

So while there is a lot of magic in Vue, the markup and bindings are pretty straight forward.

React uses JSX (you don't have to use it, BTW, but then React makes little sense). JSX is NOT valid HTML. It cannot render without being compiled. It isn't JavaScript either. The following code snippet is therefore neither valid JS nor HTML markup:

return <h1>{headline}</h1>

Is that bad? No, but it's pure magic, of course. I mean, it has it's own name (JSX) because of that (otherwise it would just be a template)!?

Now, as every React-dev knows, this means that some interpretational oddities arise. For example, we have to use "className" instead of "class" and "onClick" isn't "onclick". But all of that is relatively easy to get used to and not an issue compared to what is offered. What bothered me about React was how state was handled and bound (this got sooo much better with hooks) and that JSX has a very ugly solution to the two most common things in a dynamic template: conditionals and iteration.

Given the following data:

items = [{item: "one"}, {item: "two"}]

Let's look at Vue:

<li v-for="item in item" v-if="item.item != 'one'">{{item.item}}</li>

And JSX:

{items.map(item => 
   if(item.item != 'one'){
      return (

Looking at the above example: it there more magic in Vue? Yes. But you tell me which is more straight forward and approachable.

Hmm i see, good points, thanks!

one thing, why react makes lesser sense when not using JSX? It's just pretty straightforward createElement calls.

"you don't have to use it, BTW, but then React makes little sense"

Really? Please try writing the following JSX with createElement-calls and surprise me:

<form onSubmit={parentCallBack}>
   <input value={someUsestateValue} onChange={ev => setSomeUsestateValue(ev.target.value)} />
   <button type="submit">send</button>

And BTW, since we have a template here. Compare the following valid markups:


<form @submit.prevent="parentCallback">
   <input v-model="someDataValue" />
   <button type="submit">send</button>

Or even more native and including the complete logic in declarative form:

<form x-data="{data:{inputValue:''}}" onsubmit="parentCallback(data)">
   <input x-model="data.inputValue" />
   <button type="submit">send</button>

here: (you said "React makes little sense", that's what i'm referring to, JSX is not binded to React elements you can build up any Tree like structures)

    { onSubmit: parentCallback }, 
    React.createElement('input', { 
       value: someUsestateValue, onChange: ev => setSomeUsestateValue(ev.target.value)
    React.createElement('button', { type: 'submit' })

So, how does it feel? Does it still make sense to use React? Do you think you could actually efficiently read a React app when built like that? What is the remaining advantage over vanilla JS?

const domEl = document.createElement;
const form = domEl('form');
form.innerHTML = `
<input name="some-name">
<button type="submit">send</button>
form.addEventListener('submit', parentCallback)

My point is: JavaScript is moving to a declarative style. We want a clear separation of view/template and controller/component-logic, even if there is a move towards having these concepts in one file (component based architecture).

So my question was not if it is possible, but if it makes sense. You would certainly use a different solution than React if you couldn't use JSX.


You seem to think that you are calling some magical return function. You're not. You are simply returning the JSX, the brackets there are not a function call, they're there for formatting the JSX over multiple lines as a return can't have a newline after it.


Yes, good point. At first I didn't know what you meant, but reading my comment again, I see what you mean. I make it sound like there is a function named "return". While there is no function "return" in the React framework, you are effectively passing it on to the render function. I should have been more specific/less ambiguous. My point was that declaration shouldn't be confused with how things work. I felt like many of the arguments were comparable with saying "webpack is just a json".

Edit: and reading my comment once more, you actually can't read it any other way than you have. I will have to change that.


Having used both extensively as well, here are my thoughts:

Vue requires a little bit of upfront learning (though most things like $emit can be learned progressively very easily). But the more you learn inside the framework, the less you have to learn outside of it.

React is a lot more low level in that regard. You even need to decide between several CSS solutions, forcing you to make impactful long-lasting decisions early on.

From the rails doctrine (rubyonrails.org/doctrine/):

How do you know what to order in a restaurant when you don’t know what’s good? Well, if you let the chef choose, you can probably assume a good meal, even before you know what “good” is. That is omakase. A way to eat well that requires you neither be an expert in the cuisine nor blessed with blind luck at picking in the dark.
You’ve surely heard, and probably nodded to, “use the best tool for the job”. It sounds so elementary as to be beyond debate, but being able to pick the “best tool” depends on a foundation that allows “best” to be determined with confidence. This is much harder than it seems.

This of course becomes less of a problem after a while...

Another example:

Sure, you can just pass in a callback for onFollowUser and don't get me wrong, I love the simplicity of this. But unless you wrap that callback in a useCallback, its child components will rerender unnecessarily leading to noticeably slow performance and lag in a fairly complex UI. Until you understand how React Hooks actually works, these are very surprising side effects, i.e. not "the pit of success". There are also a few quirks with useEffect:

Reference: blog.logrocket.com/frustrations-wi...

I seem to have spent an excessive amount of time twiddling various dependency arrays and wrapping functions in useCallback to avoid the stale state or infinite re-rendering. I understand why it is necessary, but it feels annoying, and there is no substitute for just going through a real-world problem to earn your stripes.

Vue takes care of these things for you. Not even once had I have to deal with rerendering/performance issues in Vue. The reactivity system just works and lets me focus on building the product. For me, it's okay to give up "JavaScript purity" for those reasons.

I do enjoy the simplicity of writing React components nowadays. But I don't think the Hooks paradigm is "just JavaScript" that everyone just grasps immediately, it requires a lot of exposure to get to know its various edge cases. I completely understand why React renders the way it renders. But I hope they find some solution making the process more obvious. Some of it is already solved by linters, but definitely not everything gets caught and some things likely won't be possible to get caught.

Like React Hooks simplified react components, Vue 3's <script setup> (github.com/vuejs/rfcs/blob/sfc-imp...) will also reduce the boilerplate to write components. Looking forward to that.


These are all great points. I agree wholeheartedly that Vue is very easy to learn. It was the first FE framework I learned, and as I mentioned, it took me a while to finally decide to move to React because I do appreciate its simplicity.

To someone just starting out with JS/web dev, I'd most likely recommend Vue because it fairly easy to learn. I probably ought to make it clearer in this post that I chose React not for ease of learning the framework. Rather, as I've come to understand JavaScript better over the years, I've actually come to really appreciate and even rely on the "lower level" features of React to write the kind of software I want. Plus, at this point I just feel like I can't live without TypeScript, and overall I've found it a lot easier to setup with React.

Yes, hooks definitely take some getting used to! When I first learned about useEffect, I remember thinking "seriously, I have to declare its dependencies? Vue's computed and watch do that for me!". However, I came to appreciate the simplicity that useEffect offered - I didn't have to worry about the difference between things like mounted, created, beforeCreate, etc. Granted, Vue 3's composition API will remove a lot of these nuances.

There's no perfect framework, and I'm not here to say that one is right and another is wrong. At the end of the day, I personally feel a lot safer making bigger applications with React.


Surprisingly enough few weeks ago I wrote a similar post, which I think can explain the word "magic" more clearly.


Your article is golden. I'm working on rewriting this article right now and found your points to be very helpful. Thank you.


Hey guys, this post got a lot more attention than I was expecting and I've received a lot of great feedback and comments. I've read all the comments and am currently working on rewriting this article to clarify the points I made and removing parts that I now know to be false information. I'm pretty new to blogging / writing about techy things so I appreciate the patience!


Your struggles with Typescript in Vue really surprise me. I have been using Vue with the class API and Typescript for over a year and I personally find them a joy to work with. I use Vuetify too.

I also cannot complain about the lack of type check in the templates since Jetbrains IDEs offer the same intelisense in template as it does in script (the typo example you demonstrated would appear as an error in my IDE). Not only that, I get the full power of refactoring offered by Typescript - renaming, extracting, referencing, etc - and that includes Javascript code in template as well.

Obviously, your experience is likely to be different if you use VS Code with Vetur which I personally believe to be a poor plugin (with all respect to the Vetur developers).

I also dont see any black "magic" with the way Vue handles things. Using the class API, the 'this' basically gives you access to functions defined in the base class, which is a very common approach in OOP in general. Also, $emit() is just a function that happens to be prefixed with the $ symbol for identification purposes. The $ symbol itself doesnt do anything special.

I also worked with the Vue Composition API plugin for Vue 2 and I had exactly the same pleasant experience using Jetbrains IDEs.

I personally find JSX the only real black magic in the entire javascript ecosystem. I have come to believe that JSX is the best thing to use if you intend to scare away new developers.


Hi Paulo, can you clarify why do you think JSX is the only read black magic in the entire js ecosystem? i'm planning to write a article about JSX so i wanted to know your opinions. why JSX is black magic to you?


Black magic is not the right wording. What I mean is that JSX is not standard. If you look at Vue, it is essentially standard Javascript and HTML (with custom attributes) that can be understood by any web developer. JSX on the other hand is this weird and unfriendly mix of HTML and Javascript in the same code block.

There is nothing wrong with having custom syntax that requires a compilation step. Typescript falls into the same category, and I love it. I just don't like JSX cause it looks terribly ugly.

Okay let me go line by line and give my opinions :)

"What I mean is that JSX is not standard" ?? facebook.github.io/jsx/

"If you look at Vue, it is essentially standard Javascript and HTML (with custom attributes)" - i don't think vue, sevlte, or angular's templates are in any ways valid html markup

"that can be understood by any web developer" - JSX is way simpler to understand than vue's template, if i ask you "how does Vue's v-for directive work" can you answer it in simple words? but if i ask you "How does jsx loops works" i can tell you the answer "JSX is javascript so we can just use Array.map to map out the childrens directly in the template"

"JSX on the other hand is this weird and unfriendly mix of HTML and Javascript in the same code block." - JSX isn't a mix of HTML or js its Just javascript. it represents Tree like structures and we use it to build up the virtual dom.

"I just don't like JSX cause it looks terribly ugly." - well, personal preference :D

That's all. :)

Needless to say it all comes down to preference since you could use any of these frameworks to build most web apps.

JSX is not just Javascript since it has markup in it and there is special syntax to separate markup from the actual js code. If it were just Javascript, it wouldn't need a special compiler in the first place. This is more than obvious.

Anyway, tools are just tools. Languages are just languages. Pick whatever gets the job done.

Javascript will die some die, just like Vue and React will die too, just like the almighty Jquery is dying just now.

As a developer, what matters to me is to spend my time getting the job done rather than advocating in favor of a particular framework.

Btw, I develop frontends using Angular, React, Vue, XAML, Blazor and vanilla javascript/html. As I said, they are nothing more than tools.


Hi, the code in the first point for Vue isn't equivalent to the React code.

The callback prop in React code is required, as you would get an error otherwise, but you don't have to listen to emitted events in Vue. Also, you can pass callback in Vue via prop the same way you would do in React.

Another thing is the users array. In Vue version the array is bounded to the component instance - every instance has its own array, but in React version the array is shared between component instances.


Good catch, thanks for pointing those out! I'll be sure to update those.


First off, I believe anyone should be able to use any JS framework they want. You can get the job done with just about any of them, and their are successful big applications written in all of them.

Though I will say I disagree with the point that Vue is doing magic, but React is just JavaScript. If we wanted to do that I'd say that Vue is just an object. I disagree because React isn't just JavaScript. It returns JSX. That is not valid JavaScript. It's an extension of it, but it has to be compiled to regular JavaScript still. There is still a lot of magic happening for your "regular JavaScript function" to actually be able to be ran in a browser.

Again, you can definitely use which ever framework you prefer and don't even need to apologise for moving away from one framework. Just thought that with that point you ignored the "magic" that React is also doing.


Thank you for this writeup. I definitely understand the drive for a DSL to provide defined structures, which driving with free structure of the underlying language may not provide enough guidance to doing it right.

As you mentioned in both cases you have to learn how things fit together. With a lot of "magic" going under the hood is harder and usually necessary at some point. So personally I'd have the same leaning you do.


Thinking about this more, I think that you need to learn from the Java developers and add a layer of abstraction. This way you can switch out the framework without changing your code. All would need to do was implement a new backend to hook up vue or react. This would mean you would be ready for the next new framework as well.

Actually create your own language and compile it to JS so that when JS is replaced in browsers you don't need a complete rewrite of the code.


Great point, but I think the JS community is so dedicated to "koolness" that it will be 20 more years before they realize the harms of marrying a particular framework. But, I guess, it's all right because it keeps the devs employed and gives the agencies something to impress their clients with. Win-win? 🤣🤭


Well I didn't say you wouldn't be tied down to a framework, it would just be a framework a level above the other frameworks. And we could create competing frameworks at this level so programmers can choose the best one for their needs.

I wasn't countering you at all. I agree with you that the core parts of the app should be plain JS (or plain whatever language you're into) and the framework should only be used for its technical capabilities. But it's just a dream . . . looking at the full-stack worlds of Python, PHP, Ruby, etc., I know for certain it's never going to happen . . .


I dabbled with React for 1-2 months, then gave up due to complexities involving webpack and redux.

Then I found VueJS, got hooked on it and never looked back.

Fast forward 2 years, your post got me intrigued with React again. Your point about TypeScript and Vue is spot on... I think I might revisit React and see how it goes.


Imo Mithirl.js it's closer native js than React.