Why we chose Vue.js over React

The arguments against JSX and React requiring many small components are very surface level and sound like &quot;we couldn&#x27;t figure out how to make it work for us so it must be impossible&quot;.<p>1. This was mentioned already, but, yes, you can use ternaries and boolean logic for simple conditionals (loggedIn &amp;&amp; &lt;a&gt;Logout&lt;&#x2F;a&gt; || &lt;a&gt;Login&lt;&#x2F;a&gt;)<p>2. When you need more markup, put them in an if-else statement in the same render function.<p><pre><code> render() if (loggedIn) { var login = &lt;a&gt;Logout&lt;&#x2F;a&gt; else var login = &lt;form onSubmit={ ... } &#x2F;&gt; return &lt;div&gt; { login } &lt;&#x2F;div&gt; </code></pre> 3. With SFC it&#x27;s trivial to split these out into new components. You can even use bound methods to reuse the component state and props.<p><pre><code> class Navbar { LoginForm = () =&gt; { if (this.state.loggedIn) { ... } else { ... } } render() { const {LoginForm} = this return &lt;div&gt; &lt;LoginForm &#x2F;&gt; &lt;&#x2F;div&gt; } } </code></pre> 4. And finally, what stops you from creating a custom component that works like this?<p><pre><code> render() { return &lt;If cond={ this.state.loggedIn }&gt; &lt;Then&gt;Hello { this.state.userName }&lt;&#x2F;Then&gt; &lt;Else&gt;Please log in&lt;&#x2F;Else&gt; &lt;&#x2F;If&gt; } </code></pre> There&#x27;s a continuum of ways you can structure your code, it just takes some experimentation to find what works for you.<p>After working with Angular templates for a long time and then switching to JSX, I&#x27;m never going back to having my markup in a string blob with magical attributes that make it do stuff.

One of the most impressive thing about Vue.js was the ability of the framework to enter a field saturated with dozens of options, that was becoming dominated by a well-resourced oligopoly (Angular, React), and still win over developers jaded from Javascript-fatigue.<p>The <i>give-a-shit</i> factor from Evan (the creator) is extremely high and was key to its success.<p>Inspiration for anyone building a product in an established market: there&#x27;s almost always room for better.

I&#x27;ve used Vue pretty much daily over the last year in a fairly complex app (some 150+ components, Vuex store with 100+ actions, full client side router navigation) and it has been pretty pleasant. I even contribute a nominal amount to the Patreon campaign. However, the upgrade path from v1 to v2 is not a quick undertaking. Certain changes require a revisit to practically all components (e.g. change of &#x27;ready&#x27; to &#x27;mounted&#x27;, v-el to ref etc.) that don&#x27;t really bring a lot of value to the end user other than change in semantics. The upgrade diagnostic tool is a great feature, but seeing 600+ breaks in your app is not so much fun. Changes in Vuex (e.g. no more vuex: getters in the components, &#x27;dispatch&#x27; is now &#x27;commit&#x27; in the store modules) translates to significant work in a largish app just to upgrade semantics. Also, the article references the verbosity of Redux with respect to forms. In all fairness, all Flux implementations, including Vuex, have pretty much similar verbosity.<p>Just providing some balancing thoughts for folks to be aware of before investing heavy time in any framework, including this one.

My man, a lot of the pain described in this article can be solved by Mobx: <a href="https:&#x2F;&#x2F;stackshare.io&#x2F;mobx" rel="nofollow">https:&#x2F;&#x2F;stackshare.io&#x2F;mobx</a><p>One of our engineers at StackShare[0] suggested it and it&#x27;s fantastic.<p>Mobx is very simple to understand and will make writing a &quot;React&quot; page a real joy again. Redux was way too complicated for what it gave, and just shot term after term after term at me that left me with a headache. I still don&#x27;t understand Redux proper.<p>&gt;Why do you have to type so much?<p>I know! I nope&#x27;d away from Redux because of that same reason.<p>But Mobx clicked for me. And if it clicked for me, it&#x27;ll click for you.<p>Basically you have a store and you use that store anywhere in your components to share store state. When you update that store state everywhere else updates as well. Simple.<p>Another great reason to use React as opposed to alternatives is react-native. A _lot_ of knowledge transfer between the web and mobile with react native. It&#x27;s pretty insane.<p>[0] - <a href="https:&#x2F;&#x2F;stackshare.io&#x2F;stackshare&#x2F;stackshare" rel="nofollow">https:&#x2F;&#x2F;stackshare.io&#x2F;stackshare&#x2F;stackshare</a>

