The future of React Native?

The increasing demand for faster app development might be the reason why cross-platform applications are on the rise. In fact, React Native is already perceived as a viable solution to create quality software and its use expected to grow in the coming years. 

Yet, not everyone agrees that it’s the way forward for mobile app development. And rightly so – there are still some technical drawbacks that are holding React Native back, not to mention that it generally offers slower apps when comparing them with native solutions.

Despite the constant advancement of React Native, it does not provide ready-to-use modules that give access to iOS or Android APIs. This forces developers to create so-called Native Modules themselves or develop “bridges” using Java/Kotlin (Android) or Swift/Objective-C (iOS) and severely increases software development time.

Developers bring up one more problem with React Native technology — software debugging. It is much harder when using RN. It comes down to faster development but longer problem-solving which results in less accurate cost estimation (especially in case of Android).

The framework might look strong on paper, but many well-known apps (such as Airbnb or Udacity) has actually switched back to native development. Therefore, even though React Native is definitely a trending topic at the moment, only time will tell if it has the power to outshine native technologies.

What will be the dominant front-end technology in 5 years time?

In short, you might as well play roulette and bet on black, because nobody can answer this question with fact. We can only present hypotheses.

The world of web development, especially front-end development, evolves about as quickly as the physical tech industry does, and there is no way we can predict what Samsung, Apple, Nokia, and the other’s will churn out in even the next two years. Much less five.

Let’s look at a bit of JavaScript history.

Build Tools (2014 – 2018)

  • Three years ago, Grunt was the dominant build tool.
  • Two years ago, Gulp rose up and stole the throne.
  • One year ago, was Webpack’s claim to fame.
  • Somewhere in there, Browserify fought a good fight.
  • At one point, plain npm scripts became a fad.
  • When I wasn’t looking, Rollup rolled out.
  • Along the way, I built Owlister. (It is junk. Don’t look.)
  • Now, Webpack dominates, but tomorrow is unpredictable.

Transpilers (2009 – 2018)

  • Eight years ago, Coffeescript became Earth’s favorite abstraction.
  • Six years ago, Dart arrived like a drunken monkey on weed.
  • Five years ago, TypeScript was born, bringing type safety to JavaScript.
  • Three years ago, Babel arrived to let us use future JavaScript today.
  • Two years ago, Elm became a buzzword. (Nearly irrelevant, but not quite.)
  • Now, TypeScript and Babel rule. Seemingly invincible? Time will tell…

Frameworks (2010 – 2018)

  • Seven years agojQuery was the most suggested JS “framework”.
  • Six years ago, Backbone and Knockout were widely adopted.
  • Five years ago, Angular and Ember took the stage.
  • Four year ago Meteor stormed the gates and built a following.
  • Three years ago, React took its first breath. The prophecy…
  • Two years ago, Polymer and Vue made names for themselves.
  • One year ago, [Angular 2 and Vue 2] released, [bombing and succeeding].
  • Six months agopeople quit caring that “React is not a framework.” Don’t.
  • Now, Angular 4 has arrived, React dominates, and Vue is a super-power.

*These numbers are not exact, but even the absolute correct time-frames would reveal an identical pattern of “king of the hill”. Don’t grill me.

But wait, there’s more!

In the midst of the frameworks timeline, there have also been countless other contenders take a shot at stardom. Aurelia, Riot, Spine, Dojo, Deku, Inferno, Mithrill, Stapes, Svelte, etc. Any one of these lovely ladies could become the new hotness in a matter of weeks. We just can’t tell.

If I were to revisit this answer in five years, I’d most definitely be adding weird framework titles to my timelines above, as even the power-houses of today will not last forever. These tools will probably be such that I have never even heard of at this point in time.

Behold, WebAssembly.

WASM is… difficult to explain. Simply put, WASM allows developers to compile most any language into performant, browser agnostic byte code. What this means is that the front-end community has the opportunity to detonate yet again with a landslide of developers from all walks of life developing for the browser.

