New technologies are emerging and changing rapidly in the UI space. Among other technologies, the authors of this article favor React as the ultimate choice for developers.

We used to think of the sun as orbiting the Earth and plague as god’s punishment, but now we believe MVC architectures and two-way data binding are the best way to build Web UI applications.

In the past, there was no better way to explore the world, and because of cognitive limitations, people believed in these “misconceptions.”

Finally, astronomers proved the heliocentric theory, and doctors found that diseases were caused by bacteria. Similarly, React introduces the concept of one-way data flow.

None of these findings was immediately accepted by the public. Galileo’s theory was regarded as heresy. Dr Semmelweis found that the disease was bacterial, but his colleagues did not accept his findings and ended up regrettably in a sanctuary. Today, we still have the misconception that all UI architectures are created equal.

I firmly believe React, or something like it, is the future of user interface development. At this point, I hope you do not immediately jump to the end of the article to express your opinion or disapproval, please read the body of the article patiently, I will tell you why I think so.

React is a collection of smart ideas created by smart people. When React was first announced, the main selling point was how it rendered: by separating the application structure from the underlying render DOM, we could achieve declarative view rendering syntax while still applying optimal DOM mutations.

Its ideas are unique; for example, it argues that cutting across technological boundaries by separating code into HTML, JavaScript, and CSS doesn’t really work. React believes that in order to create applications with high cohesion and low coupling, it is best to put the UI’s presentation, behavior, and state in a JavaScript file. This approach creates a barrier for developers, which is the difficulty of creating uIs in plain JavaScript. For this reason, React comes with an extended syntax called JSX.

Many developers hate the JSX extension syntax. If you’re not a Web front-end developer, it’s hard to understand why developers are so averse to extended syntax.

React sparked heated discussion when it was released.

It is human nature that no one likes to see what he believes in denied. As a result, React’s core values are often overlooked in the fast-growing front-end space.

The heart of React lies in its components. The virtual DOM is a cool technology, but it’s just an implementation detail, and if React can be created without it, there’s no reason for it to exist. JSX is a nice technology, but it’s just syntactic sugar.

Components are a very mature concept today, and they predate React. When React was released, the Web component specification had already been standardized. React didn’t invent components, just as Galileo wasn’t the first to discover heliocentric theory. React just redefined it.

The React component’s main benefits lie in its composability and encapsulation. The second is its functional components and versatility. I’ll elaborate on it below:

  • Composability allows us to compose a large program with multiple small programs that use templates that do not depend on other components, code that can be modified, deleted, and replaced independently of other code in the system, and even written before future code exists.

  • Encapsulation contains the entire presentation, behavior, and state of a component. This means that external code cannot affect its behavior unless wrapped as a component.

  • Functional-style programming receives Props for rendering, which makes React components more robust. Their behavior is easy to document and understand, allowing developers to use components developed by others without having to understand how they work.

  • Multipurpose means that a component can be either a container component (controller) that is responsible for data and behavior, or a view that renders the component. This separation has always been key to MV architecture, and the elegant React component API enables true separation while preserving composability and encapsulation.

This small, centralized approach to component abstraction provides all the features that developers need, such as ease of learning and memorization, a better user experience, and the ability to generate applications that are easy to maintain and collaborate with.

There’s another component that I haven’t mentioned, and in fact, it’s the most important component.

While I’m a big fan of React, I have to admit React isn’t perfect; The React core team is actively refining it, with new ideas constantly being discussed, implemented, and discarded. While the React ecosystem is currently robust, with a large number of libraries, patterns, and practices, it still has room for improvement. We’re not even sure if we need higher-order components, rendering Props, functional Props, or components of components!

While the abundance of options can be tiring at times, this is where the React component model really benefits. With generic, small, composable, flexible and reliable building blocks, we can discuss, test, and embrace new ideas without discarding existing work.

To individual developers around the world to build a revolutionary like Redux, Apollo or styling components library, application developers can use these new tools used with existing tools, without having to modify existing code, and can not affect independently of other modules to replace certain modules, it is incredible to me.

