Hacker News Reader

Comment by jacobsenscott | Hacker News Reader

Add more fuel to the "write once, run anywhere" dumpster fire. Let's peek in there - I see C, C++, Java, JavaScript, stored procedures, wxWidgets, RubyMotion, GTK, QT, object oriented programming, functional programming, PhoneGap, React Native, Flutter, ... It is getting full in there.

What's that about the definition of insanity? Doing the same thing over and over and expecting a different result?

Sever side rendered HTML is the closest we've come, but that's not cool anymore.

View on HN

You've listed a lot of technologies that people have used to create successful products with long life-cycles. In particular C, C++, Java, JavaScript, Qt, OOP... if anything is notably missing from your dumpster it's probably Adobe AIR.

Nothing in this industry lasts forever. I'd certainly rather inherit a Java/Swing or Qt app from the early '00s than an MFC or Carbon dinosaur.

> MFC or Carbon dinosaur

Oof. Yeah MFC was something else.

I hated Swing the bit that I worked with it.. but I'm always blown away when I see the Jetbrains IDE's in the wild (I'm a VS Code guy but a few people I work with prefer the Jetbrains stuff). They managed to make a really slick, and pretty performant (if you ignore startup time) app with it.

I guess you could say VS Code is a similar exception to the rule in Electron land.

Dropbox was able to ship two mobile applications for 5-6 years using this strategy, so it's premature to dismiss it.

Furthermore, it looks like their team changed a lot and they were unable to retain the C++ talent that implemented the original strategy, nor were they able to find interested developers.

The mobile landscape has also changed enormously during those 5 years, even the official programming languages have changed.

I'm using Flutter successfully. It has the potential to become a really great platform.

Java is a good language, as long as you rarely use implementation inheritance.

I would not recommend using React Native or C++ for any project.

Could you tell why you would not recommend react native?

Pretty certain it's the unstability.

In my experience, while Flutter may not be elegant because of Dart, it more or less just works.

Developing in React Native is mostly just debugging the framework itself and browsing through React Native Github issues.

I had the opposite experience with Flutter personally, the problem is that Dart is a niche language with limited exposure (Flutter is basically the only big project in Dart realistically) and it's also a new project as well, it makes a bad combination.

Could you describe your experience more in details? What exactly didn't work out? I would like to know to understand whether it makes sense for me to invest my time in Flutter/Dart instead of a more mature solution like React Native.

Actually, I don't think we should consider React Native more mature. It's been around for longer sure, but it's significantly more fragile, keeps releasing with regressions, has poor tooling around it except for as far as React is concerned etc.

I don't know what you are trying to build on mobile but I'd definitely learn Flutter instead of RN, which I have. Others here have said you should just go full native instead, and they're probably right.

I wasn't aware of the fact that react native is fragile - it seems I did the right choice by learning Flutter. I hope it evolves even better, and also the criticism to Dart for me is so far quite irrelevant, as there are already tons of libraries and it's really easy to learn.

May I ask what kind of stuff are you developing with it? I've been working on a WebRTC app myself with it, basically porting my app from RN to Flutter. So far I've encountered no major obstacles, just a little friction which is a part of the learning curve.

It's an ecommerce app that should integrate with Firebase and online shops. :)

What specifically isn't elegant about Dart in your opinion? Seems like a perfectly good language to me, and although it's nothing fancy, it does have a bit of sugar, and a solid standard library. I also like how codegen and static analysis are so accessible through the build libraries.

It's evolving pretty quickly, too. Non-nullable by default is coming up, along with extension methods, FFI. Possibly implicit conversions.

I've been working with Flutter/Dart for the past 8 months or so, and I have to say...I'm pretty into it.

I think I've been spoiled by algebraic data types and pattern matching. I really miss them.

Non-nullable by default will be a huge win. It does feel like a huge step backwards having to deal with nulls again.

Non-nullable types are coming.

https://www.youtube.com/watch?v=J5DQRPRBiFI&feature=youtu.be...

wow! I didn't know that. I am currently learning Flutter, because I think it has a strong potential to unify mobile and desktop development, however, I didn't know that React Native was "so bad".

This has been exactly my experience. I don't particularly like Dart, but as an SDK Flutter is clearly ahead of RN. RN just keeps feeling too fragile. And the tooling is simply not there whereas Flutter has excellent tooling considering how new it is.

The nice thing about React Native compared to Flutter is that RN uses native UI widgets whereas Flutter implements its own rendering system. Flutter engineers basically reinvent a large portion of the work already done by Apple and Google in their UI kits and ultimately you have to rely on them to keep doing that work whenever changes are introduced to iOS and Android UI kits. Since RN uses native widgets they get those updates "for free". There is also the Flutter "uncanny valley" where very subtle but still perceptible differences between the Flutter engine and the native UI kit cause Flutter apps to sometimes feel slightly off. I have especially noticed this on lower end phones where the FPS in Flutter apps sometimes drops and causes the whole UI to feel sluggish in a way that native UI widgets do not.

Wasn't one of the main points with flutter having really good fps?

In my experience it generally does, but on older devices, especially older androids, when the FPS does drop, the entire UI appears to be affected, whereas native widgets seem to perform better, or at least, don't seem to drag down the performance of the entire app UI if one widget is misbehaving.

React Native - JavaScript, plenty of jobs outside mobile dev.

C++, plenty of jobs outside mobile dev, and a very nice pay to come along.

Flutter - Dart, death silence outside Flutter use cases.

I like doing projects with ionic, which have the great advantage to be ported to the web and also packaged as desktop apps. From all the apps i have developed with web tech or even i know of no users are complaining about lower performance or similar. Why developers have this opinion?

The flutter approach is interesting, however i tried really hard to become friend with dart, which seems impossible to me... I only hope somebody is building a transpiler or something.

wxWidgets does actually get close to that mark. But regardless of the library/programming environment, there will always be platform-specific code you have to deal with.

I don't think wxWidgets is a strong example for cross-platform success. While admittedly I haven't touched wxWidgets in years, back when I used it, I marvelled that it worked at all, as the source code was such an utter mess. For example, I found a bug where a class constructor would raise lifecycle change events before the constructor even finished, and the issue was brushed away on the mailing list. Argh.

Electron. It works pretty well if you're OK with the huge resource usage.

> It works pretty well if you're OK with the huge resource usage.

Isn't that an oxymoron?

No.

If the user interface is usable and snappy, it is probably fine that it consumes twice as many resources as a similar native app would require for the same result.

Example: Slack.app is a huge memory hog (though not as bad as it was before their rewrite), but it fits decently into OS X and does not lag on me.

I have lots of RAM, so the extra consumption is fine.

Sure, it annoys some programmers that it could be more efficient, but other than them, who cares? Those guys are probably using Emacs or a CLI program as their client anyway.

(I must be a rare breed, since I do email, writing, and programming in Emacs, but not chat)

I think it's a bit of an unfair characterization. I don't use emac or CLI as my client, I enjoy a beautiful UI as much as the next guy but electron is a real bother to me.

I switched from Sublime to VS Code and went from 20MB of RAM usage to 500. Add slack, add discord, you now have GBs of RAM getting eaten up just for the UIs. Most mid-range laptops still only have 8GB of RAM, add a browser to the mix and it's a constant battle to have everything running smoothly, the programs frequently crash due to memory issues. It's a real problem and not solely programmer efficiency-OCD.

Electron is also using an old version of Chromium, and most electron apps are slow to update, making it more insecure than running the web app.

While it's fair to assume most Electron apps are probably running old Electron (and thus Chromium), Electron itself has done a bunch of work to get caught up. Their 6.0 release was the first release to be shipped on the same day as the equivalent Chrome release https://electronjs.org/blog/electron-6-0 their plan is to stay at most one version behind https://electronjs.org/blog/12-week-cadence

Huh.

My laptop has 8 gigs of RAM, and I run many programs simultaneously (usually including several codebase analysis servers behind Emacs, a VirtualBox VM or two, Slack, and of course tens of Chrome tabs, several in development mode), but I don't have anything like the problems you describe. I do use The Great Suspender aggressively in Chrome and that does help a lot.

My Emacs instance itself is extremely tricked out with extensions and usually weighs in between 100 and 200 MB of RAM. Maybe that's the difference - sounds like VS Code eats a lot more.

I'm on a MacBook Pro from 2015 at work, if memory serves.

What setup are you running that handles your needs so poorly?

I'm impressed you can run all that especially multiple VMs on 8gb, I have to close Firefox when I need VMs. I'm on windows 7, on a Dell Inspiron with a RAM and disk upgrade, no special configuration or software. I didn't think to look for an addon to do that, that's pretty cool, I downloaded the Firefox equivalent, might do the trick!

I double-checked now that I'm back at work, and I was flat-out wrong. This machine has 16 GB.

No wonder I don't have issues.

I hope tab suspension helps you. It certainly made Chrome more usable for me (but I do have a bad habit of getting to fifty or seventy tabs open).

God I wish it was only twice the memory. Twice would be acceptable. Discord by itself likes to push to a full gigabyte to show me 50 lines of text with avatars and 0-5 thumbnails of images.

Even worse it's using significant amounts of video card memory, and I have a tenth as much of that.

Fair enough. I've never actually hit performance problems on my current machines, so I've never looked closely at actual resource usage.

Not if it results in only this one application feeling snappy and everything else hanging because of resource consumption. That's especially annoying when you work on a shared server. I used to work in a C++ team where many people used CLion (on a shared development server) and it made us all miserable, because the server would hang from time to time, because all the CLions ate all the RAM (sometimes just one instance could consume more than 50GB). Similar things happened with Eclipse, but a lot less often.

And then the IDE of another guy does its indexing really fast zillions of times per second, great, but then another guy sits there waiting for "git status" to complete for several minutes.

I really despise Electron apps. They always seem bloated and antagonistic toward the native user experience on my platform (eg. inferior keyboard support, hard to integrate with custom tooling like AutoHotkey, etc.). Have I just not used the right ones?

Visual Studio Code is probably one of the best received Electron applications. Tried it?

I'm not him, but yes. It's certainly nowhere near a native Mac app, and apparently that's the absolute best Electron has to offer.

I'm not a fan of them, but they do make desktop linux a bit more viable insofar as you will have desktop binaries for a lot more services than you otherwise would without electron

Reply on news.ycombinator.com