JavaScript has done its job well, but as the world progresses it will be replaced. That time could very well be within the next five years. The murderer could be WASM or it could be a new browser that takes a majority of the market share that allows developers to write their applications in Haskel. Improbable, yes. Impossible, no.

The Safe Bet.

As it stands, our best guess is that JavaScript will still dominate the browser in five years. That said, your best bet would be to acquire a slew of developers who are tool/framework agnostic by means of deep JavaScript understanding. Don’t allow yourself to be contracted to a specific tool. I guarantee you that Angular, React, Vue, Backbone, Aurelia… none of these guys will reign in five years.

Those who become proficient with languages and have a firm understanding of design patterns and architecture will have no problem adapting to future tools and are, in essence, future-proof.

Why React Dev’s Like to Hate Vue.js

After having worked on React development on medium/large scale apps, I have to admit that VueJS is like a breath of fresh air.

In my opinion, most developers are having as I call it the “Simplicity (Un)reasoning” bias, which means: if it is simple to learn, simple to use then it is for simple projects. Crazy right?

Meanwhile, the arguments in favor of React or Angular 2+ are dubious as well.

Angular is for large teams because it enforces you to write code in a typed way because of TypeScript. Yes but React and Vue support TypeScript or Flow not to mention that Vue’s lifecycle events are more clear cut than React’s.

Vue has only one person writing code. Not anymore.

Vue is for simple projects. Maybe you should read how Adobe is using it these days.

I am not writing this specifically for Vue but believe me that this simplicity can be found in other libraries as well e.g. RiotJS, StimulusJS etc.

Unfortunately, React and Angular have excellent marketing strategies, which plays a major role since they are trying to sell longevity instead of code happiness. By code happiness I mean the factor which make your developers happy to write code they understand and are proud they wrote it. With React and Angular I am not that happy, especially with React.

With Vue the selection was being made from a pool of 10+ team leaders because it just works as it should out of the box. Their vue-cli is also in the same league angular-cli is, but the difference is were angular could not operate very efficiently without, Vue could work without it with no problem.

Finally, I have to point out that lately among the majority Front-End developers, there is this strange notion that if your code is easy to understand, not very complicated and not using the latest ESxxx you are doing something wrong. If you look at Angular you have to learn RxJS, TypeScript etc. and even if you are not satisfied with this selection few will admit it. We have to get rid of the herd mentality and marketing strategy of 2–3 large companies and exercise common sense and independent spirit.

What is React? The good, the bad, the ugly.

What is React?

How does React compare to Angular, Ember, Backbone, et al? How do you handle data? How do you contact the server? What the heck is JSX? What is a “component”?


Stop it right now.


React is often mentioned in the same breath as other Javascript frameworks, but “React vs Angular” doesn’t make sense because they aren’t directly comparable things. Angular is a complete framework (including a view layer), React is not. This is why React is so confusing to understand, it’s emerging in an ecosystem of complete frameworks, but it’s just the view.

React gives you a template language and some function hooks to essentially render HTML. That’s all React outputs, HTML. Your bundles of HTML / Javascript, called “components”, are allowed things like storing their own internal state in memory (such as which tab is selected in a tab view), but in the end, you just barf out HTML.

You absolutely cannot build a fully functional dynamic application with React alone. We’ll learn more about why below.

The Good

After working with React for a while, I’ve seen three very important benefits surface.

1. You can always tell how your component will render by looking at one source file.

This may be the most important benefit, even though it is not different from Angular templates. Let’s use a real-world implementation example.

Say you have to update your site’s header with the user’s name upon login. If you’re not using a Javascript MVC framework, you might do this:

I can tell you from experience that this code will ruin your life and your friends’ lives. How do you debug the output? Who updated the header? Who else has access to the header HTML? Who holds the source of truth for the name being visible? This DOM manipulation is just as bad as a GOTO statement for reasoning about your program.

Here’s how you might do it in React:

We can tell instantly how this component will render. If you know the state, you know the rendered output. You don’t have to trace program flow. When working on complex applications, especially in teams, this is critically important.

2. Bundling Javascript and HTML into JSX makes components easily understandable.

