[HN Gopher] Building all of our new mobile apps using React Native
___________________________________________________________________
Building all of our new mobile apps using React Native
Author : arbhassan
Score : 414 points
Date : 2020-01-29 15:56 UTC (7 hours ago)
(HTM) web link (engineering.shopify.com)
(TXT) w3m dump (engineering.shopify.com)
| The_rationalist wrote:
| Why not ionic react? https://ionicframework.com/blog/announcing-
| ionic-react/
| SlowRobotAhead wrote:
| Subset of a subset would be the first reason I would come up
| with.
| aikah wrote:
| > Why not ionic react?
| https://ionicframework.com/blog/announcing-ionic-react/
|
| React Native uses the Native Components of the platform for UI.
| Thus Native. Ionic React is basically a web app, this is Ionic
| with React instead of Angular.
|
| So basically React Native == use native GUI components.
|
| Ionic React = uses HTML/CSS in a webview embedded in a Native
| App, just like Phone Gap/ Cordova, Ionic is just a framework on
| top of HTML/CSS, React Native is not.
| The_rationalist wrote:
| Most react native apps have a custom UX but needs native
| plugin access. This is the point of ionic react.
| aikah wrote:
| > Most react native apps have a custom UX but needs native
| plugin access. This is the point of ionic react.
|
| No, most React Native apps use the Native platform UX,
| that's the point of using React Native. As for plugin
| access, well I don't see how Ionic React solves anything,
| since a plugin by definition needs to be developed in the
| native language of the platform (Java or Swift).
| awinter-py wrote:
| low quality of tooling in mobile has been a reality forever and
| the vendors are not only unwilling to change, they've doubled
| down on poo-flavored buildsystems that are impossible for the
| community to fix
|
| this stuff is life or death, and also _impossible_ without giving
| up on native:
|
| > React Native on both iOS and Android and shares 95% of the same
| code
|
| > less crashes on iOS than our native iOS app
|
| > an Android version launched
|
| > team composed of mobile + non-mobile developers.
|
| ( _impossible_ on native because of the multi-day process
| required to build an ios app for the first time)
|
| > The team also came up with this cool way to instantly test
| work-in-progress pull requests. You simply scan a QR code from an
| automated Github comment on your phone and the JavaScript bundle
| is updated in your app
|
| code updating is illegal on the app store, but it's hard to kick
| out shopify. this is a shot across the bow
| trevyn wrote:
| > _code updating is illegal on the app store_
|
| This is not true, the restriction is to "download, install, or
| execute code which introduces or changes features or
| functionality of the app."
|
| (And, of course, internal users & builds can do whatever they
| want.)
| tannedNerd wrote:
| "(impossible on native because of the multi-day process
| required to build an ios app for the first time)"
|
| What??? how is it multiple days to build an app for the first
| time? It takes minutes and if you are being pedantic by
| including App Store review it tends to be under 24 hours for
| new apps and under 6 hours for app updates now. Plus you can
| distribute to your own team instantly through TestFlight.
| awinter-py wrote:
| installing the right version of xcode & getting required
| libraries -- my experience may have been particularly bad
| because of the ios 13 / swift 5.1 release, but the fact that
| these tool versions are linked to the xcode version is the
| root cause here
| yagodragon wrote:
| The web and its ecosystem are huge. The browser is essentially
| the new OS and no matter how complex and quirky js, react and the
| rest of the tools are, we're gonna stick with them for a long
| time. Big technological advances like PWA's, WASM and rendering
| engines like servo and webrender are only gonna shorten the gap
| between native and web UI experiences. Look at what happened to
| the desktop. Native UI development became a niche and even apps
| like photoshop are now just websites(figma) or electron apps.
| This is eventually gonna happen to mobile development as well.
| There will be no need to create native apps for most cases and no
| need to use those centralized app stores to "install" apps on
| your device.
|
| That being said the web is not quite there yet and that's why
| solutions like react-native and flutter exist. I don't believe
| that react-native is the future. Many people have explained in
| great detail why the idea and the execution behind RN are just
| flawed and why it makes development hard and complex. Heck, it
| doesn't even eliminate the need for native developers. React-
| native is just a transitional tech we'll use until the web and
| PWA's become good enough for 95% of the cases. The future of RN
| is the Web.
|
| On the other hand, flutter and dart seem to solve all of the
| problems we have with UI development. It's an amazing tech that
| combines all the best ideas from QT, flash, java swing, delphi
| and react-redux in one project that is completely free and open
| source. It's what we've always dreamed existed in the UI world.
| The development experience is great and designers seem to love it
| as well. Despite its advantages, flutter is still a huge bet and
| i can't see a world where everybody writes in Dart.
|
| If I had to make a guess, I'm still betting on the web in the
| long run and hope flutter captures a small market share among
| frustrated mobile/web devs and designers. I just can't see react-
| native anywhere in between.
| irjustin wrote:
| I'm always scared of these headlines for companies who aren't
| greenfield.
|
| Shopify is a perfect case for RN. Write once deploy both
| platforms. The issue that gets glossed over is for existing apps
| that have to do the data and abstraction layer on top of native
| codes. It starts to become prohibitively expensive to maintain
| the native, RN, and data layers unless you're willing to rewrite
| the native side.
|
| Airbnb fell into this problem[0] and so did my old company.
|
| I love RN for what it is and can do, but big companies that hop
| on and then are forced to hop off because of internal politics
| makes it a difficult case for RN because then it becomes "look,
| RN didn't work out for Airbnb or Shopify..."
|
| I hope for the best of luck and success to the RN engineers.
|
| [0] https://medium.com/airbnb-engineering/react-native-at-
| airbnb...
| wvenable wrote:
| I don't understand why so many large companies use platform
| abstractions. At a certain size you're big enough to have an iOS
| team that develops natively in Swift/ObjC and an Android team
| developing natively in Kotlin or Java. Developing directly for
| the platform, with expertise in that platform, is a proven long
| term bet. Screwing around with platform abstractions seems much
| riskier.
|
| The situation is a lot different if you're a small organization
| (or individual) and just don't have the resources for platform
| specific experts.
| Androider wrote:
| Headcount is the biggest expense in almost all companies.
| Larger companies also have larger and more complex apps, so
| while a small company may have a small iOS development team,
| large companies have massive iOS development teams. Massive
| team * number of platforms = serious money.
|
| You also get into all kinds of platform and feature parity
| issues. "Why can't we do X on Android but only on iOS?", "Well
| because they're two different teams, with different PMs,
| developers and release schedules. And please don't ask about
| the web team, who are in <different city>".
|
| Using abstractions you can have one massive "core" team, and
| several smaller platform expert teams. On the face of it, it
| makes sense.
| kerbs wrote:
| Do you think AirBnB's headcount was smaller when they were
| all-in on React Native?
|
| Do you think they had to go on a hiring spree because they
| went back to native?
|
| I'm skeptical there is a correlation.
| wvenable wrote:
| But developer headcount doesn't scale to the size of the
| installed base. Whether you have hundred-thousand users or a
| million users, you don't need a larger development team. Once
| you have a reasonable-sized team that can make the app, you
| don't need any more developers, no matter how successful your
| app is.
|
| Having different teams for different platforms might result
| in a slightly larger headcount my point is that risk isn't
| worth that meager benefit if you can afford it. You're still
| going to need platform-specific knowledge, and then the
| abstraction knowledge, and you're still deploying to multiple
| platforms!
|
| You also don't need to let the technology choices drive the
| team structure. You can share a huge number of resources
| between iOS and Android including planning, management,
| assets, etc. Sure you're building two different apps but you
| don't need to keep those teams in different cities.
| Androider wrote:
| But the question was why large companies use platform
| abstractions. Because they are large in headcount, by
| definition. Because the apps are already large. Because
| they _have_ massive platform specific teams, and they would
| like not to. Because the teams are geographically spread
| out, for a myriad of reasons.
|
| The large companies are what they are, and you cannot apply
| the same type of thinking to their problems as if you were
| designing the organization from scratch. There's problems
| they have, and the team structure they would like to have,
| and based on that the technology choice to favor
| abstraction makes sense.
| wvenable wrote:
| Yes, many large companies seek technological solutions to
| political problems. I've worked for dysfunctional
| organizations; they want technology to provide the
| decisions bottom-up because, for whatever reason, nobody
| wants to make any hard calls. These projects fail because
| you simply can't have success that way.
|
| If this is a political and organizational problem, then
| this choice of technology is entirely not about the pros
| and cons that have probably been debated to death in this
| topic. I agree. I think you've added some really good
| insight in this conversation. But I think that solution
| is dumb.
|
| It's especially dumb for a software company because
| software is their core competency. That's where they
| should be spending their resources on. They should be
| minimizing costs but not at the cost of their core
| product.
| Androider wrote:
| I wouldn't class this as political problems. Is Facebook
| having a gazillion developers on their app a political
| problem, or necessary given what they want it to do? How
| is replicating that for each platform a good solution, in
| any sense (political or technical)?
|
| Tech companies core competencies are the service or
| product that they provide. Making it N times for N
| platforms is a hurdle that doesn't improve on the core,
| it's a cost of the fragmented market. I'm arguing that it
| makes perfect sense both technically and politically to
| focus your vast majority of developers on your core, and
| only having specialized platform teams were necessary as
| a cost of doing business. How is developers re-
| implementing every UI screen and feature across iOS and
| Android helping Shopify customers sell more merch?
| wvenable wrote:
| > Is Facebook having a gazillion developers on their app
| a political problem, or necessary given what they want it
| to do?
|
| Yes. How is it not a political problem? It's not a
| technological one.
|
| > How is replicating that for each platform a good
| solution, in any sense (political or technical)?
|
| It doesn't change anything politically but
| technologically platform abstractions are never 100%. You
| always need an expert for each platform _anyway_ and by
| targeting the abstraction rather than the platform you
| 're just targeting a crappier experience for your end
| users and often your developers as well. React Native is
| not without it's issues.
|
| So what's the benefit? You're not saving expertise. Even
| sharing code isn't that important -- once decisions have
| been made, features planned out in detail, server APIs
| created, the actual platform specific code is a pretty
| small part overall. You still have to test on each
| platform individually. Fix platform specific bugs even in
| non-platform specific code. And you're not creating a
| dependency on a 3rd party that you don't control.
|
| > How is developers re-implementing every UI screen and
| feature across iOS and Android helping Shopify customers
| sell more merch?
|
| How is it not? I mean the argument here is that there is
| a huge savings to justify the risk but I don't think
| that's true.
| wvenable wrote:
| > Because they have massive platform specific teams, and
| they would like not to.
|
| I'm somewhat shocked at the size of some of the mobile
| app development teams at some of these companies. There's
| no way they need that many developers. What are 100's of
| developers doing on a single app for a single platform?
| How is there enough work for that many people? The
| overhead must be unbelievable.
|
| I can't imagine that adding a platform abstraction is
| going to fundamentally change the headcount if your
| headcount is already ridiculous. It just doesn't remove
| _that_ much effort.
| Androider wrote:
| The Facebook app is like Microsoft Word. Everyone only
| uses 20%, but it's a different 20% for each. The app is a
| hojillion megabytes, and serves literally billions of
| users. There's features in there that addresses some
| specific niche in Africa for "only" 50 million users,
| that some sub-team of a sub-team is tasked with
| maintaining.
| wvenable wrote:
| Microsoft doesn't use an abstraction to create Word for
| Mac OS. They have shared code, yes. But they are
| different products with different user interfaces to
| match their respective platforms. I'm not sure why mobile
| is so different that one needs a platform abstraction if
| you've already got a bazillion developers working on the
| product.
|
| Of course, Facebook does benefit by owning that
| abstraction making it exactly what they need. For
| everyone else, the risk is a bit different.
| Androider wrote:
| Microsoft has been building Word on Windows since the
| 80's, so it's never going to be re-written. I'm not that
| familiar with the Mac version of Word, but I find the Mac
| Excel version lacking compared to its Windows
| counterpart.
|
| For Word and Excel for iOS and Android they use... React
| Native [1].
|
| [1] https://blog.appfigures.com/microsoft-goes-all-in-on-
| react-n...
| horsawlarway wrote:
| As someone leading a team that does releases to clients,
| this is a pretty naive take.
|
| As you scale you get quite a few constraints that require
| additional manpower
|
| 1. Scaling generally means revenue, which means more
| internal teams pumping out more business products/features.
|
| Those features often need some sort of mobile integration.
| So you not only have your planned features, you have the
| features other teams would like you to work on.
|
| The larger the company, the more requests like this you
| get. Feature velocity MATTERS.
|
| 2. As you scale you almost always have to rework your
| backend to _some_ extent to keep up with load /feature
| growth. This means existing features are at risk of using
| deprecated & older APIs/Tools and need attention in order
| to keep working and allow scaling.
|
| 3. By the time you're scaling into the millions, you're
| almost certainly acquiring enterprise users. You can skate
| by in the individual/small/medium business with some pretty
| glaring bugs (things like 2% of all android users see
| crashes at startup). This wiggle rooms goes away when you
| start working with enterprise customers (or at least gets
| considerably tighter). It's an inconvenience when your 15
| person org has that one phone that doesn't work right. It's
| a showstopper when the 10,000 seat org has 600+ users who
| can't use the product.
|
| Those are just a few of the differences that happen at
| scale.
|
| ----
|
| Long story short, you're not really wrong from a technical
| side - A small dev team can absolutely make a small &
| focused app and manage to scale.
|
| You're just glossing over the politics of working in an org
| that's successfully scaling.
|
| It turns out being able to get additional employees that
| don't need extensive mobile experience and can just crank
| out features is a huge pressure release. It lets that
| original tiny dev team (the folks who could write a fine
| native app without any issue) focus on bigger/harder
| problems.
| throw_m239339 wrote:
| > I don't understand why so many large companies use platform
| abstractions
|
| Even large companies can be cheap. Hiring developers is a
| complicated and costly process. But I'd wager that using a
| solution that the company or a middle manager X,Y,Z didn't vet
| before can also be a complicated a costly process. Plenty of
| language X shops refuse to use language Y for political
| reasons.
| ysavir wrote:
| > I don't understand why so many large companies use platform
| abstractions. At a certain size you're big enough to have an
| iOS team that develops natively in Swift/ObjC and an Android
| team developing natively in Kotlin or Java.
|
| Because whoever made the decision to move to an abstraction
| gets to highlight "eliminated redundancies and saved the
| company $XMM/year" in their next performance review/resume.
| garrettlarson wrote:
| > As a contrast, none of the Top 10 most valuable Y Combinator
| companies use Java; largely considered the battle tested
| enterprise language.
|
| I'm not sure what this is based on, but Airbnb uses Java pretty
| extensively.
| ronlobo wrote:
| Curious to hear more about their deep dive into Native, Flutter
| and React Native as possible technology choices.
|
| Hopefully, React Native is not a nosedive ;)
| k__ wrote:
| Flutter and React-Native are different directions, I think.
|
| For higly customized UIs (think Ableton Live, Photoshop, Excel,
| etc.), I'd say use Flutter, because of the non-native
| rendering, it will look the same everywhere. Otherwise use
| React-Native.
| oakesm9 wrote:
| Exactly this. They are very different systems.
|
| Flutter renders onto a "canvas" and has a completely custom
| implementation of "native-like" views for each platform. They
| need to reimplement everything about platform views from
| scratch.
|
| React Native lets the native OS render actual native views,
| but lays them out and controls their properties using
| Javascript. You get the native behaviours "for free", but you
| do sometimes end up in the lowest common denominator
| position.
| k__ wrote:
| Yes. The common denominator isn't as low as one might
| expect. I'd guess at least 90% of all apps could be easily
| done with React-Native.
| SlowRobotAhead wrote:
| Sure. But what if the entire world doesn't want to learn
| JavaScript? What if you don't already know HTML, CSS, and
| JS? RN makes ZERO sense at that point.
|
| As a C developer, man, Flutter looks pretty damn logical!
| oakesm9 wrote:
| If it makes more sense, then go for it.
|
| With all of these platform abstractions you just need to
| understand the trade-offs they're making.
| k__ wrote:
| https://mobile.twitter.com/LinguaBrowse/status/1220695261
| 246...
| hopia wrote:
| In my experience Flutter is not any less productive than RN
| is, I'd prefer the former in every case now.
| k__ wrote:
| https://mobile.twitter.com/LinguaBrowse/status/122069526124
| 6...
| hopia wrote:
| The last time I was using React Native even text input
| was broken on Android. It made any app using it basically
| unusable. Android profiler didn't work either, opening it
| crashed the runtime.
|
| Flutter has its bugs but they're certainly not that
| fundamental issues.
| k__ wrote:
| Sounds like the opposite to me.
|
| A bug in React Native and fundamental issues in Flutter.
| hopia wrote:
| I don't follow. What I outlined were fundamental issues
| with RN, not with Flutter.
| k__ wrote:
| What you outlined sounded like a bug, the Twitter link I
| posted covered some fundamental Flutter issues.
| topherPedersen wrote:
| As a solo/indie developer I love React-Native. Attempting to
| develop for Android and iOS at the same time is absolutely
| daunting. Maybe someone out there can do it, but it was simply
| too much for my brain to handle. But with React-Native I don't
| have to worry about any of that. I just write code and it doesn't
| matter what device people happen to be using.
| fredgrott wrote:
| Hahaha ahaahah
|
| gee what happens when Android Fuchsia hits oem devices this year?
| CES surprise coming..
| Androider wrote:
| In the unlikely event that Fuchsia ever makes it out without
| being strangled by the rest of the Android organization, or
| someone high-up waking up and taking a look at it (eye of
| mordor style)... absolutely nothing? For the next 5-10 years at
| least as Android devices are slowly replaced in the marketplace
| with Fuchsia through device turnover rates alone. You think
| Android version upgrade stats are abysmal today? And you want
| to replace the whole base OS? Good luck with that.
| deltron3030 wrote:
| Strange that they didn't mention hiring as a reason, it's maybe
| even the main one. React is for the frontend what PHP was for
| backends in the 2000s, that's what most frontend devs know.
| Svelte would be a better fitting comparison to Rails in 2004.
| sandGorgon wrote:
| I think one of the coolest things that Shopify is doing is this:
|
| _We're sponsoring Software Mansion and Krzysztof Magiera (co-
| founder of React Native for Android) in their open source efforts
| around React Native._
|
| and
|
| _We are working with Discord to accelerate the open sourcing of
| FastList for React Native (a library which only renders list
| items that are in the viewport) and optimizing for Android._
|
| Basically RecyclerView for React Native.
| LeoNatan25 wrote:
| Without synchronous view layout, it's not really possible to
| have a truly recycling view without many warts. We've (Wix)
| been hacking at this for years, and it's not possible. You
| either block the UI or view flash for the user if fast enough
| scrolling is performed.
|
| Facebook engineering promised synchronous layout will come at
| some point, which will open the door to that.
| rhodysurf wrote:
| Theyve said Fabric comes out probably mid 2020 I think, which
| I am hopeful for
| liampronan wrote:
| Is Wix moving away from React Native at this point?
| LeoNatan25 wrote:
| No
| jiofih wrote:
| I'm really eager to hear how they deal with data in their RN
| apps. To me that's always the place where the most complexity and
| bugs lay hidden.
| burnJS wrote:
| I guess I'm old, but I can't believe that many people shop on
| their phones. You have limited screen space and your ability to
| input data efficiently is limited. It just seems like a really
| poor medium for researching a purchase. Guess I'm a dinosaur.
| neurostimulant wrote:
| Many online marketplace give discount when you purchase via
| their mobile apps. Kinda make sense as they can harvest a lot
| more data from installed app (compared to web) and spam push
| notifications daily to drive up sales, so they push hard to
| make people shop from their mobile apps instead of desktop web
| store.
| TulliusCicero wrote:
| I shop on my phone, mostly Amazon. Probably not for
| serious/expensive purchases, but there's tons of things that
| don't qualify for that.
|
| I buy a lot of kids' books, for example, I just look at the
| cover and description, read some reviews, and pull the trigger.
| Lots of little electronics too, like cables/adapters.
| yoshimiagava wrote:
| This is amazing team for spotiteam and all users! Congrats!
| wdb wrote:
| I am always wondering what the difference is between writing
| three differents targets, iOS, Android and Web using RN (even
| Flutter is a better choice imho).
|
| Basically you want to share the business logic between them. You
| still need to spend time to write UIs for iOS and Android which
| following interaction paradigms of the platform.
|
| Personally, I can't stand iOS apps that look like Android.
|
| Currently, I am happily working on a project where I write all
| the business logic in Swift and share between the web app
| (WebAssembly) and the iOS and Android app. The only bit that I
| customise is the UI part. I quite enjoy this approach.
|
| (I have to admit for me writing native mobile app in
| JavaScript/TypeScript feels wrong. Guess, I don't like that
| language enough)
| arbhassan wrote:
| Meanwhile Shopify's CEO. [1]
|
| [1]https://mobile.twitter.com/tobi/status/1222551057798090752
| sixstringtheory wrote:
| Oof, not classy. I think every developer has had the experience
| where you think you're so close to the finish, just one more
| thing... and then hours, days, weeks have gone by. How can he
| be so sure they're going to strike it big?
|
| This is a pictographic sunk cost fallacy.
| sergiotapia wrote:
| We're moving away from react native at Papa. Too brittle, too
| cumborsome to iterate with, feels slow and every build required a
| prayer and small sacrifice to Cthulhu.
|
| We're using Ionic 4 now with capacitor, the dev workflow is much
| better, literally testing on the browser with autoreloads when
| code changes. Couldn't be simpler. So far I like it a lot. We're
| using React so it's just like writing a SPA, only Ionic has a ton
| of UI elements out of the box like tab navigation.
| 22byebye wrote:
| << Flutter vs React Native: A detailed Comparison 1. Performance
| Mapping down the performance is the best way to find the ideal
| framework for mobile app development. Flutter is ahead when it
| comes to performance among other frameworks is due to Dart. Dart
| code is compiled to native machine code. And also the JavaScript
| layer is helpful when integrating with native components and
| eliminates the JavaScript bridge.
|
| React native offers exceptional performance for developers while
| developing an application in a native environment. But developers
| sometimes face issues while running the hybrid application
| architecture. On the other hand, Flutter allows developers to
| reuse the existing code. Flutter is in the leads in performance
| in comparison to React Native which uses JavaScript Bridge. >>
|
| Source: https://dev.to/agiratech/flutter-vs-react-native-what-to-
| cho...
| gargs wrote:
| Translation: we don't see mobile experiences driving our growth.
| ziftface wrote:
| Why is that an equivalent statement?
| LeoNatan25 wrote:
| If mobile was important enough for them, they would have
| invested in proper mobile development. Clearly it is not.
| gargs wrote:
| Companies invest in growth areas. Mobile experiences are
| driven largely by interactive native elements using the
| latest platform specific API.
| ppeetteerr wrote:
| I'm surprised no one is mentioning this:
|
| "At the beginning of 2019, we did a 6-week experiment on our
| flagship Point of Sale (POS) app to see if it would be a good
| candidate for a rewrite in React Native. We learned a lot,
| including that our retail merchants expect almost 2x the
| responsiveness in our POS due to the muscle memory of using our
| app while also talking to customers.
|
| In order to best serve our retail merchants and learn about React
| Native in a physical retail setting, we decided to build out the
| new POS natively for iOS and use React Native for Android."
|
| So it's okay to build Android and less important apps using RN,
| but their flagship iOS POSS is off limits?
| AgloeDreams wrote:
| Isn't the vast majority of their POS systems iOS based? The
| base iPad is rather fast. Why not just target your market
| directly and max out performance? Meanwhile the vast majority
| of their Android POS systems use what, lower end Kindles and
| such? They know they can't get perfect experience there but
| they don't want a bad one where it counts. They know their
| market.
| Despegar wrote:
| That really just says it all doesn't it? It's basically an
| admission that the use of cross-platform frameworks is worse
| for customers/users, but they're going to ignore that to
| optimize for their own software engineering org.
| sibeliuss wrote:
| Build RN app on Android, if it's successful then do a light
| port to iOS and decommission native team.
|
| Seems like a fantastic experiment IMO.
| apl002 wrote:
| you act like whatever something is right now is the same in
| the future. It's quite possible they see RN as the future for
| all products and easing there way into things. Maybe they are
| struggling to find Java/Kotlin devs and have a surplus of
| Swift devs. So no, that does not really just say it all.
| sandofsky wrote:
| > Maybe they are struggling to find Java/Kotlin devs and
| have a surplus of Swift devs.
|
| Based on AirBnB's experience, now you need to find React
| Native devs _in addition to_ Java devs.
| sb8244 wrote:
| I assume it's easier to find a handful of skilled Android
| developers rather than staffing an entire engineering org
| with them.
|
| From my experience with RN, you do need to get into the
| native bits, but most of the development will be not
| native. So the number of skilled native device engineers
| required should be less.
| raydev wrote:
| I can see, if you were a billion dollar company, how
| you'd have an Android infra team to bridge those
| performance-intensive items, with the UI team doing all
| their work in RN.
|
| So you can't be a startup/small shop if you want to do
| this well.
| raydev wrote:
| I think you're touching on something extremely important
| here. IME, anecdotally, not backed up by data: experienced
| native Android devs are getting harder and harder to find.
|
| The ones I've known personally hated it so much they moved
| to backend or full stack jobs.
| chrisco255 wrote:
| All this says to me is that they wanted to limit their risk
| exposure by doing an experiment on Android while maintaining
| native on iOS. Why is that hard to comprehend? Their move to
| RN this year should underscore the success of that
| experiment.
| zapzupnz wrote:
| The thing is, you can rephrase:
|
| > by doing an experiment on Android while maintaining
| native on iOS
|
| as:
|
| > by throwing their Android users under the bus
|
| It may be a cynical take but it's not an invalid one to
| take when the thrust of the rest of the paragraph comes
| down to "the native app's performance is so good, we
| couldn't dream of changing it".
| chrisco255 wrote:
| I don't know if you read the article or not but the title
| is very clearly: "React Native is the Future of Mobile at
| Shopify". So the Android experiment was successful.
| ericlewis wrote:
| Also, ios is "easy" when it comes to doing react-native.
| So by doing the hard one first, they have a lot more
| confidence in the rest.
| calcifer wrote:
| > Why is that hard to comprehend?
|
| Probably because that's not what the article says.
| jaxn wrote:
| This is how I read it too. They can then run the RN app on
| iOS too (with some modifications I'm sure). Seems like a
| smart strategy. And that the jury is still out.
| Touche wrote:
| Right, but it doesn't really optimize for their engineering
| team either since the only reason to use something like React
| Native is the ability to do both platforms at once.
| nilkn wrote:
| Is that not a tremendous optimization for the team? It
| probably cuts the team size in half (or, seen another way,
| doubles its size for free), and it unifies of a lot of the
| mobile and web stacks behind similar languages and tools,
| which in turn would allow some unification in the hiring
| and recruiting pipelines.
| Touche wrote:
| It's an optimization they aren't using, React Native is
| only being used for Android.
| nilkn wrote:
| Do they not clearly intend to use it for both in the
| future? They didn't go back and rewrite all existing
| apps, and they did an experiment with Android to validate
| the approach.
| kyriakos wrote:
| Really depends on their priorities and customer base. We
| developed a react native android app and users seem to be happy
| with it. Would native be smoother? Maybe..
| MuffinFlavored wrote:
| Why couldn't they help contribute to/optimize React Native to
| be faster?
| Despegar wrote:
| Apple really needs to start using the stick more with respect to
| the inferior-to-native cross-platform frameworks. I hope that's
| the strategy after SwiftUI matures.
| fmakunbound wrote:
| Good for you Shopify, but I fully expect you'll switch to some
| new hotness in a year or two.
| mleonhard wrote:
| > The first is a tooling team that helps with engineering setup,
| integration and deployment. The second is a foundations team that
| focuses on SDKs, code reuse and open source.
|
| They have a whole team to set up tooling for React Native. I
| wasted many days trying to do this work on my own.
|
| They also have a whole team for evaluating 3rd-party libraries
| that provide functionality missing from React Native, such as
| letting the user hide the keyboard on iOS. I wasted weeks on this
| and finally gave up on React Native and switched to Flutter.
|
| I think React Native needs some attention from user-focused PMs
| and engineers before it is ready for adoption by small teams.
| tr33house wrote:
| How has flutter compared?
| xeonoex wrote:
| Not OP, but I've tried all of the big SPA frameworks (not
| specifically react native though) and I decided to use
| flutter for a non-trivial side project and I don't ever want
| to touch the big SPA frameworks ever again. Flutter is also
| fast, pretty lightweight, and good on battery. It feels
| native on iOS and Android. I have little Android development
| experience (side project years ago) and no iOS experience.
|
| It's easy to setup, install, and it just works. I develop on
| Windows and Mac with a .NET Core backend and communicating
| via GRPC. Deploying the backend to a CentOS server. No issues
| running anything on Windows, Mac, or Linux, surprisingly.
| Whenever I have to use node, everything randomly breaks when
| switching environments. (Maybe I'm just bad with node/webpack
| and all that, but there is way too much I have to know to
| just build something).
| Thorentis wrote:
| I'm considering using Flutter (instead of Ionic which Ive
| been using for mobile up till now).
|
| In terms of Node breaking when switch platforms - are you
| syncing the node_modules folder between machines somehow?
| Don't do that. Doing "npm install" will sometimes install
| binaries specific to a platform that won't work across
| them. Put node_modules in your.gitignore, and sync between
| machines using version control rather than something like
| Dropbox. I used to just put the whole project in Dropbox
| but ran into too any issues between Mac/Windows.
| xeonoex wrote:
| Yeah, I used git and ignored node_modules. Honestly, most
| of the problems are related to Windows. Whenever I try to
| use anything geared towards web dev, there are just more
| issues on Windows. Tons of dependencies that change all
| the time doesn't help. Most of the web dev industry is on
| Linux or Mac. It's not all related to Windows though.
| Just updating packages/frameworks is scary. Setting up
| Jekyll was tough, even on WSL. I've opened issues on
| projects, and they would update the project to say that
| Windows is not supported (though IDK if node was the
| issue there). I bought a Macbook solely to deploy iOS
| apps, but it is way easier to develop anything related to
| web on it.
|
| Again, this is coming from someone who doesn't do web dev
| full time, so I'd probably resolve issues faster if I
| did, but for my side projects, it's too much maintenance.
| I just want to be productive if I have an hour or so a
| day. Flutter lets me do that. I write code, code runs on
| Android and iOS. It's easy. No react/vue/angular,
| webpack, bootstrap, scss, typescript definition files, or
| other 'magic' to worry about.
| mleonhard wrote:
| I am satisfied with Flutter. My app is almost ready for beta
| testing:
|
| https://www.cozydate.com
| mahgnous wrote:
| So they decided to join what the rest of the world has already
| been doing for years? Why announce that?
| mahgnous wrote:
| So they decided to do what the rest of the world has already been
| doing for years? Why announce that?
| OzzyB wrote:
| Shopify should stick to making ecommerce sites and leave the
| mobile engineering evangelical space to those who's businesses
| are dependent on mobile and have the necessary experience.
|
| In short, the future isn't React Native, unless you have a time
| machine that will allow you to go back and rewrite it.
| Hates_ wrote:
| So even though they develop apps that have millions of
| downloads or that businesses rely on for their in-store point
| of sales, you don't consider Shopify qualified to speak on
| mobile development?
| OzzyB wrote:
| No, I don't consider an established tech company with
| "millions of downloads that businesses rely on" choosing a
| webstack devkit for their mobile development serious.
| canistr wrote:
| "In order to best serve our retail merchants and learn about
| React Native in a physical retail setting, we decided to build
| out the new POS natively for iOS and use React Native for
| Android."
|
| Unbelievable, really. The previous paragraph literally mentions
| the importance of performance.
|
| _facepalm_
| wdb wrote:
| Why do they use RN for Android but not for iOS?
| chadlavi wrote:
| the example react native code they give in this image would error
| out:
| https://cdn.shopify.com/s/files/1/0779/4361/files/ReactJSvsR...
|
| Text has to be in a <Text>
| harrisonjackson wrote:
| You cannot see the imports.
|
| import {Text as View} from 'react-native';
|
| All good!
| chadlavi wrote:
| this is truly evil
| bil7 wrote:
| oh no, how will anyone understand the graphic now?
| ericlewis wrote:
| they changed it I think to be more incorrect, you can't put
| text in a View.
| stickydink wrote:
| It seems they fixed it!
|
| https://cdn.shopify.com/s/files/1/0779/4361/files/React_Nati...
| jammygit wrote:
| Why do they begin justifying by talking about 70% of buyers using
| mobile? Completely off topic
| SlowRobotAhead wrote:
| Isn't that them starting by declaring that mobile is really
| important to them so they didn't take this choice lightly?
| mellosouls wrote:
| This is an interesting read and may be the full story, and a
| completely justified strategy.
|
| But at the risk of sounding cynical, I'd be interested in any
| political motivations - if he's a new VP, it wouldn't have been
| unheard of for unnecessary swashbuckling Transformation Projects
| to be kicked off under the new regime for no obvious reason.
|
| Complete conjecture, I have no inside knowledge, just have seen
| this happen time and time again.
| brailsafe wrote:
| It happens all the time. At a large corporate place I was
| working frontend at, our dpmt manager spent almost no time with
| the teams and all time concerned with outout metrics. When his
| boss looked to be retiring and the prospect came up to get his
| job, he started a new year by--seemingly with no knowledge of
| how things were working--by shuffling all the teams based on
| how he thought people should be organized. He then kicked off
| two or three major tight deadline high budget projects with
| those new teams, and proceeded to take a vacation. Needless to
| say there was a lot of turnover, I got terminated, projects
| failed, and he got his promotion somehow.
| mellosouls wrote:
| Yep. I'm more than a little sceptical these days when these
| big projects are announced - especially with new managers.
| Nextgrid wrote:
| Airbnb said the same back in the day. Guess what happened then?
| https://medium.com/airbnb-engineering/sunsetting-react-nativ...
| mambodog wrote:
| it's almost like different companies make different tradeoffs
| based on different organisational needs and priorities
| hota_mazi wrote:
| And in a couple of years, "Why we are moving away from React
| Native at Shopify".
|
| Not slamming React Native but the sensationalistic headline.
| Anyone with a bit of experience in software should know better
| than making this kind of silly proclamation about the future of
| your software stack.
| wpietri wrote:
| Sadly, this sort of public PR campaign is surely related to an
| internal PR campaign. Often followed by a declaration of
| Totally Amazing Success, shortly after which the person who led
| the campaign will use the victory to move to a higher position,
| possibly at a new company.
| otaviokz wrote:
| Saw it happening a few times in my 12 year of industry. I
| suppose it's specifically common in companies that use social
| media (and other media) presence as a recruitment boosting
| tool.
|
| Twice the "leader" of the "Totally Amazing Success" left the
| company to "be totally amazing" somewhere else. In both cases
| the team was made mostly of very young engineers, the level
| of amazingness was strongly overestimated. It was also
| declared very early, before the "novelty" of the "new thing"
| faded, and also before the downsides appeared while
| maintaining the product.
| ryandrake wrote:
| RDD: Resume-Driven Development
|
| You often see this kind of stack rank of developer
| priorities:
|
| 1. What's good for my career
|
| 2. What makes my boss look good
|
| 3. What is convenient for the development team
|
| 4. What is good for the company
|
| ...
|
| 99. What's good for users
| seanalltogether wrote:
| The company I've been contracting for lasted just over a year
| on react native before heading back to native. Even though the
| product was still a prototype, we were spending way too much
| time updating libraries and trying to decipher all the breaking
| dependencies. Some easy, some very cryptic.
|
| On a side note, I'm not a big fan of people shoehorning
| stateless web development patterns into application
| environments that support stateful development. The solutions
| appropriate for development inside a web page are often not
| helpful inside an application binary.
| sschueller wrote:
| I have not seen one good app for android that has been written
| in react native. Can anyone show me one that doesn't suck in
| performance?
| solarkraft wrote:
| I'm pretty okay with the Spotify app nowadays. It used to be
| worse, I think, now I'm rather annoyed by the not that great
| UI/UX design (everything is way too large, I don't see shit,
| man).
| jchw wrote:
| From my understanding, it does exist in popular Android apps,
| but usually for larger apps its used for only parts of the
| app and not the entire app.
|
| Discord is an interesting case. They were using React Native
| for iOS and not Android. In their defense, this probably
| makes sense since substantial code sharing could be achieved
| between their desktop/web app and their iPhone app with this
| approach.
| chrisco255 wrote:
| Instagram.
| deminature wrote:
| Instagram has very limited parts of the application written
| in RN, like 'Edit Profile'. [1]
|
| The vast majority of the app is implemented natively.
|
| [1] https://instagram-engineering.com/react-native-at-
| instagram-...
| chrisco255 wrote:
| That article is 3 years old, but it mentions "Photos Of
| view", "Post Promote", "Save Posts", "Checkpoints",
| "Comment Moderation", "Lead Gen Ads", "Push Notification
| Settings", and "SMS Captcha Checkpoint". At any rate, I'm
| curious to see how this has evolved over the past 3 years
| and I remain impressed with their seamless integration of
| RN and native.
| rhodysurf wrote:
| My app is incredibly simple but its performance is good.
| HopeWaves on the play store.
| jarnagin wrote:
| Seems consistent with your comment, IMO, given that "the
| future" is by definition something which never arrives.
|
| It's much less exciting, however, to say "React Native Is
| What's Next at Shopify".
| elicash wrote:
| I don't think anybody read the headline and assumed that no
| other technology would ever be used at Shopify.
| chrisan wrote:
| Man first thing I thought of.
|
| Seems like if you try to proclaim the future you end up eating
| your words
| skinnyasianboi wrote:
| My first thought was the Airbnb article "React Native at
| Airbnb" https://medium.com/airbnb-engineering/react-native-
| at-airbnb...
| liamcardenas wrote:
| I understand how examples like this stick in people's
| minds, however, just because one company decided not to
| move forward with a technology doesn't mean that all
| companies will do the same.
|
| Facebook has continued to use it, Microsoft has begun using
| it heavily, Twitter uses it on the web[0], Discord has been
| very happy with it -- and countless other examples.
|
| [0] https://github.com/necolas/react-native-web
| [deleted]
| newfeatureok wrote:
| Honestly I think the future of mobile will just be... mobile
| websites.
|
| What's missing until regular websites have parity with mobile
| apps in functionality?
|
| - Accelerometer and all sensor support (some of these are already
| supported on various browsers on various OSes)
|
| - Background support
|
| - Bluetooth
|
| - WiFi
|
| - Better notifications
|
| - etc.
|
| Sure there will always be a need for native, but 99% of apps
| don't need any of that stuff, really. Though I suppose both Apple
| and Google have an inherent interest to gatekeep.
|
| Looking at my own most used apps:
|
| - Messenger
|
| - Mail
|
| - White Noise
|
| - Teams
|
| - Google Maps
|
| Literally all of them could be implemented as responsive pages
| with acceptable performance. There are a small number of
| companies that don't bother with mobile apps, Craigslist being
| the most notable of them until a few months ago. Part of the
| issue though is that the app stores give you a lot of visibility
| and to get that visibility you need to be in the app store. Sure
| you can use a web view, but in some ways that's even worse than
| just a responsive website because now you have to deal with the
| abstraction of your site that is a WebView. Not to mention the
| temptation to try for "best of both worlds".
| rayiner wrote:
| Users hate web apps, especially on mobile, and it has nothing
| to do with functionality. Web apps on the App Store invariably
| provoke angry screeds about how the look and feel is not right.
|
| Native apps are even more essential on mobile. On the desktop,
| web apps just look weird and waste battery life. On mobile,
| they _feel wrong._ That difference in feel provokes visceral
| hatred.
| WA wrote:
| No. Designers and some devs hate web apps for minuscule
| reasons your average user doesn't care about and doesn't
| notice at all.
|
| If an app helps them to get a task done, it simply doesn't
| matter if the thing is native or not. At least, if you use a
| somewhat reasonable UI approach like Ionic.
| namibj wrote:
| > Users hate web apps, especially on mobile, and it has
| nothing to do with functionality. Web apps on the App Store
| invariably provoke angry screeds about how the look and feel
| is not right.
|
| > Native apps are even more essential on mobile. On the
| desktop, web apps just look weird and waste battery life. On
| mobile, they feel wrong. That difference in feel provokes
| visceral hatred.
|
| They don't have to waste battery life. This is mostly due to
| poor coding/architecture, instead of "web". Especially with
| WebGl and Wasm.
| JamesSwift wrote:
| Messenger, Mail, and Teams would be absolutely crippled without
| background support and notifications. Maps would be somewhat
| viable, and I'm not familiar with White Noise.
|
| Also, 'native parity' is a moving goalpost. At the point you
| get support for all those things across all platforms, what
| else has been added to native that you are now missing?
|
| This isn't even considering the fact that there is no incentive
| for apple to play nicely without an anti-trust ruling against
| them.
| TheAdamAndChe wrote:
| Progressive web apps can already receive notifications.
| JamesSwift wrote:
| iOS supports push notifications in a PWA context? Thats
| news to me.
| NickBusey wrote:
| I was really impressed recently by Wealthfront's mobile site.
| It's so good and fast, they don't even push you to download
| their native app. You just don't need it when the website works
| that well on mobile.
| jakub_g wrote:
| Monetization. Native apps provide app & in-app purchases
| seamlessly integrated in the platform. Web payment solutions
| are clumsy in comparison. Sure, there are new APIs that ask for
| CC number, holder etc. to be prefilled but the friction is
| still not at the same level IMO.
|
| You need to pay the cut to Apple/Google but in certain
| scenarios it's preferable than asking for payment details.
| scarface74 wrote:
| Seeing that the only apps that make money for either Google or
| Apple are mostly games with in app purchases, they wouldn't be
| appropriate for web apps anyway.
| pastor_elm wrote:
| Shopify's growth model relies on bringing people into an app
| dependent ecosystem. They're not looking to be a one app
| company. They want users to locked into having many Shopify
| apps. When people are using mobile sites, the sense of
| dependency just isn't there. Not to mention it feels terribly
| inconvenient and the tracking can be stymied.
| xenihn wrote:
| The fact that Facebook themselves will never be able to replace
| their native iOS and Android apps with RN implementations says
| it all imo.
| apl002 wrote:
| this is the dumbest take on here. You think that because
| Facebook hasn't rewrote their apps in RN that RN must suck?
| What kind of evaluation for software is that.
|
| They haven't rewrote in RN because it's unnecessary. Its not
| worth the engineering resources. There is so many things on
| the global product roadmap to build then rewrite something
| that already exists and works fine.
|
| Like all software, RN is great for certain use cases. Just
| because someone isn't using it for X doesn't mean it also
| sucks for Y.
| htormey wrote:
| React Native is widely used in both Instagram and the main
| Facebook app (market places). It's also used in a number of
| other apps they make (oculus, ads manager).
| EugeneOZ wrote:
| It just says that web apps can't steal enough data from your
| phone.
| xenihn wrote:
| But RN apps are not web apps...?
| bonestamp2 wrote:
| Tricky question. They start as web apps since they're
| built with mostly web technologies, but then they're
| compiled as native apps with native components and they
| don't run in the browser. So, I'd lean towards "no" --
| they're not web apps at runtime.
| robertoandred wrote:
| React Native apps do not use web technologies.
| bonestamp2 wrote:
| I guess we can agree to disagree -- I consider JavaScript
| a web technology.
| solarkraft wrote:
| That depends on what you include in your definition of
| web technologies. React and Javascript at this point
| mostly fall under mine.
| john_alan wrote:
| non-native never feels the same. fuck web apps.
| rolltiide wrote:
| I thought that native mobile would be out 4 years ago and not
| much has changed, my only conclusion now is that I don't want
| to do android/ios apps for startups, but I'll do it for large
| organizations that are actually leveraging all the technology.
| hotgeart wrote:
| Ads and Exposure.
|
| Ads: Make a native app and a PWA, put a banner at the bottom.
| You'll get more from the native app.
|
| Exposure: I made some stupid apps and without any SEO I get
| 10K-50K installs, you can't get that with a PWA and Google
| Search.
|
| I'm 100% for PWA because I can't take anymore monopole shit
| from google play and his rules, but that's the reality.
| rajasimon wrote:
| I thought this too. You know recent TWA with PWA makes the
| website accessible with anything on the system level. Like the
| location and other information.
| duxup wrote:
| I just wish with PWAs ... there was some more love as far as
| how they're handled.
|
| Last time I looked at them it was really wonky to install a
| PWA from Chrome.
|
| Developer advocacy at the time from Google was big on PWAs,
| but they were second class citizens everywhere in Google
| land....
| untog wrote:
| You can now wrap a PWA up as a TWA (Trusted Web Activity)
| and publish it to the Play Store, which should make a huge
| difference.
| duxup wrote:
| OH TIL that. That's good, showing up on the Play Store
| was kinda random benchmark I was looking for.
| pjmlp wrote:
| They are first class on UWP since Microsoft decided to drop
| WinJS in favour of PWAs.
|
| It is also one of the ways they are pushing for cross
| platform development on their upcoming foldable devices
| (Other being React Native and Xamarin, depending where one
| is coming from).
| duxup wrote:
| Yeah I really liked MS's support that way.
| ricketycricket wrote:
| > What's missing until regular websites have parity with mobile
| apps in functionality?
|
| The desire to build web apps instead of mobile apps.
|
| > Literally all of them could be implemented as responsive
| pages with acceptable performance.
|
| Exactly. It's not a technical issue as much as an issue of
| focus/interest. Unfortunately, this has been a losing battle
| since 2008.
| newfeatureok wrote:
| > Exactly. It's not a technical issue as much as an issue of
| focus/interest. Unfortunately, this has been a losing battle
| since 2008.
|
| This is true, but there are a lot of features missing from a
| responsive site that apps have. Of course, I'd argue that all
| of the missing functionality can easily be added to Safari
| and Chrome (to name the big two mobile browsers).
| carierx1 wrote:
| Running a UI within a virtual machine is the stupidest idea
| ever.
| pier25 wrote:
| Another feature lacking in the mobile web are touch gestures.
|
| I'm facing this problem right now and the best option for
| recognizing gestures seems to be HammerJS which adds 7.5kB
| gzipped to your app.
|
| After that your app still needs to react kinetically (eg: the
| image moves while dragging it to the left and then the view
| transitions to the next image). It's a lot of code that needs
| to be shipped in the JS bundle.
|
| BTW if you have a better solution than HammerJS please comment
| here:
|
| https://news.ycombinator.com/item?id=22184079
| deepGem wrote:
| I feel quite the opposite, most of the phone apps will likely
| to be thick client variants of the web apps, given that the
| hosts have so much power and storage available. Privacy
| concerns are gonna force this model where almost every activity
| having minimal network overhead. We are going back to the
| desktop app era, is what I feel.
| na85 wrote:
| > We are going back to the desktop app era, is what I feel.
|
| Can't wait, to be honest. This era of everything as a service
| is great for developer convenience but is incredibly user-
| hostile in that it enables and encourages surveillance
| capitalism and the erosion of privacy.
| tempsy wrote:
| No mobile website has match the performance of native though
| [deleted]
| scarface74 wrote:
| Mail is the last thing I want as a web app. I don't use web
| mail on my PC. I definitely wouldn't want to use it on my
| phone.
|
| Maps is also much more responsive even on older phones than it
| is on a web page on a modern PC.
| phreack wrote:
| It can't be overstated how many apps are absolutely dependent
| on working push notifications (all chat for example) and can't
| be replicated as websites. And that's not yet implemented for
| iOS so we're all at Apple's mercy until it is, which may never
| be.
| pennaMan wrote:
| Apple will never give in and implement webpush on mobile
| safari because that would affect their precious app store.
| How will they extort developers then? That's also the reason
| mobile safari is so limited in other features.
| scarface74 wrote:
| You mean extort developers who are mostly publishing free
| apps backed by services or advertising?
|
| How many apps do you use on a daily basis that you paid
| money for, find notifications useful, and would have been
| suitable as a web app?
| [deleted]
| jammygit wrote:
| I can't stand push notifications, I disable them all except
| for a couple (like signal). They are usually only part of the
| app to manipulate you into using it constantly
| Normal_gaussian wrote:
| several applications require them to be useful. Security
| events from my home cameras, messages from clients, timers,
| email
|
| Anytime I'm using a peice of small business software I'd
| probably like it to be able to give me notifications
| beefield wrote:
| Honestly curious and hopefully not rude, but how can you
| concentrate on anything? Or does your work/life not
| require you to concentrate ever/most of the time on
| anything?
|
| (I have turned all but phone call and sms notifications
| off on my phone. I will check my email/whatsapp when I
| want and see notifications there as needed. If someone
| has something urgent, they know how to call.)
| Normal_gaussian wrote:
| Simply, it doesn't affect me adversely at all. I think
| you have a misunderstanding as to how many notifications
| are generated.
|
| Today I received:
|
| * 3 reminders to eat
|
| * 1 security alert (delivery)
|
| * about two dozen instant messages between myself and
| clients
|
| * a couple of dozen CI alerts
|
| * 3 emails
|
| Its easy to have different levels of notifications, and
| filter message channels. I have less distraction now than
| I had in an office by several orders of magnitude.
|
| Everything is either immediately relevant or very
| important. The notifications I have make me more
| effective.
| servercobra wrote:
| What kind of reminders to eat are you getting? Like
| "don't forget to eat?" or "don't forget, this is your
| plan for lunch"?
| namibj wrote:
| I'd assume some sort of "go eat now, it's time" scheme,
| so he can stay in deep flow without neglecting his food
| intake.
| Joakal wrote:
| Not grandparent but for me:
|
| 1) only certain notifications that are important have
| unique sound, vibrate, etc.
|
| 2) other semi important notifications flash. Light is not
| that bright to notice.
|
| 3) other notifications have numbers on app so there are
| some despite not seeing any notifications.
|
| Result: I stopped checking every hour. It's actually been
| an improvement for me to stay away from phone.
|
| I noticed that some apps abuse you for disabling
| notifications and Viber is biggest example. I don't care
| about holiday wishes or viber news but I need app to stay
| in touch with some people. Sadly, I only check at most
| once a fortnight because of this disabled notification
| nagging.
| thrwaway69 wrote:
| This is exactly what I was thinking a while ago. Most apps
| won't give you good notifications, just spam you so there
| could be an app that lets you have some good notifications
| instead of disabling them all through a filter.
|
| I never looked into whether this is possible to do on
| android or iOS. I thought it might not be given the power
| available to hijack all the notifications available.
| dmix wrote:
| What's your point? Do you think you represent most people?
| Can you not just turn it off?
|
| Notifications have fine tuned controls on both iOS and
| Android with schedule Do Not Disturb features and varying
| levels of priority (iOS has 3 tiers). Plus per-app controls
| to disable them from annoying apps, which in newer versions
| of iOS prompt you before they turn on, making them opt-in.
|
| It's essential for communication apps (texting, email) and
| useful for breaking news or a simple highlight of big news
| on WSJ/NYT on your activity feed, so you don't need to open
| either app to stay on top of big events if you're a news
| junkie like me.
|
| I'd personally go as far as saying push-notifications + the
| activity feed is very underrated feature of smart phones
| and has become a core part of people's day-to-day lives
| (which plenty of technologies can't say).
| npo9 wrote:
| > Do you think you represent most people?
|
| I've seen poor push notification quality increase
| uninstall and churn rates. I think the lesson is that
| many people are quickly annoyed with push notifications.
| zapzupnz wrote:
| I think that's inaccurate. There are plenty of push
| notifications that don't annoy people, that are often the
| primary basis for how people interact with certain apps
| -- Facebook, Messenger, WhatsApp, Slack, Discord, etc.
|
| Let's not assume that all push notifications are cynical
| attempts to get people engaged with the app or to push
| DLC. For things like mail, messaging, and plenty of other
| online services, push notifications are not just an
| important interface to the app; they can be _the_
| interface.
| buboard wrote:
| Its true that tons of news sites ask for permission just
| to spam you, or outright sell notifications to
| advertisers. I think the web notif channel has already
| been abused beyond repair. It may be time to redo the
| concept from scratch
|
| Killer feature for email: add an email header that turns
| an email to notification. Then email apps would push the
| notification to the user, bypassing apple's block.
| Websites already have the user's email, so no need for
| more subscriptions. If gmail implemented this, it might
| push for adoption
| apl002 wrote:
| I love push notifications. Its honestly how I stay up to
| date on whatever is happening. I aint got time to scroll
| through everything
| agumonkey wrote:
| are you the one exception that makes us all suffer from
| notification induced FOMO ? :)
| anderspitman wrote:
| Honest question: is there some reason you can't use standard
| web tech for push notifications? ie polling, WebSockets, etc?
| DevoAKA wrote:
| You can use polling or sockets when the browser is open;
| the problem is showing those notifications on the phone's
| lock screen or when you're in another app.
| anderspitman wrote:
| Oh duh. And it sounds like iOS doesn't support that for
| PWAs yet?
| jonny_eh wrote:
| There's no reason why a web app can't work with push
| notifications. Won't? ya. Can't? no.
| Random_Person wrote:
| The sites I build at work have proper push notifications.
| This problem has already been solved.
| berns wrote:
| How did you solve the lack of push notifications on iOS?
| xyby wrote:
| For iOS, can't you just wrap your web application in a
| thin native app layer that provides the push
| functionality?
| avip wrote:
| You can, you just can't publish it on the appstore.
| berns wrote:
| From the app store guidelines:
|
| 4.2 Minimum Functionality
|
| Your app should include features, content, and UI that
| elevate it beyond a repackaged website. If your app is
| not particularly useful, unique, or "app-like," it
| doesn't belong on the App Store.
| nicoburns wrote:
| Would push notification support not be exactly the kind
| of feature that would qualify for this rule? In practice
| there are hundreds of apps like this on the app store.
| cma wrote:
| Perhaps the main distinguishing app-like thing is
| distracting notifications.
| SlowRobotAhead wrote:
| Right! I ran in to this when I wanted our app to "portal"
| to the website and just move Bluetooth data along. Apple
| thought about this and doesn't like it.
| noir_lord wrote:
| 4.3 We'll continue to get away with this until the EU
| makes us stop.
| psaux wrote:
| They probably embedded the browser in a client.
| rubyn00bie wrote:
| I will never enable push notifications from websites. This
| problem has not been solved. It also doesn't hold across
| devices or if the browser isn't open.
| Klathmon wrote:
| While the web notification story on android is much better
| than on iOS, it still has it's own share of issues.
|
| The biggest one that i've run into is how exact timing of
| notifications is difficult. Sometimes notifications can be
| delayed for hours and there's not really much you can do to
| fix it, other times they will arrive minutes later.
|
| I previously worked on a PWA which had to be converted into a
| thinly wrapped webview for Android because we needed
| notifications to pop within seconds of their scheduled time,
| and we just couldn't achieve that with web notifications at
| the time.
| lazyier wrote:
| > Honestly I think the future of mobile will just be... mobile
| websites.
|
| This.
|
| Having to install software on my phone to use a service is
| cringy as hell and is a huge red flag for me. Like when trying
| to order food from a restaurant or shop somewhere.
|
| It's almost always going to be a automatic no. I just don't
| trust them. They always want permissions to access things on my
| phone, which is just pure nonsense.
|
| It's going to take a while for businesses to realize that in
| order to get a wide audience for the software they are paying
| for the last thing they want to do is force people to jump
| through hoops in order to use it.
|
| For every one of 'google maps' there is going to be ten
| thousand other apps that simply have no benefit from being
| 'native'.
| seemack wrote:
| I agree with the overall points, less so the pointless
| vitriol. Installing software is cringey as hell now?
|
| The main issue here isn't native apps. It's the existing
| framework for installing them.
|
| For instance, would it be that far-fetched to be able to open
| an app in a single click?
|
| Current extended process: 1) Click link that takes me to app
| store page 2) Find and click install button 3) wait 4) Click
| "open app" button
|
| Streamlined process that accomplishes the same: 1) click link
| 2) wait 3) app opens up (download/install hidden behind
| spinner)
|
| Even if you have to add a pop-up in there to display
| permission requests, it's still a much smoother experience.
|
| You'd have to worry about app sizes but that's a solveable
| problem as well.
| tadfisher wrote:
| https://developer.android.com/topic/google-play-instant
| Udik wrote:
| > Installing software is cringey as hell now?
|
| When you know that the features you're interested in can be
| made easily available by a simple web app.
| seemack wrote:
| Perhaps I'm misunderstanding the logic but doesn't that
| mean using a fancy pen is "cringey as hell" since you can
| just use a simple ballpoint pen?
|
| Sorry, it just seems unnecessarily negative to me.
| VRay wrote:
| It's like you ask someone if you can borrow their pen,
| and they say "Sure, but only if I can rifle through your
| wallet and attach this GPS tracker to you"
| Udik wrote:
| Yes, you are misunderstanding the logic. A normal web app
| doesn't need to be installed, disappears each time you
| close it, runs in a tight sandbox. Much better and
| lighter than have an app installed.
|
| Besides, I do find fancy pens cringey, but that's another
| story :)
| avip wrote:
| Offline is still a thing.
| partiallypro wrote:
| But website can be packed up and saved as PWAs, also "offline
| sites" have been a thing since the 90s.
| ojr wrote:
| Other things missing: Contacts, Device Identifier, In-app
| Purchases, and a trustworthy distribution platform with a large
| base of affluent customers.
| thespace12 wrote:
| Actually the future of the application UI is React.
| pier25 wrote:
| > Honestly I think the future of mobile will just be... mobile
| websites.
|
| Indeed.
|
| A lot of people still think that native is superior than web
| but the problem is that most websites are bloated pieces of
| crap.
|
| If anyone doubts this check the Missive email client on iOS
| which was even featured by Apple on the AppStore and runs on
| Cordova:
|
| https://medium.com/missive-app/our-dirty-little-secret-cross...
|
| (sorry for the Medium link)
| _hl_ wrote:
| > What's missing until regular websites have parity with mobile
| apps in functionality?
|
| Performance. But we're beginning to approach performance parity
| - not by the web becoming an faster, mind you, but by apps
| becoming slower. It used to be only cheap/poor-quality apps
| that felt like glorified web pages, but now even many high-
| profile apps are just parts of a web stack embedded into an
| app.
| weberc2 wrote:
| Absolutely this. Native apps are just so much smoother, and I
| say this as someone who really wants the web to win, and who
| used web apps almost exclusively because my 16GB iPhone 6 had
| very little space for apps. Also, the quality of native apps
| was much higher (e.g., Twitter feed doesn't abruptly jump all
| over on mobile) although this could just be due to more
| budget allocation into native apps for whatever reason.
| gargs wrote:
| Not just smoother, native apps done right are interactive
| at the visual element level.
| weberc2 wrote:
| Can you elaborate on this? I'm not following.
| sciprojguy wrote:
| Native iOS developer here (10 years). Knowing how to
| leverage UIKit and CoreAnimation properly can give a very
| smooth UX. SwiftUI has significantly upped the ante on
| iOS13 and future versions; it's reactive without the
| middleware layers, and it lets you get your app done
| (with live view previews) and not have to drag in a pant-
| load of external frameworks.
| axbytg wrote:
| Agreed. Map performance especially on native is night and day
| -- 60fps smooth scrolling even with React Native, vs choppy
| shitiness on the web.
| onion2k wrote:
| You make a fair point but it's one about the current state of
| apps rather than the future of apps. In the future phones
| will be more powerful and apps will do mostly the same stuff.
| In theory that should mean the apps will be faster.
| kllrnohj wrote:
| > In the future phones will be more powerful
|
| Single-core performance is largely topping out. The gains
| are incremental at best.
|
| Mobile SoCs have gone incredibly multi-core incredibly
| quickly (6-8 cores are common!). Meanwhile the web is
| incredibly bad at handling that. JavaScript code still has
| to fight with the GC for CPU time on the single thread they
| both occupy. WebWorkers are incredibly heavy & limited.
|
| WebAssembly might have threads eventually (it's on their
| roadmap), but then how long until that happens and will the
| typical webapp ever even migrate to webasm?
|
| Meanwhile CSS & DOM performance continues to be poor, so
| webapps are left in this awkward state of needing to re-
| write part of the browser.
|
| Hardware isn't fixing any of this. It's been almost a
| decade of hardware not fixing this at this point.
| pjmlp wrote:
| It depends pretty much on what the app is all about.
|
| CRUD mobile apps can be made pretty fast when not doing an
| SPA bigger than Quake just for displaying text.
|
| SSR, pure CSS3, caching, server workers, mobile first, can go
| a long way.
|
| Naturally there are other kind of apps where native wins
| hands down, e.g. WebGL vs GL ES 3.2/Vulkan/Metal/DX.
| yummybear wrote:
| It certainly possible, but there is a lot of arcane
| knowledge that goes in to the techniques listed. Native
| apps, generally, has better performance "built in".
| pjmlp wrote:
| Arcane knowledge? That is pretty basic stuff for anyone
| doing Web since the HTML 3 days.
|
| Have you ever done native Android, including using the
| NDK?
|
| It is full of arcane knowledge, scattered about commit
| comments, medium, G+ and Twitter posts from Android team
| instead of being on developer.android.com, APIs
| introduced in one IO are deprecated/replaced by the next
| IO, OEMs (cough Samsung) that change AOSP behaviours,...
| dmitriid wrote:
| Yes. Web is full of arcane knowledge. Take virtual lists
| for example:
| https://news.ycombinator.com/item?id=22186827
| hellisothers wrote:
| One thing I feel is overlooked in these discussions is WebView
| UI performance isn't as good as native. You'll always notice a
| difference scrolling a list natively vs on web. It just _feels_
| different, same goes for all the other micro-interactions if
| pushing/popping views.
| AgloeDreams wrote:
| This. And if you compare it with the very best say, iOS has
| to offer in touch interaction it's just different worlds.
| Look at the multitasking and swipe interaction on an iPad pro
| at 120Hz. You just can't even think of that world.
|
| I have a funny feeling that Apple's next big developer move
| on the iPhone is to enable those types of smooth, cancelable
| interactions out of the box in Xcode via new SwiftUI
| components just for it. When they make it easy and clear,
| people will use it and then the gap will widen.
| alexashka wrote:
| You're viewing it through the lens of a developer.
|
| The user wants the best experience. Because software costs 0$
| to distribute, the best user experience will always win out.
|
| The future of all software is faster, better software. Websites
| are shitty, arcane technology - the opposite of the future.
| rchaud wrote:
| If a website is popular and does the basics well, it doesn't
| matter how 'shitty' the technology is.
|
| Amazon.com has easily the most hideously designed product
| pages out there. Because sellers can "customize" the product
| page, you get their content (usually hero images with tiny
| text) mixed in with text-only product details, "users also
| bought" carousels, Q&A and Reviews all jammed together.
|
| And they're still doing better than most large ecommerce
| stores (Walmart, Best Buy etc.) because the stuff that
| matters (pricing, delivery time) is better than the
| competition.
|
| Switching to the Amazon app doesn't fix any of these problems
| because it's primarily a content and UX issue.
| solarkraft wrote:
| Of course if a store is just plain cheaper and over all
| quality wise better, it it's not that important that it
| looks hideous and abandoned. But to some people it matters.
| And if two stores provide the same product at the same
| price, I think I'll prefer the one that looks nicer.
|
| It doesn't decide everything, but it's pretty certainly a
| factor (although Amazon must have determined that it's a
| small one to them, as they are still micro-optimizing for
| other page-related aspects like loading speed).
| carierx1 wrote:
| The web is truly a horrible user experience. Thankfully the
| its dying and native apps will prosper.
| hombre_fatal wrote:
| I don't know, I get to use uBlock when I use web apps and I
| have some control over the client even on my phone. Native
| apps can basically do whatever they want and users are waking
| up to this.
|
| I would like all of my applications to be sandboxed by a
| browser I have control over.
| EthanHeilman wrote:
| >Literally all of them could be implemented as responsive pages
| with acceptable performance.
|
| Speaking personally I like the division between highly
| sandboxed websites (no GPS access, no notifications, etc...)
| and trusted apps.
| brlewis wrote:
| This is only because the trust given to apps is insane. No
| distinction between foreground GPS and background GPS? Sure,
| I wouldn't want web sites to work that way either. But if
| permissions were sane there would be no reason not to have
| native apps and web apps ask for the same permissions in the
| same way.
| scarface74 wrote:
| There has been a distinction between the two on iOS for at
| least two years.
| EthanHeilman wrote:
| I don't ever want to give a website access to microphone
| because someone could turn it on via an XSS. Websites on
| the whole seem to be far more vulnerable than mobile apps
| because:
|
| 1. their code is refreshed on every load,
|
| 2. their software is often updated on a daily if not hourly
| basis,
|
| 3. they will often pull code from remote sources on every
| page load,
|
| 4. they don't even have to pass the minimal review and code
| signing of an app store,
|
| 5. and it is very likely that they are written in
| javascript.
|
| I agree with your general point that better permissions
| would improve the situation. For instance asking each time
| it wants to use the microphone, rather than an approve once
| model.
| [deleted]
| ohadron wrote:
| Technically, and from user experience point of view, this makes
| perfect sense. Native apps are rarely actually needed.
|
| However, Apple is making a huge pile of money out of app store
| sales, and it has huge leverage as long as the 'app' model
| lives on. They are strong enough to prevent this from
| happening.
|
| Ever ask yourself why mobile iOS web doesn't support push
| notifications like Android does? It's because that will be a
| shift in the wrong direction from Apple's standpoint.
| scarface74 wrote:
| As I asked before, which apps have you paid for, that would
| have been better as a web app, and that needed push
| notifications?
| reaperducer wrote:
| _Honestly I think the future of mobile will just be... mobile
| websites._
|
| That was Steve Jobs' original vision for the iPhone.
|
| The difficulty was that once the App Store launched, people and
| middle managers thought that if a company didn't have an "app,"
| it wasn't a real company.
|
| Now that the web has matured, there are not that many things
| outside of games that require an app. But there are still many
| people (including many in my own company) that think an "app"
| adds credibility to a company, even if that app does less than
| the web site.
| solarkraft wrote:
| > What's missing until regular websites have parity with mobile
| apps in functionality?
|
| Performance.
|
| > Literally all of them could be implemented as responsive
| pages with acceptable performance
|
| But not with great performance. A user feels the slight
| stutters, glitches and slow-downs.
| divbzero wrote:
| Ten years ago Facebook fought this battle and lost. [1] [2] [3]
|
| [1]: https://www.facebook.com/notes/facebook-engineering/using-
| ht... "Using HTML5 Today"
|
| [2]:
| https://appleinsider.com/articles/12/09/11/facebook_admits_h...
| "Facebook admits HTML5 not competitive with Cocoa Touch"
|
| [3]: https://techcrunch.com/2012/12/13/facebook-android-faster/
| "Facebook Speeds Up Android App By Ditching HTML5 And
| Rebuilding It Natively Just Like The iOS Version"
|
| I have always rooted for mobile web apps, but the lack of
| feature parity and distribution challenge ("Add to Home
| Screen") puts them at a constant disadvantage and companies who
| control mobile OS's have little incentive to change this.
| carlosdp wrote:
| In re: distribution challenge, PWAs can already be published
| to the Google Play store.
| marvindanig wrote:
| Yeah, and those are called TWAs-as in Trusted Web
| Activities. As much as I dislike Google in general, they
| have been good at bringing web development and native apps
| closer than ever.
| koheripbal wrote:
| It strikes me that, more than anything, it is the lack of an
| efficient "Add to Home Screen" flow, that has doomed mobile
| websites.
|
| ...and it's intentional. By having an app store, mobile OS
| distributors know that they have control over a massive
| revenue stream.
| scarface74 wrote:
| There has been an add to home screen shortcut on iOS since
| day 1.
| bostik wrote:
| A good part of it is their absolutely _massive_ 30% cut.
| The only reason they get away with it is that when Apple 's
| app store first came out, most of the online casual
| applications were games. Hosted by a few gargantuan
| aggregators ( _cough_ newgrounds _cough_ ) who charged 70%+
| of the revenue for their ... service.
|
| Against a backdrop of above-criminal-rates extortion, 30%
| must have looked like a bargain.
|
| To put these numbers in context, very good agents get 15%.
| tombert wrote:
| Forgive me a bit, since I haven't been on Newgrounds
| since before the iPhone came out, but did Newgrounds ever
| charge to host on their site? Did they allow you to
| monetize your games?
| grawprog wrote:
| https://www.newgrounds.com/wiki/creator-
| resources/monetizati...
| scarface74 wrote:
| Most of the money being made on the App Store is for in
| app consumables from pay to win games. You'll have to
| forgive me for not shedding a tear for them. I hope Apple
| Arcade takes a huge chunk of their revenue.
|
| It's not indy developers trying to make a living.
|
| The other types of apps that use to make Apple a lot of
| money are streaming services. But most of those are now
| not allowing you to do in app purchases.
|
| I'm looking through all of my apps, and I only have two
| or three that I actually paid money via in app purchases
| and those were to turn off ads.
|
| All of the rest I had to buy subscriptions on the app
| makers websites or buy content in the case of Amazon for
| Kindle books.
| dessant wrote:
| Though we _should_ shed some tears for those who just try
| to sell their apps and make a living, after already being
| ripped off for expensive equipment and an annual
| developer account fee.
|
| If Apple would care, it would be possible to charge a
| smaller commission based on the app category, and to
| vaive annual developer account fees for verified open
| source developers.
| rbrtl wrote:
| Apple gear is no longer as comparatively expensive as it
| used to be -- they aren't ripping you off, they have put
| a lot of work into delivering different 'gear' to what's
| available in the rest of the market. Shed a tear for
| people who buy HP and need a new laptop every year or
| two. I'm typing this on a 7-year old MacBook Pro, which
| works better than the day I bought it.
|
| Hosting an app marketplace is not a free endeavour
| either. They host infrastructure to facilitate all of
| this, and they review app code in an attempt to prevent
| malware being distributed by underhanded developers.
| Maybe they could vary the price based on the use case,
| but why should they? No one is compelled to publish on
| the App Store, why complicate their business model to
| give themselves more work for less money.
| bsaul wrote:
| As a developer of a pro app in a niche market trying to
| make a living on the app store, i can tell you those 30%
| are what prevents me from working full time on my app.
| marvindanig wrote:
| Oh, 100%!
|
| It is absolutely intentional that iOS Safari on iPhones
| does not have support for fullscreen api, for example,
| whereas both WatchOS (somewhat) and iPadOS do. Apple is
| quite anti-competitive when it comes to letting web apps
| utilize the full potential of modern web standards.
|
| And they often use "industry advocates" driven psy-op
| tactics to manoeuvre public opinion such as the following:
|
| [1] https://stackoverflow.com/questions/49589861/is-there-
| a-non-...
| jollins wrote:
| As you said yourself though, this was 10 years ago.
| Steltek wrote:
| Didn't Facebook also want native app access so they could
| work around OS limits like background processing via shady
| stuff like leaving the microphone on? I prefer webapps for
| security reasons because of Facebook's checkered history with
| native apps.
| scarface74 wrote:
| But what happens if Apple or Google gives web apps more of
| the capabilities of native apps?
| [deleted]
| GrumpyNl wrote:
| Why does everybody think they have to build at the scale of
| Fb. Most of the apps will do perfectly fine when they are web
| based.
| reaperducer wrote:
| _Ten years ago Facebook fought this battle and lost._
|
| That was ten years ago. Phones and web sites have changed a
| lot since 2010.
|
| If the battle was re-fought today, I'm not sure the winner
| would be all that clear.
| globuous wrote:
| [2] is from 2012 though, almost a decade ago. The web has
| come a long way since, and in five years to a decade could be
| competitive. With wasm and webgpu and what not. And as of
| today, i dont think the mobile web interfaces for fb and
| messenger are particularly worse than their native
| counterparts. They save me the notifications actually...
| muxator wrote:
| The web post-wasm could be a whole different beast from
| what the web was originally supposed to be.
|
| Not that the current situation is idyllic, but I fear a
| post-wasm web would be even more opaque and less
| inspectable.
| dmitriid wrote:
| > The web has come a long way since, and in five years to a
| decade could be competitive.
|
| The web is always 5 to 10 years away from being
| competitive.
|
| Meanwhile Twitter struggled to implement such a trivial
| thing as a virtual list on the web:
| https://grumpy.website/post/0RQvmdNmN
|
| It took them almost a year after the resign to fix most of
| these issues. While breaking or half-breaking functionality
| for almost everything else.
|
| And that's for a website that's nothing but text and
| pictures. I wouldn't he my breath waiting for web to be
| competitive.
| protonfish wrote:
| It makes sense that a company with a business model based on
| mining and selling personal data would not find mobile web to
| be acceptable - too many privacy and security protections
| that can be eschewed on native. For the same reasons,
| consumers should choose HTML.
| troquerre wrote:
| The power of websites is that they run cross-platform. If your
| website works on chrome on windows it'll work (for the most
| part) on Firefox on Mac and safari on iOS. Apple is against
| this philosophically because it doesn't take advantage of the
| unique capabilities their devices provide. It's the same reason
| why Apple stopped supporting flash
| https://www.apple.com/hotnews/thoughts-on-flash/
| scarface74 wrote:
| That's not true.
|
| Back in 2007, Adobe claimed that they could get Flash working
| on the original iPhone if Apple had allowed them.
|
| When they finally got it to run on Android years later, it
| required a 1Ghz processor and 1GB of RAM and it still barely
| ran and was horrible on battery life. The original iPhone had
| 128Mb of RAM and a 400Mhz processor. It wasn't until around
| 2011 when there was an iPhone that met those specs.
|
| Adobe was always late delivering Flash on mobile from Android
| phones and Palm phones.
|
| It was so bad, that the Motorola Xoom was advertised to be
| able to browse the "real Internet" because it could support
| Flash. At launch it didn't. Leaving it in the embarrassing
| position that you couldn't browse the Xoom advertising page
| that required Flash on a Xoom.
| troquerre wrote:
| Supporting all of Apple's functionality was one of the
| reasons for not supporting Flash that Steve shared in his
| post, but I think you're right that Adobe not being able to
| get Flash working on iPhone was the main reason. Thanks for
| the correction!
| pier25 wrote:
| This.
|
| I developed a number of Air mobile apps back in 2012-2014
| and all the blame is on Adobe. Flash was extremely
| inefficient and Adobe didn't want to invest the necessary
| resources to properly bring it to the mobile world.
|
| Adobe cancelled AS4 (aka Flash Next) which would have made
| Air a very competitive crossplatform solution. They shifted
| all its resources into HTML5 to throw a bone to the Flash
| community and it was a complete failure.
|
| https://insights.stackoverflow.com/trends?tags=actionscript
| -...
|
| Don't get me wrong, it probably made economical sense for
| Adobe but it was a shame.
| dnh44 wrote:
| Also flash player on the Mac was terrible and consumed a
| lot of energy. I'm not surprised Apple didn't want it on
| iOS.
| pier25 wrote:
| Truth is even if Apple had wanted to bring it to iOS it
| didn't really have a choice. Users would have blamed
| Apple for the low battery time.
| ridiculous_fish wrote:
| Native controls can afford to be richer (in principal) because
| knowledge transfers across apps. Websites do not enable such
| transfer: there's too much of a culture of customizing
| everything. On mobile the problem is somewhat less noticeable
| because rich native interaction models haven't really emerged.
| pier25 wrote:
| Good point.
|
| In the mobile and desktop world devs are totally fine with
| using native GUIs that ship with the OS (even encouraged to
| do so) but in the web world projects are criticized for using
| libraries like Bootstrap and devs and designers are expected
| to reinvent the wheel every time. Also don't use a native
| alert or you will condemned to hell.
| kitsunesoba wrote:
| Only if mobile web can jump the hurdle of feel. Even the best
| mobile web apps still feel kinda clunky/laggy in subtle ways
| that the average native app doesn't.
|
| It's actually pretty comparable to the situation with desktop
| Linux where the gaps between the layers are subtly perceptible,
| which leads to a sort of slipshod/duct tape impression that
| isn't great.
| wayne_skylar wrote:
| This is the right answer. You've got the web paradigm of the
| nav bar showing up when you scroll up (among other oddities).
| I think it would be very easy to have a mobile browser
| extension to show pages full screen in a special
| interactivity mode to make most mobile apps work on the web.
| partiallypro wrote:
| A lot of native apps feel clunky because they are poorly
| coded and thought out. As OP said, 90% of cases are where
| companies don't need native apps, because they simply don't
| require that performance level or permission set.
| jszymborski wrote:
| It's times like this where it becomes painfully clear that
| FirefoxOS was (1) ahead of its time and (2) woefully poorly
| managed.
| pjmlp wrote:
| Actually Symbian Web Runtime and WebOS were ahead of their
| time.
| wpietri wrote:
| I'd believe you for some of those apps. But definitely not for
| Google Maps. Even on their own OS and their own hardware, they
| are clearly pushing performance limits for the Google Maps app.
| And have been for years.
|
| I think you're definitely right about gatekeeping, though.
| Apple's app store gross revenue is ~$50 billion/year. That's an
| incredible incentive to make sure that web apps will never be
| as good.
| api wrote:
| I'm convinced that the long-term future of all UI development
| is web based, at least at the rendering layer. WASM may free us
| from JavaScript.
| goatlover wrote:
| IS WASM canvas-based or HTML/CSS? Because canvas is not what
| comes to mind when thinking in terms of Web UI.
| api wrote:
| WASM can access the DOM. Check out this:
|
| https://github.com/gopherjs/vecty
|
| Like React but in Go. Not quite mature yet but getting
| there.
| buboard wrote:
| I m a web fanatic and use only the browser. My other apps are
| dropbox and skype , a decibel meter and strava, so things that
| cant exist on the web anyway. I use multiple gmail accounts so
| webmail is better
|
| Since most content apps use browser links at some point it
| doesn't even make sense to e.g. have a twitter app
|
| Now, i wish we could have a better api than web push
| notifications though
| cletus wrote:
| Apps are dominant on web because, well, the web sucks. We can
| gloss over this on desktop because of raw processing power but
| still, layout if html is just plain terrible.
|
| Of course mobile processors will continue to improve but on
| mobile you're making a trade off between performance and
| battery life and battery life will probably never be not a
| concern.
| pier25 wrote:
| The mobile web sucks because of ads and bloated websites not
| because some inherent technological flaw.
| privateSFacct wrote:
| Look at your most used apps - none of them are "responsive
| pages". That should tell you something. Folks who have tried
| responsive pages haven't done that well.
|
| I am curious - what is the most popular responsive webpage on
| iphone would people say? I'd like to check out the current
| leader in this space.
| aantix wrote:
| Because once a company is invested in the native side, they
| probably aren't going to look at greenfield solutions anytime
| soon?
|
| If you're considering building a new app, a responsive site
| with JS is definitely a contender. Take a look at the
| performance numbers.
| https://twitter.com/dhh/status/1174802413548474368
|
| And they're only increasing, making it a more viable choice
| with each year passing.
| hopia wrote:
| Google?
| akmarinov wrote:
| I use Facebook's as I don't want Facebook's grubby hands
| using private APIs on my phone to get every bit of data they
| can. At least the browser limits them.
| edgyquant wrote:
| Plus the facebook app eats battery life. IME my phone
| battery lasts all day unless I install facebook: then it
| lasts a few hours.
| newfeatureok wrote:
| None of my most used apps are responsive pages because Safari
| neuters the functionality.
|
| - White Noise -> Safari can't play background sounds once
| closed.
|
| - Messenger -> Notification trouble, not to mention Facebook
| won't let you use the mobile version of Messenger without a
| lot of effort.
|
| - Google Maps -> Close, but a lot of the functionality, like
| reminders require notifications which isn't up-to-par with
| just Safari
|
| - Teams -> See messenger.
| j2bax wrote:
| Apple does some fairly beautiful responsive webpages...
| Albeit rather heavy! https://www.apple.com/apple-arcade/
| jayd16 wrote:
| Whats the slack app written in?
| philshem wrote:
| Desktop apps are (in)famously Electron.js
|
| iOS is native:
| https://twitter.com/SlackHQ/status/931599784137363459?s=20
|
| Android is native, too (no source)
| jamil7 wrote:
| The iOS app is native UIKit I believe.
| wpietri wrote:
| I haven't tried it on iOS, but Twitter's web app is quite
| good on Android/Firefox and Android/Chrome. Not quite as good
| as native, and prone to developing lag if I don't
| occasionally restart the browser. But surprisingly good.
|
| They talk about the process of building it here:
| https://blog.twitter.com/engineering/en_us/topics/open-
| sourc...
| AgloeDreams wrote:
| I tried it, it's pretty close honestly, but the performance
| just feels off and it does weird stuff all the time. The
| iOS app is just better.
| distances wrote:
| It's unusable on Firefox Focus though. Trying to expand
| anything completely breaks scrolling on the page.
| xeonoex wrote:
| I hope not. I started using flutter recently and it is by far
| the best development experience I've had creating anything with
| a UI. Easy to install (even on windows), build, stateful hot
| reload, and the code is easy to read and write. No
| HTML/CSS/JavaScript.
|
| I know web devs probably don't agree, but HTML and CSS weren't
| designed to build responsive, interactive applications, and all
| that has to be done to make it work makes it a pain in the ass
| to setup and develop. With stuff like WASM, Flutter, and
| Blazor, I'm hoping we have viable alternatives to traditional
| web development.
| ENGNR wrote:
| The biggest feature I'd like parity on for mobile web.... is
| logins.
|
| As the tracking war rages, humble little login cookies are
| becoming a casualty. For example if someone gets a
| transactional email (say a new booking notification), opens it
| on their iphone, it opens safari.... in a new context. No
| login! So frustrating for them. You can send tokens with the
| links, but they really need to have an expiry date on them, and
| if the user forwards the email it risks exposing their whole
| account. So now you have to start playing with an intermediate
| 'sort of logged in but don't let them do anything too
| dangerous' state
|
| And now browsers are using "AI" to magically work out which
| cookies to delete. That's great, but.. can we not have an
| explicit UX for the user to say hey, this is a login cookie,
| I'm logged in because I want to see my data and be authorized
| on this website every single time I come here (and an equally
| special logout function that deletes it without trouble).
|
| I'm a pretty heavy user of mobile web and rarely use apps, but
| logins for power users and tech impaired users is pretty much
| the main reason we're looking at react-native too
| JamesSwift wrote:
| Theres native platform support for that now with shared login
| context between browsers and apps.
|
| e.g. https://developer.apple.com/documentation/authentication
| serv...
| ENGNR wrote:
| If I'm reading it right that's for if you control the app
| though. They still lose login if they follow a link from a
| mail client or slack app over to a mobile web app, which
| wouldn't happen if they were going to an actual app
| AgloeDreams wrote:
| > acceptable performance
|
| Until your competitor shows up. I think you are honestly right
| for the most cases, but the expectation on mobile, (esp. since
| the OS is written in native and 120Hz screens are coming) is so
| freaking high. The touch response rate expected is just going
| to make hybrid and web apps just seem like trash to the average
| consumer when compared directly with native apps. They just
| don't do it and just don't feel right.
| kllrnohj wrote:
| > esp. since the OS is written in native and 120Hz screens
| are coming
|
| High-refresh rate mobile displays already happened. There's
| more 90Hz than 120Hz on the market at the moment. Typically
| gamer-focused phones like the Asus ROG Phone or the Razer
| Phone, but non-gamer-focused flagships are also now 90Hz like
| the Pixel 4.
|
| And of course on the iOS side of the ecosystem some iPad
| models already have 120hz displays, too.
| hugey010 wrote:
| I thought the cool thing to do was declare React Native dead for
| your org, not the new hotness?!?
|
| I try to re-evaluate my opinion of the mobile ecosystem monthly,
| and would love to know how people agree / disagree with my
| rankings:
|
| 1. Just make a web page
|
| 2. Native iOS & Android
|
| 3. Flutter
|
| 4. Some ordering of remaining cross-platform tools depending on
| requirements. (React Native, Vue Native, Xamarin, Ionic,
| Titanium, PhoneGap, Kony...)
| trevyn wrote:
| Really depends on what you're making.
|
| Personally, I find RN much more productive than native iOS, for
| the areas where it is applicable. The hot reload is quite
| magical.
|
| Also, you can push JS updates without needing to update the app
| in the store, which is a huge plus.
| throw_m239339 wrote:
| > 1. Just make a web page
|
| This is 100% reasonable for a lot of apps. I for instance uses
| the web version of Gmail on my phone without any issue, and
| Gmail is a complicated app.
|
| Trade-off: not easily discoverable in the store of the
| platform, harder to test because of browser differences, might
| not be as fast as a native app from a UI perspective.
|
| > 2. If your app involves persistant storage and functions that
| are not supported by web browsers, or you need optimal
| performance like games.
|
| Great performances, easy to stick to UI styles for each
| platform, access to good quality tools for testing, no, leaky
| abstraction.
|
| trade-off: unless you are using a language supported by all
| platforms (C/C++), duplicate codebase for business logic.
|
| > 3. Flutter
|
| I don't know flutter because I don't know Dart.
|
| > 4. Some ordering of remaining cross-platform tools depending
| on requirements. (React Native, Vue Native, Xamarin, Ionic,
| Titanium, PhoneGap, Kony...)
|
| Phonegap and Ionic apps are essentially webapps.
|
| trade-off: for React Native likes: leaky abstractions which
| leads to issues when not knowing the underlying platform, the
| need to write "plugins" in the native language...
| hugey010 wrote:
| _I don 't know flutter because I don't know Dart._
|
| I don't fully understand this opinion. Learning "new" things
| can be difficult, but there's little "new" in dart compared
| to other languages. Maybe you can elaborate?
|
| Installing required tools, setting up a project, including
| debugger, is just damn easy (VSCode extension FTW). Also, any
| prior experience in mobile using Kotlin, Swift, or JS,
| translates well to Flutter and therefore Dart. Bonus
| knowledge bridge for people with MVVM experience due to first
| class async Streams API and third party RxDart (following
| ReactiveX spec).
| pjmlp wrote:
| I have a different order:
|
| 1. Just make a web page (specially since many apps are just
| pretty CRUD ones)
|
| 1.1 For certain devices WebGL/WebAssembly can eventually also
| be an option
|
| 2. Native iOS & Android
|
| 3. Native iOS & Android with server side driven code for the
| business logic (maybe even UI layouts)
|
| 4. Native iOS & Android for the views with C++ for business
| logic
|
| 5. Your point .4 regarding cross-platform tools
|
| I don't have high hopes for Flutter, with Chrome and Android
| teams also pushing for their own solutions, and its dependency
| on Dart.
| hugey010 wrote:
| Totally agree with your 3 and 4.
|
| I've had, to my surprise, the most success with Flutter.
| (I've built multiple React web apps and spent way longer
| attempting React Native.)
| jamil7 wrote:
| Apollo Server and it's associated iOS and Android clients can
| make your 3rd option really easy to pull off as it generates
| your CRUD logic and model code.
| jdmg94 wrote:
| if only they could figure out their caching...
| jdmg94 wrote:
| who is using flutter for their product? something in the wild
| (production) that has a real user base?
| anon9001 wrote:
| Shopify is right to use React Native.
|
| I build an app with React Native Web and we produce
| Android/iOS/web from the same code base with 3 developers.
|
| No, it's not perfect. Yes, JS can be awkward and confusing. Yes,
| a truly native app built by expert platform-specific developers
| would be better.
|
| But I'm able to ship this product with less than half the team
| size I would need for native development. JavaScript developers
| are cheap to hire, and they don't need to know any
| objc/swift/java/kotlin to build the product.
|
| Our product is consistent, because it's the same code across
| platforms. The business people paying us to build the app are
| thrilled at how quickly we can turn around features.
|
| We've been shipping this way for 2 years and I would strongly
| recommend it to everyone.
|
| Also, before people jump in with "But RN is slow and bloated!",
| it's actually not. The performance is just as good as truly
| native and the binary is small. The real downside is having the
| app not feel native, but only developers seem to notice.
| Pragmatically, most apps are so bad that if your Android app has
| an iOS look-and-feel nobody seems to care.
| wdb wrote:
| Don't know last time I tried React Native and wanted to use
| some cool feature of iOS. I either had to write my own RN
| plugin in Swift/ObjC or wait for someone else to do it.
| neurostimulant wrote:
| It's actually not too bad. You don't even have to put those
| native code as a separate plugin. You can simply add the
| native code directly to the generated ios/android project
| like you do a native app.
| misiti3780 wrote:
| expo is taking care of this, not there yet, but getting
| better every day.
| npo9 wrote:
| You say that like writing plugins is hard or undesirable.
| freehunter wrote:
| That's what I don't understand when people criticize
| frameworks like React Native... "I didn't like that I had
| to build 15% of the app in native code, so I ditched RN and
| now have to write 100% of the app in native code, but twice
| and in two different languages"?
| tilolebo wrote:
| React Native isn't the only abstraction out there. You
| could use Flutter, Ionic or similar.
|
| Or do they have the same issue?
| anon9001 wrote:
| They all have the same issues, but RN has the largest
| community.
| davidwparker wrote:
| Flutter has a larger number of "star" on Github. It also
| has more issues and more pull requests. React Native has
| 3x more followers on Reddit. So I guess it depends on
| your definition of community.
| harrisonjackson wrote:
| Exactly - this is native code that would need to be written
| either way, right?
| seanalltogether wrote:
| > JavaScript developers are cheap to hire, and they don't
| need to know any objc/swift/java/kotlin to build the
| product.
|
| OP is pretty much saying that.
| rhodysurf wrote:
| Thats a benefit of React Native though. Share as much code as
| possible and write wrappers for the Native features you need
| for your project. I really love the model.
| kerbs wrote:
| > with 3 developers
|
| There is a fairly large chasm between a small team and a
| Shopify, AirBnB, or Udacity. These companies have dozens-if-
| not-hundreds of developers piling on complexity.
|
| These companies don't necessarily feel the pain of building on
| somebody else's sand on day 1 or day 100, but on day 1000. This
| is what AirBnB and Udacity ultimately discovered.
| nimrody wrote:
| I'm sure Shopify has way more than 3 developers working on
| their mobile apps.
|
| They can certainly afford to have separate teams doing web, iOS
| and Android development and optimize for each environment.
| crystaldev wrote:
| > No, it's not perfect. Yes, JS can be awkward and confusing.
| Yes, a truly native app built by expert platform-specific
| developers would be better.
|
| This can't be understated. You can always tell when you've
| opened a React-Native (or similar "portable") app. It always
| feels like shit.
| anon9001 wrote:
| > It always feels like shit.
|
| Yeah, it does, to developers only. They're not the target
| market.
|
| I used to lobby for my employer to care about the latest iOS
| feature or fight over what the HIG advises is best practice.
|
| Unfortunately, most business would be perfectly happy if they
| could have a designer draw a pretty looking app and have it
| magically pop into existence. Platform features are an
| afterthought, if a thought at all. I'm not thrilled with the
| state of the app industry, but it is what it is.
|
| The really elegant solution is to have a passionate team of
| platform-specific developers pushing the boundaries of what's
| possible on a mobile device, constantly using the latest
| features and profiling for battery usage and network usage.
| Ideally a team that does this would be so proud of the code
| that it becomes open source to serve as an exemplary model of
| software engineering actualized.
|
| I know what's "right", but I also know what the market wants.
| The market wants me to churn out cross-platform CRUD apps as
| quickly and cheaply as possible.
| ksec wrote:
| >Pragmatically, most apps are so bad that if your Android app
| has an iOS look-and-feel nobody seems to care.
|
| Yes, but I not so sure if it works the other way round.
| baron816 wrote:
| > JS can be awkward and confusing.
|
| > JavaScript developers are cheap to hire
|
| There's your problem. Go hire JS devs that know what they're
| doing.
| Scarbutt wrote:
| Hiring good devs doesn't make JS less stupid, you have to
| recur to third party stuff like lodash and
| https://github.com/inspect-js to keep it tolerable.
| anon9001 wrote:
| My point is that it's not a problem. I can take someone fresh
| out of bootcamp with a basic understanding of react
| components and css and get them churning out code that works
| on 3 platforms.
| acpacp wrote:
| Good luck with that kind of project.
| bcrosby95 wrote:
| There's plenty of niches that can do well off a model
| like this. Not everyone has to be the next Google.
| "Lifestyle" business can mean hundreds of millions in
| revenue. Sometimes with just a handful of developers. And
| profit margins way higher than any big tech company.
| anon9001 wrote:
| Thanks. I've had pretty good luck so far. I would not
| want to be managing 3x the team size with 3 different
| repos to build my crappy CRUD app.
|
| Keep in mind that I'm not trying to do anything
| revolutionary here. I just work for a company that needs
| apps on the major platforms with the least effort and
| expense possible.
| throwaway55554 wrote:
| Is there an impact on battery vs true native?
| merrvk wrote:
| Pretty similar experience here. The rate at which we've been
| able to get features out the door has doubled since we switch
| from native.
| fingerlocks wrote:
| > they don't need to know any objc/swift/java/kotlin to build
| the product.
|
| I have a hard time believing this, and I've been making apps on
| both platforms for >10 years. And I _love_ react-native. My
| latest day job is basically forking popular react-native
| packages, often rewriting them in Swift, fixing numerous bugs,
| and adding features specific for our company.
|
| And all this experience has taught me that in no way can you
| expect anything but the most basic, ugly CRUD app from a JS
| dev. I have tried many times to assign "just" the cross-
| platform code to a javascript person and it never works.
|
| What do you do when there are native build errors? Xcode needs
| to be upgraded, or parts of your RN modules are deprecated?
| Gradle files need to be actively maintained. There are features
| and UI behaviors that are difficult to grok without some
| background on the individual platforms (e.g., push-
| notifications). There's also _combinations_ of packages that
| can break your app- "react-native-sound" and "react-native-
| audio", the sound and microphone packages respectively, modify
| the same singleton on iOS. Adjusting settings in one breaks the
| behavior in the other! How could a JS dev possibly hope to
| solve something like that?
| anon9001 wrote:
| I've only had to dive into the native code a handful of
| times, but I do basically make an ugly CRUD app. Most apps
| are ugly CRUD apps though. I haven't used the Shopify app,
| but it probably falls into that category too.
|
| > What do you do when there are native build errors?
|
| I periodically do suffer through xcode upgrades, bad RN
| module linking, gradle issues, etc, but it's a couple of days
| of work every few months to say current. The JS devs don't
| really have to think about this stuff for the daily work. I
| think it's totally possible to get away with one person that
| knows how to do the hard technical stuff when it crops up.
|
| That said, I don't build the most technically sophisticated
| product. The vast majority of changes we make are for
| design/marketing or for features that build on what we
| already have. I think that's true of most apps.
|
| It's not for everything, and I'm glad Firefox (for example)
| does do native Android development. I couldn't imagine that
| working with React Native. But look at the apps on any random
| phone and the ones that couldn't be made in RN is pretty
| small.
| fingerlocks wrote:
| Having one dev that knows something about the native side
| makes this very believable now. I haven't had the pleasure
| to work on a basic CRUD app that didn't also have some A/V
| or special file IO work. Your project sounds ideal for an
| exclusive react-native JS team.
| orange8 wrote:
| > And all this experience has taught me that in no way can
| you expect anything but the most basic, ugly CRUD app from a
| JS dev.
|
| > I've been making apps on both platforms for >10 years. And
| I love react-native
|
| Doesn't this make you a JS dev too? Or how exactly do you
| define JS dev?
| fingerlocks wrote:
| "JS dev" is shorthand for "JS-only dev".
|
| I made Android apps in Java and iOS apps in ObjC/Swift for
| many years. I still mostly write native code, but now I'm
| writing native code in various react-native packages.
| apl002 wrote:
| All I can is, as a RN Developer, I love it. I love being able to
| use 1 language for both app platforms. The RN community is
| amazing. Many of the comments here talking about outdated
| packages were likely burned by RNs early days when it was <0.40.
| RN has come along way since then. Its been a while since I ran
| into an issue updating packages or couldn't find a lib for
| something I needed. There is also great resources when you want
| to handroll something yourself.
|
| Migrating an existing native stack to RN might not be the answer,
| but anyone looking to get their startup off the group should
| consider RN. Its fast development and converting a React web dev
| is super easy.
| tannedNerd wrote:
| And I as a mobile native developer for both android and iOS on
| the other hand now know to skip talking with Shopify for future
| jobs as I hate RN and the performance hits and non standard UI
| it introduces. So we both win!
| tekstar wrote:
| The sad thing is, all* their tier 1 mobile apps are still
| ios/android native and are not going to be rewritten, so they
| still need native devs. But after this blog post native devs
| will be a lot harder for them to find and hire.
|
| * except for POS for Android which apparently has been
| rewritten, but not yet released, in RN.
| BharathMG12 wrote:
| We did multiple experiments on server driven UI for our mobile
| apps.
|
| 1) Using native app - Sending layouts in JSON and using Flipkart
| Proteus library in Android to render them. This only enables
| appearance changes and not behaviors. So we really didn't server
| driven LOGIC.
|
| 2) Using Flutter - Wrote the wrappers for Flutter widgets. Those
| wrappers basically just converts JSON to Flutter widgets at run
| time. And also enabled actions to be server driven. The complete
| app was made server driven using this approach. The only problem
| is, too much of abstraction in the client made the code base very
| messy and hard to reason.
|
| 3) Using React native - The biggest selling point for using react
| native is, codepush feature. We didn't have to write dumb client
| wrappers which expects JSON from server. We can just write normal
| JS code and deliver it to client devices without making app
| update. This enables really rapid experimentation for product
| features. We are currently developing this.
| ChrisMarshallNY wrote:
| I used to be a cross-platform framework skeptic _(Disclaimer: I
| have written a LOT of cross-platform, low-level code over my
| career)_.
|
| I am less of a skeptic, nowadays. I think that it makes good
| business sense for most connected apps. Also, the quality and
| stability of the frameworks has increased.
|
| It really stinks to spend two years training your team on a
| framework, only to have said framework suddenly float to the top
| of the tank, belly-up. React seems to have settled in for a long
| stay. It's kicked its shoes off, and grabbed the remote.
|
| That said, it won't affect me. I tend to write stuff that
| controls devices, so my code needs to be pretty "bare bones"
| native.
| tombert wrote:
| I keep putting off learning React Native, largely because I don't
| really do a lot with JS anymore.
|
| I know that there exists ClojureScript bindings to React-
| Native...does anyone here have any experience working with them?
| secondo wrote:
| Arguably the biggest concern with React Native is that it is
| controlled by a single entity, Facebook, and that they are not
| one of the leading mobile platforms who from a business
| perspective have strong incentives to ensure the future of their
| respective app eco systems.
|
| Facebook's incentives with React Native are somewhat unclear.
| This is a big, yet often unspoken, reason companies are vary of
| depending on React Native for their mobile stacks. With more
| large companies such as Microsoft, and now Shopify getting behind
| React Native those incentives will have to please a larger group
| and should become much more aligned with mobile developer
| communities at large - and not just Facebook's desires.
|
| If Shopify manages to play an active role in the development of
| React Native and expand the project beyond the sole control of
| Facebook then React Native will become a much more viable option
| for companies who for political reasons have refrained from using
| the technology.
| oakesm9 wrote:
| It is no longer the case that Facebook is the only major
| contributor to React Native. Facebook and Microsoft now just
| started formalising their collaboration on the project with
| monthly(ish) meetings[0]. Other large companies like Twitter
| are using React Native Web (different than ReactJS) for their
| main progressive web app[1].
|
| Other large companies using React Native are:
|
| - JD.com
|
| - Skype
|
| - Uber
|
| - Tesla
|
| - Discord
|
| You do have a point about _control_ of the React Native project
| though. That's still all with Facebook. The Github repo is
| currently setup as a mirror of part of the internal Facebook
| monorepo. Therefore, all pull requests need to be merged by a
| Facebook employee before it becomes part of "core". This is
| enough of a barrier that "non-core" part of React Native were
| split out so they could be managed and released
| independently[2]. It is also true that while other major
| companies are _using_ React Native, they might not be actively
| contributing.
|
| It would be good if Facebook put some proper structure around
| React Native as an open source project, however, for now the
| project is running along fine.
|
| [0] https://github.com/react-native-community/discussions-and-
| pr... [1] https://mobile.twitter.com/ [2]
| https://github.com/facebook/react-native/issues/23313
|
| edited: not sure how to make this list correctly formatted
| pjmlp wrote:
| Microsoft should be on that list as well.
| oakesm9 wrote:
| I missed it off as I mentioned them in the paragraph above.
| They seem to be investing more and more into React Native
| with support for Windows and using it in Office.
| pjmlp wrote:
| It is a bit more than that.
|
| They are also supporting React Native for macOS, and most
| of their teams that are in the C++ side of "C++ vs .NET"
| eternal politics seem to want to go with React Native for
| the managed layer.
| malloreon wrote:
| >>> Facebook's incentives with React Native are somewhat
| unclear
|
| I always figured this conversation happened:
|
| 1: "We have all these engineers who write javascript but users
| are switching to native apps. what do we do?"
|
| 2: "We could retrain them all."
|
| 1: "That would be expensive and time consuming."
|
| 2: "We could fire them all."
|
| 1: "Also expensive and time consuming."
|
| 2: "Wait, what if we made it so you could write native apps in
| javascript?"
| [deleted]
| zarmin wrote:
| 1: "Great idea. Which version of Electron should we use?"
| ipsum2 wrote:
| React is also controlled by Facebook, and yet is one of the
| most popular Javascript frameworks. I don't see how React
| Native would be any different.
| malloreon wrote:
| The second/third paragraphs of your comment could be
| find/replaced Shopify for Airbnb from 2-3 years ago and fit
| right in.
| draw_down wrote:
| It is interesting that React's detractors have seemingly
| abandoned technical arguments, and now it's all about how evil
| Facebook is. A while back, the argument was about how the
| license for React was scary and evil and they would steal all
| your patents, but they changed the license. So now I guess it
| has to be just FB = evil
| ameixaseca wrote:
| React Native sounds like a mistimed bet now. Maybe 3-4 years ago,
| but at this time? There are a number of better alternatives.
|
| I spent some time working on a RN project, and even though the
| whole idea of declarative interface, state update, etc is
| interesting, it is not exclusive of RN - and there is the whole
| rest of the story: RN libraries are a mess and usually buggy,
| there is virtually very little compatibility between native and
| web, and.. have anyone ever tried updating a RN codebase?
|
| I remember we had to recreate the full project and copy the files
| manually because everything was broken beyond any hope, this
| after spending a full week trying to fix the build.
|
| For Shopify seem that even a PWA could fit, and would be much
| more compatible, reliable, etc.
|
| By the way, one of their justification is "in-house know-how",
| which I heard so many times before... This is usually how you
| justify crappy decisions by using inferior technology and then
| spending 2x the effort to try to fix it. I hope it doesn't happen
| with them, but it does like like that's the way they are heading
| to.
| Androider wrote:
| It's interesting how differently you can look at things. I
| would consider the best time to start a React Native project to
| be sometime next year, and after 1.0 ideally.
|
| It's exactly when you jump on the bleeding edge that you end up
| with cuts and bruises. For every new shiny thing you'll be
| trading your current known problems for a set of unknowns and
| the inability to even Google-search for the solution. Let the
| tinkerers do the bleeding, and only once they've buffed the
| sharp parts can you as a company like Shopify start to bet on
| it.
|
| It seems module and library handling was just revamped in React
| Native (not a user myself yet, perhaps next year), so thank you
| for your sacrifice. Developers picking up RN today will
| hopefully have a smoother experience.
| bfrog wrote:
| Good luck, you'll need it
| TheMagicHorsey wrote:
| I wonder if Shopify did their homework and looked at Flutter.
| Flutter seems to meet their objectives more than React Native
| does.
|
| And as an added bonus, Flutter is easier to reason about, has
| edit and continue, and is more performant.
|
| Perhaps the use of Dart instead of Javascript was a deal killer
| though?
| Androider wrote:
| It would be pants-on-head insane for a company like Shopify to
| go all-in on Flutter. Is Flutter going to be around 10 years
| from now? Can Shopify support Flutter on their own if nobody
| else is using it 10 years from now? I don't mean that
| technically the license would allow them to, but can they in
| practice field the manpower and skills to do so across all the
| platforms they need.
| SlowRobotAhead wrote:
| I don't know much about RN or Flutter; but why is it "insane"
| that flutter cant exist in 10 years but RN will still be
| king?
|
| Why can't RN die within 10 years? Because it's been around
| since 2013 vs 2017? Because you like one more than the other?
|
| I have concerns about Google's commitment to Dart/Flutter,
| but I'm not sure one scenario is pants on head insane and the
| other just fact.
| Androider wrote:
| React Native could very well fall out of favor in the next
| 10 years, but the amount of companies using it today means
| there is a sufficient base to share the maintenance burden
| with, of which Shopify could potentially carry a large
| amount because of the significant overlap with the rest of
| their tech stack. If Google becomes disinterested in Dart,
| could Shopify step up and maintain it? Seems unlikely, and
| why on Earth would they want to, it's nowhere close to the
| rest of their competencies?
|
| If for one technology you can extrapolate from today out to
| the next several years at least, and the other's path is
| effectively entirely opaque and at the whim of another
| party, it's a company-killer level risk to bet on the
| latter. Put it this way, if Google drops Dart/Flutter
| tomorrow, Google will be just fine as they have very little
| skin in the game so to speak. Technical reasons one way or
| another are completely overshadowed by the business risks,
| as the landscape is today (which will change over the
| years, but Shopify is making their decision today).
| SlowRobotAhead wrote:
| Not to be TOO snarky but... I'm sure there are a whole
| bunch of Angular 1.0 people who said the same thing.
|
| I'm not convinced it's a worse idea to guess lottery
| numbers than to guess what will be successful languages.
| To that point however, React isn't a language (or a
| framework) it's a library.
|
| I would say Google has more to lose by dropping Dart and
| Flutter as a language and frame work than Facebook
| has/had by dropping React.
| hopia wrote:
| I don't see how it's any crazier than publicly declaring
| React Native as their future like this.
| stefano wrote:
| With React Native, you're betting on a framework. With
| Flutter, you're betting on both a framework and a new
| language. Flutter also works on a much lower level than RN,
| which means it would be harder for them to pick up the
| development if the need should arise.
| htormey wrote:
| They talk about looking at flutter in the article.
| SlowRobotAhead wrote:
| They use the word once to say "we did a deep dive". It's
| never mentioned again.
| glisom wrote:
| Good luck, lol
| xyby wrote:
| Is there a reason that the web is not a target of react native?
|
| It seems somewhat insane to have a cross platform approach and
| leave out the biggest platform of all, the web.
|
| Or - looking at it the other way round - what approaches are
| there to take a working pwa website and turn it into an app? What
| advantages over such an approach can react native bring to the
| table?
| chadlavi wrote:
| react-native-web exists: https://github.com/necolas/react-
| native-web
| hn_throwaway_99 wrote:
| Maybe you've heard of ReactJS?
| rpeden wrote:
| It is, and it's even mentioned and linked to in the article.
| harrisonjackson wrote:
| There has been a large push to support web as a target in
| react-native by expo.
|
| https://docs.expo.io/versions/latest/
|
| Depending on the complexity of your app - expo is the best
| place to start with react-native. Their managed workflows allow
| you to write in 100% javascript w/ a lot of the native
| libraries already linked an exposed in JS. If you need
| something they haven't bundled already then you can eject and
| have a good starting point.
|
| Expo web is still fairly new but they seem to have prioritized
| it as highly as support for Android and iOS.
| yesimahuman wrote:
| The Ionic team recently released React support so you can build
| a PWA using React and target iOS, Android, web, and electron.
| Uses Capacitor under the hood for full native access. It's been
| getting a lot of usage since the release:
| https://ionicframework.com/blog/announcing-ionic-react/
| WorldMaker wrote:
| Also you can use Capacitor with any PWA-style web application
| without using any of the rest of the Ionic Framework.
| https://capacitor.ionicframework.com/
|
| It's currently the best maintained successor to
| PhoneGap/Cordova.
| sandGorgon wrote:
| Anyone know where React Native stands in modern development -
| especially when compared to Flutter and the upcoming Compose.
|
| All the native frameworks are also React inspired.
|
| I personally love the work done by Airbnb for its Android MvRx
| framework. Again, React inspired
| jamil7 wrote:
| React and it's model are great. React Native on the other hand
| is leaky, heavy and you'll spend a bunch of time fiddling with
| packages, upgrading them, tracking down weird linking issues
| and ultimately writing some Objective-C / Java code to debug /
| glue / fix whatever native API you're dealing with. Thats only
| from my experience though. I would much rather the Compose /
| SwiftUI direction.
| gnusty_gnurc wrote:
| This is exactly my experience too. It's an absolute nightmare
| juggling three package managers at once.
| [deleted]
| ksec wrote:
| I wonder if that mean Rails will be moving to React Native as
| well?
|
| DHH [1] said they will reveal a major new technical direction for
| building web apps.
|
| [1] https://twitter.com/dhh/status/1214962255785119744
| Andrex wrote:
| Why was the title changed? It differs from the original
| article's, which I believed was the guideline.
| KaoruAoiShiho wrote:
| Can anyone from Shopify directly address the points brought up in
| the Airbnb posts.
| Androider wrote:
| Shopify CEO expressed his thoughts on the matter quite
| succinctly https://twitter.com/tobi/status/1222551057798090752
| KaoruAoiShiho wrote:
| Cool, though I'd argue *too succinctly. Go into it please,
| for the sake of the community.
| dmamills wrote:
| The Shopify CEO is going to be pretty disappointed when he
| finds out all of those diamonds are actually just npm audit
| fixes, dramatically out of date packages, and strange
| platform specific behavior regardless of the "write once, run
| everywhere" tagline.
___________________________________________________________________
(page generated 2020-01-29 23:00 UTC)