React Native for Ubuntu | Hacker News Reader

React Native for Ubuntu

github.com

380 pointsbpierre138 comments

Many of the comments seem to misunderstand what react-native is, and why Ubuntu might want to do this:

React Native is a variation of React, which is a framework for building UI components. It supports stateless components and stateful components. Compared to many paradigms for designing elaborate UI, React often offers lower levels of complexity and easier to understand performance characteristics.

An ecosystem around react has built up with various approaches to data storage and data flow. This project has great potential because it means that a developer can learn one set of skills and develop native quality UI for a variety of platforms.

Try building something simple (with a few components, and perhaps redux) using react, and you'll get what's interesting about it.

Could you explain how React Native relates to React?

I've never used it and don't really know much about it but from a quick reading it seems that React is about building reusable components in HTML, CSS, and JavaScript. React Native provides bindings to native components that you'd use in Objective-C/Swift on iOS or Java on Android.

React is a conceptual framework which lays out how UIs are specified and how they behave (via the component model). Then when it comes to rendering the UI, the React framework allows several rendering targets (the classic one is React-DOM, which renders a DOM for web pages). React Native is a React renderer for iOS and Android apps.

React began targeting the browser DOM. Now, React is actually the shared library used by both react-native and react-dom.

In React (in general) you build components out of other components. Thus react-dom contains pre-defined components named after HTML dom elements. They behave like a very standards-compliant and consistent dom implementation.

So if you want to build a name badge component in React for web, you'd define a "render" method that used the dom-oriented components.

With React-Native, there was no reason to implement a component called Div. Instead, the authors created one called View. Instead of copying the browser DOM's behavior they created simple components that are fairly direct abstractions of native UI toolkit components... Things like ListView, Modal, etc. To build something using React Native, you just compose these existing components to make your own components.

Tangent: Interestingly, you can use a library called react-native-web to render React Native components in a browser, which makes it very elegant to share code between web and mobile versions of an app. There are a few differences, but it lets your pure js components designed for native work perfectly on the web, so it's actually not a bad approach for building for the web... in some cases React Native's components contain behavior you'd end up implementing for web anyway.

React Native employs the React library. It's exactly the same except instead of using "web components" to construct user interfaces such as <div> and <span> elements, we use native components. For example, the React Native "View" component maps straight onto iOS's UIView and Android's android.view.

Check out the tutorial here for some basic examples: https://facebook.github.io/react-native/docs/tutorial.html

Offtopic, just a nitpick: Is there a convention in the Ubuntu eco-system to use .ubuntu as an extension? Otherwise it would be nice to change the name of this file to something like README-ubuntu.md so that GitHub displays it as prettily as other markdown files.

The very unofficial convention is to write README.something. Indeed, it should have been README.Ubuntu.md

Personally, I like `ubuntu/README.md`, with a mention in the regular `README.md` for the Ubuntu-specific version.

This is great for GitHub, because when you go into the ubuntu/ subdirectory it shows the README in there just like it would for the repository root.

Someone has sent a pull request to do just that, so it'll probably be fixed soon. Off-topic a bit, but I'm surprised it is on github and not launchpad. Having it on launchpad would stop all this pesky collaboration ;-)

I've always wondered about who exactly prefers to use Launchpad. I've had to use it for PPAs, and it seems terrible. I feel like the median FOSS developer would see no benefit in hosting a new project on Launchpad vs. Github or anywhere else.

As I heard from a dev-ops friend whom I hold in very high regard, Launchpad is better for admins, while Github is better for developers. I wish I could recall the reasoning behind the distinction.

Personally, I've never been able to wrap my head around Launchpad, but I haven't put any significant effort toward doing so either.

It seems like if you install a package via a Launchpad PPA, you can be confident it will receive updates along with the rest of your installed packages; if it was from github, you'd have to add a cronjob to pull updates or something else along those lines, which would be more prone to (silently) fail. Though my general experience of PPAs is that they are fairly failure-prone themselves...

Mirrored on NoteHub for ease of reading: https://notehub.org/kjnvu

https://github.com/CanonicalLtd/react-native/pull/1

So iOS, Android, macOS, UWP and now Ubuntu. Awesome to see vendors like MS and Canonical jump in to bring React Native to their platform. I'm looking forward to seeing universal component sets that make it easy to develop cross-platform desktop apps.

I wrote a library, react-native-style-tachyons[0] (based on tachyons.css), which makes it easy to have at least consistent styling for react-native.

