Live data from Hacker News

The not so hidden cost of sharing code between iOS and Android

blogs.dropbox.com

121–130 of 335 posts

Re: The not so hidden cost of sharing code between iOS and Android

#121
post #96

Earlier quoted context omitted.

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 con…

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

Re: The not so hidden cost of sharing code between iOS and Android

#123

I often struggle trying to explain to more junior developers that there are times when it's OK to write code more than once. There is a mindset that you should only ever write code once. It exists for (very) good reason. But if you follow it dogmatically, you may end up with an unmaintainable tangle of dependencies that can only be resolved with a rewrite. Sometimes, it's OK to write the same thing twice if the alter…

At the very least you need to repeat yourself in as much as repeating the names you defined for constants, variables, macros, and functions when later invoking them. A program written in the limit of the style of don't repeat yourself either repeats these names many times and/or has too many layers.

Re: The not so hidden cost of sharing code between iOS and Android

#125
post #90

Earlier quoted context omitted.

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 m…

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 con…

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?

Re: The not so hidden cost of sharing code between iOS and Android

#126

This reminds me of LLD’s approach of sharing an architecture but having separate ELF, COFF and Mach-O implementations. This made it much faster than gold which wasn’t actually slow. Apparently sharing code isn’t necessarily a great idea.

They did start out with a shared atom model for all three platforms but switched away from to separate implementations for ELF and COFF http://lists.llvm.org/pipermail/llvm-dev/2015-May/085088.htm...

Re: The not so hidden cost of sharing code between iOS and Android

#127

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 rendere…

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.

Re: The not so hidden cost of sharing code between iOS and Android

#128
What I don't see them saying was that it was the wrong choice in 2013 for a scrappy team and an evolving product, just that it's not the right choice in 2019 for a company with ~infinite dollars and a stable product.

I'm looking at building a mobile product solo right now, and I'm finding Flutter a pretty compelling idea. Building everything twice means being circa twice as slow, meaning I can learn about what the market needs half as fast.

I might be wrong, of course, but this isn't the article to persuade me otherwise.

Re: The not so hidden cost of sharing code between iOS and Android

#129
post #15

I have come to this same conclusion after many years. It's not cost-effective to have any bespoke business logic (models, controllers, etc.) shared between the two mobile platforms (don't get me started on sharing UI code). If you have some incredibly tricky low-level algorithm/library and/or need for speed, think database, crypto, intense graphics, etc., then fine, you may be able to swing a shared module in C++ or…

> a good requirements spec

I think that kills a lot of interesting projects right there. If I could write a solid spec, that would mean I believe I wouldn't learn much from shipping the product. And also that my competitors aren't learning or advancing.

Post reply on HN