Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Facebook Android IOS Programming

Facebook Brings React Native To Native Mobile Development 78

Posted by timothy from the reflex-hammer-writ-lare dept.
the_insult_dog writes Despite a lack of dev tools, samples, tutorials, documentation or even a blog post or press release, Facebook's announcement that it's bringing the popular React.js JavaScript library to iOS and Android native mobile development stirred up comments like "groundbreaking" and "game changing." In a series of videos from the recent React.js Conference 2015, Facebook engineers said they're rejecting the "write-once, run-anywhere pipe dream" in favor of a "learn-once, write-anywhere" paradigm. All efforts to duplicate native performance and look-and-feel actually feel like "s__t", an engineer said in explaining the company's new approach to native development in a conference keynote video. Yet to be proven, with tools in the works, it's supposedly a huge success internally at Facebook and experts said the new approach could shake up the whole mobile dev industry.
This discussion has been archived. No new comments can be posted.

Facebook Brings React Native To Native Mobile Development More

Facebook Brings React Native To Native Mobile Development

Comments Filter:

  • Hype (Score:3, Informative)

    by Dan East ( 318230 ) on Thursday February 05, 2015 @03:04PM (#48992137) Journal

    Hype much? If your JavaScript isn't portable enough to run on a modern mobile browser than you suck. The fact that they can make something happen that is supposed to happen by default doesn't exactly excite me.

    • Hype (Score:4, Interesting)

      by Anonymous Coward on Thursday February 05, 2015 @03:14PM (#48992209)

      I think you missed the point. The article is talking about running javascript without the browser layer (i.e, "native" on the OS) and getting better performance out of it. This has nothing to do with javascript browser compatibility.

      • Re: (Score:1)

        by Anonymous Coward

        You both missed the point. It's more about porting facebook's react framework to iOS and Android so no matter what language you are writing in, you will have a familiar framework to work in.

        • No, all three of you missed the point.

          "Facebook engineers" are "game changing" the game by "rejecting" the "paradigm" that is "popular" (they're closing Facebook), instead embracing a "yet to be proven" "new approach" where your "pipe dreams" "look and feel like s__t " (unclear, they probably mean 'shat', which is short for William Shattner, who will buy the empty husk of Facebook and fold it into the Priceline Syndicate).

          Focusing on a "groundbreaking" new business model, they'll be "approaching nativ

        • Are you certain there was a point to be missed? I'm not entirely sure there was.

      • Re: (Score:3)

        by msobkow ( 48369 )

        I thought Apple specifically banned interpretive languages for iOS, such as Java. If it were merely a matter of compiling to the target machine, there are many which could have done so for deploying Java code on iOS with a little bit of porting.

        • Re:Hype (Score:5, Funny)

          by gstoddart ( 321705 ) on Thursday February 05, 2015 @03:49PM (#48992571) Homepage

          I thought Apple specifically banned interpretive languages for iOS

          LOL, I hope you meant "interpreted".

          Otherwise all I get is "this code symbolizes the despair and longing of the programmer".

        • They did... and then a few years back they changed their minds, after Java was no longer an issue. As such, there are cross-compiled .Net/Mono apps on iOS now.

          But besides that, this is a case of Facebook creating an iOS-specific library that implements React.js in native code -- so by the time the binary hits the App store, there's no interpretation going on. I'd call that an improvement, myself.

          • Really?
            I know mono can produce real native machine code - no VM or such involved, not like Microsoft's ngen that only pre-JITs.

            If they have JS compiled to native code too, then that might be interesting.

        • Re: (Score:2)

          by sribe ( 304414 )

          I thought Apple specifically banned interpretive languages for iOS...

          Not exactly. They ban downloading and interpreting code in anything except the Javascript interpreter which they provide. So there is exactly one option for interpreting code--the one over which they have control for security issues.

          • I think you meant "the one over which they have control for profit issues"

            • Re: (Score:2)

              by sribe ( 304414 )

              I think you meant "the one over which they have control for profit issues"

              Really. Explain exactly how disallowing alternative interpreters increases their profit.

            • Yeah, insofar as interpreted code may present a way to escape sandboxing, which in turn could lead to security problems, which in turn could lead to plummeting profits.

  • Judging by .. (Score:2, Insightful)

    by Anonymous Coward

    Judging by the Facebook App. This react is a piece of shit. Just use Objective C or Swift and stop wasting everyones time.

  • I have a dream ... (Score:5, Informative)

    by farble1670 ( 803356 ) on Thursday February 05, 2015 @03:07PM (#48992157)

    Facebook engineers said they're rejecting the "write-once, run-anywhere pipe dream" in favor of a "learn-once, write-anywhere" paradigm

    I'm sure that is Facebook's dream: an oversupply of software developers with the skills required for employment at Facebook.

    • Re: (Score:1)

      by Anonymous Coward

      Nah, I think they're saying learn one framework and code using that framework everywhere. Basically the same as write-once, run-anywhere except you'll have more code duplication.

      And they're talking about trying to manually make web page controls (like buttons) look exactly like the OS' buttons. I'm not a web developer. Why don't browsers handle that with a button tag? Why does every website need to recreate all the basic controls? As an desktop application developer, the web seems so bad in every way t

      • Re: (Score:1)

        by Fwipp ( 1473271 )
        Less than 20 lines of code to import a library? wow, Java's come a long way.

      • Re: (Score:3)

        by SQLGuru ( 980662 )

        It's less of an issue of recreating all of the "basic" controls and more a factor of every single designer wants to style buttons differently. You either buy into the native aesthetics or you don't complain when you don't have a native experience.

    • You know what I suspect the other part of this dream is?

      Ensuring there's a library of tools which will have code embedded in to to have every app phone home to Facebook and violate your privacy.

      There is no way in hell Facebook is writing any tool which doesn't benefit them ... which means by default I'm sure it will be set to call home to Facebook, and it would take lots of effort by developers to disable that.

      Sorry, no, but apps which want to integrate with Facebook are annoying ... no, I do not wish to sh

      • On what basis do you conclude that "phone home" code will be included, and that it will be difficult to remove? Does the current React.js include such code? If not, is there a reason to believe it would be included on the React native? As per TFA, Facebook did write it to benefit themselves, but that certainly doesn't mean it is useful only to them.

        • Re: (Score:2, Insightful)

          by gstoddart ( 321705 )

          On what basis do you conclude that "phone home" code will be included

          Because Zuckerberg and Facebook are greedy douchebags who want the marketing/personal information?

          Does the current React.js include such code?

          Irrelevant, this is a binary, which means you don't really know everything it does.

          As per TFA, Facebook did write it to benefit themselves, but that certainly doesn't mean it is useful only to them.

          My inherent distrust of Facebook says it will be self-serving library -- because that's kind of what th

    • The "learn-once, write-anywhere" paradigm is overrated. How hard is it to learn Java for Android, or Objective-C for iOS? If it takes any significant amount of time compared to the total time building the project, then you don't have a very complicated project.

      Seriously, for shared code, make a C library and it'll run on both Android and iOS. Problem solved. Mobile programmers have been doing this for years.

      • The "learn-once, write-anywhere" paradigm is overrated. How hard is it to learn Java for Android, or Objective-C for iOS?

        Well i agree in principle, I've seen Java written by C developers, and Python written by Java developers. There's definitely a knack for doing something in clean way in each language.

        Seriously, for shared code, make a C library and it'll run on both Android and iOS. Problem solved. Mobile programmers have been doing this for years.

        really?

        IMHO, the amount of actual platform-agnostic code is very, very small. for example, you may have to interface w/ location services on both platforms, but the way you go about it is going to very different.

        • really?

          Yeah, it's a common strategy. The only thing that remains will be UI code, which is a small part of the application unless it's a trivial application. If it's a trivial application, it doesn't matter what strategy you use, because you can rewrite the whole thing for either platform fairly quickly.

          Incidentally, there are some really nice HTML5 apps out there too. The fact that Facebook couldn't get theirs to work is more a reflection on Facebook than on the technology.

          • Yeah, it's a common strategy.

            It's a common fantasy. It's why things like PhoneGap exist.

            Mobile apps aren't just UI code and generic business logic. The platform provides everything: bluetooth, location, account management, database tools, patterns for background tasks and database access, camera, graphics tools ... and the list goes on and on. All of these things are specific to the platform. You can generalize them w/ abstractions, but that's a massive, massive effort and is obviously a very different approach than a shared library.

            • It's a common fantasy. It's why things like PhoneGap exist.

              OK, so you don't do it lol.

              btw, if you're really having trouble with your developers writing lousy objective-C code, send them to bignerdranch for training, and they'll be writing above average Objective-C code after a week.

              If a week seems like too big of an investment, then once again, you're not building any kind of substantial app anyway, so it doesn't matter.

              • OK, so you don't do it lol.

                no, it's not done, for the reasons i already stated. lol back at you friend. i'm talking Android and iOS which is what matters.

                but hey, don't take my word for it. go and write a simple app that gets the users' location and displays it on a map. see how much you can factor into a shared library. the average app isn't a bunch of generic number crunching algorithms. it's platform specific code. it's interfacing with the file system, maps, databases, keystores, bluetooth, location, and so on. none of that can b

                • no, it's not done, for the reasons i already stated.

                  You're wrong, and here is the reason I will give you: I've seen it done. There it is, all your hypothetical reasons proven wrong because of data.

                  • You're wrong, and here is the reason I will give you: I've seen it done. There it is, all your hypothetical reasons proven wrong because of data.

                    you clearly have no specific domain knowledge on this or you'd be giving examples. i suspect when you do give example, you are going to point out sharing of some math libraries or something similarly platform-inspecific, or sharing across mobile platforms that are based on similar architectures.

                    i'm talking iOS and Android, which is really what matters here.

                    • you clearly have no specific domain knowledge on this or you'd be giving examples.

                      ROTFL no doubt I don't.

                      i'm talking iOS and Android, which is really what matters here.

                      Oh really? And here I thought we were talking about popcorn.

                  • It's done in specific circumstances, such as games, where there's a lot of logic that is platform independent. But for most mobile apps other than games, it's more talked about than actually done. For exactly the reason the OP suggests.

    • Block JavaScript from unwanted sources like Facebook I don't care what they do!

  • If the code is written in JavaScript, and if "anywhere" involves a compiler, not just an interpreter, then the performance of the software should be nearly optimal anywhere. And, somewhere along the years, I got the impression that JavaScript compilers were becoming rather popular. I might be mistaken about that, but the notion should still be true, that if every platform included a JavaScript compiler, write-once/run-anywhere could work.

    • Re: (Score:2)

      by RingDev ( 879105 )

      My understanding in this case (which may be incorrect) is that they are doing OS specific versions of React.js to allow them to take advantage of different OS optimizations.

      For anyone leveraging React.js, it would still be write-once/run-anywhere assuming that those developers do not also intend to leverage OS optimizations. Or, if they are intending on switching languages/platforms, the port would be significantly easier because even though the code in React changes based on OS, the API remains the same.

      -R

  • Uh huh. (Score:1)

    by Anonymous Coward

    I'm still baffled at how piss-poor Facebook's apps are. I think it's less a "pipe dream" in general and more a "pipe dream" for them in particular. They need to stop pretending everyone else is at fault and smell the coffee - you guys suck, not the tools you're complaining about. Your fault if you gave up on them, if you couldn't get such a simple service working in a browser. Stop bolting on extra shit before you get your core app right, that's the lesson to take home here. If I can write a cross-platform,

  • This story has been up for an hour and and there hasn't been one reference to the obligatory. [xkcd.com]

    • React isn't a standard, it's a GUI framework. They're proposing compatibility layers for other GUI frameworks on other platforms, with no intention of replacing those other frameworks. Of course it's possible, because other such compatibility frameworks are available and quite successful. What React offers that the others do not is that the development environment is familiar to web developers.

  • It's interesting technology (both react and react native). But the javascript ecosystem and tooling is a bag of shit. People put up with it on the web because you don't have a choice. The only reasonable explanation for node.js to exist is that some people are too stupid to learn php. javascript on the server or desktop or pocket is a massive step backwards. But this caters to people who are too stupid to understand that so I'm sure it will be wild success. Sometimes I think intel is bankrolling the j
  • I used React.js, then I dropped it in favor of html, because after all, html is how you build UI in... ...html. Sure I use templates, I use client-side javascript view-model binding, but I found React.js over engineered and not worth using. To me it's always screamed "flavor of the month" against other, more mature javascript libraries like Backbone and Ember. But to each their own I guess.

    • Re: (Score:3)

      by Shados ( 741919 )

      Backbone is a piece of shit. It had its time of glory, for like... 6 months. It has so many problems and design flaws, its ridiculous.

      That said that isn't the point of React. If you want easy to use/maintain...yeah, you can use it, but there are significantly better libraries for that. The point of React is to generate the most efficient UI update batch job possible whenever you change your state, because if you do it yourself, either you'll end up with a totally absurd amount of code, or you'll do it in a

      • Except react's update tree is WAY MORE than something like knockout.js or others. Hell, even Angular.js is better. So don't give me that crap about all that complexity being for performance, because it's not, I've benchmarked it.

  • There's already a ReactiveCocoa [nshipster.com], I wonder how the Facebook framework differs? Apart from being able to be used cross platform that is...

    The cross platform stuff I try off and on through the years, but it always leaves be cold compared to whatever tools exist specifically for each platform.

  • Search engine wise, it's innocent enough, to prove your account; I've yet to give it to any of them.

    I read an article that said Facebook wanted into the mobile market, well here they are.

  • This article should be entitled "Will Facebook's Reactive Native shake up the whole mobile industry?". This story is in need of a textbook application of Betteridge's Law.

Slashdot Top Deals

/earth: file system full.

Close