I&#x27;m a designer and not a coder, so I feel obliged to provide my comments with salt added up front.<p>That being said, JSX vs. wrapping HTML in if-statements seems like the same kind of trouble to me. I&#x27;ve done a few simple prototypes in Clojure&#x2F;Script, so my reasoning is heavily influenced by the fact that I know very little about other languages, and only have moderate amount of knowledge about Clojure.<p>The solution I&#x27;ve encountered in Clojure is to represent the entire page as a data structure. Conditionals and transformations are applied directly to this data structure, which is then sent as-is into the rendering pipeline (which commonly seems to be React). The HTML is never really written by hand, it&#x27;s just a final &quot;coat of paint&quot; on top of the data.<p>To me, this seems far easier to wrap my head around than splicing two languages together in the same file and potentially finding that the interaction between the two is not as harmonious as one may wish.<p>Rendering <i>to</i> HTML, rather than rendering <i>within</i> HTML (so to speak), seems like it would remove the entire decision point where you have to pick between one library or the other based on the quirks of how it looks when it&#x27;s spliced into HTML.

I believe React is popular (among other reasons) because you don&#x27;t need to learn what is v-if v-else and other repeative commands when you have plain and simple JS equivalents.<p>React has te philosophy &quot;It jusy works&quot;, and people love this

If you prefer html templates you&#x27;re going to choose a framework like Vue, Angular or Svelte. If you prefer Javascript driving the show you&#x27;ll be more comfortable with something like React. The two approaches are duals of each other.<p>Personally I prefer an all JS solution because it&#x27;s better suited to handle conditions and loops as compared to using custom SGML markup with framework-specific tags and attributes. In my opinion SGML&#x2F;XML should only be used for markup, not program logic.<p>There are a few things I think React got wrong though - handling of children being one. Having different code paths to handle a single child versus multiple children was a design mistake. The Children convenience module is awkward to use. The state life cycle and immutability in React takes a while to get used to. It does seem more complicated than it needs to be and has spawned a plethora of React state management add ons.

Our company migrated to vue.js, 6 months ago. Our complex app is messy with JSX, router, and new dev can&#x27;t keep up with code. Now we start every new app with Vue.js. The gap between junior dev and senior dev comes closer. They can collaborate with less bugs, less problems and less time to develop.

&gt; Fun fact: Yii was created by a Chinese speaking guy - Qiang Xue. So, you might call Yii+Vue stack not just very difficult to pronounce, but also a Chinese stack :)<p>Fun fact: Qiang Xue got his PhD at Duke University and developed Yii2 while living in the D.C. Area by leading a multi-national team of core contributors, the top 3 being from Germany, Russia, and Ukraine.<p>He also moved on from the project mid-2015 and the other maintainers have run day-to-day operations since then. It&#x27;s not a &quot;Chinese stack&quot;. I&#x27;ve read the source and issues extensively and it is high quality code that welcomes high quality contributions - no matter where people are from.

I was initially confused about why a Drupal shop would need either Vue.js or React, since Drupal sites are most typically blog like things.<p>Appears it&#x27;s for their backend though, and this is actually pretty nice: <a href="http:&#x2F;&#x2F;pixeljets.com&#x2F;sites&#x2F;default&#x2F;files&#x2F;why-we-chose-vuejs-over-react-282.gif" rel="nofollow">http:&#x2F;&#x2F;pixeljets.com&#x2F;sites&#x2F;default&#x2F;files&#x2F;why-we-chose-vuejs-...</a>

