Hacker News new | ask | show | jobs
by faceyspacey 3184 days ago
Ultimately the declarative way of writing apps is objectively better and more predictable than the old mutable way :)

Now that said, I agree on the performance costs, and too wonder why Walmart is hellbent on this strategy, given the endless resources they have.

But at the end of the day, they have a head of engineering and need to make their lives simpler just like everyone else. If you know how to squeeze the performance out of RN/React, developing apps in the semi-FP declarative sate-driven way is a dream compared to all the old ways of client app development. People who's views are so against React/ReactNative usually haven't experienced it for themselves. I suggest really giving it try before making these comments which usually serve just to validate decisions already made. I.e. to make one's self feel better about sticking to the old ways. However, I totally understand what it feels like for new tools to pop up that put into question old ways I've invested a lot into. That said, don't you think you'd be better off fully exploring these ways before shooting them down? Don't tell me you have--zero people that have grokked the effectiveness of declarative state-driven programming make these remarks. They usually leave some hint at their experience with React. In short, it's only you left in the dust :)

Give the tools a try, which I know will likely be hard for you because you are likely coming from the Native world. I will say this: it's a lot more than just one language to make hybrid apps (i.e. like past tools such as Titanium). And, of course perf will be a challenge. That said, the perf is amazing given what it is. But more importantly, the style of development is what it's all about. It's so different and so much more predictable/debuggable than the old mutable ways. To me, it matters not that it's in JS. What matters is the declarative state driven way of development. If you can do that in native code, you're basically doing the most important aspect--and basically there's no argument from me there. There are some libraries that allow for that, but it's nowhere near the extent of what you can do in React/JS, given its ecosystem. I lot of work is being put in here to make this the best of breed future of application development. If you can't see it, you're missing out. Do your homework on React once and for all. You can thank me later.

Last point: Walmart's tool here is specifically meant for making apps where some of it you want in "actual native" and other parts in "react native." Without a doubt coding the React style is the best DX for UI development. AND without a doubt, "actual native" performs far FAR better. So what they have here is a toolbox for those with an "engineering mindset" to pick the best tool for the job. Everything that's happening is just getting better and better for all parties involved, no matter where your experience lies.

5 comments

I’ve done both native (Mac, Windows, iOS, Android, Gtk+, Tizen) and React.

Your post comes off as condescending fanboy hype. I understand you want to promote React, but this approach does more damage than good.

My personal experience is that “declarative” in this industry is a perennial silver bullet. What often goes unnoticed is that declarative languages are not very future-proof, as extensions are constrained by the originally chosen primitives. Pathological examples are enterprise Java+XML and CSS — both of these were hailed as declarative breakthroughs originally, and today they are the stuff of “TheDailyWTF” nightmares.

Surely that will not happen to React, you say, because it gets so many things right? Well, as a thought exercise, imagine what things could be like in 2027 and then imagine you’re stuck working in a 15-year-old patched up JavaScript/HTML hybrid. That is the endgame. I like React, but it’s subject to the same market forces as every other technology in this space.

> Java+XML and CSS — both of these were hailed as declarative breakthroughs originally, and today they are the stuff of “TheDailyWTF” nightmares.

Java+XML isn't declarative, XSLT was. XSLT declined when XML declined. CSS works quite well even today and is still widely used.

Declarative coding style is in many ways resistant to obsolescence since you're just declaring what you want than how to do it. The best example is SQL; mostly unchanged in decades.

XML is certainly declarative.

As far as CSS goes — ask any front-end web developer if they would like all programming to be more like CSS...? It is a collection of thousands of properties, often overlapping or contradictory, some with their own sublanguages for further specification, and many features are defined as hidden side effects of one property when nested inside another. A total mess.

You can only declare what you want if the language lets you say it. (Think of Wittgenstein’s famous maxim.) SQL was a great design informed by decades of research. Most software designs are not like that, unfortunately.

I'm a fan of declarative (eg. logic) programming but how is XSLT declarative when Java and XML isn't? XSLT has been proven Turing-complete a long time ago (eg. [1]), and if anything, is functional, being derived from DSSSL/Scheme up to the XML syntax.

[1]: http://conferences.idealliance.org/extreme/html/2004/Kepser0...).

> imagine you’re stuck working in a 15 year old patched up JavaScript/HTML hybrid

That should be quite a powerful language by then, if it's not already.

My point was that the world around will change, and at some point the declarative language that seemed so succinct will become clunky and inadequate to express the new requirements.

Java+XML really is the poster child for this. There was a time when it was the fresh declarative kid. React will most likely follow a similar path, not through any fault of its own.

> My point was that the world around will change

