Dropbike: Data Breaches and Free Bike Rides
ipfs.io
ipfs.io
Okay, good job code monkey. Now move along, we have to get back to focusing on our shitty business.
For example the initial exchange was:
> Hey Tristan, thanks for reaching out to us about this. We really appreciate you telling us about this. We don't have a bug bounty scheme, but I've forwarded your feedback to our software team. Thanks again, Tristan.
Solutions like React Native, NativeScript and Flutter are providing real developers alternatives to trudging through bullshit on two separate app platforms just to deliver a similar looking experience to two walled gardens. This makes me happy.
BTW - I'm not even a React fan, I think it's over-engineered/not as simple as it should be. However it is/was a paradigm-shift type project and the divorce from the DOM model to enable support for something like React Native was a great move as well.
I wrote an app that locally loops over 5MB of JSON and then sorts it based on a datetime string (which is converted to a date class) - and it does this every few seconds. You can't tell that this is happening though, because the phone doesn't lag. It doesn't even use a significant amount of battery. It just works.
I wrote the same app in React Native + NativeBase earlier, and even though I implemented that in a smarter way, the app still lagged. Even just a general react native app that doesn't do anything weird just feels "off" sometimes.
Source: Wrote the same app 4 times (Swift, Java, React Native, Flutter) - Flutter was the clear winner, and a joy to work with.
But you’re right in general.
Additionally, with JS most code runs on the UI thread unlike most native apps. If you use a web worker with RN you'd get similar behavior to your native app.
You CAN make highly performant software, even games, with React Native. You just need to take the time to truly understand the platform, and you will reap massive benefits.
Eventually I'd like to make an example app in ~3 of the alternatives (native, nativescript, flutter) and use appium to do comparisons and various timing.
Here's a very unscientific test (showing GPU usage) I did on the Note 8 switching between menus really quickly. It's barely noticeable (if at all) for me, but it certainly shows on older phones.
Canvas for Android (Native): https://i.imgur.com/5mWueG7.png Falcross Menu: https://i.imgur.com/DpKVNDK.jpg
(It's also important to note that this isn't noticeable at all on iOS. The app is buttery smooth with a consistent framerate on iOS.)
Other than that, a few nitpicks: The "recently played" icon at the top is clipped for me, the energy/star/circle icons at the top flicker when you switch views, etc.
Things like that basically don't happen if you use "real" native development (or Flutter) with "real" native components.
If the react native app is sufficient for it's intended audience, then learning dart/flutter, or 2 native platforms is academic at best, as it's unlikely to sway revenues.
Maybe certain use cases can never be handled in react native, but for most, it's sufficient to not impact revenues.
At the end of the day, the user doesn't care about your programming stack, only results, and react native has been deployed at scale by large corps to demonstrate viability for most, if not all cases
The flickering when viewing lightbox/modal views is actually due to my navigation library, react-native-navigation, which is otherwise excellent. I believe they're fixing that in their v2 release, at which point those transitions should be indistinguishable from native.
I've also made a ton of progress on Android performance in the past month, including the mindblowing realization that I had set hardwareAccelerated=false in my app's manifest over a year ago. The game should now be very smooth in all views, even on very low-end Android devices :)
I like Flutter but I just don't want to commit to dart, but it represents an entry in the hybrid continuum (native -> webview) that can't be ignored because of how it works.
One thing though -- looping through 5MB of JSON doesn't seem like something you should be doing...
[EDIT] - Just saw your other comment with the render comparison pictures -- thanks so much for the input!
I do plan to write a better comparison about the whole development lifecycle, performance, etc. later though.
I'd also like to urge you to reconsider dart. It feels kind of like a Kotlin-Java hybrid language, and I mean that in the best way possible. It's definitely familiar to anyone who has programmed OOP before, so it was really easy for me to get started with zero experience.
> One thing though -- looping through 5MB of JSON doesn't seem like something you should be doing...
I agree. I should get to fixing that.
Have you seen the Flutter Show[0]? It's actually a pretty good watch, though I'm a little skeptical/suspicious of how hard the marketing team of Flutter is pushing things, it reeks of when subpar/fledgling projects try to advertise/market themselves to greatness. Then again, the way Flutter works is pretty novel for the space so it's clearly not a marketing-only play.
Upfront I want to say that I fully recognize that disregarding dart is a childish thing to do, I mean to try building a not-bad flutter app as early as this weekend (I got my fill of nativescript-vue recently and liked it but want to see what else is out there), also I've watched and read enough about flutter that it's about time that I actually built something with it. Also, I'm not a fan of Java's semantics and ergonomics (though it's better than a large group of other languages), but I do always hear nice things about Kotlin. I've programmed in OOP but don't really want to any more -- structs + methods + interfaces/typeclasses/traits (i.e. golang, haskell and rust) are like 100% of what I want out of "OOP" approaches now, don't want the rest that comes with it in java land.
On that note, what do you think about Reactive programming (relatively recently announced as BLoCs in flutter)? I'm not sure I actually like trying to have primary data processing paradigm for applications, but I know it's a very popular approach -- I find an Observable gets you 99% to where you want to be, and observables are almost (if not completely) equivalent to streams but no one wants to do that, day 2 mobile app data management seems to almost always be "let's add streams".
[0]: https://www.youtube.com/playlist?list=PLOU2XLYxmsIK0r_D-zWcm...
[EDIT] - I particularly like these two posts in sequence on your blog:
- https://nikhiljha.com/blog/how-to-write-android-apps-in-2018
- https://nikhiljha.com/blog/a-reflection-how-to-actually-writ...
It also has that big red 'Google built this' flag, opensource not withstanding. Feels way riskier using it than any of the first 2 or even the 3rd.
I've had IPFS support on my website for a while now and figured since one of the top HN posts was about porting a blog to IPFS I'd share the IPFS link.
The best practice is to have a domain using dnslink[0] which always points to the most recent IPFS hash on a gateway with the content already pinned. I believe this is what the IPFS team does for their blog, using a combination of a static site generator and web hooks.
edit: looks like this might be relevant: https://github.com/ipfs/go-ipfs/issues/3860
As an alternative, I'd recommend either my website: https://fn.lc/post/dropbike/ or the cloudflare AMP cache https://fn-lc.amp.cloudflare.com/c/s/fn.lc/post/dropbike/
https://github.com/d4l3k/opendropbike
It's not quite production ready, but does most of the basic things.
Dropbike - send this candidate an email saying “You, sir, are hired”.