Out of curiosity, one reason the author mentions (and I know, it&#x27;s not his selling point) which I&#x27;ve seen others reiterate is that React&#x27;s render() method doesn&#x27;t support if statements. I know you can write something like the code below in React, so what exactly does that criticism refer to?<p><pre><code> function Home(props) { return ( &lt;div&gt; &lt;h2&gt;HELLO&lt;&#x2F;h2&gt; &lt;p&gt;Duis a turpis sed lacus dapibus elementum sed eu lectus.&lt;&#x2F;p&gt; { (() =&gt; { if (props.location.query.home) { return ( &lt;p&gt;You specified a home query: { props.location.query.home }&lt;&#x2F;p&gt; ); } else { return ( &lt;p&gt;No home query was specified.&lt;&#x2F;p&gt; ); } })()} &lt;&#x2F;div&gt; ); }</code></pre>

I hope I don&#x27;t get downvoted for asking this but is React going out of fashion already? A lot of the talk about it was &quot;React is here to stay&quot; or &quot;React is as permanent as JS itself&quot; but now this is the second or third time people seem to be going for Vue instead. What happened?

It has been quite some time since I started writing front end code, tried understanding angular, left it. I was lucky that I came across Vue.JS via HN, it was gitlab&#x27;s post. I haven&#x27;t ever tried React, because Vue is amazing. With nearly no knowledge of JS, I was able to write an app in Vue reading just the official docs, they are downright amazing. I faced the issue of webpack et al, thus I started writing a guide to write vue apps in vanilla JS,<p><a href="https:&#x2F;&#x2F;github.com&#x2F;thewhitetulip&#x2F;intro-to-vuejs" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;thewhitetulip&#x2F;intro-to-vuejs</a><p>This is a work in progress.<p>I feel Vue is gaining ground because of it&#x27;s simple syntax, there isn&#x27;t much magic to it, just enough magic.

Vuejs looks great for POCs or small projects. It feels better like Angular-1 to start with. I use VueJs a lot for small stuff i.e. usually something that I can fit into one index.html file and forget about it. React killed that simplicity (i.e. stopped supporting it). Angular2 - I can&#x27;t figure out why anybody uses that.<p>But when it comes to larger projects - I still go back to React, TypeScript and Redux. While Vuejs makes it simpler to code, React+TS+Redux make the end-product very much reliable.

One small point to add here. Evan You is a pretty amazing individual, but he is no longer alone. There is a core team of six members.<p>I know because the guy who got me interested in Vue.js, Chris V. Fritz, lives in the Lansing, Michigan area and is responsible for the excellent docs on Vue.<p>I haven&#x27;t been able to locate a list online but I know there&#x27;s a core member in Paris and another one in Japan.

I would recommend Cx to anyone building complex forms. It&#x27;s one package that covers all common problems related to forms - validation, data-binding, multi-value lookup fields, horizontal form layout, theming etc.<p><a href="https:&#x2F;&#x2F;cx.codaxy.com&#x2F;starter&#x2F;admin&#x2F;orders&#x2F;1" rel="nofollow">https:&#x2F;&#x2F;cx.codaxy.com&#x2F;starter&#x2F;admin&#x2F;orders&#x2F;1</a><p>Disclaimer: I&#x27;m the author.

The author says they don&#x27;t like purity and immutability, because it limits their ability to &quot;get stuff done&quot;. But in the long run you get many benefits, whether you have 1000 developers or one. Namely that a whole class of bugs will be eliminated and you can do quick reference comparisons to tell if something changed.<p>Every time I go to look at Vue I can&#x27;t stand the fact that it DOESN&#x27;T have JSX. I&#x27;ve used every template system you can think of and they always fall apart when things get hard.<p>JSX is basically JavaScript but a much easier and nicer syntax (basically HTML).<p>You get the same flexibility with Elm, but even there you don&#x27;t get the nice JSX syntax:<p>ul [class &quot;grocery-list&quot;] [ li [] [text &quot;Pamplemousse&quot;] , li [] [text &quot;Ananas&quot;] , li [] [text &quot;Jus d&#x27;orange&quot;] ]<p>The one criticism I happen to agree with is certain aspects of using forms in React. Checkboxes and radio buttons are pretty buggy and stupid. Kind of unacceptable at this point.

I am still unsure if there is a legit use case for Vue or React over plain HTML+CSS+JS.<p>I can understand the use case for React native. To build native applications on multiple platforms.<p>But what is the use case for React, Angular, Vue etc? Can somebody give a minimal example?

It&#x27;s been a while since I&#x27;ve needed a front end framework but if react doesn&#x27;t scratch your itch, you should check out cycle.js.<p><a href="https:&#x2F;&#x2F;cycle.js.org" rel="nofollow">https:&#x2F;&#x2F;cycle.js.org</a>

I&#x27;m not sold on the whole &quot;code quality&quot; vs &quot;getting things done&quot; mentality here.<p>I think there are diminishing returns in reducing technical debt and keeping a high quality codebase, but the point of doing it that you can maintain a sustained, relatively high &quot;getting things done&quot; rate over the project&#x27;s lifetime. There are times where you should implement something in a quick and easy way, but if code is going to be present and important for a long time then going the extra mile usually pays off.

I&#x27;ve been using Vue.js at work for this kind of thing: <a href="http:&#x2F;&#x2F;reassurez-moi.fr&#x2F;taux-pret-immobilier" rel="nofollow">http:&#x2F;&#x2F;reassurez-moi.fr&#x2F;taux-pret-immobilier</a><p>It was as simple as adding Vue.js itself and one JS file for custom code. I tried using Angular but right off the bat, I had to install hundreds of dependencies via NPM.<p>That&#x27;s what I like about Vue.js. It&#x27;s simple to reason about for the kind of use case I linked above.

The arguments against Redux (which this article doesn&#x27;t really make, but still) are very valid - it is a nice abstraction and way to think about data flow, but its simply too much boilerplate.<p>Almost every Redux example is tons of repetitive code because of this, and that&#x27;s before you add in middleware, thunk, saga, reselect etc. Yes I know Dan himself wrote a bunch of articles on how you don&#x27;t really need to use it and how its conceptually simple, none of that changes what most of the libs and code looks like.<p>I don&#x27;t have the answer but I can&#x27;t help but think there has to be a better way to handle this. We had templates and generics decades ago exactly to reduce repetitive boilerplate.<p>Redux should never have been adopted in its current form. Its exactly the sort of thing that should be handled by a framework&#x2F;tooling for you. Imagine if for every React component you had to write a custom parser&#x2F;resolver&#x2F;reconciler, all of which had 99% common code and just passed params around. That&#x27;s what redux boils down to.

Thanks for the detailed write up and comparisons. Also kudos for not bashing other frameworks and giving a level headed comparison.<p>Two big things I noticed that drove you away from react.<p>1) too many subcomponents: I think jsx can be improved to have logic tags within them. E.g &lt;js:for&gt; and &lt;js:if&gt; tags that the transpiler can move to ternery and array map calls.<p>2) too much verbosity: something like mobx or deep-observable can help here.<p>Honestly react has become the Java of UI. Going back to fundamentals. All you need is a tiny library that diffs a vdom tree to real dom.<p>And you need a tiny library that allows you to observe a single source of truth object and connect it to view.update() changes.<p>All in all this shouldn&#x27;t take more than 5kb of code.<p>We all want: good abstractions, fast performance, actionable errors and small library so the page loads in no time.

