81–90 of 335 posts
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…
This is precisely the experience of my startup trying to rely on flutter. It's a constant battle. Moreover Android and iOS are different implementation with different capability with constantly evolving API. It's hard to keep cross platform code in sync many #ifdef with edge cases. Moreover with REST API architecture majority of the common code is in back-end. So building in Swift and kotlin for respective platform i…
Yes it was kind of a pain in the ass to share code like this, but it worked, and the mobile guys mostly just dealt with the specific problems relative to the mobile domain and not api integration issues with our cloud.
That being said, I can tell you for certain our mobile devs (most of them anyway) would've preferred writing their own client api in the native language of the platform. Maybe Dropbox just got tired of dealing with that, they have the money now to hire fleets of engineers to write just about anything on any platform, why would you even bother sharing a client library in that case? But in our case, we were a small team, so we really didn't feel comfortable just letting the next mobile dev who walked in the door come up with another foundation library.
Coding is hard, coding with a team is even harder.
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…
Electron. It works pretty well if you're OK with the huge resource usage.
Isn't that an oxymoron?
It's funny that they have a hard time hiring experienced senior C++ devs even though the language has been around so long. Presumably it would have been easier to find someone really good at something newer like, say, Vue.
Let's be clear that senior C++ developers are masters of their domains because they enjoy solving a particular set of problems that a low overhead systems language requires. However, in the mobile world, from my experience, hiring good senior mobile engineers means they come with a specific skillsets already. They can take a view, animate it a certain way, and then respond to touches. Those are things that are entire…
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…
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.
This is precisely the experience of my startup trying to rely on flutter. It's a constant battle. Moreover Android and iOS are different implementation with different capability with constantly evolving API. It's hard to keep cross platform code in sync many #ifdef with edge cases. Moreover with REST API architecture majority of the common code is in back-end. So building in Swift and kotlin for respective platform i…
So I'm also interested in hearing more elaboration on how Flutter has been a struggle for you.
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…
I achieved 90+% code share in Xamarin including UI across windows - ios - andriod. 100% buisness logic shared. You can write cross-platform UIs, and swap out to native code on a widget by widget basis. Threading is seemless. Sure it has its own set of issues, but everything is a trade-off. Look at your use case, and define what trade-offs you are happy with.
The drop-box use-case is also an outlier - to achieve high levels of responsiveness, it must integrate with low level platform specific APIs to the point their entire app may be some kind OS specific service. Look at blogs about their desktop apps and you see my point.
If you going to drink cool-aid from companies just because they are dominant in an area, atleast drink the cool-aid of a startup which was created for the purpose of building cross-platform apps.
Recently worked at a company doing similar to this to support Windows and macOS. To add to the difficulty, they used Chromium as a UI front end much like Electron. All built in house though. They hired me as a JS/HTML/CSS dev, but same as the article states, the C++ work was the true bottleneck. They knew I had some C++ chops and set me to work doing C++ with a sprinkle of JS here and there. Due to incompatibilities…
Reading the article and now this, I really can't grok this perception. There are plenty of us out here, I think, it's just we're buried in the heap caused by mass resume farming, aka modern recruiting. Recruiters and hiring managers don't think of me as a senior dev with 15 years writing software and delivering value to end-users... I'm just YA candidate who doesn't have any experience in the latest JS framework du jour, so I might as well not exist.
Earlier quoted context omitted.
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?
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)