I think this is a good thing for shareable components, as they would have consistent spacing etc.

[0] https://github.com/tachyons-css/react-native-style-tachyons

I'm not really talking about styling, more about the same kind of abstraction you get for Android vs iOS: common components are exposed as the same "universal" component that will render as the specific one on each OS and OS-specific ones are instead used directly.

This was cross-platform too:

https://en.wikipedia.org/wiki/Swing_(Java)

It was also highly stateful and was unpleasant to use, neither of which are problems with React. I do mostly backend, but I do code review on all our front end code, and it really seems to be close to the right abstractions for building good UIs.

IMHO it was actually quite easy to use and had very sensible abstractions, however it failed to look good anywhere. SWT was much better in this regard (but much less fun to use).

It was straightforward to use. I wouldn't call it easy by any stretch of the imagination--you're still trapped into Java-style callbacks. It also has all the classic problems of event loop oriented frameworks, meaning you're manually managing massive state machines. IIRC there was no attempt to assist organizing the data flow across user actions except via traditional threading coordination mechanisms.

What other coordination mechanisms do you have in mind? (assuming closureless/continuationless languages like Java or C++ pre 14)

Well, I wouldn't use a closureless/continuationless language for a UI except as a platform for a higher language. This is 2016 and the lack of such primitives are absurd.

