Put aside the scoring and conclusion parts, the author has a couple interesting observations that resonate with me:
> ... but conscientious developers will be interested in doing things right. They’ll spend hours Googling for examples, trying to learn how to type things that TypeScript simply can’t type properly.
> ... if you only need to hire one or two developers, using TypeScript may make your opening more attractive to almost half the candidate pool.
On the other hand, it seems that the author worked on a few medium-size projects and then moved on:
> All projects for which impact was judged were >50k LOC with several collaborators working over several months.
So I wonder if he was able to evaluate the impacts from a longer term perspective, which shall include refactoring experience, iteration speed, developer morale, etc.
While React Native is constantly being improved, to use it in its current form, one has to be very aware of its under-developed parts, and more importantly, make them aware of by designers and PMs.
Surely for any "fancy" feature one may think of doing with RN, there are always some libraries, plugins, tutorials, solutions that exist in the vast ecosystem trying to help. But more often than not they eventually lead into a maintenance/integration nightmare, simply because how fast the whole mobile industry moves and leaves things behind.
Therefore, I suppose that a wise approach is what I would call "React Native-first design": let the whole team (PMs, designers, devs) know that anything that is not officially supported by React Native and without caveats is off the limit -- just try to avoid the design until it is fully supported.
Usually technology is used to solve business needs, but in this case the business has to adapt to the limits of a particular technology, even while other technologies offer the full range of features any business might need.
Adapting a business to technological limitations has always been the case. Entire industries are shaped by technology. That you are unaware of it is probably because you are a fish unaware of water.
All engineering may require tradeoffs, but when you're so prioritizing developer experience over the actual business that you're dropping perfectly viable features just so you can cling to the illusion of increased productivity, perhaps it's time to take a step back and reevaluate things.
What use is "productivity" without a performing product?
Is it a high-value feature to the end users? Then absolutely, you're correct.
Anyway, in my experience, most good PM and designers want an understanding as towards the amount of effort their features and designs mean for engineers. So if you aren't providing them that feedback, and letting them to factor that into their process, you're doing them a disservice.
Sure, I’m not advocating for developer experience above all else, just pointing out that the fast/cheap/good “pick any two” balancing problem can be solved in multiple ways. I totally agree that we build products for our users not ourselves.
This is far from novel. PMs, devs and architects allow the tech stack to influence product all the time, often on the basis of back of napkin cost-benefit analysis.
In fact, an org that doesn’t define tech constraints is setting itself for overengineering while a disciplined org can use those constraints to drive more, not less, business value.
If you tell me we can't hit business objectives because the team wants to use react native instead of swift without a really good reason, it's not going to work.
An example of where this is already common is when deciding to ship a web app vs a desktop app. Web apps will always be more limited, and sometimes those limitations get in the way of business needs, yet you still see web apps as the most common UIs these days. It's a tradeoff that the business should be consciously making.
Saving money might also be a business need. For this to work, obviously the whole business has to buy in to the benefits of RN, and they should be aware of the trade-offs up front.
But does RN actually save money? Or does e.g. having to keep up with the rapid development, maintaining your own native bridges and components, etc etc etc only cost more time and money in the long run?
I've read a bunch of react native postmortems and I'm usually reading "yes we're faster, but we're spending a lot of time on maintenance". It gives me the feeling it's probably faster short-term, but not viable long-term.
Besides, I'm sure there'll be a next big thing (Flutter?) soon enough, causing investment in RN to drop and it never getting up to par with the native platforms. (see also: PhoneGap / Cordova, Xamarin, etc).
I think Xamarin really stays up-to-date with the newest features for iOS. At least that was true back when I wrote some apps with it, a few years ago.
I believe they have some automated tooling to update the APIs when Apple releases newer versions of the iOS SDK, so usually new features arrive on the same day in Xamarin iOS SDK as they do in Apple's iOS SDK.
I am not sure if the situation is the same for Xamarin and Android.
I wouldn't really hesitate to use Xamarin again in the future if a client requested it, but I haven't tried React Native yet and not sure if I should dedicate time for it or if it'll be gone in a few years. Seems quite a few mobile jobs require React Native experience these days.
I’m not convinced everyone has these issues. I would agree if you have a native codebase then adding RN will only cost you. Not everyone has or needs a significant native code base.
+1 but there has to be a balance. Some features that non developers think is quite easy could take very high effort and vice versa. But I agree having to not have a feature that your competitor seems to have but you can't because you used 'X' would snowball into a big roadblock when multiple such cases crop up and the sexiness of the framework fades..
IIRC the survey was open in July/August. But it took the authors 3+ months to produce this result, which IMO has very limited commentary. It would have been much nicer for such a time-sensitive survey to come out sooner.
(Disclaimer: Using RN in production) The author listed some very legit points that RN is lacking and I share the same pain or complaints. You can beat up any tech with its shortcomings and that will be a good read. But arriving at a conclusion that something unjustified is better is logically flawed.
I have been missing a feature from Alibaba Cloud that AWS does not provide and there seems no easy replacement: Their Object Storage Service (OSS)
provides an endpoint for transforming images (resizing/thumbnailing, compressing etc). Putting it behind a CDN (which is also integrated in the feature), this solves virtually all the image processing requirements ever needed in a common web or mobile application. https://www.alibabacloud.com/help/doc-detail/44687.htm?spm=a...
I use a (not so well known) feature with Google AppEngine - Images API. It's pretty awesome as well. Works really well for web applications with basic image manipulation requirements.
Glad that you find it useful. I'd like to point out that lambda+s3 notification solution is asynchronous, while this OSS feature does transformation synchronously and can be applied to any objects (not just the new ones which could trigger functions), which is pretty awesome.
I work for Alibaba Cloud. Drop me an email (in my profile) if you're interested in the opportunities. Yes, we have office in Seattle (Bellevue).
I currently live in Bellevue, not looking for a job right now but where is the Alibaba Cloud office? Downtown? Factoria near T-Mobile? Crossroads near MS campus?
It's quite common to include the nearest major city, especially when your city is more or less a suburb of it. People outside the Puget Sound aren't going to know where Bellevue is. Redmond is probably the only other well known city in the sound, because of Microsoft.
Please don't trust any Chinese company will protect your data, because even my company will sale or buy some personal data, we will gather as much data as we can.
> even my company will sale or buy some personal data, we will gather as much data as we can.
What does this even mean? What is the subtext here? Because your company (which one?) is regarded as high status (higher than Alibaba?) / serious about data protection (but then you say it sells personal data?) ?
The practice of your company has no bearing of the practice of Alibaba. Alibaba could be better, Alibaba could also be worse.
Disclosure: I'm a Chinese working oversea and am genuinely interested in reacquaint myself with the business practice in China.
Hey that's not cool. How can you just disqualify a company that way just because they are Chinese? Alibaba is an excellent company with a lot of integrity.
Wener seems to be Chinese and working for a Chinese company [1]. They didn't state their reasons for not trusting Alibaba clearly, but that doesn't mean they're speaking from ignorance or prejudice.
I have no solid opinion myself, as I have no real knowledge either way.
I think the trust deficit towards Chinese companies is due to their government. The government can just force their companies to hand over all data. They already do for their own citizens.
The US doesn't have a great firewall they force all data to go through which they utilize to weaponize javascript served from their own companies to international citizens. China does this. They used their great firewall to modify Baidu javascript to serve malware to international users to turn web browsers into a DDoS against github. All because github hosted projects that allowed Chinese citizens to read the uncensored web.
So, no, you can't trust anything hosted in mainland China. And, no, it's not the same as the US.
In the US, there is due process. Granted, that due process has been seriously eroded over the years in cases where the government can claim terrorism, but otherwise, it still takes a court order to force a company to comply with a government request for information.
Right now, apparently at terrorism. And there is still a line, a court must approve it, might be a kangaroo court, but a judge is signing off on things.
That it shouldn't have happened in the first place? That our legal process is pretty damn broken? I have a similar story in NYC except I never sued so I didn't get a check. Just a massive waste of my time, energy and money and no recourse.
the worrying fact is that the govt is whole and sole of the society, it can happen that one day they just kick out the company from mainland. Just like Google left china few years back, I don't think US is this bad. I hope not.
Due process, transparency, the option to overthrow the government. China has none of these. Hell, their government can ban the words "net neutrality" and "freedom" if they want to tomorrow, with no protest or recourse options. Very few countries have these kinds of constraints on companies.
I think we are also conditioned to not trust China. Certainly in the U.K. coverage about China is always negative, from dog stews to mafia-styled political stories. And of course the fact that China is gobbling so much and so fast ... Alibaba is apparently much bigger than Google and Amazon combined. Who's to say that Alibaba isn't the commercial face of the Chinese government? I think that's what we're really wary about.
Rational or irrational, we're definitely jealous, so whatever, that's high compliment for China. But China really is becoming a super, which means it's a threat to the old order. In South East Asia, it was once unthinkable to not see the US as an ally. Now this is shifting, for better or for worse cough South China Sea
App Engine from Google's cloud has such feature -- image transformations and CDN for them with dynamic resizing and some easy transforms from URL parameters.
The prices are excellent if you have a small number of images read/processed many times over a month. If you have a large number of images touched only a few times a month, it's horrendously expensive.
For example I can thumbnail ~7M images in ~2 days on my dedicated machine (40/s) which costs me $60/mo to colocate. $60/mo gets me a paltry 20k images from Imgix (though admittedly I can process them multiple times for the same price, I don't need to).
Right. In my last two jobs, one of them had a relatively low volume of images (let's say, around 30k being requested per month) scaled to an arbitrary number of transformations, whilst the other had a high volume of images (millions) with a low number of transformations.
In both cases, the cost of doing it ourselves (using something like thumbor) would have been a few thousand per month. In the former example, imgix cost a few hundred, in the latter it would have cost in the hundreds of thousands.
imgix is the fastest of the services i've looked at (transformation time is roughly half what I got from cloudinary, and average response time is also about half), but its pricing model means it's completely unaffordable for certain types of product.
Disclosure, I am from imgix.
If you start to exceed $500/month we can offer discounts and certainly when you are looking at millions of images then a flat rate at a lower level makes a lot more sense. 30 million unique images certainly should not be $90,000, that would be outrageous.
The $60 above doesn't include bandwidth from either my transit provider or Imgix, you can purchase a CDN separately.
Imgix is 8c/GB which is certainly competitive but by no means unique. CloudFront is only $0.005 more expensive on the higest tier and gets as low as $0.02 on the lowsest. A cheaper CDN like CDN77 starts at $0.049/GB and goes as low as $0.007/GB.
Cloudfront charges for requests and it can often be the biggest component of your bill.
CDN77 performance in terms of latency is not that great. If you are looking for a cheap CDN with good performance, buy edgecast from a reseller. The only problem with edgecast is that they charge a really high fee for SSL support for custom domains
Imgix is okay, support is terrible, and status page can stay green for 15minute when they are down (eg recent fastly issue). We stuck with them when image processing was slow due to capacity which the CEO eventually publically apologised for, but in new projects we will probably avoid them.
We used imgix on last project as a last line of defense against unoptimized images due to the timing constraints of the project. However on greenfield, we would build the image optimization into the build process (could be as simple as few imagemagick commands), and the save pipeline for CMS'ish part (content blocks, adding products etc..) and then just use a dumb CDN.
Imgix really annoyed me as they didnt bother replying about the status page fiasco, this is after we gave them a free-pass with their capacity planning which made us look like idiots recommending them (i.e images loading super slow). Not again, bad ethics.
Wait people get annoyed at 15 minutes now? I honestly read your comment as if it was 15 hours at first and agreed but come on, 15 minutes is nothing unless you're paying for a five nines SLA.
Mate if their status page isn't saying anything and you're losing money pick up the damn phone rather than mashing F5 on a webpage.
"Please don't start a SaaS business" I was asking a question that just needed a quick answer to change my mind but you went with an insulting topping so that you could look smart. Classy.
There's a community project in c# but we don't have an official sdk for it as we didn't have the expertise on the team and haven't gotten around to outsourcing this yet. Would you (or anyone reading this) be interested by any chance, and has the credentials (github account with relevant projects) shoot an email to kvz@transloadit.com : )
I am using Imgix for a personal photography site and it works great with S3. You point it to an S3 bucket, give it the access keys, and then use the URL they provide instead of the S3 bucket URL.
Using various query params, you can then control a bunch of transformations to the images that are applied on the fly when requested.
i use cloudinary for these same type of features over AWS. Their libraries and UX isn't always the best but their transformation features are out of this world good.
You could create a Lambda function to create and upload these transforms back to S3/CloudFront. Would definitely be a nice feature to get out of the box though.
Not only they provide real-time resizing on CDN, but many many many other things: hardware HTTPS acceleration (check their HTTP vs HTTPS latency,) per-file authentication, hardware Gzip, 'bouncer' for websocket connections. They used to provide free load balancing on the edge for APIs, but I can't find that service in the control panel anymore.
For an AWS equivalent, can deploy https://github.com/RealImage/concave on Lambda+API Gateway in the same region as the source images s3 bucket, and stick a Cloudfront distribution in front of it. Hit me up at sudhir.j@gmail.com if you need help.
I do not understand the appeal of squashed merges. The only pro i know of is the ease of reverting a merge. On the cons side: you obfuscate an entire branch into a single commit, effectively making git-bisect useless. Furthermore, if multiple people collaborate on a branch, all code blames to one person, quite literally rewriting the code history.
It's going to be highly pipeline, workflow, and team interaction dependent. In my place of work you generally only have one person working on a branch to add small, modular features. For releases we cut master into release branches. We fairly frequently need to downstream a commit from master into the staging branch and more rarely the production branch. The squash allows for a quick and easy cherry-pick of the feature to apply downstream.
If the code change is not widespread, I would always encourage a squash. Commits to two different parts of the codebase that do not directly rely on each other on the other hand should remain separate.
Squash merge would be most useful in cases where someone turns in a PR and then there's back and forth which result in them making additional commit such like "Fix typo" and "Change struct name". That's not useful history and it's sometimes easier just to squash merge rather than give the contributor a lesson on reabse every single time. Naturally you shouldn't squash if the history needs to be cleaned up manually but it's rare to have multiple authors on one PR.
actually they always merge via -no-ff.
and time tracking in issue's is also a ee only thing.
actually the last releases were pretty much focused on ee-only stuff, it's sad that it will be more closed caused by the money.
> ... but conscientious developers will be interested in doing things right. They’ll spend hours Googling for examples, trying to learn how to type things that TypeScript simply can’t type properly.
> ... if you only need to hire one or two developers, using TypeScript may make your opening more attractive to almost half the candidate pool.
On the other hand, it seems that the author worked on a few medium-size projects and then moved on:
> All projects for which impact was judged were >50k LOC with several collaborators working over several months.
So I wonder if he was able to evaluate the impacts from a longer term perspective, which shall include refactoring experience, iteration speed, developer morale, etc.