> If your answer is "A native Cocoa/WPF app", you are on another planet
If developers weren't so scared of Swift and C#, this wouldn't be a problem.
> (writing Desktop apps) is massively expensive, both in terms of actual dev time per feature (easily 10x the cost), and also in finding specialist developers who know these dated technologies.
I find the opposite to be almost universally true.
Writing a lightweight native desktop app is almost always cheaper than trying to build a JS-heavy app that has to run well in Mobile, and Tablets, and in a standard web browser, and in Electron fake-native-desktop web browser. Yes, you have separate projects with separate codebases. But two or three small lightweight projects is almost always cheaper than one big codebase with lots of targets, in terms of total cost of ownership.
I think, only a special kind of "developers" is afraid of learning languages. A language is, after all, means to use the frameworks. If you are an experienced developer, moving from a language to a language is a matter of hours to days, depending on paradigm changes. Learning frameworks takes much longer, obviously, but with the wealth of information available out there these days (Stack Overflow, message boards, blogs, etc.), "hacking" on new frameworks is also quite easy.
I think all these "massive cost" comments come from sheer ignorance. Those "devs" are frightened at the need to learn a new language and frameworks, overestimate the time required to learn those, look around them and only see likewise clueless "devs", frightened of changes, and extrapolate some comically high overestimation of cost and time, when in reality, a properly written software is much more accessible to join in and support than a web "app" with the contemporary "sexy" observer pattern nonsense splattered all over, coupled with a horrible, horrible dependency management system and a language/framework combo that requires multiple dependencies to perform the most trivial of array loop.
Spot on, I serioulsly don't understand people that are Java developers/front-end developers/technology X devs if you're not talking about you're currently working on, and instead treat that as their profession.
Anyone would think it to be ridiculous if a carpenter told you he only works with saws because he is a saw carpenter and that for other kinds of work you should see the plane or sander carpenter. To me saying you're an [insert tech here] developer sounds the same...
> Anyone would think it to be ridiculous if a carpenter told you he only works with saws because he is a saw carpenter and that for other kinds of work you should see the plane or sander carpenter.
...and yet there are specialties within like "framer" and "finisher", among others. Then you have interior workers like specialized custom cabinet makers, flooring specialist, drywallers, painters, etc.
What I'm trying to say here is that even in "carpentry" for putting up a house, there are numerous specialties.
> I think all these "massive cost" comments come from sheer ignorance.
I can't speak for others, but for me, the "massive costs" isn't about having to learn another language or framework. It's instead the massive costs to my employer. It might even be a massive cost to me as a single developer.
By developing a cross-platform app using a single set of easy-to-use tools, a large audience of users can be gained, that would otherwise be prohibitively expensive to support if native-only was the mantra. Instead, that application would have to be developed for only one, maybe two of the "major" platforms (and guess which platform it wouldn't be developed for - that would be the platform that I like most).
Supporting and maintaining a single codebase for one platform is a monumental task for any company, let alone a single indie developer. Supporting and maintaining multiple codebases for multiple platforms can be debilitating for a company, let alone a single developer.
I lived and played in those times; back in the "second gen" if you will of the microcomputer days - you had games and apps by different companies, and developers. In most cases, a game or app was only developed for one of those machines (usually the Apple IIe or the C=64, sometimes both - maybe an Atari too), but the other systems were all considered "second tier" by most developers. You might get a port of a game or app - but most times, you had to settle for something else, or buy a second system (ha! only if you had real money! I look back on the costs of those systems back then, and wonder how my parents ever managed it).
There's a reason you see a lot less of that going on today; it isn't because devs are frightened of learning a new language or framework.
meaning he works for a company that heavily leveraged an existing protocol, IRC, for which there are already a metric fuckton of native clients and libraries for every platform under the sun.
Implementing their shitty web client was undoubtedly far more work than supporting a handful of native clients.
With my company, our users have always begged for an Mac OSX and iOS app. We never provided it, because we have zero-internal expertise with any of the technologies involved. We could contract, or hire for that specific purpose, but the moment that team member was gone the project would be dead and out of sync with the rest of the codebase.
The codebase isn't lightweight to begin with, and duplicating it for a native app that maybe only one person could maintain was a non-starter.
What'd be a good example for the kind of lightweight project that can reasonable be duplicated for Native Mobile, Native Tablet, Native Desktop, & Web Browsers?
> We never provided it, because we have zero-internal expertise with any of the technologies involved.
Couldn't your team learn the technologies? These days there is an abundance of resources available (online tutorials, books, bootcamps, etc), especially for ecosystems as popular as the Appleverse.
I can't pretend to know your situation, but as a reference point we had an iOS project come up at work a couple years ago and I was able to pick up Objective-C and the Apple libs in a few weeks while still being productive on other projects. I followed Apple's official tutorials[0] and built some toy apps, then learned the rest as I went on the real project. This is after having never owned an iDevice and doing mostly web and devops work in scripting languages for many years prior. A few peers of various experience levels were able to ramp up in about the same amount of time, so I'm not special.
> With my company, our users have always begged for an Mac OSX and iOS app. We never provided it, because we have zero-internal expertise with any of the technologies involved. We could contract, or hire for that specific purpose, but the moment that team member was gone the project would be dead and out of sync with the rest of the codebase.
I don't see how that is any different. If your Windows team members all left, that project would be dead or out-of-sync too. Wouldn't you replace valued team members who leave, in both cases? Or is this a concern that you won't be able to find developers willing to work with OSX and/or iOS tech?
> With my company, our users have always begged for an Mac OSX and iOS app.
Repeating this again because this should be telling. If your getting feedback begging for an OSX and iOS app, there's probably a number of really good reasons for that.
> What'd be a good example for the kind of lightweight project that can reasonable be duplicated for Native Mobile, Native Tablet, Native Desktop, & Web Browsers?
Spotify, Slack, Twitter, Facebook, any streaming video service (Hulu, Netflix, Amazon Prime Video, HBO GO), etc.
Note that I'm not using "lightweight" to mean "small weekend project", but to mean "less complex than the codebase needed to reproduce these features in a browser or Electron browser".
--
If you are truly a small company / startup, and you truly have to support all platforms with a small team, then sure Electron makes sense despite all the drawbacks. I totally understand that.
But I usually hear this excuse from big companies, that still want to perceive themselves as small, but aren't. Slack is a billion dollar company, they are not a small business / small startup. If a company is large enough to have more than two people working in HR full time, then they are probably big enough to do this stuff right. "We're a small team" simply isn't true for them.
No one is scared of C# and Swift, XAML and so on, but these technologies aren't even close to what you have available on the web. React and Redux make apps possible that you wouldn't get with older technologies, not even with 10 times the effort and code. The animation possibilities, transitions, the flexibility overall, the eco system, debugging capabilities, hot module reload - if you have worked with it, you will not want to go back. Case in point, modern apps like VSCode, Atom, Hyperterm, Discord do things that would be very hard for a native app to mimic, and they do that with absolute ease.
I agree though that Electron is a problem. React native will probably be the best way forward. Microsoft has recently taken over RN-Windows and ReactXP, a RN-web clone. RN runs natively, doesn't need a browser, while being able to tap into the JS eco system.
Redux and co are still the same pattern fundamentally, it's just that the implementing code is spread throughout your stack, instead of in an "Observable" implementation. That combined with an optimisation allowing identity and state equality to be conflated.
I don't know what you're saying, this is the complete opposite. Redux was made to centralize, because observables are literally spread throughout the stack. The entire logic is combined in composeable containers, later wrapped in a single store. Flux pattern is also completely different in how it works, there's almost no similarity whatsoever.
That is the whole point of immutable state, and it is very effective because parent props are also notified through shallow checks, while observables have to bubble up and keep track of their relations.
You also seem to agree now that both are completely different.
That's not MVC. That's the MVC Facebook attempts to show in a ridiculous presentation that finally convinced me how much they had to misinform to get these silly concepts any legitimacy.
See the wider picture, how flexible they are and how fast they grow. Their freedom in making things possible that would be very hard to realize.
The shell that i'm using for instance, Hyperterm, it does things no other shell can do, and they had more than a decade to evolve. JS doesn't have a problem displaying json as json, display webpages on link clicks, moving up git logs with my trackpad, adding tabs with a plugin that contains a few lines of code and a little css, ... it just comes easy to JS.
The same flexibility you see in Atom, VSC and the others.
> JS doesn't have a problem displaying json as json...
You know what else doesn't have a problem doing this? Literally any other programming language or tool that I've ever used to look at/edit Json.
> Hyperterm, it does things no other shell can do...display webpages on link clicks moving up git logs with my trackpad, adding tabs with a plugin that contains a few lines of code and a little css, ... it just comes easy to JS....
Any pretty much any other terminal built with flexibility and extensibility in mind (even the base terminal in Linux can handle links lol, that's definitely not exclusive to js). ZSH springs to mind, with the benefit of being written in Case, so that you know, it's actually fast...
> The same flexibility you see in Atom, VSC and the others.
Ah yes, including the freedom to not open any binary file, or any file >2mb in size!
> React native will probably be the best way forward. ... RN runs natively, doesn't need a browser, while being able to tap into the JS eco system.
Similar arguments were made when Java first came on the scene. "Write once, run anywhere." [1] Years later, here we are again with "native" Javascript libraries. I'm sure in another 20 years or so we'll be rehashing this again, just with some other language.
Java Swing wasn't native, though. SWT is more comparable.
React Native isn't "native" (in quotes), it's native... it uses the actual widgets provided by the host OS. You use similar techniques to create your UI for each platform, but you do generally need to create separate UI for each platform with React Native.
> these technologies aren't even close to what you have available on the web
Yeah, they're that much better, that we grumpy old non-JS programmers keep wondering what the big deal is when somebody comes along and rewrites something that existed 20 years ago.
That isn't the point. JS does something the others can't. It has flexibility and a community that's larger than anything you know plain and simple. Btw, i am a grumpy non JS developer, or used to be. Started with assembler, c/c++, then c#. That sums up most of my professional career. I was wrong judging JS too fast, that's all i'm saying. Many of my colleagues are still grumpy about it, they'll get over it over stay behind. If they do move on they will see what they're missing soon enough.
If developers weren't so scared of Swift and C#, this wouldn't be a problem.
> (writing Desktop apps) is massively expensive, both in terms of actual dev time per feature (easily 10x the cost), and also in finding specialist developers who know these dated technologies.
I find the opposite to be almost universally true.
Writing a lightweight native desktop app is almost always cheaper than trying to build a JS-heavy app that has to run well in Mobile, and Tablets, and in a standard web browser, and in Electron fake-native-desktop web browser. Yes, you have separate projects with separate codebases. But two or three small lightweight projects is almost always cheaper than one big codebase with lots of targets, in terms of total cost of ownership.