Same will happen to your Swift or Android-Java codebases though. Go try to build and run on your 2015-17 machine+OS+devenv any just-slightly-real-world-beyond-hello-world run-off-the-mill 15-year old Visual Studio 6 line-of-biz (or other) codebase right now.. or whatever they used on Macs back then (I'd imagine the compatibility story for pre-OSX stuff is maybe even slightly worse than in MS land). Software that's meant to survive is meant to be maintained, I guess.

Or the server side of a web app? What's it gonna be, CGI or ASP 3 or PHP 3.. always the same story.

Bringing up HTML/JS/CSS from those days to function (though not shine) for today's requirements might prove comparatively tame by comparison =)

I can’t speak much for the rest, but old Mac codebases in particular hold up better than you might think. You can write an application that runs on every version of Mac OS from 1.0 (circa 1985) up to High Sierra with just a handful of conditionals through the use of Carbon [0]. Porting pre-OS X software should be similarly simple, given that it’s written in C or C++ (Pascal was somewhat popular for classic Mac apps, not sure what getting that code running on modern machines would look like).

When it comes to “new world” Mac stuff, the things keeping something written for OS X 10.0 from running on modern macOS have more to do with API deprecations than anything else. Objective-C is still widely used and is well supported (even with Swift’s growing popularity), so usually getting an old codebase of this nature running just means fixing a couple of deprecation errors, fixing a bunch of warnings, and hitting compile. The nature of change in the native sphere has largely been evolutionary, not revolutionary, so it’s largely stayed the same with new things being added. It’s not like the web where wheel reinvention and fads are a constant.

[0] http://blog.steventroughtonsmith.com/post/109040361205/mpw-c...

> What often goes unnoticed is that declarative languages are not very future-proof [...] Surely that will not happen to React, you say, because it gets so many things right? Surely that will not happen to React, you say, because it gets so many things right?

It is often not appreciated how simple React really is. Its simplicity is actually well suited to survive a long, long time. Forget classes, lifecycles, schedulers and all this stuff for a moment. If you boil it down what you're left with is but a single signature: `createElement(name, props, chilren)`. That's what JSX transpiles into.

With that you can map pretty much every visual-oriented api on earth and as we can plainly see it goes further than that and starts rendering flat out everything that can be rendered in the same friendly manner we're used to:

shell consoles: https://github.com/Yomguithereal/react-blessed

word: https://github.com/nitin42/redocx

pdf: https://github.com/diegomura/react-pdf

samplers: https://twitter.com/GabeRicard/status/911989894267973633

mobile: https://facebook.github.io/react-native/

3d: https://github.com/Izzimach/react-three

windows: https://github.com/Microsoft/react-native-windows

macos: https://github.com/ptmt/react-native-macos

sketchapp: http://airbnb.io/react-sketchapp/

keynote: https://twitter.com/nishb1/status/913744410537537536

VR: https://facebook.github.io/react-vr/

hardware: https://github.com/iamdustan/react-hardware

What's even crazier is that everyday eco-system packages can be applied to the wildest targets. For instance animations via react-motion on shell consoles: https://github.com/gaearon/react-blessed-hot-motion or react-router on VR: https://youtu.be/Mf0Fy8iHp8k?t=12m25s

It's always the simple, almost trivial ideas that seem to survive and spread. React was released 4 years ago and has kept to a stable api. 16 was a rewrite, and it's a drop in replacement.

Forget classes, lifecycles, schedulers and all this stuff for a moment. If you boil it down what you're left with is but a single signature: `createElement(name, props, chilren)`.

When you pare it down to that, you're merely saying that GUIs are trees of configured objects. It's not a great revelation because the very first production GUI (Smalltalk 1972) already worked like that.

To get React from that idea, you need to add back all the stuff that you left out in the previous sentence. You add JavaScript, HTML-like syntax for defining trees and object attributes, component lifecycles and all that. And then it's not a generic idea anymore but a fairly specific implementation that will be superseded by something else eventually.

Also, coding in the React style is the "best DX for UI development" mainly if you're a web developer who doesn't want to learn the platform or the native tools but still wants to have "mobile developer" on your resume. (IMO)
>Ultimately the declarative way of writing apps is objectively better and more predictable than the old mutable way :)

how has this anything to do with RN ?

You can write declarative codebases in swift or kotlin, no need for RN to achieve this.

I never coded native apps so forget my ignorance but how would you build an UI declaratively with swift? The turorial shows very imperative/mutative code indeed:

@IBAction func setDefaultLabelText(_ sender: UIButton) { mealNameLabel.text = "Default Text" }

No need to apologize for asking an honest question :)

By combining a good databinding framework and reactive extension

so Bond & RxSwift or DataBinding (from google) & RxJava (or RxKotlin if/when it becomes a thing).

Of course, behind the scenes, this accesses the platform widgets in an imperative way (but that's also what RN has to do when it manipulates the same widgets). What matters is the API surface you interact with.

Declarative way of thinking is closer to how humans think while imperative code is closer to how machine works. That is why declarative way is objectively better and more predictable to model human behaviors, not necessarily the more efficient for machines.

Performance will improve due to Moore's law and optimizations.

The big picture is with more and more companies open source their technologies, software development is becoming a more and more social activity and Darwinian.

The mindshare winners are the survivors in technology (and talent) market.

> while imperative code is closer to how machine works

somewhat. less so these days than say back in the 8086 era.

cpu's these days do all kinds of wild stuff, with their long pipelines, staged execution, executing multiple instructions simultaneously, and other interesting behavior.

combine that with smarter compilers that can transform code in various ways to capitalize upon cpu developments, and you might be slightly surprised how some ostensibly boring and linear imperative code actually behaves on a present day cpu.

I already did give these tools a try and first rat out of the trap the sample code generated by React Native had build errors in production XCode8. I will confess that it did confirm my bias against bringing in any 3rd party dependency at all unless there is absolutely no choice in the matter and it also confirmed my practice of structuring my code so that any dependencies I'm forced to bring into a project (either by time crunch or clueless management) can be removed as soon as possible.