Vue JS framework is very simple yet powerful, also better in performance wise. Learning curve is very easy. You can pick the fundamentals in a day or two. Within a week you can reach intermediate level.<p>It comes with all the basic stuff of SPA like data binding, event handling, routing, state management, components.<p>I have been creating a video tutorials series on Vue js 2 framework.<p>Vue.js Tutorials: <a href="http:&#x2F;&#x2F;www.youtube.com&#x2F;playlist?list=PLJ6Y8JfXAV-8_2lHNgP1DhCwvB6le3rty" rel="nofollow">http:&#x2F;&#x2F;www.youtube.com&#x2F;playlist?list=PLJ6Y8JfXAV-8_2lHNgP1Dh...</a>

I find it completely unbearable to use React with plain JS. I have to use at least Coffeescript and if possible Livescript or Clojurescript. Vanilla JS is just too clunky.<p>The problem with JS is there are too many patterns in the code, like the mentioned list.map(function(whatever) { ... }). Because JS is a medium power language it doesn&#x27;t let you abstract this stuff with macros or at least rewrite the syntax.<p>Coffee and Live provide some relief, but Clojurescript is heaven.

While this is a good overview of why _they_ chose Vue over React, I wouldn&#x27;t risk deriving that you should do the same too.<p>To balance the scale a bit, this is what they gave up, in favor of &quot;shit that just works&quot; (because this is the tone I&#x27;m getting from the article):<p>1. They decided they want off the enormous driving force for developer experience that is Facebook, and more importantly the Facebook codebase that shapes decisions in React, see [1] and [2].<p>2. They opted out of major innovation that directly stem from (1), see [3].<p>3. Parting with Redux, they also decided to part with a community that thinks functionally. This is a big deal not because of writing &quot;pure functional code&quot;, but because these group of people can reason about the implications of bad citizenship on the browser - which really, is something the Javascript community really needs.<p>4. Moving away from functional-esque (for lack of a better term), they also move away from predictable testing. Forget purity and sideeffects. A good litmus test - think about how easy it is to test any given framework at scale, and if a framework is &quot;built with testing in mind&quot; (read: angular) how many hacks would be involved. When you have good foundations for testing, you can do this [6] and be sure everything can be covered [7] .<p>The only thing I see as a down side with React is the bundle size. The physical size. However I&#x27;m not worried one bit because of (1) and (2).<p>For Redux, I take the liberty to use MobX for small-medium projects (which probably is the overwhelming majority of projects), and Redux for large projects, or projects that I want great testing story in (in many ways these correlate, but some times they don&#x27;t).<p>Redux is &quot;boilerplatey&quot; because it is highly granular. This is why the ecosystem around it exploded. But because of (3) the ecosystem around it has a sharp focus around the patterns and practices it applies, which makes choosing the &quot;wrong&quot; library not such a big deal; in a sense its ecosystem is predictable, because it is simple.<p>JSX or templates, I don&#x27;t think this deserve a major part of the discussion. Both ideas exists for a long while, and even their predecessors exist for more than a few decades [4] and [5]. I don&#x27;t think anyone is tilting the scales any where in a major way. I personally am convinced JSX is a new thing because you have first-class IDE support across the board (which you don&#x27;t have for a given data-properties backed templating language unless it becomes ginormous like Angular). JSX is also simple to hack and you can opt-out or implement your own dumb-templating solution-to-JSX.<p>Having said that, I see Vue coupled with PHP quite a bit, like, it&#x27;s an informal standard stack, so it may make sense if you&#x27;re coming from PHP (but then again so did Facebook, right?). Maybe someone can explain that (is it the Laravel backing?).<p>[1] <a href="https:&#x2F;&#x2F;facebook.github.io&#x2F;react&#x2F;contributing&#x2F;design-principles.html" rel="nofollow">https:&#x2F;&#x2F;facebook.github.io&#x2F;react&#x2F;contributing&#x2F;design-princip...</a><p>[2] <a href="https:&#x2F;&#x2F;facebook.github.io&#x2F;react&#x2F;contributing&#x2F;implementation-notes.html" rel="nofollow">https:&#x2F;&#x2F;facebook.github.io&#x2F;react&#x2F;contributing&#x2F;implementation...</a><p>[3] <a href="http:&#x2F;&#x2F;isfiberreadyyet.com&#x2F;" rel="nofollow">http:&#x2F;&#x2F;isfiberreadyyet.com&#x2F;</a><p>[4] <a href="http:&#x2F;&#x2F;blog.vjeux.com&#x2F;2013&#x2F;javascript&#x2F;jsx-e4x-the-good-parts.html" rel="nofollow">http:&#x2F;&#x2F;blog.vjeux.com&#x2F;2013&#x2F;javascript&#x2F;jsx-e4x-the-good-parts...</a><p>[5] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;XSLT" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;XSLT</a><p>[6] <a href="https:&#x2F;&#x2F;facebook.github.io&#x2F;jest&#x2F;" rel="nofollow">https:&#x2F;&#x2F;facebook.github.io&#x2F;jest&#x2F;</a><p>[7] <a href="https:&#x2F;&#x2F;medium.com&#x2F;@jondot&#x2F;how-to-snapshot-test-everything-in-your-redux-app-with-jest-fde305ebedea" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;@jondot&#x2F;how-to-snapshot-test-everything-i...</a>