For the time, Swing was pretty good. Things have moved on and now data flow and state management are primary selling points—see things like CoreData (I'm not really aware of anything like it in other languages) or two-way binding that's prevalent in javascript libraries. This by no means solves state management but I think the primitives are easier to reason with.

What, in your opinion, made SWT less pleasant to work with than Swing?

Not in the same way though.

Swing drew and managed its own widgets using cross-platform Java.

React Native uses native widgets and drives them from cross-platform JavaScript.

I find your comment incredibly insightful.

Wonderful.

Thank you.

In that React Native is more like SWT (also not entirely joyfult to work with)

Swing is cross-platform in the sense that "HTML5" (i.e. HTML-plus-JS-plus-CSS-plus-Web APIs in a browser) is cross-platform. The "Native" part about React Native refers to React Native using native components of the operating system (like SWT, I think?).

It still doesn't work on older Windows, which seems like a glaring omission to me. Windows 7 remains the most popular version of Windows; UWP runs on Windows 10+ only.

All of the official ports of React Native are targeted at mobile or touch-first platforms. (I consider the UWP and Ubuntu ports official in that they come from Microsoft and Canonical, respectively.) Only the unofficial Mac port can truly be said to target a desktop platform.

What underlying toolkit would a Windows desktop port of React Native use, anyway? WPF? Old Win32?

Microsoft has already answered this. Their React Native target for the windows desktop uses UWP.

Microsoft is pushing UWP as a capable desktop platform. AFAIK, they aren't ending support for their other platforms just yet. WPF is still being worked on last I heard. If you look at win10+, UWP is a perfectly valid choice for React Native. You could have React Native targets for WPF, win32, etc etc if you wanted.. I'm not sure what use cases could benefit from that though.

Keep in mind, if they're missing something in UWP that they need for React Native, they can add it to UWP.

I find it is strange that a supported development plataform for Ubuntu on Ubuntu uses dependencies outside the main repositories (ppa seems fine, however they even use npm directly to download some dependencies).

This is a pretty fragile ecosystem. Yesterday I saw one colleague having build problems from a Maven project because one dependency changed hosts. Seemingly an easy fix, however in the new host they didn't include the version used by this specific program. My colleague ended up blindly using a newer version that seemed to work, however this is pretty fragily.

> This is a pretty fragile ecosystem

Bad from a security point of view, too.

Linux distribution packages are digitally signed and reviewed.

This is one of the most important points.

And an issue for it has been open since Jan 2015:

https://github.com/node-forward/discussions/issues/29

It's, imo, negligent.

Is there a simple way to convert npm dependencies into signed debs?

Seems to be a npm module called npm2debian for converting npm modules to debs. Never used it myself though. Source: https://www.npmjs.com/package/npm2debian

Individual NPM modules seem way too granular for individual distro packaging. apt(1) et al are just not built to handle sources with 10mm packages, or systems that want 100k packages installed.

Also, Node's require() works in such a way that you can require(foo-1.0) and require(bar-1.0), and then bar can require(foo-1.1) and that works, and you end up with your module and the bar module each having their own version of the foo module loaded into the Node runtime.

Distros really aren't set up to handle that: a distro expects a package should be able to be upgraded independently by the sysadmin to whatever the newest version is. There are one-off hacks done for each of the (very few) packages that are set up to run "beside themselves", like python2 and python3, by making them entirely separate packages; but having "foo-1.0" and "foo-1.1" together is basically impossible.

Both of those problems are basically pointing in the same direction: that distro-level packaging and development-dependency-level packaging are semantically different acts and trying to map a package-hierarchy 1:1 from one to the other just doesn't make sense.

It makes far more sense to me, personally, to vendor all the development-time deps of an app or framework into that app or framework, and then package that whole release bundle into a distro package and sign that.

---

Or, to put that another way:

npm(1) is meant to be a build tool, in the same way that make(1) is a build tool. It makes perfect sense for building a Debian package to require calling npm(1), just like it makes sense for it to require calling make(1).

But npm(1) shouldn't need to be there on the deployed system, just like make(1) or any other part of the compilation toolchain shouldn't need to be installed just to install and use binary packages.

> distro-level packaging and development-dependency-level packaging are semantically different acts

This is a good point, but it also seems that distros have a fairly clunky naming convention that makes many useful cases of multiple side-by-side versions seem more clunky than they actually are.

That does seem to be the nature of the Node.js ecosystem, though (together with a number of other language-centric ecosystems).

Package things up, and the community complain about that instead.

Am I the only one who feels like this is anything but native?

I've worked as a "real" native Android and iOS developer for a fair few years and just started working on a project which is built using React Native (Android and iOS).

You're right that the development experience is nothing like "real" native. It's using lots of web tech so it's never going to feel like Java or Swift, however, that comes with its own advantages such as code reuse and libraries.

I'm actually really impressed with the quality of the apps you can create with it. They feel native and feel really smooth, but you need to be aware of the limitations. The major one is that the apps are essentially single threaded so you need to be aware what work you're doing to avoid UI stutters. That does make it less suited for very data heavy apps, but you can work around it if needed.

Overall, as a "real" native developer I'm pleasantly surprised.

Can you use React Native for the UI thread and talk to another thread to get data or perform long running calculations?

Yes, I do this in my app. It's well-supported by the platform and quite easy -- there are built-in primitives to call a native function from javascript that returns a promise, which can then be fulfilled/returned asynchronously on the native side once your long-running calculation or transfer is finished.

My main concern is about the performance and overhead that whole node ecosystem brings.

Despite that, it's nice to read a positive feedback :)

Other then using the same package manager there is very little overlap between the node ecosystem and react's, so I'm not sure what you are referring to

Maybe I missed something.. where are all js files going to be rendered on?

javascript engine provided by the OS, in iOS it's JavascriptCore, in UWP it's the chakra engine. Not sure what it is in Ubuntu, probably v8 packaged with the executable.

In either case, it's not using node or v8/chromium .

Sorry about my uneducation but if v8 is running standalone isn't this similar to having node running on the OS?

v8 is just a javascript engine, node.js is a platform built on v8.

Node.js adds various standard native modules - mostly various IO (file, tcp etc...), a way to load other modules, access to the underlying OS (environment variables etc...).

running v8 alone is akin to running the browser without html or the dom api, you basically can compile and run javascript functions, but can't do much with it.

Isn't javascript really really really fast?

The Julia websites has a benchmark for various languages performing some tasks. Javascript seemed pretty comparable to Java.

Every language has it's pros and cons in terms of performance and benchmarks are notoriously inadequate to compare but my general probing of people in the industry result in the following regarding language speed:

1. c/c++ is the fastest.

2. modern java is either the same as c/c++ or about 2x slower

3. modern javascript (i.e. v8) is about 4x slower then java.

4. python/ruby and most other dynamic languages are about 10x slower then java.

Never seen C# really compared with others because it's rarely ran on the same systems.

Go, Rust and all the new shiny languages are still far away from when we can infer about their performance, but they are probably somewhere around the Java level.

I wouldn't lump all of the "new shiny languages" together; they all have their own performance profiles.

Sorry, I meant all the new shiny languages are too young to make good estimation about and from those Go and Rust appear to be somewhere in the Java level.

Didn't mean to imply that other shiny languages are in the Java level, just bad grammar on my part I suppose.

Why do you think Rust is at the Java level for example?

It's a low level language without a GC and compiles to LLVM, it should in theory rival C/C++ in performance, but it's still young and only recently begun making headways for performance.

So just a hunch, also some barely usable benchmarks that appeared on HW a few months back.

> only recently begun making headways for performance

What gave you this impression? MIR landing?

I'm not saying it is a wrong impression, but it doesn't match mine. My impression is that Rust is routinely very fast, often rivals C, and most of the recent headways were surrounding the performance of the compiler, not the resulting programs.

Also, the Python JIT compiler PyPy in many cases matches or exceeds V8.

Source? According to this Rust is faster than Java http://benchmarksgame.alioth.debian.org/u32/performance.php?... Here you can see that it wins in almost every benchmark compared to Java http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

>> is faster than Java

You seem to have cherry-picked that single-core-x86 n-body measurement just because the quad-core-x64 n-body program measurements are slower than the Java program measurements.

http://benchmarksgame.alioth.debian.org/u64q/performance.php...

Like I said, benchmarks are a terrible way to gauge performance, most of my rankings come from people's experience in various situations, Rust is too young for people to have any experience with it.

Worth noting that Dalvik/ART has very different performance characteristics than a desktop or server JVM (many of the optimizations that proguard does matter a ton on Android where they wouldn't matter very much at all with the jvm).

Javascript has been optimized to hell but I'm not sure I would call it really really fast. Its still going to be much slower than Lua (a language that its easier to make go fast) and a good Javascript JIT interpreter uses lots of memory and needs some warmup time.

I'm not familiar with React Native but can't you use Web Workers to get multi threading, and get around the UI stutters?

> It's using lots of web tech so it's never going to feel like Java or Swift

I'd consider Swift to be native, but Java generally not. You can compile Java to machine code, but typically people run bytecode on a VM.

I think by Java he's talking about Android.

I think we need to find better terminology, then. The same thing happened for 'realtime'. It used to imply hard deadlines in performing actions (like applying brakes in a car). Now there are realtime web apps that certainly don't have those sorts of requirements.

My understanding of real time is that it can be broken into hard real time and soft real time. Hard real time systems (such as car brakes) require a guaranteed response time. Soft real time systems (games are the canonical example) have similar time constraints, however the penalty for not hitting them isn't considered an absolute failure (not hitting 16ms/frame every now and again isn't the end of the world). I'm not aware of any other definitions of real time systems?

>it's never going to feel like Java or Swift

.. or Lua, or Bash, or Qt, or Love, or Unity, or Tcl/Tk, or C/C++, or .. anything else that this is now sitting alongside, 'in the stack of usable components'.

Its good for web developers. But in the 'native application' realm, there are .. frankly .. a lot of better ways to do user interfaces than the franken-nightmare that supports the gloss...

Isn't react native using one thread for uiand another for running js?

Can you use service workers with react native?

Your app doesn't need to be single threaded. To begin with, the JS that you write is running on a different thread to the app's UI thread, but if you also have blocking work that you want to offload to another thread, that is possible by writing a native module [1, 2]. The story isn't perfect, there are probably some things that you want to be dealt with asynchronously, but could be written in JavaScript, but on this front React Native isn't any less limiting than native.

[1] https://facebook.github.io/react-native/docs/native-modules-...

[2] https://facebook.github.io/react-native/docs/native-modules-...

To the extent I have used RN, I find the good parts to be: - Fast & iterative development

- If you are web developer, easy to switch to this (duh!)

- The "React" philosophy of "diffing" and pushing changes and having a virtual DOM

- Javascript - less boiler plate and easier to write (YMMV)

But, with RN you hit the limits in some spots:

- Handling navigation. The available navigator components are difficult to work with. The idioms are little sticky. I know they've started working on a new one

- With Android SDK, you have the full set of components available and hence more choices - components, Material themes etc.,

- Because of the above point, you are always ahead, unless you have bandwidth to write wrappers for new components/ changes

- Slightly noticeable lesser frame rates compared to native. I don;t think this is a deal-breaker though.

Overall, the RN team is doing a great job by bringing the well tested RN concept to the mobile world and making "reusable code" worth an attempt. The choice depends on one's requirements and technology choices available in the project etc.,

React Native is a React based JavaScript runtime that renders by using React output as a base when talking to the APIs of various different native platforms. As an example, React Native for iOS renders the GUI using UIKit.

I'm with you. This is "React Glommed onto its Dependencies, Because: Ubuntu".

But then, platform domination is always a thing, and right now its Reacts/Facebooks' thing, so onward it rolls. For my part, I'm looking forward to React wiping out every other single, similar, framework in the repo's. (I'm not.)

