5 ms·
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
by faceyspacey 9y 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.
- pavlov 9y agoI’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.
- visarga 9y ago> 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 9y agoMy 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 9y ago> 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 =)