3 ms·

In the context of a website, I completely agree with you. No blog needs react. Reddit is worse because of react. However, given websites aren’t the only use of

by ddek 6y ago

In the context of a website, I completely agree with you. No blog needs react. Reddit is worse because of react. However, given websites aren’t the only use of react I strongly disagree with your overall sentiment. My organisation uses react in place of desktop apps, and it’s been a game changer for us. We work faster, we train devs faster, deployment is easier, we can painlessly hit everything from desktops through iPads, and we make far fewer mistakes. I really don’t see an alternative, at least outside SPA-land.

ivan_gammel 6y ago
This is that moment that proves we’ve made no progress on desktop. In 1990s we had Borland Delphi and CBuilder, in 2000s we had .Net and Qt, now this? How on Earth this is better?
- ddek 6y ago
  Could you explain why, in terms of the reasons for react I gave in my previous comments, any of your suggestions are better than react?
  - ivan_gammel 6y ago
    We can look at this from multiple angles. Everything I write below is not React-specific, but concerns all browser-based applications (by browser-based app I will mean here both SPA websites and SPA wrappers). 1. UX SPAs do not offer native user experience and it's generally harder to provide it on all platforms at once, even with solutions like Cordova or React Native. Usability and accessibility requirements differ, interaction patterns differ, and sometimes you have to produce completely different designs on desktop and small touchscreen devices. On desktop specifically there's a rich history of rapid application development tools and UI frameworks aligned very well with platform guidelines and design patterns. Native development on mobile still beats everything else when it concerns UX. 2. Development The development cost for browser-based apps and React specifically is definitely one of the lowest, due to popularity of this technology and availability of the tools. RAD and technologies like JavaFX can be inexpensive only if you already have the team familiar with the stack. The development speed of RAD tools was and still is impressive when it concerns UI. The interactive prototype of a screen created in 15 minutes in a visual tool IS the application that can run. All you need to know as a developer, is the component library and programming language. I do not really see, how React could be better here. One big advantage of browser-based apps is ability to develop both for desktop and mobile platforms at once, but this has UX consequences (see above). The architecture of native or imperative-style frameworks is generally better than of any of JS solutions. JS ecosystem tends to reinvent the wheel by gradually introducing best practices which are pretty standard everywhere else for decades. E.g. it took some time to build Redux, which is quite similar to the UI event dispatching mechanisms in Java and the like, but uses its own unique terminology - reducers, stores etc - for what is actually a combination of classic design patterns like Observer. 3. Deployment and support One major benefit of SPAs is instant delivery of new version to all users, achieved by design, but the SPAs packaged in desktop wrappers do not even have this benefit. Also, is mitigated by the existing approaches on distribution of standalone desktop apps via update infrastructure (which also allow canary deployments). One of the rarely visible costs of WebView apps is the resource consumption on the client, which is usually ignored by the developers of online services. Browser engines are not the most efficient VMs for running application code and they require A LOT of RAM. Just compare Slack and mIRC - similar chat functionality (Slack may have better support for rich content and integrations), but how different they are in utilization of resources!

by ddek 6y ago

ivan_gammel 6y ago

This is that moment that proves we’ve made no progress on desktop. In 1990s we had Borland Delphi and CBuilder, in 2000s we had .Net and Qt, now this? How on Earth this is better?

ddek 6y ago
Could you explain why, in terms of the reasons for react I gave in my previous comments, any of your suggestions are better than react?
- ivan_gammel 6y ago
  We can look at this from multiple angles. Everything I write below is not React-specific, but concerns all browser-based applications (by browser-based app I will mean here both SPA websites and SPA wrappers). 1. UX SPAs do not offer native user experience and it's generally harder to provide it on all platforms at once, even with solutions like Cordova or React Native. Usability and accessibility requirements differ, interaction patterns differ, and sometimes you have to produce completely different designs on desktop and small touchscreen devices. On desktop specifically there's a rich history of rapid application development tools and UI frameworks aligned very well with platform guidelines and design patterns. Native development on mobile still beats everything else when it concerns UX. 2. Development The development cost for browser-based apps and React specifically is definitely one of the lowest, due to popularity of this technology and availability of the tools. RAD and technologies like JavaFX can be inexpensive only if you already have the team familiar with the stack. The development speed of RAD tools was and still is impressive when it concerns UI. The interactive prototype of a screen created in 15 minutes in a visual tool IS the application that can run. All you need to know as a developer, is the component library and programming language. I do not really see, how React could be better here. One big advantage of browser-based apps is ability to develop both for desktop and mobile platforms at once, but this has UX consequences (see above). The architecture of native or imperative-style frameworks is generally better than of any of JS solutions. JS ecosystem tends to reinvent the wheel by gradually introducing best practices which are pretty standard everywhere else for decades. E.g. it took some time to build Redux, which is quite similar to the UI event dispatching mechanisms in Java and the like, but uses its own unique terminology - reducers, stores etc - for what is actually a combination of classic design patterns like Observer. 3. Deployment and support One major benefit of SPAs is instant delivery of new version to all users, achieved by design, but the SPAs packaged in desktop wrappers do not even have this benefit. Also, is mitigated by the existing approaches on distribution of standalone desktop apps via update infrastructure (which also allow canary deployments). One of the rarely visible costs of WebView apps is the resource consumption on the client, which is usually ignored by the developers of online services. Browser engines are not the most efficient VMs for running application code and they require A LOT of RAM. Just compare Slack and mIRC - similar chat functionality (Slack may have better support for rich content and integrations), but how different they are in utilization of resources!