Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing React Native [video]

youtube.com

Post reply on HN
Print view View original

51–60 of 193 posts

Re: Introducing React Native [video]

#51

Post by donw »

themgt wrote: post #48

Well, my money is on this (concept if not implementation) being the future of client-side development. Absent horrific performance/robustness problems, which seem pretty unlikely from this team, this is sounding like the droids we were looking for, the holy grail ring to unite us all, web and native. And did even Steve Yegge ever see this next big language coming?

Having spent the past six or so months working with React and Flux, I sure hope so. For the first time in my technical career, I've actually enjoyed working in Javascript.

The real power of React isn't just the virtual DOM -- it's being able to leverage Flux and an immutable, single-source-of-truth app state. Pretty much every time I turn around to build something, this combination has made what used to be an exercise in hair-pulling into an absolute joy.

Re: Introducing React Native [video]

#52

Post by seanmcdirmid »

jbigelow76 wrote: post #34
seanmcdirmid wrote: post #30

Earlier quoted context omitted.

Honest question: Would you even need something like react on windows given that wpf/winrt already support dependency properties and data binding?

TL;DR to below: focusing on JS instead of Xaml seems like a smarter play for a .NET developer that hasn't used Xaml in WPF or SL previously. I put "web oriented .NET developer" in my response for this specific type of question. I kind of defaulted (11 years ago) into ASP classic and ASP.NET as a result of ad hoc consulting/support work for MS technologies back in 2000. But despite my affection for C# I abandoned ASP.…

I program in WPF in C# with absolutely no XAML. I used to use dependency properties/data binding a lot, I even made a wrapper [1] so you could write things like:

    w0.Right.Bind = w1.Left + w2.Width;
And that would automatically generate a one way data binding in WPF (so if w1's left property, w2's width property, or w0's width property changes, w0's left property is automatically recomputed).

I've since moved on to my own dependency management (rebranded hence forth as managed time) system called Glitch [2], but that's because I'm trying to invent what's next.

I'm an MS employee but I have no idea what what is being done in this area. I do have lots of respect for WPF, it was weird that the other platforms couldn't put forward a decent UI platform for so long (well, JavaFX, but it didn't go anywhere).

[1] http://bling.codeplex.com/

[2] http://research.microsoft.com/en-us/people/smcdirm/managedti...

Re: Introducing React Native [video]

#53

Post by spicyj »

Touche wrote: post #5

If I'm one of Reacts competitors I'm ecstatic that they're abandoning the web. It reminds me of when Angular wastes energy on angular.dart because of a Google mandate. Didn't help them much.

I work on React. We're not abandoning the web.

Re: Introducing React Native [video]

#54

Post by digvan »

sydcanem wrote: post #33
digvan wrote: post #25

It fails like many other framework tried to create native apps with JavaScript

Those mobile Javascript frameworks uses the DOM. React native won't.

It's not about DOM. UIKit is pretty sofisticated to build layer to translate JS to native code. It needs years of work and constant update.

Re: Introducing React Native [video]

#56

Post by je42 »

btown wrote: post #38
bobajeff wrote: post #32

I wish they'd go into more detail on why they can't make an app like paper in the browser environment. They mentioned something about Web Workers being crippled and later on explained how their framework puts JavaScript in it's own thread by default. I'm also wondering why in their experience no one ever comes close to native widgets when imitating them in a Web apps.

> Web Workers being crippled As Tom said, you can't do layout or prerendering-to-bitmap in a web worker: there's no DOM or Canvas API unless you bring your own, and despite Emscripten it's foolhardy to bring your own. If you want to decode a JPEG, you have to do that on the main thread and pass it to the worker right now (except in Firefox with its nonstandard ImageData API). [0] Which brings us back to square one. >…

Since you are in native you could decode in native in a different thread and pass the decoded data into the Webview, but not sure if thats really better since you would still have to create an image object from the raw bitmap data.

Re: Introducing React Native [video]

#58

Post by tomocchino »

marknutter wrote: post #40
bobajeff wrote: post #32

I wish they'd go into more detail on why they can't make an app like paper in the browser environment. They mentioned something about Web Workers being crippled and later on explained how their framework puts JavaScript in it's own thread by default. I'm also wondering why in their experience no one ever comes close to native widgets when imitating them in a Web apps.

There's quite a bit of hyperbole in this talk. Some web apps do in fact come close to native, but to the trained eye of a Facebook software engineer it will feel miles behind. Your average Joe doesn't give a shit, as long as they can use the app. If they did, Facebook's Paper wouldn't have been such a flop.

This is absolutely a great point, and honestly, I used this exact argument early on in the development of React Native to convince folks that cared a ton about craft and were super worried about performance, that it's more important to make sure you have a reliable application that adds value to peoples' lives, before you even earn the right to start thinking about craft.

My phrasing was somewhat hyperbolic, but I basically said: "Do you honestly think that a person, in the middle of a natural disaster, trying to determine whether or not their family and friends are okay, gives a sh about 60fps animations?"

The real value of React Native is that it allows engineers who know React (and React is really, really easy to learn btw), to build great feeling applications without putting in a ton of effort. Sure, it's possible to get close enough on web, but it's really, really hard to do so.

One of the things we tout in product infrastructure at Facebook is that when building frameworks, you need to enable engineers to fall into the "pit of success". The asynchronous nature of this implementation allows application logic to be run off the main thread by default, which we think is a huge advantage over a traditional web model.

Re: Introducing React Native [video]

#60

Post by tomocchino »

leeoniya wrote: post #36
bobajeff wrote: post #32

I wish they'd go into more detail on why they can't make an app like paper in the browser environment. They mentioned something about Web Workers being crippled and later on explained how their framework puts JavaScript in it's own thread by default. I'm also wondering why in their experience no one ever comes close to native widgets when imitating them in a Web apps.

with gpu-accelerated css transitions, requestAnimationFrame, virtual dom and web workers, the experience can be damn close. he makes it seem like "no comparison", this is provably false at least for the apps he demoed. for games, native is still necessary. what react offers beyond performance though, is definitely awesome. imo, the talk comes off a bit like a sales pitch at a pep rally.

You're absolutely right that it is possible to get close. I think my main point here, (though I probably didn't cover this well enough and I was being somewhat hyperbolic, I guess), was that 'damn close' is unfortunately not the default on web, and it's actually really, really hard to get there.

Sorry for coming across as a sales person. Someone tweeted about a previous presentation of mine in the past asking "who the hell is this marketing guy they had do this talk". I assure you I'm not in either marketing, or sales, I just get really excited sometimes.

Post reply on HN