5 ms·
This is a bad sign to me, talks about how to optimise start up performance and optimise list views when the processors in our pockets are the fastest they've ev
by intoverflow2 10y ago
This is a bad sign to me, talks about how to optimise start up performance and optimise list views when the processors in our pockets are the fastest they've ever been.
Do we really have to switch to developer centric development where devs have an easier life using JS at the expense of performance?
Think the millions of users would prefer their devices to have better battery life, load faster and have less cruft just to draw a few text boxes of a profile edit screen or a grid of photos (something I would have thought would be effortless to mobile devs in 2017). Rather than the handful of devs having a slightly easier day at the start of the process.
This whole move seems especially strange to me coming from a Facebook company, have we forgotten the move from native > webtech > native already?
- a-saleh 10y agoI think almost always, if there was a choice between making thing easier for the developer and squeezing more performance with more difficult practices, majority chose better developer experience.
- a13n 10y agoEspecially as chips get faster, teams can afford opting towards a better developer experience to move faster and retain happier engineers. It isn't only developer experience, also developer velocity. That was the whole motivation behind React Native in the first place.
- LeoNatan25 10y agoFrom my experience, any native developers that work with React Native have a mental toll from having to adapt to what seems like unnatural technologies from the native side. Add on top of that the terrible web ecosystem, terrible JS base library (and, perhaps, the language itself), the lack of IDE (not code editors), the debugging experience, the packager performance, and it's just not a good experience for people who have worked in better developer environments, such as Android Studio, Visual Studio and Xcode. The only people really happy, from my experience, are web developers who are already familiar with this technology and ecosystem.
- a13n 10y agoHaving done years of iOS and web development, React Native is a far better developer experience than Xcode. Take it from a former UIKit author: https://twitter.com/andy_matuschak/status/560511204867575808 https://twitter.com/andy_matuschak/status/560511204867575808
- chrisan 10y ago> Think the millions of users would prefer their devices to have better battery life, load faster I'd love to see some testing here. Are we talking fractions of a percent or something like 20% more battery drain? If its fractions I am willing to bet most people would pick an easier life (assuming JS is their definition of easier). > have we forgotten the move from native > webtech > native I doubt many have, especially Facebook themselves. What a large cost that must have been for them. To have failed that and be willing to risk doing it all over again with native > "webtech2.0" must say something.
- greyman 10y ago> devs having a slightly easier day I think the goal here is to target both iOS and Android with just one codebase. But I also happen to hate this trend, and I see it on Windows too. It seems like companies stopped creating native, good-looking and performant GUI applications built on .NET (or on Win32 which I still would find acceptable), and instead opted for uglier and less performant applications running on some javascript or node.js framework, because those will also run elsewhere.
- charrondev 10y agoCould you give an example or two of a beautiful 3rd part .NET or Win32 app on windows? In my mind many of the standard win-forms-esque looking apps are really ugly or have issues scaling on hi-dpi screens.
- preordained 10y agoBeyondCompare springs to mind. Holy crap, I love that tool.
- danmaz74 10y agoOTOH, this kind of tech is a godsend for smaller shops and solo developers, where having two completely separate codbases (or three if you also do a web version) can be impossible.
- creyes 10y agoOr smaller startups who need to support both platforms at launch. We're going through that right now and we definitely can't afford to pay for a java dev and a swift dev and a js engineer (me). We also can't afford the Dev Shop costs of both iOS and Android. and our customer base is split 65-35. React-Native is literally a gift sent from God to save us
- LeoNatan25 10y agoDo you mind sharing what your application does, and possibly a link to the app store of it?
- sotojuan 10y agoWelcome to programming with web technologies!
- reggieband 10y ago> devs have an easier life using JS I think that is willfully missing the point. Creative work, especially UI-centric product development, requires significant iteration. Layouts change frequently, entire view hierarchies can be re-worked, sizes are tweaked obsessively. This isn't just about decreasing the burden of engineering (as if Obj-C/Swift/Java/etc. were so hard to master). This is about decreasing the time from concept (e.g. Photoshop mock) to implementation (interactive working app) so that iteration can happen quickly. As much as I love the performance possible when coding directly against Native APIs, I also have direct experience using web views in native apps. The improvement in the design process around web views is worth investing in getting the performance as close as possible to native. This is multiplied when you consider the cross-platform benefits. However, the performance and UI experience of web views is not good enough. I can't vouch for React Native giving the iterative benefits of pure web view development nor the performance benefits of pure native development. However, if it does strike a reasonable balance between them I can totally understand why people invest in it.
- nonsince 10y agoSo why not have a virtual DOM-based data-driven layout engine that _isn't_ an HTML/JS stack. Something in a language that is more optimisable and works everywhere, like Lua with C extensions, or OCaml, or Java. JavaScript is hard to get predictable performance from and HTML is extremely complex, we can do better if we're writing native apps (hell, we should have had a better online solution years ago too, but we don't have control there).
- jetter 10y agoReact Native does not generate any HTML. It generates native controls.
- reggieband 10y ago> why not have a virtual DOM-based data-driven layout engine that _isn't_ an HTML/JS stack I'm not advocating RN, I just understand the motivations behind frameworks like it. I think "to make devs lives easier" is not a fair assessment. Also, to be fair, JS performance is generally adequate. My own experience with performance on mobile devices often fell back to rendering (e.g. managing textures, making animations smooth, infinite tiled scrolling). Very rarely was raw CPU processing a major concern. My experience may not be typical. As for other cross platform native development libraries/platforms/etc. - I've had some experience with a few of them (e.g. marmalade[0] which was in C++) and generally they do not work for me. I even attempted to write my own and it was its own monster. In general, I am personally biased towards Native. I would definitely take RN on a test spin if I was in the prototype phase of a new app. I would use that time to determine if I wanted to bring RN into production or re-write as Native. [0] https://en.wikipedia.org/wiki/Marmalade_(software) https://en.wikipedia.org/wiki/Marmalade_(software)
- erikpukinskis 10y agoUnless you are making a video game, or doing high throughput data processing, the JavaScript language is probably not your performance bottleneck. For the most part performance problems in consumer apps are things like pagination, poor re-use of data structures, over pre-caching, etc. Instagram never has more than what... 10, 20 elements on the screen? And it's all pretty much text or at most a 10 second video clip. There's no reason even a crappy mobile processor can't handle those elements. It's all a matter of being intelligent about what you put on the screen and when. There's no need for high performance rich data structures. There's no big data.