Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Hybrid Apps And React Native: A Time To Transition?

Accomplished musicians often talk about how, at certain moments in their careers, they had to unlearn old habits in order to progress. This process often causes them to regress in performance while they adjust to an ultimately better method. Once the new approach is integrated, they are able to reach new heights that would not have been possible with their previous techniques.

Like musicians, all professionals should frequently question their methodologies and see what other options exist. If one approach was previously the best, that does not mean it remains the best. Then again, many established techniques have been the best for decades and might never be surpassed. The important thing is that one is willing to consider alternative approaches and is not too heavily biased towards the one they are most familiar with. This analysis is often more difficult in software development because new frameworks and technologies emerge almost as quickly as they die off.

This article will apply this analysis to hybrid mobile apps and present why I sincerely believe that React Native is in many ways a superior solution for apps developed in 2017, even if it introduces some temporary pains while you’re getting acclimated. To do this, we will revisit why hybrid apps were created initially and explore how we got to this point. Then, within this context, we’ll discuss how React Native stacks up and explain why it is the better approach in most cases.

Further Reading on SmashingMag: Link

An Origin Story Link

It’s 2010. Your company has a pretty awesome web application that uses jQuery (or, if you’re hip, some sort of AngularJS and React precursor like Mustache). You have a team of developers competent in HTML, CSS and JavaScript. All of a sudden, mobile apps are taking over. Everyone has one. Mobile apps are the new Tickle Me Elmo! You frantically research how to make your own mobile app and immediately run into a host of issues. Your team is ill-equipped for the task. You don’t have Java or Objective-C developers. You can’t afford to develop, test and deploy two separate apps!

Not to worry. The hybrid mobile app is your silver bullet. This shiny new technology allows you to quickly and (in theory) easily reuse what you have (code and developers) for your lustrous new mobile app. So, you pick a framework (Cordova, PhoneGap, etc.) and get to work building or porting your first mobile app!

For many companies and developers, their problems were solved. They could now make their very own mobile apps.

Problems Arise Link

Ever since 2010, developer forums, blogs and message boards have been full of arguments about the efficacy of hybrid apps. Despite the great promise and flexibility described in the previous paragraphs, hybrid apps have had and continue to face a very real series of challenges and shortcomings. Here are a few of the most notable problems

User-Experience Shortcomings Link

Over the past couple of years, the bar for UX in mobile apps has risen dramatically. Most smartphone owners spend the majority of their time using only a handful of premier apps5. They, perhaps unfairly, expect any new app they try to be as polished as Facebook, MLB TV, YouTube and Uber.

With this very high bar, it is quite difficult for hybrid apps to measure up. Issues such as sluggish or limited animations, keyboard misbehavior and frequent lack of platform-specific gesture recognition all add up to a clunkier experience, which makes hybrid apps second-class citizens. Compounding this issue is hybrid apps’ reliance on the open-source community to write wrappers for native functionality. Here is a screenshot from an app that highlights all of these issues. This app6 was selected from Ionic’s showcase7 and was created by Morgan Stanley.

Screenshot of the app store listing for MS StockPlan.8

Screenshot of the app store listing for MS StockPlan (View large version9)

A few things should be immediately apparent. This app has a very low rating (2.5 stars). It does not look like a mobile app and is clearly a port of a mobile web app. Clear giveaways are the non-native segmented control, font size, text density and non-native tab bar. The app does not support features that are more easily implemented when building natively. Most importantly, customers are noticing all of these issues and are summarizing their feelings as “feels outdated.”

User Interface Challenges Link

The majority of users are very quick to uninstall or forget new apps10. It is crucial that your app makes a great first impression and is easily understood by users. A large part of this is about looking sharp and being familiar. Hybrid apps can look great, but they do tend to be more platform-agnostic in their UI (if they look like a web app) or foreign (if they look like an iOS app on Android or vice versa).

Before even installing an app, many would-be customers will review images in the app store. If those screenshots are unappealing or off-putting, the app might not be downloaded at all. Here is an example app found on the Ionic showcase. This app11 was created by Nationwide, and, as you can tell, both apps look just like a mobile-friendly website, rather than a mobile app.

Screenshot of the Nationwide app on iOS12

Screenshot of the Nationwide app on iOS
Screenshot of the Nationwide app on Android13

Screenshot of the Nationwide app on Android