Each of these libraries implements complex functionality outside of the React domain, but they are not mutually limited because each of these tools can leverage the component composition model. Thus, the React component model is not just a UI primitive, it is an innovation primitive.

Unlike progressive JavaScript, React doesn’t have to refactor a lot of code with the new tool. Unlike holistic frameworks like Ember or Angular, React is flexible enough to cope with inevitable changes.

It is important that the platform be able to adapt to change, as change is always inevitable and costly.

Smart people don’t suddenly stop observing a problem and come up with a solution. People will not stop being frustrated by the limitations that exist and will not stop seeking freedom. As developers, we don’t hold back from using better tools when we find them. No matter how much you want to keep things the way they are, history rolls on.

When change occurs, a system ideally should be able to adapt to the change, and complete replacement would be costly.

After the framing wars of the past decade, we are now living in a period of unprecedented prosperity and peace. Tools like React enable us to build and maintain great products.

If our tools hinder progress, we must keep moving forward and have to give them up. The price of revolution is destruction: we’ll have to replace all our libraries, rethink new approaches, retrain our teams, repeat our mistakes, rewrite or refactor a lot of code instead of focusing on the product we’re creating.

The innovation stage is divided into two parts:

  • A period of rapid reform

  • A long tail of slow growth

The growth was rapid in the revolutionary period and gentle in the refinement period.

React was a revolution. It overturns current best practices and makes major improvements to the developer experience almost overnight. Right now we are iterating at a rapid pace, the kind of rapid innovation we are used to, but soon it will flatten out.

But the curve doesn’t really determine the rate of innovation. As long as we remain creative and innovative, and developers actively make decisions, our ecosystem can continue to change rapidly.

Whether we use other frameworks within the React ecosystem, build frameless progressive Web applications, or don’t build Web platform-specific software at all, we can learn these lessons from React and its ecosystem and be flexible to change without subverting existing code.

  • Building large systems with small modules: Build software with many small units of specific functionality, avoiding a holistic architecture. Think carefully when designing apis and interfaces to make them easy for others to use.

  • Make code easy to copy and delete, not easy to change: it’s better to use combinations than inheritance and mixing. Encapsulate behavior. Do one thing well.

  • Code for people first, not machines: make code easier to understand. When writing code, keep the intent simple and not overly academic. Do name accurately, write necessary documentation, ensure code specification, easy to use by others.

  • Use programming languages intimately: React takes advantage of new JavaScript language features and ecosystem tools because it only uses JavaScript, even though it has a JSX syntax. Avoid string-based DSLS and non-idiomatic interfaces, as this reduces compatibility.

  • Don’t break the existing state unless you absolutely have to: stability is a value in itself, because change can lead to extra work, waste, or, in the worst case, abandonment of AngularJS. Either change the technical solution initially, or it’s best not to change in mid-stream and use code modules or similar tools to adapt to the change. In your own code, don’t adopt a new library just for the sake of it; weigh the costs against the benefits.

  • Keep an open mind: If you follow the previous rule, this last one is inevitable. Sometimes, new ideas can be scary, change can be inconvenient, but revolutions happen every once in a while. Don’t be too rigid, keep an open mind and listen to what people have to say.

Technology changes so fast in the UI space that I believe React is the ultimate UI choice.

While I don’t personally value the virtual DOM, it has proven to be one of the most promising features of React. Because of the separation between the virtual presentation layer and the UI implementation layer, React is ideal for server-side rendering and general-purpose Web applications. Native mobile platforms are an important part of user interface development. React Native can help us in this area, and Recoil makes React useful in both Kotlin and Swift.

ReasonML and ReasonReact help us extend the React paradigm to platforms beyond JavaScript. With augmented and virtual reality booming in the future, I hope React VR and other experiments like it can help us predict storms.

Eventually React will be replaced by something else. We don’t know yet what the mandatory function will be, maybe WebAssembly, we don’t know what will happen next. Either way, I’m looking forward to it with excitement.

For now, with React’s strong presence, I believe the UI space will remain focused, stable, and thriving in the short term.

https://medium.com/@jevakallio/the-present-future-of-user-interface-development-ebd371255175