The weird mix of HTML / Javascript soup above might make you cringe. We’ve been conditioned to not put raw Javascript in the DOM (like onClick handlers) since we were wee developers. You’ll have to trust me, though; working with JSX components is really nice.

Traditionally you separate views (HTML) from functionality (Javascript). This leads to monolithic Javascript files containing all functionality for one “page”, and you have to trace complex flow from JS > HTML > JS > bad-news-sad-time.

Tying functionality directly to markup and packaging it in a portable, self-contained “component” will make you happier and less filthy in general. Your Javascript has intimate knowledge of your HTML, so mashing them together makes sense.

3. You can render React on the server.

If you’re building a public facing site or app and you’re following the render-it-all-on-the-client path, you’ve already done it wrong. Client-only rendering is why Soundcloud feels so slow and why Stack Overflow (purely server-side rendering) feels so fast. You can render React on the server, and you should.

Angular and others encourage you to do disgusting things like render your page with PhantomJS and serve that to search engine crawlers based on user agent, or pay actual cash money for that as a service. Ugh.

The Bad

Don’t forget that React is only the view.

1. You DO NOT GET any of the following:

  • An event system (other than vanilla DOM events)
  • Any AJAX capabilities whatsoever
  • Any form of a data layer
  • Promises
  • Any application framework at all
  • Any idea how to implement the above

React on its own is useless for the real world. Worse yet, as we’ll see, this leads to everyone reinventing the wheel.

2. The documentation is not “accessible” nor “good.” Again, this is a blog post for stupid people. Look at the first part of the sidebar on the documentation page:

React documentation sidebar

There are three separate, competing quickstart guides. I’m overwhelmed and I’m not even drunk. The sidebar below that is straight out of my nightmares, with sections that obviously shouldn’t be there, like “More About Refs” and “PureRenderMixin”.

3. React is large for how little you get, including how little cross browser support.


That’s without the react-with-addons library you will need to actually develop a real app!

That’s without the ES5 Shim library you need to support IE8!

That’s without any sort of application library of any kind!

React is a comparable size with Angular, even though Angular is a complete application framework. React is frankly bloated for how little functionality you get. Hopefully, this will improve in the future.

Stop Saying Flux

Perhaps the most annoying part of React development is “Flux.” It’s far more confusing than React. The name “Flux” is a pretentious barrier to understanding.

There is no such thing as Flux. Flux is a concept, not a library. Well, there is a library, sort of:

“Flux is more of a pattern than a framework”

Ugh. The worst part is the name: React didn’t reinvent the last 40 years of UI architecture knowledge and come up with some brand new concept for data management.

The concept “Flux” is simply that your view triggers an event (say, after the user types a name in a text field), that event updates a model, then the model triggers an event, and the view responds to that model’s event by re-rendering with the latest data. That’s it.

This one-way data flow / decoupled observer pattern is designed to guarantee that your source of truth always stays in your stores / models. It’s a Good Thing™.

The bad side of Flux is that everyone is re-inventing it. Since there’s no agreed on event library, model layer, AJAX layer, or anything, there are many differentFlux” implementations, and they all compete with each other.

Should I Use React?

Short answer: yes.

Long answer: unfortunately, yes, for most things.

Here’s why you should use React:

  • Works great for teams, strongly enforcing UI and workflow patterns
  • UI code is readable and maintainable
  • Componentized UI is the future of web development, and you need to start doing it now.

Here’s why you should think twice before you switch:

  • React will slow you down tremendously at the start. Understanding how props, state, and component communication works are not straightforward, and the docs are a maze of information. This will be countered, in theory, by a grand speed up when your whole team is on board.
  • React does not support any browser below IE8, and never will
  • If your application / website doesn’t have very much dynamic page updating, you will be implementing a lot of code for a very small benefit.
  • You will reinvent a lot of wheels. React is young, and because there’s no canonical way to do events / component communication, you’ll have to build large component libraries from scratch. Does your application have dropdowns, resizable windows, or lightboxes? You’ll probably have to write those all from scratch.