It is clear from the app store reviews (3 stars on both platforms) that this app has several issues, but it is unlikely that any app with this UI would attract new customers. It is clearly only used by existing customers who think they might as well try it out.

Performance Issues Link

The most common complaints about hybrid apps cite poor performance14, bugs and crashes. Of course, any app can have these issues, but performance issues have long plagued hybrid apps. Additionally, hybrid apps often have less offline support15, can take longer to open and perform worse in poor network conditions. Any developer has heard any of the above called a “bug” and has had their app publicly penalized as a result.

Overall Lack of Premier Apps Link

All of these issues have added up to the vast majority of premier apps being written natively. A quick look at both PhoneGap’s16 and Ionic’s17 showcases demonstrate a noticeable shortcoming in premier apps. One of the most highly touted hybrid apps is Untappd, which despite being a pretty great platform, has fewer than 5 million downloads. This might seem like a large number, but it puts it quite far down the list of most used apps.

Additionally, there is a long list of apps that have migrated from hybrid to native. That list includes Facebook18, TripAdvisor19, Uber20, Instagram3821 and many others.

It would be quite challenging to find a list of high-end apps that have moved from native to hybrid.

Final Defence of Hybrid Apps Link

The point of this section is not to be overly critical of hybrid apps, but to show that there is room for an alternative approach. Hybrid apps have been a very important technology and have been used successfully in many cases. Returning to the Ionic showcase, there are several apps that look better than the ones above. Baskin Robbins22, Pacifica23 and Sworkit24 are three recent examples.

For the past four years, hybrid app developers and frameworks have been working hard to improve their apps, and they have done an admirable job. However, underlying issues and foundational shortcomings remain, and ultimately better options can be found if you’re building a new app in 2017.

Another Approach Link

Although it is clear that hybrid apps do not quite stack up against native apps, their advantages and success can’t be ignored. They help solve very real resource, time and capabilities problems. If there was another approach that solved these same problems, while also eliminating the shortcomings of hybrid apps, that would be extremely appealing. React Native might just be the answer.

Overview and Advantages Link

React Native25 is a cross-platform mobile application development framework that builds on the popular React web development framework. Like React, React Native is an open-source project maintained largely by developers at Facebook and Instagram.

This framework is used to create Android and iOS applications with a shared JavaScript code base. When creating React Native apps, all of your business logic, API calls and state management live in JavaScript. The UI elements and their styling are genericized in your code but are rendered as the native views. This allows you to get a high degree of code reuse and still have a UI that follows each platform’s style guide and best practices.

React Native also allows you to write platform-specific code, logic and styling as needed. This could be as simple as having platform-specific React components or as advanced as using a platform-specific C library in your React Native app26.

Similarities to Hybrid Apps Link

Like hybrid app frameworks, React Native enables true cross-platform development. Instagram has shared that it is seeing between 85 and 99% code reuse27 for its React Native projects. Additionally, React Native is built using technologies (JavaScript and React) that many web developers will be familiar with. In the event that a developer is not familiar with React, it is a dramatically easier to learn if they are familiar with AngularJS, jQuery or vanilla JavaScript than it would be to learn Objective-C or Java.

Additionally, debugging28 React Native apps should also be a familiar process for web developers. This is because it is exceptionally easy to use Chrome’s debugging tools to monitor a code’s behavior. Chrome tools can be used when viewing apps in an emulator or on actual devices. As an added bonus, developers can also use more native debuggers as needed.

Screenshot of the React Native debugger29

iOS React Native debugger window

The main takeaway here is that React Native solves the same core problems that hybrid app frameworks set out to solve.

Further Improvements Over Hybrid Apps Link

Unlike hybrid apps, React Native apps run natively, instead of within a web view. This means they are not restricted to web-based UI elements, which can be sluggish when paired with a poor JavaScript interpreter30. Because React Native renders native UI elements, apps immediately feel more at home on the platform and make the user more comfortable on first use. Additionally, developer quality of life can be improved with React Native through more complete use of native tooling and profiling utilities.

Below are two screenshots of a recently released React Native app. These images highlight the platform-specific interface that can be achieved using this framework. As you can see, each app uses its native map and has callouts that follow each platform’s design guidelines. On Android, the callout is a card that rises from the bottom of the map. On iOS, the callout connects to the selected element on the map. The same actions can be performed in both apps, and most of the code is shared, but that extra bit of platform-specific polish really helps with overall usability.

