Self-Documenting, Crystal Clear JavaScript The space race for the front-end framework that will dominate all others for the foreseeable future is over, and the winner? This is something many developers took as gospel ages ago, but is still a question in the minds of many others who weigh the frameworks against one another and are decidedly undecided. React. Low Maintenance; High Maintainability A common shortcoming in my software systems from years ago resulted from the fact that I was a solo developer, writing myself every aspect of every application from the very bottom to the very top. Despite the vast amount of code I continued to maintain, I still knew it all well because every bit of it was something I wrote, including the underlying custom framework that powered different clients’ custom CMSs. Fast-forward to the last few years where I [finally] moved on to work in a large tech company with teams of developers, past and present whose code I need to work in and around, not to mention that other developers, present and future, will have to work around code. It was immediately obvious how critical it is writing code that provides developer high maintainability and high understandability. my any Front-End Frameworks When front-end frameworks started exploding into our lives, I was in awe. The whole front-end world that I usually worked on because I to as needed to fulfill my clients’ requirements was suddenly a world in which I was eager to spend most of my time; it allowed me to start doing back-end development on the front-end! had Coming from a history of only ever dealing with applications based on custom frameworks I wrote myself, this was a new experience, having to learn and base applications on a third-party framework. This gives the framework a significant and important responsibility, as any application written on top of it builds into it an inherent bond that is not likely to be broken. The question became: to which front-end framework do you want to handcuff your applications moving forward? Why VueJS? I decided initially on VueJS in part because it offered a much looser handcuffs than React. In fact, I was pretty gung-ho all along that Vue was all I really needed. In my view there are two interrelated reasons that still render Vue a viable React alternative for some use cases: 1. Continuity When dealing with legacy code, Vue is more of an ideal solution because it can be grafted onto existing HTML markup and DOM content in-place with almost zero development effort or prerequisites. 2. Effortless Integration Anywhere Like React, the most powerful use case for Vue is a larger-scale project in a transpiled, bundled application, e.g., with Webpack, however Vue is flexible enough to be used effectively via a simple library. This is unlike React, which is an impractical choice with which to write components meaningfully using vanilla JS on top of existing content. <script> I expound at length on these considerations in my article, . One Major Reason VueJS > React After having on several occasions dropped VueJS into existing, legacy code, I did move on to writing full SPA applications entirely in Vue. Writing those applications was a great experience. I was making the most of all that the rich, juicy Vue documentation has to offer and feeling pretty good about it. Then some time passed, and I started developing with React for my day job. I had already tinkered with it previously and I was pretty well aware of what it could and could not do. One concern (mentioned in the aforementioned article) had to do with HTML no longer being modifiable by non-developers (the way it always had been previously at the company) due to the fact that React markup is only written in JSX and requires compilation and deployment. Enter ReactJS, Conqueror Despite concerns about any limitations, we plowed forward with our React development. Some time later, I had to go back into the Vue apps I had built to make modifications and add extensive new functionality, but I quickly found that . I had to slam on the brakes I was a bit shocked; for probably the first time in my life, I found myself floundering trying to work in code I wrote entirely myself. I could not believe it as I had to struggle to keep solving puzzles by referring to external documentation and Google to determine how I needed to modify existing and even add new Vue components to fulfill my client’s requirements. You may be thinking I should have written my Vue components better or perhaps that I should just have a better memory of all the intricate parts of Vue’s custom syntax. Perhaps… but in any case, as I went back on my day job to continue work on our React application, I had an epiphany: I can lay my eyes for the first time on extensive React components written by other developers and completely understand every single line of code. Q: Why is that? A: Because it’s JavaScript! just When I say React is “just JavaScript,” what I really mean is it’s just JavaScript. Yes, there are a few React-specific things you need to understand (e.g., lifecycle hooks, props, state, refs, etc.) but that handful of things aside, your components are all just written with declarative, vanilla JS, making it zero-effort cinch for anyone (including yourself) to review/inspect/understand/modify an application written in React. vanilla This is the major contrast with VueJS because with Vue, you are required to learn a vast sea of the framework’s intricate configuration options and keywords, though in a small application this may be less obvious. It’s true writing markup with Vue is better because “it’s HTML,” but all of the Vue code that comes with that vanilla markup is complicated and convoluted, requiring developers to have a deep, intimate familiarity with it in order to review/inspect/understand/modify an application written in Vue. just This point was the nail in Vue’s coffin for me because, as I mentioned above, I was struggling to understand Vue app, as I had to keep looking up references to understand how or why I had done something before and trying to figure out how to modify existing or add new functionality. I have had to do the same type of thing with React, going back to an app I had worked on months earlier, and there is just no comparison with how effortless it was. my own In Conclusion It is not my intent to besmirch the good name of VueJS or , who I think is pretty brilliant. Evan You Coming from someone who considered for a long time Vue to be the answer to all of my front-end questions, it is certainly still a framework that I know will perform phenomenally for many developers and organizations, however React has proven itself to me the one front-end framework I am most excited to concentrate on for the foreseeable future ( ;) ). …until the next next big thing comes along