Depends on your definition of native. If by native you mean using the native UI toolkit (QT in case of Ubuntu) then yes, it is 100% native. However, if your definition of native means a compiled language instead of a interpreted one like JS, then no it is not. That said, the actual native toolkit Ubuntu has also runs JS in userland (QTQuick) so I doubt it is much different technically.

Is this guy rather platform allowing to develop React Native apps on Ubuntu or developing React Native apps FOR Ubuntu Touch? Or maybe both? The README is pretty vague.

Is this sentence machine-generated?

Isn't everything?

Now this (d?)evolved into a philosophical discussion pretty fast...

Is this question machine-generated?

For Ubuntu and Ubuntu Touch

React Native is just React using native components instead of the typical web components.

All this is about React Native also supporting native components in Ubuntu, namely the phone and the new desktop.

There's more to it than that. React Native has a lot of things that aren't in React/ReactDOM. The most obvious is the bridge between javascript and native code.

React Native has supporting tools like the packager which you wouldn't hear too much about in high-level comparisons. But when you compare targets like iOS, Android, and Windows, they are all using different javascript engines. There is a lot of platform-specific work that needs to happen before you can write native components.

Conversely, ReactDOM has the code to create/update DOM. ReactDOMServer outputs static HTML. What we used to call React.JS (or simply react) is now the combination of React, ReactDOM, and ReactDOMServer.