Screenshot of the Vett Local app on iOS31

Screenshot of the Vett Local app on iOS
Screenshot of the Vett Local app on Android32

Screenshot of the Vett Local app on Android (View large version33)

How Is This Done? Link

Below is a sample React Native component. It demonstrates some common elements that make up React Native apps and highlights the areas that web developers should already be familiar with. Following the code snippet is a description of what each section is doing.

import PropTypes from "prop-types";
import React, { PureComponent } from "react";
import { Dimensions, StyleSheet, Text, View } from "react-native";
import LoadingAnimation from "./LoadingAnimation";
import SearchBar from "./SearchBar";

const { width } = Dimensions.get("window");
const styles = StyleSheet.create({
	title: {
		backgroundColor: colors.transparent,
		fontSize: 19,
		fontWeight: "500",

export default class MovieList extends PureComponent {
	state = {
		movies: [],
		filteredMovies: [],
		loading: true,

	componentWillMount() {

	_fetchMovies = () => {
		fetch("", {
			method: "GET",
			.then(res => res.json())
			.then(res => {
					movies: res,
					filteredMovies: res,
					loading: false,
			.catch(err => {
					error: "Unable to get movies.",

	_applyFilter = term => {
		const filteredList = this.state.movies.filter(
			movie => movie.title.toLowerCase().search(term) !== -1,

			filteredMovies: filteredList,

	_renderTitleRow = movie => {
		const titleLimit = width >= 375 ? 26 : 20;
		let formattedTitle = movie.title;
		if (formattedTitle.length > titleLimit) {
			formattedTitle = formattedTitle.slice(0, titleLimit - 3) + "...";

		return (
			<Text numberOfLines={1} style={styles.title} key={}>

	render() {
		if (this.state.loading) {
			return (
					<LoadingAnimation />
		} else {
			return (
					<SearchBar onFilterChange={this._applyFilter} />
					{ => this._renderTitleRow(movie))}

Much of the code above should be familiar to most web developers. The vast majority of the code is just JavaScript. Much of the rendering logic will be new, but the migration from HTML to the React Native views is pretty straightforward. Additionally, the style attributes are quite similar to CSS. Let’s walk through some of this code:

  • state
    State34 is an object that contains many of the values that our component35 MovieList needs to function. When state properties are changed (using this.setState()), the entire component is re-rendered to reflect those changes.
  • componentWillMount
    ComponentWillMount36 is a lifestyle function that is called prior to the component being rendered. Initial network requests often belong in this function.
  • _fetchMovies
    This function makes a network request that returns an array of movie objects. After it successfully completes, it updates state with the list and sets loading to false. Note that it also sets the initial filteredMovies to the returned list.
  • _applyFilter
    This function is called by our imported SearchBar component. For simplicity’s sake, assume that this function is called (likely with some debounce) whenever the value typed into the SearchBar component is changed. This function just contains some JavaScript that filters the filteredMovies list to the relevant titles.
  • _renderTitleRow
    This function outputs the view for a single movie. It contains some logic to make sure our output is uniform and renders a basic text component.
  • render()
    This function outputs the view for the component. It conditionally renders the list of movies or a loading animation, depending on the loading value stored in the state object.

Who Is Doing This? Link

When deciding how to build your own application, it is important to learn from industry leaders. Other companies and developers might have wasted years and millions of dollars building applications, and in minutes you can learn from their mistakes and experiences. Here is a quick list of some large companies that are using React Native in their apps: Facebook37, Instagram3821, Airbnb39, Baidu, Discord, Tencent, Uber40 and Twitter41.

Many of these apps were originally written using other approaches but have transitioned fully to React Native or are now using React Native to augment their existing native applications.

There is a notable trend of many premier apps being moved to React Native as a cross-platform solution, whereas, previously, most technology shifts among this class of apps were from cross-platform to platform-specific. This change simply can’t be ignored.

What Should You Do Now? Link

Just like the musician who has to rethink their approach to progress, so too must mobile app developers reconsider their technologies. It is critical that we make decisions based on the best options available and not rely solely on our familiarities. Even if the transition is uncomfortable initially, our industry and the app marketplace are highly competitive and demand that we continue to progress.

React Native is a highly attractive technology that combines the reusability and cost-effectiveness of hybrid apps with the polish and performance of native apps. It is seeing rapid adoption and should be considered as an alternative approach for any upcoming would-be hybrid apps.

(da, vf, yk, al, il)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41

↑ Back to top Tweet itShare on Facebook

Paul Francis is a partner and product manager at The BHW Group, an Austin-based mobile app development company. There he has worked on dozens of mobile app utilizing React Native, hybrid technologies, and traditional native technologies. Outside of the office, he enjoys baseball, trivia, podcasts, and arguing about movies.

  1. 1

    Chris Wilson

    June 14, 2017 10:24 pm

    PWAs. That is all.

  2. 2

    Michael Long

    June 14, 2017 10:41 pm

    I get the enthusiasm, but then at the end you go and overstate the facts.

    Yeah, Uber is using React… for UberEats, not their flagship app. Instagram is “augmenting” their native apps with a few features here and there. Twitter, as near as I can tell, seems to using React for their mobile web platform and again, not for their native apps.

    There’s another issue to consider, and that’s lag time. Apple and Android intro new features into their platforms annually and native developers can pick them up from day one and run with them.

    React, Ionic, and PhoneGap developers, however, will always lag behind as they have to wait not only for Apple and Google to release their latest OS’s, but then wait for the community to fold support for those new features into their respective platforms.

    You’re also a step removed from the massive amount of support in the iOS and Android development communities.

    I’ve also talked to some React folk who’ve done projects who tell me that you can get to 95% on a multi-platform project pretty fast… and then burn a lot of time trying to nail down platform specific issues.

    • 3

      Paul Francis

      June 15, 2017 3:42 am

      Hey Michael, thanks for the comment and for reading the article. I understand your point about the flagship apps, but I do think it is telling that these listed companies are interested in this technology, rather than other cross-platform approaches.

      Your point about lag time is valid, but I think is lessened with RN than the other technologies. Speaking from how we do it, we have a number of native developers to help bridge those gaps. We have found this a tremendously simpler process than doing the same with hybrid apps. I think the linked article about the ballistics library lends further light on this.

      Also, and I wonder if you agree on this, but I would argue that this new feature wait time is not as big of a deal as it was previously. Although new OS features continue to emerge, the rate has slowed down over the past couple of years and many new features are less revolutionary than in the past. Additionally, many companies can’t invest too many resources into new OS features because of fragmentation. They rather invest in features for all users.

      One last thing to point out is that this article is more about hybrid Vs. RN. The RN Vs. native question is a valid one, but was not really addressed in this article.

      I definitely see your points and appreciate the feedback. All the best!

    • 4

      > I’ve also talked to some React folk who’ve done projects who tell me that you can get to 95% on a multi-platform project pretty fast… and then burn a lot of time trying to nail down platform specific issues.

      I think that number (remaining 5%) will shrink as RN progresses and there are more info and solutions for those issues. I’d imagine it would vary greatly between projects.

    • 5

      While your points are valid, you really need to check the adoption rate of each OS.

      Android used [May 2017]:
      Marshmallow (v6.0) – 31.2%
      Lollipop (v5.0) – 23.3%
      Kitkat (v4.4) – 18.8%
      Nogat (v7.0) – 6.6% [Newest, released on August 22, 2016]

      iOS has better adoption rates, but still, do you really need the latest features for all the apps you develop?

  3. 6

    Thank you for this article sir, I am code noob and there is too many frameworks that i am lost where to start. lol

  4. 7

    Joao Araujo

    June 15, 2017 9:45 am

    Great article and comments. Thank you all for the healthy and respectful discussion. :-)
    Paul Francis, could you please point out some advantages (if aware of it) from RN over NativeScript? I read a lot of discussion and comparison between RN and NativeScript and in my opinion NativeScript won the current battle (not the war). Therefore I started this week to learn NativeScript and not RN.

    • 8

      Hi Joao. Thanks for reading the article and the kind comment :)
      Unfortunately, I do not have first-hand experience with NativeScript, so I am not the most helpful resource on that question. I can say that for our company, we really like the React framework and use it on almost all of our web apps. So, it is very nice to have a common (or very similar) framework across our teams. Additionally, as a consulting company, we try to put our clients on maintainable and hopefully long-lived frameworks. Given the comparative interest in both platforms (github activity, stackoverflow questions, etc.) and the big names behind and adopting RN, it made it a great option for us.

  5. 9

    Trevor Brindle

    June 15, 2017 6:30 pm

    Though my company is transitioning from hybrid to React Native, and agree with many of the sentiments of this article, I think it is perhaps a bit disingenuous to claim that hybrid apps have poor UX, compromised performance, etc because they are hybrid. Consider that the point of hybrid apps was to lower the barrier to entry; That is exactly what it did, and subsequently allowed less experienced & talented developers to write apps. Put poor programmers on a hybrid project, and you’ll get a poorly built hybrid app. Put poor programmers on a React Native project, and you’ll get a poorly built React Native app.

    Also in terms of a lack of premier apps, again consider the origins and necessities of hybrid. Premier apps with millions of users are more likely to have a larger development team and budget, capable of supporting duplicate native projects.

    Don’t forget that absolutes and generalities, perhaps here a bit ironically, rarely belong in software engineering.

  6. 10

    Why is
    _fetchMovies = () => {
    used and not

    _fetchMovies() {

    • 11

      The former is a modern syntax that makes it so you don’t need to bind(this).


      instead of


  7. 12

    Shantanu Sinha

    June 16, 2017 7:07 am

    Hello Paul,

    Great piece of information up here :)

    I am not that much of coding guy, but yeah this looks promising.

    Thanks for the share.


  8. 13

    Jens Bröcher

    June 16, 2017 6:17 pm

    It is possible to build apps which look and perform completly indistinguishable from a native app with hybrid frameworks…

    The examples shown by the author are just poor design and not a fault of the technology.

  9. 14

    Michael Dobekidis

    June 18, 2017 9:06 am

    It’s not Objective-C or Java, is Objective-C/Swift or Java/Kotlin
    These things make a difference because it is much easier to learn Swift and Kotlin than Objective-C and Java.

    Also React Native is not exactly Javascript per se, its JSX mostly with some Javascript here and there.

    Good article however, a bit biased versus hybrid development showcasing only badly executed Apps.

    But I guess the point was to showcase RN which is open source only in name because in reality if FB and IG developers stop supporting it, many apps will be left hanging, whereas with a hybrid or native App one wouldn’t have this problem.

  10. 15

    Ionic co-founder here. To be clear, we’re big fans of react native and other similar technologies, but I think this post is disingenuous for a few reasons. First, you’ve picked and chosen apps that have less than stellar artistic designs, that have a heritage of being native apps that didn’t look much better or didn’t have better ratings, and then blame that on the technology when it’s actually a different problem. At some point, a company has to invest considerable design resources to build a design that matches what we see out of the top design-oriented startups, and that’s a new skill for the enterprise companies you pointed out; their native apps would look the same or worse.

    I will point out a counter example is MarketWatch that you conveniently left out ( They moved from Xamarin to Ionic and you’ll notice they have a lot of happy users and better ratings than before. Don’t take my word for it, they did a case study with us:

    Native, Hybrid, or somewhere in between won’t solve the need to have great designers building apps.

    Also, let me clarify our priorities at Ionic. We are focused on enabling teams to build apps that run not just in the app store but on the mobile web and desktop with more shared code than ever before. One view of the world is that it shifts entirely to mobile app stores. The other view is that the door users enter continues to be fragmented across desktop, mobile, and other devices, driven by search and shares across the web. Data from Google suggests the latter is actually the reality we live in.

    There has been a lot of talk lately about the long tail of apps and how users aren’t installing or using more than a handful of name-brand apps. In this reality, we’re focusing on helping everyone else reduce the cost and risk to building apps, and enabling them to take advantage of real mobile web traffic and the potential of PWAs to bring back some of the control they once had over customer acquisition.

    We’ve always considered Ionic a long game strategy, betting big on the idea that developers would find that being app store-only was a losing proposition and that apps would need to be built faster and more affordably than before, and run everywhere users are with the same code. I think we’re well positioned for that, and we’ll be here as long as the web is.

    • 16

      Hi Max, thanks for reading the article and for the in-depth comment. I agree with your points on poor design being poor design, regardless of technology. However, I do not agree that I “conveniently left out” the MarketWatch example, I simply was not aware of it. Although, I don’t think that serves as a true counterpoint. You describe them going from Xamarin to Ionic, whereas the article is exploring how RN is the outlier among cross-platform approaches in that premiere apps, that were previously platform-specific native, are exploring RN.

      I do agree that there remains a vital place for technologies like Ionic and you bring up a fantastic point in regard to non-mobile platforms. However, I think that for apps that are focused heavily on installed mobile RN and traditional native are the top choices and that is evidenced by the examples stated. Among those, RN typically works nearly as well as traditional native, while costing quite a bit less.

      By the way, our company has made quite a few Ionic apps and I wanted to thank you and your team for your work. Hybrid apps really helped us bridge the gap from web to mobile and Ionic played a considerable role in that. All the best.

      • 17

        Josh Morony

        June 23, 2017 7:14 am

        Perhaps it would have been a better comparison to highlight the good examples of Ionic applications that you mentioned in the article, i.e:

        * Baskin Robbins
        * Pacifica
        * Sworkit

        rather than focusing on the applications that likely haven’t had as much development effort. It is of course easy enough to create a bad application, so it makes more sense to focus on the good ones for comparison – if those have shortcomings then I think they are fair game to address.

        I think there are valid points to be considered, but I don’t think there are any shortcomings that Ionic faces in terms of the UI/UX points you mention.

        I think where hybrid applications can struggle is in creating layouts with complex animations on older/low power devices, custom animations for view transitions are a pain, relying on community maintained Cordova plugins to access native functionality can bite you if you don’t know how to work with those plugins yourself (which would require you to write native code). I’m sure there are plenty more valid criticisms as well, but there are also a lot of benefits to Ionic and it’s perfectly capable of creating “native quality” applications.

  11. 18

    Raymond Camden

    June 22, 2017 2:31 pm

    It is a small nit (I have other issues too, but I’ll focus on one ;) – but hybrid apps do not have less offline capabilities. Heck, they run local to the device itself so they *always* work, online or offline. If the app makes a network call w/o checking for the network status, then it will certainly fail, but that applies to native apps as well.

    I’ll also call bunk on the idea that users (I mean real users, not those of us here) recognize native controls via web controls and actually care. Do you honestly think a non-technical user loads up an app and says, “Oh wow, that’s not a native tab control. I don’t know what to do now!”

  12. 19

    Olivier Allouch

    June 23, 2017 3:30 pm

    Knowing React.DOM, learning React Native was so easy. React-Navigation is really great (finally!).
    We spent the last 10 years trying to trick the browser into believing nothing has changed in the page, for performance.
    “No, the location hasn’t changed, I just did an offset on that div using transform.”
    “Please, don’t trigger a global reflow. I only changed a div inside another div. Look ! I even added overflow: hidden. You even got your new ‘contain’ css property.”
    I really see React Native as the new browser made for React.
    We have flex for layout. “div” is now “View”….
    What’s funny is that you can even see the same tricks, like telling the engine to copy a View in the GPU for fast animations (with renderToHardwareTextureAndroid and shouldRasterizeIOS).
    And if React Native isn’t the ultimate universal browser, it may be closer than we think ( )

    React Native is Chrome without ascendant compatibility :)

    Olivier Allouch

  13. 20

    Small observation – you want componentDidMount or componentDidUpdate for network requests, componentWillMount describes itself in the docs you provided as inappropriate for side-effects

  14. 21

    Thanks for sharing. Interesting read, but a little one sided imo. All competing frameworks are trying to solve pain points of the now, but my bet is that some variant of a hybrid model will prevail in the long run. We’ve just got to suffer the pain in the meantime!!

    To me it feels like a continuation of a theme I’ve seen and have been coding around over the years – 20 years or so back it was native desktop apps vs websites, then websites 2.0 vs java applets & flash. And back then the debates were over the same type of issues – performance, integrations and look & feel. The web models here started off clunky but eventually prevailed as they matured and became the path of least resistance.

    • 22

      Thanks for your 20+ years of insight Gary.

      I like how you said “path of least resistance”. This path appears to be where the most value for both the developer and the clients is. For developers, the value is the ease and efficiency of development which in turn will enable costs savings to be passed to the clients.


Leave a Comment

You may use simple HTML to add links or lists to your comment. Also, use <pre><code class="language-*">...</code></pre> to mark up code snippets. We support -js, -markup and -css for comments.

↑ Back to top