I think your opinion on putting weird stuff in your HTML attributes vs. putting weird HTML-like stuff in your JavaScript is enough to make an early call on whether you&#x27;ll prefer React-like libraries or Vue-like libraries.<p>As a programmer, React has been my go-to UI library for quite a while because I see always being in JavaScript mode as a benefit (no invented scope to learn or inject things into, no invented logic to learn, <i>everything</i> is lintable, easy-to-follow state change flow) that&#x27;s worth the drawbacks (un-pretty conditionals in render(), manually handling form input), but I can also echo the feedback in this article when it comes to having designers working on your components.<p>&gt; JSX is also the reason when you have to keep splitting your 15-lines-of-html-code component to 3 components, 5-lines-of-code-in-each.<p>&gt; ...this approach of splitting components into super-dumb components because of JSX restrictions will always put you out of flow when you are solving real business task<p>I don&#x27;t understand what this has to do with JSX without an example.<p>&gt; ...now you have to create 10 functions to get input from 10 inputs. 80% of these functions will contain single line with this.setState() call<p>Working with forms is definitely one of the most painful parts of React, and one of the differences I most enjoyed when porting our sample app to Vue.js 1.x for inputs which only affect the value they bind (most interesting thing I learnt: the React component structure the original was written with mapped almost verbatim to Vue.js components, the main difference was in flexiblity of what you can pass down the tree - e.g. React components as props, but I believe Vue.js 2.x is now closer to React&#x27;s flexibility), but most of this section comes across as hyperbolic.<p>Writing onChange handlers which are as generic as you can get away with for the current form is key, but it generalises to setting state based on input names, which can as be simple as the name of the state variable, or a path in state which should be set for simple form input even in deeply-nested forms, plus the appropriate value based on the input type.<p>e.g. if you&#x27;re doing a simple form with text inputs, selects, radios etc. where checkboxes always correspond to boolean state, you could use this for every field (you don&#x27;t even have to put it on each input, you can let onChange bubble up to a form with onChange={this.handleChange}):<p><pre><code> handleChange(e) { let {name, type} = e.target let valueProp = type === &#x27;checkbox&#x27; ? &#x27;checked&#x27; : &#x27;value&#x27; this.setState({[name]: e.target[valueProp]}) } </code></pre> (It&#x27;s game over for simplicity once you want to do <i>proper</i>, user-friendly form validation, but that&#x27;s a truth universally acknowledged :))