React (the "react" npm package) doesn't target anything.

So they are basically rewriting the concept of a web-browser (which already is an application delivery platform)? Personally, I think this is crazy, and it saddens me. Why not cooperate with the browser vendors. Given their position, they should be able to pull some strings here and there.

This has got nothing to do with browsers. This is just a set of APIs that allows developers to use ReactJS (not web, just javascript) to write Ubuntu apps. I didn't read the ReadMe in detail but judging from React Native for Android, iOS, Windows and OS X, this will use QT UI toolkit under the hood, not web tech.

This has everything to do with browsers. What React Native does comes very close to what a browser is doing. React is just a very thin layer on top of JS/HTML that makes the browser a little more efficient and pleasant to program for (they are not the only ones by the way, there are many virtual dom implementations). But that layer is getting thicker and thicker. You can say "react native" and "browser" are different things, but they really aren't. Both are application delivery platforms.

My problems with React:

- They try to push a programming paradigm, without considering that other programmers may have different or even better paradigms.

- They put too much functionality into a single framework.

- Frameworks are a bad idea anyway. It is much better to divide functionality into self-contained libraries.

- They try to redo what the web, a huge standardization effort, is doing.

- React does not fully support all HTML/CSS constructs.

Now all of this isn't really a problem right now. But if React grows and gains more traction, then it could become a problem (just like Internet Explorer became a problem after a while).

Have you ever used React Native, or read anything about it for that matter?

It's just JavaScript wrappers for native UI toolkits. Much in the same way there are Python wrappers, Ruby wrappers etc. The only difference between React Native and someone else's JS bindings is that React Native makes use of a virtual view hierarchy and several other React-isms - which have absolutely nothing to do with the web except in-so-far as that they were first implemented on the web.

Yes, React Native supports an API based on the web's Flexbox API, and view styling similar to CSS - but these are applied to native views. React Native doesn't implement any rendering of its own. However, if anything this is bringing web technologies to native development, they're in no way conflicting with browsers - React Native has nothing to do with a web browser.

As I said, React Native provides bindings for native UI development. Now, whether or not you think that's a good idea is up to you. Swift and Cocoa are generally pretty good, so I can see why iOS devs might steer clear. However, the Android SDK is a complete joke, React Native is significantly more efficient to develop with.

> However, the Android SDK is a complete joke, React Native is significantly more efficient to develop with.

Are there any other reasons for choosing one over the other? Are they similar in terms of what you can do/the performance? With libraries like phonegap/cordova, you have to sacrifice some APIs and the resulting app may be more sluggish. I was wondering if it's the case with React Native.

I have no experience with phonegap/Cordova. But to the first part of your question, please see my answer below/ or above. to another comment.

> They try to push a programming paradigm, without considering that other programmers may have different or even better paradigms.

