Can we please stop trying to Javascriptify everything? The cross-platform thing has been tried again and again and again, and always runs into the same pitfalls: poor mimicry of native standards, inefficiency, debugging difficulty because of abstraction layer built on abstraction layer, enabling developers with poor understanding of the underlying platform to make an absolute mess of an app for others to maintain later on, and so on.
I disagree entirely... I hate how an app for everything means vendor lock-in. Developers should embrace web standards and come together on making apps/tools that don't suck. I think having to write for android, ios, osx, windows, chromeos and linux sucks worse..
Apps do the same things everywhere. Why do we still need completely different languages, codebases, etc (not to mention teams of experienced hires) to deploy any little CRUD app?
Maybe we aren’t interested in fixing this because it means there’s less engineering to be done.
“It is difficult to get a man to understand something, when his salary depends on his not understanding it.”
I'd be interested in solving it, but not with Javascript.
I think it's less about engineering costs and more about dislike of javascript. Maybe even specifically javascript tooling and electron.
A big reason people want to standardize on javascript is because it is the runtime of the Web - I can't wait for Web assembly to get even better so we can standardize on something else.
Unpopular opinion time, but Apple would be wise to make JavaScript a first class language for writing Mac apps. Probably 90% of apps don’t need the raw speed of Objective C or Swift. Obviously they want to encourage people to make Mac-only apps, but even so, web technology is 100x easier to use for making Mac apps than Cocoa and Storyboards is today.
React native excels for a single use case: rapid greenfield development with limited resources. If I were a startup that simply had to support web, Android and iOS, it would be a no brainer.
Unfortunately, there is an almost religious devotion to it so it ends up used for many things it is actually terrible at (large teams, integration with large existing native apps, performance critical and highly interactive apps, apps that would be better off serving one platform, etc).
Last time I tried, what I found was missing is some guidelines on how to architecture an application. For the web, we have React, Angular and plenty of frameworks to choose from, which help having some base app skeleton to build on top of.
In Qt (QML), I couldn't quite find something like this and I had the feeling I needed to create my own framework from scratch, which is hard when, at the same time, you need to learn a new technology. There were some random ideas in various blogs and articles but nothing major or at least no officially supported one.
...note how I’ve said nothing to refute your comment because what you wrote it in responds to none of the historical empirical problems with this approach and just asserts “let’s make this not suck” glossing over the reasons why it sucks.
Every time I am required to update my web browser to support some new snowflake code I am again reminded just how wrong you are.
You are writing code that runs nowhere, unless you can afford to shell out $1000 a year to keep your hardware current and $50 a month for the bandwidth to keep your software current. That's totally unsustainable from a global perspective.
I wish I could agree with you, but those numbers are beyond silly. You think I pay $50/month for home internet access? You think any device I own is worth $1000 or purchased within the past year?
In my view, the big issue right now is Electron, and developers who are comfortable developing for 1 Google browser per application. There's enough wrong with the current browser ecosystem that we don't need to make up numbers.
I don't think you would have trouble finding $1000 msrp of web connected gizmos in any given household in the US, and less than $50 a month for intertubes is a pretty good price, so right on, good for you. Just saying, we shouldn't be in this rat race.
It may come up against the same pitfalls again and again but it has produced some of the most popular desktop + mobile apps out there because it consistently has some of the best benefits (large community, standards driven approach, lots of developers who know the language)
React Native only minimally uses native views. Rather than standard controls, they paint generic views, which still requires custom implementations and reinventing the wheel.
While React Native doesn't fully support native navigation components out of the box, there are third party libraries that interface directly with native navigation modules, e.g. https://wix.github.io/react-native-navigation. Moreover, React Native makes it easy for developers to 'drop down to' native code at any point to fully leverage native SDKs and APIs alongside their Javascript code using the NativeModules API.
It's easy to get trivial examples of native integration working, but as soon as you try more complex things it starts to break down. Code push? Oops, your native integration in old app versions just broke. Share an existing native UI library? Sorry, Yoga has its own (incompatible) thing going on. Yes, there are workarounds for all these things, but at what point does the overhead defeat the purpose?
Also, the security and performance implications of the Javascript dependency ecosystem should not be ignored.
Small greenfield app on a shoestring budget? It's perfect for that.
Although much as it pains me, I think that is a lost cause. And it was lost through attrition - devs kept throwing non-native (often, JS-based) apps at users, and users got conditioned to each app having its own look, much like websites.
I feel you. In most cases, Android and iOS's native components are superior to custom-rolled UI elements. Easier to use, more performant, and they leverage our platform muscle memory.
Fortunately, it does seem like these platforms are beginning to converge on a set of common UI patterns, e.g. Android adopting the tab bar, and iOS apps beginning to adopt Android's horizontal-paging navigation. The colors, iconography, and typography shifting can disorient somewhat, but I'd argue it's the navigation model that's most disruptive when using different apps.
It's much worse on the desktop, where we already had very detailed GUI standards, with decades of polish - and it's all getting thrown out because of the latest Electron etc fad. The upside is that Linux sees some great apps (like VS Code), but I'm not sure that's worth the cost.
Can we please stop gatekeeping our industry and embrace tools that lower barriers?
But seriously, if you're concerned about the quality of software, build better tools that guide new developers into best practices. Remove needless abstractions, replace others, and optimize the rest.
With the issues I've had with React Native, I'm keeping my eye on Flutter, great dev experience backed by a well resourced team, hope to see its ecosystem catch up.
- As another commenter mentioned, they ignore and close legitimate issues on a regular basis
- Breaking changes are a way of life and extremely frequent
- They ignore native warnings: our project had zero before introducing RN, now has hundreds
- Navigation is a mess
- Integration with existing native apps works for tiny features but falls apart in larger teams
- Debugging issues that cross the JS <> Native boundary is a nightmare
- Keeping pace with native updates is made much more difficult by the API churn- want to update to Xcode 10? First you have to update RN, which will break all your features
- Poor maintenance of views meant to mimic native views
- If you have a hybrid native/RN app, instead of reducing the platforms you have to support from 2 to 1, you've effectively increased it from 2 to 3
I agree with some of these. It's really annoying that Facebook can't figure out how to hire a dozen or so talented developers to focus on the open source side of react and try to minimize the number of warts that people in the community end up having to deal with.
While React Native is open source, Facebook does not prioritize needs that are outside of its core use cases. So many frustrating aspects of RN go unfixed by FB, and issues and PRs about them get ignored by the arrogant guy who closes issues without any explanation. Not sure how he thinks he's helping anyone by doing that.
> It's really annoying that Facebook can't figure out how to hire a dozen or so talented developers to focus on the open source side of react
Now that I think about it, I think I would actually enjoy being employed to help maintain the React Native project. I really had a lot of fun building a React Native app, but there were so many issues that didn't get any attention. It would be quite fun to spend all day helping people with issues, fixing bugs, writing tests, and merging PRs. That probably sounds like a terrible job to some other developers, but I really enjoy it, and it would be great to get paid for it.
All experiences I've had with submitting issues with repro's were all closed, basically they've closed 100's of issues indiscriminately without any attempt to investigate or resolve them. I also believe Flutter's Skia approach is superior to React Native's [1].
There's one guy on the team who aggressively closes issues. It's extremely irritating to read an issue and see that progress was being made only to have that guy make a terse comment and close the issue for no apparent reason.
Each of those issues likely wasted hours, days or weeks of time for many, many people.
Desktop compatibility is very important for Flutter adoption in my eyes. Even if only for rapid development, it is of tremendous value. Web runnability is quasi standard nowadays, too. Even if it's only for previews.
I'd love to hear more about how this differentiates from existing alternatives, namely Proton Native[1] and the NodeJS bindings to libui[2]. I am specifically interested to see how/if/when Microsoft will support Linux and macOS, as the aforementioned solutions already do.
Yes, it will be cross platform, it's all part of the move of Office to React, see this whole Twitter thread [0] from Sean Larkin:
> And here's ReactXP which is baked in to Skype (consumer) to make it possible to ship cross plat and single code base native applications with consistent UI
It's not clear to me that maintaining multiple forks of react native per environment is so much easier. And that still doesn't buy you native performance & controls. I don't really get it to be honest.
The developer who started that twitter thread massively overstated how much react was going to be used in MS Office applications because for some reason he didn't like that a college professor said that scripting languages aren't appropriate for developing an office suite. You can see in the first tweet he says that all of the office applications are being re-written in javascript, and after everyone was thoroughly dissapointed that MS would do that, other developers from MS commented here and on reddit that all of the office tools were going to stay written in C++, and react was only going to be used for some of the UI design, there was never a plan to rewrite everything in react.
Officially Office 365 includes the subscription version of the native client apps. The web apps are called Office Online. Lots of people are confused about this though, as it's confusing.
For Android, iOS and Windows 10, they build the app using React Native so it's quite lightweight. For Linux and macOS, at the moment you need Electron so it's heavier.
I don't see the point to mentioning the specs of your old PC. My first computer had 4k and a tape drive does that mean software for your PC was bloated?
I’d be more interested in knowing if someone had ported the ideas behind react in a cross platform language, rather than shipping a JavaScript engine with all your apps. Or maybe there should a JavaScript virtual machine in the OS itself.
I had the same idea: a lightweight variant of Electron, that just uses WKWebView for the GUI and JavaScriptCore for the core functionality, passing messages between them (serializing via JSON).
I have a proof of concept already, but it's not cross-platform so that's a major downside, and I don't think many people need the combination of (1) Mac-only, (2) lightweight, (3) using JS for the core logic, (4) using web views for the GUI. I just don't think there's a market for that.
Javascript is implemented on every major platform. And I do not really see download size as an issue. Many people play games, and the textures used for even a simple RPG take up more space than a javascript engine.
If people are willing to download that much for an entertainment product, then it should be no surprise they are willing to put up with javascript in their work and personal productivity apps.
I think they take issue with the bridge aspect of react-native and with shipping a node binary instead of using the platform's built-in javascript engine (a-la react-native). For instance, <View> would create either an NSView or System.Windows.Controls.Grid using a yet non-existent JS api on each platform, instead of having a bridge that talks back and forth with the platform-native language.
I think ReactXP is not a visionary project but Microsoft's approach to take advantage of javascript developers and make them able to build mobile apps for Windows phones beside indispensable platforms(Android, iOS).
Xamarin is a cross-platform solution that allows developers to create apps on iOS, Android and Windows Phone using a single code base. Xamarin apps are written in C# and XAML, allowing .NET developers to leverage their skills and experience. Xamarin apps can be more efficient than React Native apps, which are limited by JavaScript performance and the overhead of the React Native bridge. Xamarin was acquired by Microsoft in early 2016 and is supported by a dedicated team of engineers. It offers a comprehensive development solution including tools for coding, debugging, performance analysis, builds, automated testing, and distribution.
ReactXP, unlike Xamarin, provides a way to create mobile apps and web apps using the same source base. ReactXP (like React and React Native) allow experienced web developers to make use of their existing skills and knowledge. ReactXP was developed by the Skype team at Microsoft in support of their development needs. ReactXP builds upon the work of Facebook and the broader React open source community.
Both Xamarin and ReactXP are great solutions, but they solve somewhat different problems.
Hey Microsoft, when are you going to integrate Xamarin and React Native??? You are obviously fans of react, and it would be nice to have one native language (C#) for writing integration code to react native apps.
Why, though? If you don't care about the web, then Xamarin Forms is strictly superior to React Native in terms of resulting UI. And if you do, then Xamarin is not an option anyway.
It looks the project leads want more consensus on Linux React Native
(ie, something actively maintained and preferably merged to mainline React Native support): https://github.com/Microsoft/reactxp/issues/41
Then again, different platforms have different sets of hardware features, so sharing 100% of the code is usually not possible or desirable if you want to make the most of each platform.
> Share most of your code between the web, iOS, Android, and Windows
How is it better than React and React Native if it still is web+mobile+Windows and doesn't offer Linux and macOS support? Also doesn't the fact React is by Facebook and ReactXP is by Microsoft and introduces Windows support look suspicious like if they were building an incompatible version of React like they've done with Java in the past?
I'm sure this was in the works well before Safari/iOS 11 implemented the majority of the PWA standard, but can someone help me understand what the target market is for this in 2018?
We just built a ground-up PWA and users LOVE it (Android/iOS, tablet/phone/PC).
Why complicate and slow your programming + production software down by trying to XP?
What a surprise that a supposedly "cross-platform" solution from Microsoft does not support any of the competing platforms (macOS, Linux...). /s
Smells of EEE...
That name harkened back to era of Internet Explorer 6 and evoked painful related JS/CSS development memories even before realizing it's Microsoft's project :D