I&#x27;m glad to see that Vue is getting more adepts. Kudos to the core team for making it so easy and accessible for everyone.

&quot;I expect Vue to become a primary JS framework in 16-24 months if Evan You makes right steps, at least around backenders and smaller teams of frontenders.&quot;<p>When Vue.js gets a big enough community passionate enough to host their own conference, we&#x27;ll be able to consider this as a possibility. :)

I wonder why people need Redux, Using simply React is great and enough if you understand it well

I once wanted to use React as a virtual DOM library, nothing more. Turned out that I had to create &quot;components&quot; for every div I wanted to draw. Of course, this was a nuisance to the point that I had to let go of React.

&quot;JSX is also the reason when you have to keep splitting your 15-lines-of-html-code component to 3 components, 5-lines-of-code-in-each.&quot; this stuck with me the most

I have just learned React !!!<p>That&#x27;s it, I am learning C++.

My only issue with Vue is using programming flow within tags. This gives me acid flashbacks of coldfusion spaghetti horror.

You don&#x27;t need to use Redux, and I don&#x27;t - it gives me nothing I need and adds complexity.

Can&#x27;t comment on vue much other than I think it would be the one I would go with if I had to pick one of these js frameworks due to some of the nice projects I&#x27;ve seen in little code. But yii2 for admin panels seems like another great selection for generating quick ugly forms only 5 people might see a month.