React and React Native are framework/libraries/whatever made by Facebook to solve Facebook engineering problems (they're cool in the way they unashamedly only open source what they actually use).

They have their own paradigms they prefer and it works well for them and many others. Why should Facebook cater to every programmer's favorite paradigm?. You could honestly say the same thing about most frameworks—do people complain Rails makes it hard to do functional programming?

> React is just a very thin layer on top of JS/HTML

React is in no way a layer over Javascript. React is just an API to write UIs with pluggable backends. The backend can be HTML, HTML Canvas, iOS UIKit, Android widget toolkit, Winforms, GTK, QT, etc etc. It's just a higher level API for writing UIs in Javascript. It's not a platform for application delivery. Browsers and application run times + stores on iOS/Android/Ubuntu are are platforms for application delivery.

React is not even a framework. It's just a library which you can include in your bigger framework.

> - They try to push a programming paradigm, without considering that other programmers may have different or even better paradigms.

Programmers who don't like how React works can use something else. There are lots of choices out there. Angular2, om, cyclejs, mithril, ember, backbone are some of the choices. You make it sounds as if React is a browser with a limited set of APIs.

I'm not saying React is perfect but the arguments you make are totally invalid IMO.

> React is in no way a layer over Javascript.

I was thinking about JSX here. It is translated to Javascript, so a layer, imho.

Layers are not a bad thing. What is bad is that React tries to lump together many layers into a single framework.

JSX is syntactic sugar for JavaScript.

Not clear what you are referring to by the "many layers" or indeed the "framework".

Well you can write pure JS instead of JSX if that helps. An example: https://github.com/ustun/react-without-jsx/blob/master/child...

Thanks. That actually looks better to me than JSX, and I would like to avoid transpiling JS in a pure web app.

(disclosure: I've been an Angular 1 dev for a bit over a year and only skimmed some React material, but I have also done other stuff for the last 30 years)

It might look more familiar, but it's not better than JSX. It gets really tedious to write the pure JavaScript versions of components especially when specifying lots of attributes and nested components. It's also hard to follow. Everyone I've worked with on React projects has had similar initial reactions, it just looks weird to have html inside JS. But try it out first, I'm sure you'll grow accustomed to writing JSX and the tooling built around it.

I disagree. I'm working on a large react project now and am not using JSX. I find JSX to be very ugly with all their closing div tags.

Check out this project to see how people use React without JSX:

https://github.com/jador/react-hyperscript-helpers

React is not a framework. According to it's home page, it's: A JAVASCRIPT LIBRARY FOR BUILDING USER INTERFACES.

React Native might look a web-based kind of toolkit but it's not. It supports a HTMLish layout system based on Flexbox, but it's its own native compositing and layout framework. It circumvents the HTML layouting middle layer and a browser layer. It doesn't need any virtual DOM, for example.

While it might sound redundant, it's more about making UI layout simpler, faster, and all in all more "native".

There's already plenty of browser view-based layout frameworks, and in general they run into the same limitations (performance, lack of native components, etc). This is an alternative solution to that. Think of it as a middle ground between Xamarin and Phonegap.

I'm of the opposite opinion, finally someone is getting a replacement for html and the web api that will actually fit with the design and implementation of applications.

I'm tired of websites trying to be apps just so they'll have a better distribution model or once in a lifetime use site that wants me to install it's app.

The fact that they are making all this with Open Source is even better.

Besides, the standard protocol bodies we know from the web today (and that many of us don't like at all) were created after Netscape or IE created the foundation upon which they work on alone.

I think this misses the point. React Native is not a replacement for the web in any meaningful sense. I think React Native can be a really useful platform to develop on, but it was developed precisely because iPhone and Android made it so difficult to build robust mobile applications with web technologies. The proliferation of apps that you have to download just to use it "once in a lifetime", as you say, is a consequence of trying to convert what can be done just as well on a free and open web into an isolated application. The web has plenty of problems - every open, standardized system does, and aging ones tend to have far more problems. But abandoning the web would be a complete disaster. I'm glad to see better options for building apps than what exists today. I think being able to use JavaScript to build the client side of native applications can be a tremendous boost to productivity, and I think native applications have and will always have their place. I love electron and I applaud the efforts of the React Native team for making otherwise unnecessarily isolated proprietary development platforms easier to integrate with and more accessible. But rooting for the end of the web is like rooting for the downfall of a free and democratic society - I'm pretty sure it's not something any of us actually want.

> [React] was developed precisely because iPhone and Android made it so difficult to build robust mobile applications with web technologies

Exactly. Therefore, in my opinion, Facebook should instead try to get the web back on track of being the application delivery standard. If this is not possible (google/apple not cooperating), they should imho give ReactNative an API that is compatible with the web. Of course, they can build their virtual dom etcetera on top of that (but it should be optional).

React Native is here to help us build apps today with performance in mind. Leveraging web won't have similar performance because it will always have a layer (browser). And it will take who-knows-how-long to implement whatever API that's available on native but not in browsers. React Native allows accessing native API today.

And as far as I know, FB actually tries hard to improve web by participating TC 39 actively. Web is still big part of them.

Sorry, didn't mean to imply that React Native is a replacement for the web.

I meant that React Native can become a replacement for the parts of the web (or just html, the web is bigger) that try to be an application inside what is essentially a document viewer.

I think the web (or rather html) is wonderful for what it was intended for - document viewing and editing (sometimes collaboratively).

Blogs, newspapers, Q&A sites and anything built around content really, should definitely still be in built using html/web , but the various SaaS products should be built using a tool built for apps.

I do agree with you about ReactJS - I think it's effectively a tax Facebook imposes on startup web development - but the same cannot really be said about ReactNative which is a relatively okay cross-platform UI toolkit that happens to have the same API as ReactJS.

Care to elaborate on how it can be considered a tax on startup web development?

After being initially excited about the idea of React, I have been working on several teams doing React-based web development. My eventual conclusion is very simple: the overall amount work that goes into developing web apps has increased compared to vanilla HTML/CSS/JS. Performance is abysmal, and as is the case with many frameworks, you're soon reaching a point where your people spend more time (and in the end: computing resources) tricking the framework into doing what they want it to do. I would say the component philosophy of React does offer some organizational benefits, especially for working in a team, but it's nothing that couldn't be replicated by simply introducing coding conventions.

In the end, I do believe Facebook - as a company that can't really move fast anymore (and doesn't have to) - knows this imposes the same restriction on smaller companies by taking away their agility and maxing out developer resources for work on what used to be trivial stuff. Rationally, from Facebook's perspective, React has to serve two functions: priming and funnelling programmers into their enterprise, and suppressing development efficiency elsewhere. It's positioned very well to achieve both.

This has to be one of the strangest conspiracy theories I've ever heard. If other shops felt the same way you did about React - that it was an evil master plot by Facebook to sap all of our productivity and competitiveness - they just wouldn't use it. There's plenty of other options.

The fact that it continues to enjoy high popularity despite being designed, as you seem to think, as a tech debt Trojan horse.... maybe you have to consider all those other companies out there know something about the folly of developing apps with "vanilla HTML/CSS/JS" that you don't.

That's not really what I was trying to say. I think it's perfectly well designed to suit Facebook's internal needs. And it's also guaranteed to drain resources from startup developers. Intent is not necessary, it's just what happened.

> If other shops felt the same way you did about React [...] about the folly of developing apps with "vanilla HTML/CSS/JS" that you don't

I'm fairly confident that almost nobody shares this opinion, so personal attacks on my competency are expected, yes. The problem with all tech fads is that support for them is absolutely ardent, until the pendulum swings in the other direction.

It was unwise to post an unpopular opinion and I accept people's judgement that it was a net detriment to the discussion. But I posted it and now it's out there. If it's any consolation, I wouldn't do it again.

It's amazing how much productivity is draining out of my team when we are waiting fractions of a second for a component to hot reload. I want to go back to vanilla full page re-renders immediately /s

This "conspiracy theory" has been around for long enough, and was discussed by Joel in 2002 in his "Fire and Motion"'article:

http://www.joelonsoftware.com/articles/fog0000000339.html

The idea that big companies keep throwing out new technologies to keep little companies churning, even if it didn't exist when Joel wrote about it, could have been adopted after. Of course, some of his calls were wrong in that article, but that's a different discussion.

That's weird considering I've heard a lot praise for React in how quickly it makes developers iterate and ship. Granted React is easy to mess up in a larger scale, but most of the time I feel like it's the engineer's faults for not researching the implications of their dependencies and code or knowing how to profile/debug well.

I know that sounds like a copout, but it's just my personal experience. We just rewrote a slow React app some person that didn't know what he was doing did at work and it's fast and fine now.

Why should anyone of Facebook's many employees care that much about you, your company or any other little startup?

They have no reason whatsoever to think or act like you described.

Amount of work going in a webapp has increased because they are doing more. A new tech becomes very popular when it solves some pain points felt by most developers, after usage its own pain points may emerge or tech may advance to allow more complex/diff solution.

People facing problems with regular JS/HTML are looking for React or other solutions. Just a hip factor can't justify its popularity.

if you are getting poor performance, you are almost certainly doing something incorrectly. I'm sure someone here will have suggestions if you share more details.

> My eventual conclusion is very simple: the overall amount work that goes into developing web apps has increased compared to vanilla HTML/CSS/JS

Not true. Application complexity has increased over time for the web, that is the effect you are perceiving. React actually helps cut through that complexity like a hot knife through butter.

> Performance is abysmal,

The above response applies here as well. What performance are you talking about specifically? There are a ton of large scale, production applications that are running React ...

> and as is the case with many frameworks, you're soon reaching a point where your people spend more time (and in the end: computing resources) tricking the framework into doing what they want it to do.

React is not a framework, it is a very basic view library. There are literally only seven public API endpoints that developers use:

* componentWillMount

* componentDidMount

* componentWillReceiveProps

* shouldComponentUpdate

* componentWillUpdate

* componentDidUpdate

* componentWillUnmount

That's it, that's all you have to learn, the rest is generating markup and learning about setting properties and state within a component. The only exception that I will admit is that integrating react with d3 is awkward.

Having built large web applications before React came along, there is a very good reason why it is so popular and that is because it moves the focus from dealing with transitions between states and simply dealing with the state as if we were building the app from scratch.

Why wouldn't you use something like Electron in this case and leverage a real browser? This strikes me as a really bad idea to make a native-like app in a cross-platform way.

Not everything needs to be react these days, guys.

The whole point of react native is to not have to deal with a browser. React native is not for cross-platform development.

It is. Just in a different way.

Its cross platform development of logic, with per platform development of ui.

Not "Write once, run everywhere" but "learn once, write everywhere"

Electron is more like phonegap. React native is nothing like Electron. React Native's aim is not to bring HTML and web technologies to other platforms. The idea is to allow developers to write UIs in native UI toolkits using the react API. The end result is not a webpage wrapped in a browser window like electron or phonegap but actual platform native widgets controlled by JS code instead of objective-c, Java or C++.

Perhaps change to the title to ubuntu mobile? It's a little ambiguous.

Should be for Unity 8, therefore for desktop as well.

Ah, thanks.

Interesting.

But what are the available ubuntu UI components devs have at their hand as of today? Is it based on unity 7 or ubuntu mobile components?

How different it is for a dev from developing an electron based app on ubuntu.

Wouldn't it make more sense to build React Native on top of already cross platform frameworks such as wxWidgets/Qt? So it's cross-platform right off the bat.

The point is to use UI components that are native to the platform. There are lots of existing cross-platform technologies you can use if you don't care about the UI looking "native". React Native is specifically set up so that everything but the widgets are cross platform.

I love React and want to be excited about React Native but the process of getting your dev environment setup for it is painfully long with way to many steps.

I know this seems like a silly thing to bitch about but it kills my idle curiosity when I have to set aside a significant chunk of time just to get to the starting line.

create-react-app finally got me beyond that roadblock and I'm deep into creating my first production React UI. Obviously this doesn't solve the problem for React Native, but it's worth mentioning, since it's an official release.

https://facebook.github.io/react/blog/2016/07/22/create-apps...

I'm actually okay with the process for normal React, it's just downloading npm and then typing a long list of packages after npm install. It's React Native then I find the 'from zero' to working dev environment process faintly ludicrous.

What are you having problems with? I remember setting up react-native to be a total breeze the first time around, especially compared to html react.

We completely revamped the React Native getting started experience a month ago. Let me know if it's easier now: http://facebook.github.io/react-native/docs/getting-started....

That is so much better than when I last looked!

Great job.

Does porting react-core/base from JS runtime to native runtimes like C/Rust have any merits.

The UI abstraction with libreact-core + libreact-{platform} is the holygrail for native UI development. Samsung & MS have previously committed on bring RN to Tizen & Windows.

I would love to see react-core ported to LuaJIT.

Does this render QT/QML components ?

I'm still loving that Adobe Flex won the war. Remaking the web in its image even as it fades into irrelevance.

JSX was instantly understandable and desirable to me due to its close philosophical connection to MXML.

Once again I mention that JavaScript technologies are converging on recreating Flex and I get down votes without discussion.

Weird.

Reply on news.ycombinator.com