[pavlov]

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.

[jeswin]

> 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.

[pavlov]

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.

[tannhaeuser]

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...).

[visarga]

> 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.

[pavlov]

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.

[dualogy]

> 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 =)

[kitsunesoba]

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...

[mlsarecmg]

> 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.

[pavlov]

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.