MITHRIL JS

In short: FOTM

With all the evangelism I&#x27;ve seen on HN about React, I have yet to see a cohesive post about the benefits that it provides that makes it worth the investment in learning.<p>Nor have I seen a seen a good review of tooling that provides a good path for someone who wants to try it out.<p>What I do see, are arguments that &quot;it can do that too if you only knew how to use it!&quot; That and a lot of sample code that embeds html within the code, which frankly looks like a delegation nightmare. (and scattered postings about documentation not being up to date)<p>You could downvote me. Or... you could point me to a helpful and up to date resource or recent posting that is actually helpful. Or better yet, write one.

Clickbait title for the HN crowd, I sense that articles like these are analogous to the old <i>which color to paint the bikeshed</i> debate.<p>Front-end libraries and frameworks should be trivial because front-end web development is largely trivial, it&#x27;s the ecosystem around it that has bloated in complexity, including Vue.js and React.<p>Take a standard API that is already simple enough to understand and use (DOM), and re-package it for people who wish to call themselves &quot;software engineers&quot; to justify the time they spend on making simple things work in a complicated fashion. If you disagree that front-end complexity is getting way out of hand, just read the source code of any modern single-page app including its dependencies.<p>I think that code written by amateurs cobbling together vanilla JS is generally faster in development and performance, more easily understood, and easier to maintain than code written by a professional web developer using whatever framework. The early web itself was largely cobbled together by hobbyists, and so should it continue to be.<p>The industry disagrees with me, that&#x27;s fine. I&#x27;m aware there are many reasons why my views are the exception not the norm. I just hope that something far better supercedes this era of web development, which would require social and cultural shifts to occur.

This is a great article, thanks for sharing.<p>&quot;Not being able to put plain old IF condition to some block of HTML code sucks&quot;<p>In my usage of React, I found that this limitation forces me to use functions to break down my code, a skill which is simply required when working on large projects. Of course, that&#x27;s what everyone else says, too.<p>&quot;JSX is also the reason when you have to keep splitting your 15-lines-of-html-code component to 3 components, 5-lines-of-code-in-each.&quot;<p>Truth to this -- React can make things slower when your project is inherently monolithic, but you&#x27;re tempted to abstract things into ugly Listwrappers, ListViews, ListViewData, ListViewDataContainers, etc. It gets ugly if you aren&#x27;t good at abstracting things very well.<p><i>React should approached with caution.</i> I think this guy has the right idea, don&#x27;t put all your eggs into the React basket. Don&#x27;t underestimate the cunning of Mark Zuckerberg. If possible, don&#x27;t rely on React, because if you create something groundbreaking, you <i>will</i> be in for a legal situation with Facebook.