JetBlue explains to a passenger how it got a photo of her face - <AUTHOR> https://boingboing.net/2019/04/23/in-this-twitter-exchange-jetb.html <comment><USER2> This essentially gives the government much tighter control of a process that, while decent, has some loose ends in it. For instance, document forging is something that is less effective than it used to be given digital chips and facial recognition.

It is of course legitimate for a democracy to check things like which plants are coming across the border and to deny access or apprehend war criminals and the like. However, the USG does not have a current record of using its powers for good recently. Example: the muslim ban. Anyone who managed to get around that is a hero even if it was illegal because it's an immoral policy.

Tighter control means tighter control of dissent. Want to find that soldier with those leaked documents? Want to locate that journalist with news of unseemly interventions in central America? Want to find those people of the wrong race or religion that are the convenient scapegoat of the moment? Sure, let's make border control more precise. Most people are actually decent and should have default global freedom to move and work by birthright. US border control is about denying people entry, but the main effect is denying ordinary people with a minor effect of deterring crime.

<comment><USER3> We have yet to see another Stalin with all this new tech. Something I hope we never see. I wish Gulag Archipelago was history 101 at university.

<comment><USER4> Xi Jinping is trying pretty hard.

<comment><USER5> Stalin is 10M deads in the lead.

<comment><USER6> I thought most of those deaths were indirectly, resulting from agricultural and economic policies and forced relocations and only a relatively (10%) small number of executions?

If you include economic causes, you might need to include the excess mortality of systematically impoverished communities in western nations — and I don't just mean "PoC in the USA", as I can point to a UK study claiming the government's austerity policies since 2010 have caused 120,000 excess deaths: [https://www.bmj.com/company/newsroom/health-and-social- care-...](https://www.bmj.com/company/newsroom/health-and-social-care- spending-cuts-linked-to-120000-excess-deaths-in-england/)

Also, if those deaths were related to economic policies, you probably have to weigh them by population size.

Obviously that's still a million executions more than most; I am not defending him, this is just about making it an apples-to-apples comparison.

<comment><USER5> It looks like something of ~7M from the famines, ~2M from Gulags, ~1M from executions, uncertain number from torture.

Numbers from

[https://en.wikipedia.org/wiki/Excess_mortality_in_the_Soviet...](https://en.wikipedia.org/wiki/Excess_mortality_in_the_Soviet_Union_under_Joseph_Stalin)

I'd say if famines are the cheapest way, many dictators with a genocide mind set would do that if possible.

</comment></comment></comment></comment></comment></comment><comment><USER7> Most relevant details, from the last link [1]:

> _It took her photo, comparing her picture to a preloaded photo databased of > all the passengers with tickets on this flight, and then she got a check > mark, indicating she was cleared to board. The whole process took about five > to six seconds._

> _The Aruba experiment is expected to last somewhere between 45 and 90 days._

> _" We're basically capturing that picture at the boarding gate, providing it > to U.S. Customs and Border Protection. They're identifying the traveler," > Farrell said. "It's actually the U.S. government that's implementing the > biometric matching system that does all the hard analysis and crunching of > the data."_

> _A biometric exit system to track non-U.S. citizens using their faces or > fingerprints has long been a congressional mandate, particularly after 9 > /11, to improve border security and identify people who've overstayed their > visas._

> _Crockford says people don 't know how CBP might share that data with local > police. CBP insists it'll discard photos taken of citizens, and only keep a > database of non-citizens._

> _Customs and Border Protection has been piloting similar biometric tests at > airports in Atlanta, New York and the D.C. area. And, according to a customs > official, the goal is to deploy facial recognition tech widely by early next > year._

I guess it must be comparing with their passport photo? (Or visa photo, for foreigners?) It doesn't seem much different from the way you're already required to show your physical passport and they check your photo manually. It's also always been pretty normal to have your photo taken by countries when passing through passport control. So I don't really see what the problem would be here?

[1] [https://www.wbur.org/bostonomix/2017/06/21/jetblue-facial- re...](https://www.wbur.org/bostonomix/2017/06/21/jetblue-facial-recognition- pilot)

<comment><USER8> Is it really that useful to identify someone who has overstayed their visa _when they are leaving the country_? Sure, you then know not to let them in next time. But it seems like a lot of effort when there are so many people overstaying their visa and _not_ leaving out of the airports.

That said, even as a libertarian, privacy-conscious person, I'm not sure I have a problem with exit controls like this. It's important to know who is crossing the border, in both directions.

But why do they even need the photo? Presumably the name is already on the ticket... surely they can detect overstays from names + address alone, not just photos?

<comment><USER9> > It's important to know who is crossing the border, in both directions.

Why?

And if there exists an important reason to know that someone is exiting the country does that same criterion not also apply to exiting a state or city or neighborhood?

I am not being sarcastic; I am genuinely unable to come up with a reason it's important to track _who_ leaves almost any place, except in highly unusual cases (e.g. "OK guys, chatmasta has gone; let's get to work planning the surprise party for when he gets back")

<comment><USER10> Its worth pointing out that the US is literally the only country in the world that I have visited, in my recollection, that does not have passport control upon exiting the country.

<comment><USER11> I know it's not quite the same thing, but most countries in the EU have no passport control upon exiting _or entering_ the country as long as it's within the Schengen zone.

So France has basically no idea who shows up from Germany or leaves via Belgium. The countries on the external borders are supposed to handle all that.

Now I suppose it's possible there is a lot of data exchanged in real time and so on, but it's also possible that is a complete mess and nobody really knows anything, especially about citizens (GDPR).

<comment><USER12> To the parent's point, though, passports ARE checked at the point you exit the Schengen area, whereas they're generally not when you leave the US.

<comment><USER13> They are checked by the foreign country though, not by the country you're leaving.

I have not crossed that many non-Schengen land borders, but as far as I remember it was the same every time, when going from France to England through the channel, Belgium to England by train, France to Switzerland (before Switzerland joined Schengen) and Canada to the US.

<comment><USER12> When flying from a Schengen area country to the US, border patrol on the departing side is entirely managed by that country. Often e.g. United-operated flights from larger European airports will have their own passport check, but that always happens after you pass through the departing country's passport control. At least, this is my personal experience flying between Germany and the US ~once a month.

I have been to a few airports where you explicitly clear US customs at the departing airport before leaving for the US — Vancouver, BC and Dublin Shannon come to mind.

If you've overstayed your automatic 90-day Schengen area travel visa, a common hack for backpackers and such is to intentionally leave the Schengen area from someplace like France that's generally less strict about counting exact days than many other EU countries.

To be fair, I don't have much experience flying from the Schengen area to non- Schengen area non-US countries. It's totally possible this is all rigamarole that the US government pressures other countries to do.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> What is tiring me out about all this "technology improvement" in airport check-in is how confusing it is and how often it changes.

There is no one clear process anymore.

Last week I went to board a flight and checked in using the phone app. At the airport I needed to get a baggage ticket so I used the machine there for that, but it basically had me go through the whole check-in all over again. On top of that the first machine errored during the step to pay the baggage fee so I ended up doing that again with another machine.

Afterwards I went to drop off my bag and was told the tag was not "active" and I'd have to go to the desk.

What the hell is the point of any of these electronic options if at the end of it all I still have to wait in line for an agent, stand there while they "mmm- hmmm" at their computer and avoid eye-contact with me for 5 minutes just to finally scan the tag I had printed and attached myself?

<comment><USER15> Automation and self-serve makes sense even if N% of people fall through the cracks. As long as N is small enough that you can comfortably reduce headcount while not degrading customer experience.

<comment><USER14> In my case I'm pretty sure N is 100%

</comment></comment></comment><comment><USER16> Privacy concerns aside, I can't wait to read the "Facial Recognition let me on the wrong flight when I got in the wrong line by accident" articles that are going to come out of this. Unless these systems have some fantastic (1e-6) P_{false alarm} rate or better, people are going to be mistaken for other people and let on the wrong flight sooner or later.

<comment><USER17> You need at least 2 people for this mixup to happen...

<comment><USER18> You don't, really. Whoever is checked in first gets the seat. The second person will be questioned, and hopefully it will be cleared up. With the number of flights in and out of the US each day, it's bound to happen unless the false positive rate is extremely low, which would only be possible through an extremely invasive cataloguing of photographs beyond those taken for DMV and Passport photos.

</comment></comment></comment><comment><USER19> Here in Australia we have automated passport control gates that scan a chip in our passport then takes a photo of our face (and I assume does some matching with our passport photo) before allowing reentry. It's quite quick and very convenient. Although I'm not aware of any airlines being able to use the system for boarding.

<comment><USER20> Note that is only for international travel.

In Australia, you don't need an ID for a domestic flight; and non-flyers are permitted to walk to the gate, no boarding pass is required to go through security.

<comment><USER21> There's some talk about changing this but I hope they don't. It's really convenient to just walk on and fly - you can do Sydney to Melbourne door to door in 2 hours.

</comment></comment></comment><comment><USER22> I guess now we all know what the REAL ID act was about.

[https://www.dhs.gov/real-id](https://www.dhs.gov/real-id)

<comment><USER23> This was somewhat explicitly what REAL ID was about. Provide name age, address and photo to the feds along with any related state ID info (which often correlates easily with fed info). I would not be surprised if airport cameras already put "citizen ids" on photos for the right folks...

<comment><USER24> IDK enough about this to know who's right, but the DHS denies this:

> Is DHS trying to build a national database with all of our information?

> No. REAL ID is a national set of standards, not a national identification > card. REAL ID does not create a federal database of driver license > information. Each jurisdiction continues to issue its own unique license, > maintains its own records, and controls who gets access to those records and > under what circumstances. The purpose of REAL ID is to make our identity > documents more consistent and secure.

</comment></comment></comment><comment><USER25> > Was my image, in the space of those seconds, sent to CBP, run through a > database, matched to a name, and then sent back to @JetBlue?

Actually, it was probably done in a fraction of a second.

<comment><USER26> Yes, that was a funny thing she tweeted. So surprised that a few KB of data was transmitted on a high speed network in under a second. :)

</comment></comment><comment><USER27> It is annoying that the title of the article is inaccurate. They use an API that calls external government servers to compare the photos.

<comment><USER28> To be fair, it's not clear how these devices work. It _sounds_ like they are taking a photo, submittiting it to an API and waiting for a result. However FTA linked in the Twitter exchange "preloaded photo databased of all the passengers".

It implies that the devices that JetBlue are using for boarding, already have all the photos in them. If this hardware belongs to JetBlue (rather than CBP/DHS/etc), then one would be correct in saying that JetBlue has the passengers photos. So we really don't know either way how this works.

I'll also add my personal anecdote: Recently I flew internationally out of SFO (I live in the Bay Area) and CBP was there to take "exit photos" of everyone with similar style devices. This was not part of the boarding pass process as we still had to do scan tickets afterwards.

<comment><USER29> The same article later states

> "We're basically capturing that picture at the boarding gate, providing it > to U.S. Customs and Border Protection. They're identifying the traveler," > Farrell said. "It's actually the U.S. government that's implementing the > biometric matching system that does all the hard analysis and crunching of > the data."

So I'd say it's more likely that it is CBP who has the database (and not JetBlue).

</comment></comment></comment><comment><USER30> I am curious to how this would work if 2 twins travel together. If it would mismatch or demand both to verify with a manual check?

</comment><comment><USER31> Given the new Travel ID requirements coming up, I'm not surprised in the slightest by this.

</comment><comment><USER32> Can biometric data be hashed like a password would be? Or is the signal too noisy?

<comment><USER33> I would guess they encrypt whatever they send to DHS. Hashing would destroy all the information required to make a match.

<comment><USER34> not necessarily, consider e.g. [https://medium.com/value-stream- design/introducing-one-of-th...](https://medium.com/value-stream- design/introducing-one-of-the-best-hacks-in-machine-learning-the-hashing- trick-bf6a9c8af18f)

</comment></comment></comment><comment><USER35> I sense there's a business opportunity for "finding another person's data that looks very similar to you according to facial recognition models"...

If there is such a person, you could sign up with their name / birthdate and walk through the control points without having to show your ID (which you didn't bring "because you thought the face ID was sufficient").

</comment><comment><USER36> Yet another example that if something profitable is both technically possible and legal, it IS being done whether you know about it or not.

</comment><comment><USER37> Delta too -- though they've been less responsive:

[https://twitter.com/RealPressSecBot/status/11232845870635130...](https://twitter.com/RealPressSecBot/status/1123284587063513088)

</comment><comment><USER38> I can bet that they have a copy of all photos on their servers. No company will be foolish enough to build a business/service that relies on another entity, much so a government organization that is not known for building highly scalable services. This is a crucial part of their process and any delays will impact their bottom line. So they have all faces with them and so does every other company. Also, just the face is not enough, they need all the other identifying info associated with it. So they got everything.

Also, the government organization is not foolish enough to build such a service they get to be blamed for. They gave/sold that data away.

Just the face is of no use, the identifying information that goes along with it is also given. So at this point any company in the US can just query your entire info from your photo. Privacy is dead and it is provided as a service by the government. Wonderful.

Question is can anyone get this data?

<comment><USER39> While I'm totally onboard with the privacy concerns, this is ridiculous FUD to just assume that every company just took on the security and storage risk of holding that data. Find me an enterprise department/exec that would willingly take that on to support a trial.

The corporate bogeyman is a great story but I think you're being a little unrealistic here. These systems typically allow the picture to be sent in with a name, and the system returns a success or fail response.

<comment><USER38> I don't think so. I am being completely reasonable and rational here. Let me ask this, what is special about JetBlue? If JetBlue doesn't host the service on their data centers would they be willing to offer such a service? If a government agency can reasonably be expected to not play favorites and offer the service to anyone within reason, do you think they will be able to scale it up and offer the kind of SLAa expected by money making businesses? Why would an agency want to get in to that endeavor?

Please, offer me alternative view points rather than calling my theory FUD.

<comment><USER40> Presumably the airline could always fall back on traditional paper/mobile boarding passes if the system goes down. It'd mean a bit of a delay, but it's not like the whole operation would grind to a halt.

It's true that we have no guarantee that the airlines won't save our photos along with our ID information, but they _could_ already have been doing that for years. There just doesn't seem to be that much reason why they would.

</comment></comment></comment></comment><comment><USER41> I work for a large company that uses genomics data for health care related research. The GDPR is a huge pain in our butts. But man do I love the "people over companies" attitude of this law as a citizen.

</comment><comment><USER42> It's kind of surprising that we're still surprised by this.

<comment><USER43> It's good that we are surprised. The total surveillance system is being normalized far too quickly.

At this rate, in 10 years we will see even more "conveniences" like for example automatic face id in shops and on websites that pull your payment information and can authorize payments from your card/account - with no setup.

People will say "Kinda spooky how they can just take my money automatically but it's convenient" and you'll be there to say "It's kind of surprising that we're still surprised by this." ;-) I hope!

That will be underpinned by even larger surveillance and data collections on people, that can do a lot of harm when/if data is leaked or the systems are breached.

<comment><USER44> This is already closer than you think, Amazon actually has a physical store exactly like this: [https://www.amazon.com/b?ie=UTF8&node=16008589011](https://www.amazon.com/b?ie=UTF8&node=16008589011)

</comment></comment></comment><comment><USER45> see also how Runa Sandvik got a copy of all her photos from the DHS:

[https://medium.com/matter/how-i-requested-my-photographs- fro...](https://medium.com/matter/how-i-requested-my-photographs-from-the- department-of-homeland-security-97ec2d51f7a0)

</comment><comment><USER46> Honestly, if implanting a chip in my arm meant I could just walk through immigration/customs/check-in without carrying anything I'd do it. I have Global Entry so things are already pretty good but I'd give them anything to ease the process. And it's not like I'm going to lose my arm in the normal run of play so that's even better than my passport.

</comment><comment><USER47> This is dope

</comment><comment><USER48> That's just bizarre. This would never, ever, fly under the GDPR.

<comment><USER49> Are you sure? According to what the airline said, the airline doesn't have the facial recognition data; rather they are just taking photos from passengers who opt in to board via this method, and the photos only need to be stored for a few seconds so they can be sent to DHS for verification.

The airline isn't taking or storing photos of passengers who don't opt into this process, but it is presumably sending the government a list of all passengers prior to boarding so that photos of passengers who opt in can be verified. Would this violate the GDPR?

<comment><USER50> > According to what the airline said, the airline doesn't have the facial > recognition data

I absolutely do not believe the tweets from a company PR representative as to how their technology actually works.

<comment><USER25> Regardless of whether this PR person knows anything or not, I think the much more likely scenario is that they are sending facial recognition requests to a CBP API vs. building their own facial recognition database with 100s of millions of identities out of thin air.

<comment><USER51> But they have your photo after they take it, and the CBP verifies for them who you are. From this information transfer, the airline can replicate the CBP database entry for each person that it takes a picture of... In the long run, they can build a facial recognition database of everyone who flies. Am I wrong about this?

<comment><USER52> No, but whether they actually are or not is another question.

They could also build the same database 10 years ago by taking your picture as you scanned your boarding pass.

<comment><USER51> I haven't done international travel (by normal means), have they always taken your picture for that? Thanks for the info!

<comment><USER52> No, but they could surreptitiously take your photo if they wanted to. I doubt there is much expectation of privacy at an airport gate</comment></comment></comment></comment></comment></comment></comment></comment>


Premium Android hits the wall - <AUTHOR> https://theoverspill.wordpress.com/2015/09/01/premium-android-hits-the-wall-the-q2-2015-smartphone-scorecard/ <comment><USER2> When I bought my first Smartphone, the first one of the Samsung Galaxy series, there was a very notieceable difference in features between the lower end smartphones and the flagships. Buying a cheaper one would have meant half of the 840x400 resolution my Samsung had.

Now I have a Moto G, which is simply good enough for my needs. The improvements a flagship phone would grant over the Moto G are not worth 3-4x the price for me.

<comment><USER3> The curious thing is that the very good medium priced Android phones (200-300€ / $250-$350 unsubsidized) have not had an effect on Apple.

I hope one of the reasons is Apple having publicly stated that using their customers private data is not their business model.

<comment><USER4> I think another part of that (in the US at least) is the dominant framework of carrier contracts and subsidies. This is starting to change in theory but up until now, the norm has been for a person to finish a 2-year contract, walk into a carrier storefront, and choose from several phones with ~$200-250 price tags.

When you see an iPhone next to a Galaxy or an HTC variant with carrier logos plastered all over it, the iPhone seems like the most "premium" option and the price difference is either minor or nonexistent. Besides, the iPhone, through a combination of legitimately good track record and expert marketing has an excellent reputation.

But if you're buying your handset outright, those other devices with less (or essentially no) marketing like the Moto X or the Nexus 5 start to stand out a little more if you're not married to one platform or the other. The difference between $200 and $250 isn't much to the person buying subsidized but the difference between a $350-400 handset and a $650-800 one is obvious. You can almost buy two Nexus 5's for the cost of an iPhone so the glass and metal "industrial design" may start to matter less. At least that's what happened for me.

When I stopped doing the contract-and-subsidy thing to switch over to a $30/mo prepaid plan, I considered an iPhone 5S (the current iPhone) and the Nexus 5. The iPhone was maybe a little bit more capable and had nicer construction but if I got the Nexus, I'd save enough to pay for 11 months of service.

Maybe I'm just a compulsive bargain shopper and spend a lot of time looking for the best bang to buck ratio. Maybe I'm just a cheapskate. Either way, my concern wasn't about targeted ads based on my search and navigation history. It was about not necessarily getting the absolute "nicest" thing out there, but rather something that did everything I needed it to do without spending a premium for that last 10% of quality/reputation/etc.

</comment></comment></comment><comment><USER5> I don't buy premium because the companies track record for upgrading android is atrocious.

Nexus is the line I buy.. unfortunately the lack of sd slot is a bummer.

<comment><USER6> I used to buy premium android phones until a few months ago and switched to an Iphone exactly because of this... The upgrades go through carriers in the UK and EE couldn't be bothered to follow security patches, so I figured it's better to go somewhere that I can at least download updates as soon as they come out.

<comment><USER7> Did you consider Sony Z-series? (Full disclosure: I have one but other than that I am unaffiliated : )

</comment></comment></comment><comment><USER8> The problem is nobody sees these phones as premium they're just expensive.

The solution is to release fewer phones, give timely updates and support them longer (Like Apple).

<comment><USER9> > The solution is to release fewer phones

My wife went into the EE shop ( UK mobile company ) recently to see what was on the market as her old Galaxy S2 was dying.

She came out with a list of six Samsung phones alone and a couple of Sonys. _Is a Galaxy Alpha better than an S6? What 's a Galaxy Mini?_ So bewildered by the permutations that she just threw away the list and bought a second-hand Galaxy S4 on eBay. Potential sale for Samsung lost.

Android vendors might think they're satisfying all possible market requirements but actually they're confusing potential customers. As you say, probably easier just to go to the Apple store and choose between two.

<comment><USER10> That's just a throwback to the featurephones of old, which were bewildering but somehow made Nokia and friends quite a bit of money.

Nobody seems to have picked up on the fact that Apple's success was also based on extreme simplicity: they sold just one model with a variable amount of memory. That's it. They didn't diversify their line until very recently, when they started to feel a bit insecure ("will people really like such a big screen? Fuck it, let's ship both") -- IMHO this simplification helped tremendously in selling to demographics that would have otherwise steered clear of "those nerdy gadgets".

Featurephone-like strategies make sense for upstarts looking for "a market, any market" and small players trying to carve niches; I would have thought Samsung was big enough to play smarter these days.

</comment></comment></comment><comment><USER11> Alternative headline: something vaguely like free market competition has effects roughly in line with what theory would predict.

<comment><USER12> Like iPhones being massively subsidized by the carriers (at least in the US), at the cost of Android offerings, because "We NEED to be able to offer iPhones!"?

Like the abysmal messing around of the carriers everywhere in Android phones' software, crushing any hope of a good, speedy upgrade system for any of them from the very beginning? A thing nobody would ever dare ask of Apple, because "We NEED to be able to offer iPhones!"?

Nope, sorry! At this point, the reason for the iPhone being big is first and foremost the iPhone being big. ~90% of the profits at ~15% market share? Please!

</comment></comment><comment><USER13> > A year back, in the second quarter of 2014, the combination of Samsung, HTC, > LG, Sony, Motorola and Lenovo together shipped a total of 129.4m > smartphones. (...)

> In the second quarter of 2015, the combination of that same group shipped a > total of 114.7 devices.

This is drastic indeed.

<comment><USER14> I can't tell if you're being ironic (I suspect you are), but the figure needs to be seen against the market context: in 2Q 2014, total smartphone shipments were 301.4m devices [1]; in 2Q 2015, they were 337.2m [2]. That's an 11.6% growth. Apple's shipments grew 34.9% [2]. So why did none of those "premium" Android OEMs see an increase in sales, yet Apple, with much pricier devices and fewer models, did? This is the key question.

(Disclosure: I'm the author of the linked post at the top.)

[1] [http://www.idc.com/getdoc.jsp?containerId=prUS25037214](http://www.idc.com/getdoc.jsp?containerId=prUS25037214) [2] [http://www.idc.com/getdoc.jsp?containerId=prUS25804315](http://www.idc.com/getdoc.jsp?containerId=prUS25804315)

<comment><USER11> Surely, given the growth of Xiaomi, Hauwai and "Others" in your own links the answer is obvious? Apple is, to a degree, insulated from competition, since you can't buy a cheap equivalent from a competitor that runs the same OS and apps as your current phone.

I'd also question whether every device sold by Samsung and the other "premium" Android developers you mention, could be considered "premium".

Certainly there's a lot of Samsung devices that are aimed further downmarket than some of those from Xiaomi or Huawei (and vice versa). And even within a single manufacturer, you've not presented any evidence to suggest that people haven't shifted from non-premium Samsung to premium Samsung. (You could argue that would inevitably lead to higher profits, but I'm not sure that high profit is synonymous with "premium", so if that's the assumption then it's worth spelling out).

<comment><USER14> Some argue that Android is itself "a competitor that runs the same OS" \- look how many UI/UX features are common to both.

"I'd also question whether every device sold by Samsung and the other "premium" Android developers you mention, could be considered "premium"."

Of course, they aren't. But one can deduce what has happened to sales of the high-end models from those manufacturers by comparing previous handset totals, and ASP (average selling price). Samsung has said that the S6 + S6 Edge sold about as many as last year's S5, which itself was a disappointment in sales compared to 2013's S4. ASPs have fallen (by my calculations from $350 in Q2 2014 to $317 in Q2 2015 for Samsung; from $331 to $319 for Sony; from $237 to $235 for LG [not much of a fall]; HTC from $388 to $237. Motorola/Lenovo isn't exactly comparable because it spans a takeover period.

(One can calculate the numbers from publicly available figures, but I can't point you to a specific place for them - I just looked them up.)

If ASPs are falling, then generally you can infer that fewer top-end phones are being sold. You can easily think up scenarios where that's not the case, but all the indicators are down: fewer phones, lower ASPs, lower revenues.

"Certainly there's a lot of Samsung devices that are aimed further downmarket than some of those from Xiaomi or Huawei (and vice versa)."

But that's always been the case, even before Xiaomi or Huawei were contenders. However before them, there were few choices for premium features as you can get cheaper from Xiaomi and Huawei and OnePlus and so on.

"And even within a single manufacturer, you've not presented any evidence to suggest that people haven't shifted from non-premium Samsung to premium Samsung."

I think you mean that the other way round? (From premium to non-premium.) I haven't presented that evidence because it's impossible to extract from the available data. You'd need a giant consumer panel, like that run by Kantar ComTech, to see those shifts. But we can say with clarity that the companies that used to define "premium Android" are selling fewer phones at the premium end - which is told through lower ASPs, revenues, handset sales and profits.

"(You could argue that would inevitably lead to higher profits, but I'm not sure that high profit is synonymous with "premium", so if that's the assumption then it's worth spelling out)."

Yes, it is generally my assumption - one I think is accepted more generally than just in smartphones - that premium products attract higher gross margins. Other things being equal, that should feed through to higher operating profits.

</comment></comment></comment></comment><comment><USER15> Sadly the android market is moving to prettier phones at the substantial cost in functionality. So sure there are many phones that look like a premium handset, but they they have an epoxied battery inside and often lose updates in a year or so. Normally you'd expect a nice aluminum and glass phone with top cpu/ram/gpu/storage specifications to last a long time. Except when they expoxy in a disposable battery or no longer gets OS upgrades.

What I find even more baffling is that it's becoming fairly common to offer custom removable backs (at the cost of complexity and thickness) and still not allow for a larger battery or replacement.

Take any 2 year old phone that's seen daily use and it's likely that one of the primary complaints about it's functionality is poor battery life. Normally that could be fixed with $15-$25 on ebay.... only if it's replaceable.

Sad, planned obsolescence strikes again.

</comment><comment><USER16> Is there any mid-range 4G Android phone that you would recommend? My priorities are battery life, camera, tethering, and GPS signal acquisition time (only had a problem with this on one phone long ago but super annoying).

</comment><comment><USER17> No one I know associates Android with a premium experience, thanks to the fragmentation and the abysmal levels of support from the vendors or carriers.

Case in point, I was trying to download a local news app on my Nexus 7 running stock Android 5.1, but it wouldn't, because "this version of Android is not supported", so even the Nexus line is apparently not premium enough for some.

<comment><USER18> I was trying to copy some files over to my iPhone and couldn't. Just plain couldn't. You had to use iTunes, which doesn't run on Linux, so apparently you're shit out of luck. Want to copy files from Linux to the iPhone? Get an Android, apparently!

How's that for a premium experience?

<comment><USER16> iTunes is required to manage the metadata db on the device for music and videos; "any device with DBVersion > 4 does NOT work"[1].

Copying files to/from the device is supported (works well for photos; music and videos won't appear in the native apps): [http://www.dedoimedo.com/computers/linux- iphone-6.html](http://www.dedoimedo.com/computers/linux-iphone-6.html) -> The proper solution

[1] [http://www.libimobiledevice.org/](http://www.libimobiledevice.org/) -> Status

<comment><USER18> Thanks, but I ended up getting an android device. I'm sure there's some way for Linux to jump through Apple's hoops and do this, my point is that the experience was not premium at all. I had to fight the phone to transfer some files, whereas android just let's me drag and drop them in.

</comment></comment></comment></comment><comment><USER19> Am I the only one who feels that "Premium Android" is a contradiction in terms? Naturally, its success would be more wish than fact.

<comment><USER18> Ugh, it's an _operating system_. Why would "Premium Android" be a contradiction in terms? What's so great about iOS that makes it so "premium"? Jeez, with these apple fans and high horses.</comment></comment>


Questions to ask before adopting microservices - <AUTHOR> https://medium.com/@ebin/stop-you-dont-need-microservices-dc732d70b3e0 <comment><USER2> I recently did some reading on microservices, since I had to create a multi- service deployment.

I really don't understand how people are able to manage the complexity when they split every single small domain of an application into its own service. You have to re-invent layers that are normally provided to you by the database, you have to deal with a lot of extreme edge and failure cases and you also lose any ability to statically figure out how data flows through your application (codebase becomes harder to understand, fixing bugs will probably take longer).

In our case, we have each _application_ as a separate service. On top of that, we have some smaller supporting services to make certain things easier, but they're limited and their use makes sense outside of creating complexity for sport.

<comment><USER3> Microservices are for companies with 500+ engineers.

They help teams manage complex interdependencies by creating strong ownership boundaries, strong product definition, loose coupling, and allow teams to work at their own velocities and deployment cadences.

If you're doing microservices with 20 people, you're doing it wrong.

It's when you have 500 people that the average engineer doesn't need to know about the eventually consistent data model of your active-active session system. They just need your service API.

<comment><USER4> What do you do if you have ~20 people and a decade old million line monolith that you're now bumping up against the limits of?

<comment><USER5> 20 people wouldn't make a million line in a decade. That's more like the output of a few hundreds people.

<comment><USER6> Haha, I love comments like this.

We've written over 10 million lines as 20-40 people in the past 15 years. I'll be sure to tell everyone we're not supposed to be moving so fast.

<comment><USER5> Funny enough, you wouldn't be able to work fast at all in a 10 MLOC codebase. Working with and navigating that amount of code is a bummer.

Imagine for a minute, if there were 50 developers (ignoring managers and administrative overhead) trying to understand 500 lines a day (a medium sized module in most languages), they still wouldn't be able to go through half the codebase in a whole year. So basically most of codebase can't be read or maintained.

</comment></comment></comment></comment></comment></comment><comment><USER7> I've had good luck with more of a hybrid architecture: one central monolithic- ish service and numerous supporting microservices to perform specific (usually asynchronous) tasks. The microservices tend to be things that are easily separable from the core of the system and can be turned on or off without affecting core functionality (they also tend to be long-running and/or resource-intensive tasks). This is especially helpful in instances where we might not want to even deploy some capabilities depending on the environment.

I think you get some of the benefits of both approaches here: A single monolithic service that encapsulates the functionality needed for a minimal working system, and the ability to carve off and maintain clearly non-core functionality into separate programs to avoid bloating up the main service.

<comment><USER8> I agree with this. Microservices have their place. So do monolithic, centralized services. Using both in the same system is certainly not a sin, can can certainly be correct.

I'm currently reading through Juval Lowy's latest book, Righting Software. Juval is widely credited as one of the pioneers of microservices [1], and he states in the book that even he doesn't appreciate the term. He illustrates his point by comparing the small, eight-inch water pump in his car versus the huge, eight-foot city water pump that moves water to his home. Both perform an unarguably essential service. But just because the pump in his car is orders of magnitude smaller, does not make it a "micropump". A service is a service no matter how big or small it is.

Should you use microservices? As is the answer to any sufficiently interesting question: it depends.

[1] [https://en.wikipedia.org/wiki/Microservices#History](https://en.wikipedia.org/wiki/Microservices#History)

</comment></comment><comment><USER9> I think that if the question you ask is: Should I use microservices or not? Then you have already failed. The question you should be asking is: Where should the application be split?

Nowhere, or into two unequally sized chunks, are both valid answers. If you can't split a component without resorting to weird coupling shenanigans, then don't split it.

</comment><comment><USER10> Finally someone acting reasonable in this discussion. When I tell people my startup (We're two developers, a few thousand LoC, a pretty simple web service) is built as a monolith people look at me as if I'm crazy. Many people don't seem to realize that microservices are are A tool, not THE tool.

</comment><comment><USER11> My advice is favour places with engineers who both have the knowhow and the power to make decisions based on cost/benefit analysis. There is no right or wrong without context. Beware of places where engineering is driven by hype and/or dogma.

<comment><USER12> You mean the engineers that have rolled out multiple monoliths and microservice architectures across different teams with different backgrounds, all the while keeping careful track of expenditures?

I'm sorry, these people do not exist. People are going to eyeball and wing it, based on personal preference and their gut feeling. Dress that up with good- sounding arguments and maybe even some metrics and you have all you need to convince the stakeholders - who almost certainly don't understand the issue at a deeper level, nor do they care to.

It's also made more nuanced by the fact that people talk about different things when they mean "microservice". Anything can be split up into arbitrarily small services. This is attractive from a management standpoint, because you can assign engineers in a simple manner without too much crosstalk. Most likely, nobody will ever bother to check if you're spending 10x the engineering resources to do the job.

In essence, I can wholly recommend microservices to engineering managers who want to take full advantage of Parkinson's Law.

</comment></comment><comment><USER13> Do not apply rules dogmatically would be a good rule... The willy-nilly breaking up of monoliths into microservices without a good reason to do so other than 'everybody else is doing it too' or 'microservices are cool' are going to result in a lot of busywork and ultimately will not serve your business interests.

If and when the time is right to break out some part of a monolith into a service is probably going to give some kind of net benefit. But breaking up a monolith into > 10 services without having done a proper analysis of the downsides and the benefits of doing so will result in wasted effort.

Monoliths aren't bad per-se, neither are services or even microservices. Knowing when and why you choose each and what the drawbacks of these are for any given situation is something the reason why you have CTO's and architects. Way too often the decisions about this level of granularity are taken at the wrong level with all kinds of predictable results.

Asking these questions is a good start. An even better start would be to ask yourself whether _you_ are the person best positioned to answer these questions, and if not what individual or group of people is.

Most companies (SME's, < 500 employees < 100 devs) do not need microservices but some of them _might_ use them to their advantage. Some problems you won't solve without, some are going to become needlessly complicated if you use them. In most cases either a well architected monolith _or_ a couple of services with a unified front end will work as well or better than either a monolith or microservices. Some environments lend themselves particularly well to microservices (Erlang, Elixer), others are next to impossible to put together without including half of a new operating system.

Use common sense and err on the side of caution. A very good indication that you are using microservices wrong is when they start to call each other horizontally, effectively re-creating RPC or function calls across process boundaries.

</comment><comment><USER14> I was one of two developers who built a large micro-service system from scratch. It was the correct way to do it given the requirements and limitations. The dev-ops overhead was HUGE. Handling multiple repositories, versions, version-dependencies, documenting/coordinating changing APIs between the micro-services.

Even something as simple as having 12 different repositories meant 12 different Bitbucket pipeline yaml files and there was no way for repos to share pipelines. So one change meant 12 changes.

It was good experience, and HAD to be done in that type of architecture, but keeping it all organized was a challenge.

<comment><USER15> One of the major overhead for me was writing tests. I used to get so frustrated because there are so many, so many things to mock / stub.

Do you have any suggestions for testing (Mostly service API testing) ?

<comment><USER16> I'm only probably a month ahead of you but with my research and initial testing I've liked [https://stoplight.io/open- source/prism/](https://stoplight.io/open-source/prism/) so far. There are a lot of other options out there too if you are willing to make a swagger/open api spec

</comment></comment></comment><comment><USER17> A lot of these things do come down to manager or mid-level dev types who just want to use hot tech, either because it's a shortcut to sound like an expert, or they want to do it to gain experience in it.

The problem is, the tech is hot because google etc do it, and they're using it to solve problems light years from what yours might be.

The results are absurdly engineered monstrosities. Simple blog sites with 10 different frameworks in them, running on some absurdly complex cloud infrastructure.

</comment><comment><USER18> My team's currently building a proof-of-concept microservicey replacement for a chunk of our company's platform, based on solid understandings of the problems the existing one has, what it'll need to do in the future etc. The architecture offers some very compelling solutions to these problems.

But we based this on evidence, we're testing everything to destruction, we're embracing tooling to help us manage everything (we could not do this without Terraform or something of similar capability)... but actually, our domain maps to microservices extremely neatly.

It's probably the first place I've ever worked where that's the case.

I like this article, because it draws attention to very real issues and problems with these architectures, and there is an overall danger and enormous risk in using an architecture "because it's good" or "because it's the way of the future" rather than the only correct reason to choose an architecture: because it's the right fit for your problem.

Oh also, because our thing is still a proof-of-concept, we may yet throw it all away and build something else. While initial results are promising, we haven't properly proved the concept yet.

But what a joy to work somewhere that lets us do this.

<comment><USER19> > based on solid understandings of the problems the existing one has

This. It strikes me that developing a clean monolith with well separated concerns _and then_ deciding to pull off chunks into microservices, as being infinitely smarter than the reverse - finding your microservices to be higher interdependent, and trying to glue them back together. YAGNI should be a over- arching principle when starting out a project (and possibly, a business).

</comment></comment><comment><USER20> I'm mostly a solo developer now, and I'm working with microservices all the time. It's very good to focus on a single domain while developing a single part of the system, just like coding modules or classes.

That said, I'm always wondering why we are conflating so many different things when talking about microservices: deployment and scalability, multi-repo and code structure, integration tests and distributed transactions, and so on. I mean: you can definitely build your application in a monolithic system with a microservices architecture. It's just separation of concerns all the way down and a proper abstraction for the communication channel. You don't need to embed your system architecture in your repos and your code. These are "framework" problems. Just use one that abstracts all the deployment details until it's time to push the code to prod and you have to split your code in different containers. For example, I'm now settled on Moleculer ([https://moleculer.services/](https://moleculer.services/)). It just works.

(edit: grammar)

</comment><comment><USER21> Working on a microservices project currently. It is very well designed. Although i think this is not because of it being microservices. It is because of the team of skilled engineers.

Using microservices is complete overkill here. Lots of DevOps, hard to get the mental picture for new people. Also we share a lot of code between the repo's. That shared code is in a separate repo. Splitting of code from one repo and putting it in another repo. Refactoring tools dont like it that much. The quality of the code base is what matters and that is quite alright here.

I liked this line in the article: _But you should always remember; a well designed codebase can always be switched to microservices, as and when you approach the threshold._

I will remember that when I design a new monolith: every "application" in that monolith should be able to stand on its own. Every PR will be reviewed like that.

</comment><comment><USER22> Isn't a monolithic service just kind of a single service micro-service system?

<comment><USER23> I dear to say that a well designed monolith has a lot of mini micro-services build in.

<comment><USER22> Yeah I agree with that

</comment></comment></comment><comment><USER24> We only has 8 services and already see the pain of microservices. We are trying to merge some of them.

I think micro service is a useful technique, only when use properly at a certain scale.

I wouldn't bother doing microservice when team is small and product isn't mature because we still haven't figured out exactly what each service has and may eventually has to duplicate some functionality.

With that being sad, I think thing like auth, push notification is absolutely should be their own services.

</comment><comment><USER25> _> We replaced our monolith with microservices so that every outage could be more like a murder mystery._</comment>


In Neanderthal DNA, Signs of a Mysterious Human Migration - <AUTHOR> https://www.nytimes.com/2017/07/04/science/neanderthals-dna-homo-sapiens-human-evolution.html?module=WatchingPortal&region=c-column-middle-span-region&pgType=Homepage&action=click&mediaId=thumb_square&state=standard&contentPlacement=3&version=internal&contentCollection=www.nytimes.com&contentId=https%3A%2F%2Fwww.nytimes.com%2F2017%2F07%2F04%2Fscience%2Fneanderthals-dna-homo-sapiens-human-evolution.html&eventName=Watching-article-click <comment><USER2> Dupe, see [https://news.ycombinator.com/item?id=14697330](https://news.ycombinator.com/item?id=14697330)</comment>


Trying out Let's Encrypt (beta) - <AUTHOR> https://conorpp.com/blog/trying-out-lets-encrypt/ <comment><USER2> Looking through the code and the issue tracker ([https://github.com/letsencrypt/letsencrypt](https://github.com/letsencrypt/letsencrypt)) I can't help but think they are approaching this wrong... In an attempt to make the certificate install completely hands off and fully automated, they are baking in a tremendous amount of complexity on top of a fundamentally brain-dead simple process.

I need to generate a private key, send you the public key, and get you to sign it. Somewhere in there, I need to prove I have control of the HTTP server on the existing A record, or that I can add a DNS TXT.

I can't say I'm a fan of shipping a SimpleHttp server baked into the tool, listening on port 80 (so run as root) which is also trying to deal with account authentication at the same time as generating the CSR, scanning directories of private keys to try to figure out how to sign the ACME nonce, etc. Getting this 'letsencrypt-auto' process to be able to receive and respond to HTTP requests on my domain is a different class of problem than getting a specially crafted file into a specific path on my domain. The former is clearly much more difficult in production than the latter....

Why not simply a script which;

      - Takes as it's input the CSR and privkey files
      - Does an HTTP GET to retrieve the ACME nonce
      - Sign the nonce, generate the file you need to put on your webserver and tells you
        the path to put it.
      - Prompt to 'Press ENTER once the file is in place...'
      - HTTP GET to indicate file is in place, server verifies, and returns the completed
        full-chain cert.

(An optional parameter with a path to copy the signed-nonce file would make the script non-interactive.)

This could be written in a few lines of bash, right, assuming you could find an openssl command line which could sign the nonce in the correct form?

Keep in mind you have to repeat this process every 6 months with your live site, so what we want are simple composable / pluggable tools which don't try to own too much of the overall process, right?

Alternatively, ship two separate scripts (le-verify, le-certify) which create the ACME validation file and retrieve the cert once the file is in place, respectively.

I'm also not quite sure, why is there any concept of a user account on letsencrypt at all? Hopefully it is optional, I don't see what in this process requires that I register an "account" with them?

<comment><USER3> The _whole point_ of let's encrypt is to be fully automated. Without that, it's just yet another crypto tool with poor usability.

<comment><USER4> If they think that being fully automated is the main reason why people are interested in them they are mistaken. Top two reasons seem to be that they are free and that there are no usage restrictions.

I personally don't want a fully automated process. Shutting down all my virtual hosts to let their tool pretend to be my server is a big NOPE.

<comment><USER5> The "turn off server while it generates certificates" was indeed the one surprise in the process for me (while the rest was quite straightforward, kudos on that).

What I wonder is why it has to be port 80, not another port ?

<comment><USER6> I agree, turning of the webserver is inconvenient and port 80 needs root which I do not like.

</comment></comment></comment></comment></comment><comment><USER5> I've documented how I got it working for my site last night (using manual mode to explicitely specify the domain names), including the dhparams step you'll need to get the A+ rating with ssllabs: [https://gist.github.com/cecilemuller/6d70cb4f463d8a391db1](https://gist.github.com/cecilemuller/6d70cb4f463d8a391db1)

</comment><comment><USER7> I used their docker container in manual mode and the whole process was a great experience. No need to stop the main server. The steps were:

        1. Run the container without ports in manual mode
        2. Use the GUI to enter account data and URLs for the SAN certificate
        3. Let the client print out the challenges
        4. Copy the challenges to the webroots using the provided command
        5. Press ENTER and wait a few seconds. Certs and Keys are ready to be linked from the webserver.

Everything went as expected and I am a happy user of letsencrypt.

[1] [https://letsencrypt.readthedocs.org/en/latest/using.html#run...](https://letsencrypt.readthedocs.org/en/latest/using.html#running- with-docker)

</comment><comment><USER8> Something I miss on all these howto posts about Let's Encrypt is the revocation of the old certificate on renewal.

Say I have a cert that is valid until 2015-12-31, but I want to renew it now.

       ./letsencrypt-auto --agree-dev-preview --server \
          https://acme-v01.api.letsencrypt.org/directory certonly

will get a new certificate, but the old one, as far as I can see, is still valid and could be used for the domain until it expires.

letsencrypt-auto has a revoke function, but there is no easy way to tell it to revoke the last valid cert, or it should do it with a `renew` function.

<comment><USER9> Accoring to [1] revoking is considered an exceptional use case and will not be automatically performed on early renewal.

[1] [https://community.letsencrypt.org/t/maximum-and-minimum- cert...](https://community.letsencrypt.org/t/maximum-and-minimum-certificate- lifetimes/264/14)

</comment></comment><comment><USER10> Does anyone know if letsencrypt can support networked appliances (for example a NAS)?

I suppose I can only sign my nas if it has a domain name?

<comment><AUTHOR> You can technically use TLS with anything. All the certificates give you is a trusted 3rd party that authenticates that a domain is what it claims to be. So if you want that authentication for your NAS domain name, then of course.

</comment></comment><comment><USER11> Has anyone tried this out with VirtualMin?

<comment><USER12> Eric (a Virtualmin employee) has been experimenting with Let's Encrypt for some time, and, as I understand it it is possible to setup manually without any extra hoops imposed by Virtualmin (which is usually the case, as Virtualmin does things in a very standard way, by design). We have plans to include support in the very near future; not the next release, which is coming in a few days, but soon after.

Nothing should prevent you from setting it up manually, but it will be available easily in the near future, as well.

Edit: I just talked to Eric. The official client has historically required extremely new Python versions (newer than any Linux distro for servers ships with), but that's recently been fixed. I think Jamie was already working on implementing our own client, however, because of that problem, so we may end up shipping our own client. Regardless, it'll soon be supported by Virtualmin. We're as excited about it as anyone.

<comment><USER11> Awesome. Thanks for the feedback! Will this simply be a new tab under the SSL options for a virtual server?

<comment><USER12> Probably. Jamie will determine the UI for it, but it'll probably be as simple as turning it on for the domain. Validating the certificate requires either an addition to DNS or to the web root directory; so the domain will need to have a valid glue record, but otherwise Virtualmin will be able to do all the work.

And, it does look like Jamie will be implementing a client for it within Webmin, so we won't need to add the ACME Python client and its dependencies to make it spin. A nice side effect of that is that Webmin alone will also be able to use Let's Encrypt, instead of a self-signed certificate for Webmin itself (of course, people who have purchased certs can use those for Webmin, but if you have dozens or hundreds of Webmin systems, it'd be silly to figure out certs for all of them; even a wild card cert would be a nuisance to deal with).

</comment></comment></comment></comment><comment><USER13> Nice webpage style. What is it?

<comment><AUTHOR> I used a Jekyll theme and have made incremental changes over the past few months to make it my own. You can see the source on my github account

</comment></comment><comment><USER14> What I also don't like is that its python. Nothing against python, however it's really aweful that I need to somehow distribute that files either via tar.gz, unpack install the requirements, etc.. I think a static binary would've been way better, ie. rust, golang, c, c++. even a simple *.jar file would've been better, however that comes with another cost.

<comment><USER15> There are already implementations in different languages, including one in Go: [https://github.com/xenolf/lego](https://github.com/xenolf/lego)</comment></comment>


Three ways to build an ecommerce business to 500m in revenues - <AUTHOR> http://lsvp.wordpress.com/2007/03/16/three-ways-to-build-an-ecommerce-business-to-500m-in-revenues/ <comment><USER2> Is there much to learn from that article? I guess what he says about branding is interesting, but it seems way to simplistic.

Take amazon for example which he puts into the first category. Its not appropriate, they apply themselves accross multiple category not just books and there marketplace (and some other products) are more like a service than ecommerce. Also he gives netflix as another example, I am thinking DVDs have high markups and there rental structure makes them again a bad example.

My real issue with this and his previous article is that its way to over simplified and doesnt give that much useful info except to say don't pick a market thats too small. Am i missing the point?</comment>


Ransomware Creators Let Man Off the Hook Due to His Low Income - <AUTHOR> http://wccftech.com/thundercrypt-ransomware-taiwanese-man/ <comment><AUTHOR> Nice discussion on reddit: [http://musho.tk/l/c375f01a](http://musho.tk/l/c375f01a)</comment>


Last call for Arc bugs - <AUTHOR> http://www.arclanguage.org/item?id=9257 <comment><USER2> Because after today, any bugs you find in the Arc language are _staying_ in there!

</comment><comment><USER3> _"…to push out a significantly better implementation of News…"_

HN? If so, will that be a purely back-end improvement, or front-end as well?

<comment><USER4> It's the version you're seeing here, or something much like it. It's significantly updated relative to the version in arc2.tar.</comment></comment>


Investing Outside the Bay Area - <AUTHOR> http://haystack.vc/2018/07/21/investing-outside-the-bay-area/ <comment><USER3> Ignoring all the risk-tolerant VCs and angels, with billions (trillion?) of capital in the silicon valley ecosystem for a sec. If one simply looks at the big non-US tech companies development offices and hiring activities

Rakuten: San Mateo having most job openings outside Japan, next closest is Toronto

samsung: US having 1100 opening, next is india with 26. in US, there's 114 jobs in california, next is texas with 81

Tencent: only offices outside China is Palo Alto and Seattle

It's clear that most tech companies are aware that all the talents are in Silicon Valley - and because of chicken and egg effects, all the talents come to and stay in Silicon Valley. And when one forms a network in silicon valley, she would be bombarded with job requests with silicon valley companies every day, and if she chooses a better job, it would be still in silicon valley.

<comment><USER4> Maybe true if you're targeting the senior talent who got in early enough to buy houses and have kids, but all the 20-somethings I know (myself included) plan to get out within 5 years, barring a drastic increase in compensation. I suspect there is a large, untapped market of disaffected young engineers who moved here to start their careers but would move to a second-tier city for the right job.

<comment><USER3> There are still alot of cheap real estates along the BART and caltrain stops

[https://www.estately.com/bay-area-home-affordability- transit...](https://www.estately.com/bay-area-home-affordability-transit-stop)

Pittsburg/Bay Point $430,000

Blossom Hill $657,000

San Jose $680,000

And the largest job growth recently has been East Bay, around Pleasanton.

If you are young and starting out, making $110-140k, try living in east bay or san jose and rent a room for $1k - 1.5k, you should be able to save enough money for a down payment for a house soon enough. The stories I've heard for people that couldn't afford their rent, are people living in $3k apartments in SF.

<comment><USER5> Let me try and complicate this :)

First, I submit that $430,000 is still expensive. Instead of buying the median home in Pittsburg and commuting 60+ minutes on BART to downtown SF, I could add an h and buy a huge home in my favorite neighborhood in Pittsburgh PA for about the same price and have a chill bicycle commute: [https://www.zillow.com/homes/for_sale/Pittsburgh- PA/pmf,pf_p...](https://www.zillow.com/homes/for_sale/Pittsburgh- PA/pmf,pf_pt/house,condo_type/11288076_zpid/26529_rid/) (Obvious and legitimate objections: fewer job options, snow.) This is just me trying to say, $430k for that arrangement does not strike me as "cheap" given alternatives in other metros.

I agree that with a tech salary it's possible to save up for a down payment and buy in the Bay Area. But the risk seems unacceptable to me. Paying ~$1M for a house is a big bet that the Bay Area housing market stays hot. I don't want my wealth to be so tied up in a hyperlocal bet like that. I see things going one of two ways (and this is probably over-simplistic).

Option 1: A $1M starter home is the new normal. Prices stay flat or keep rising over the long haul. In that case my investment is sound. But I don't want to live in that kind of place. Where will my kids' teachers live? How will I cope with the moral ickiness of living in a place where housing costs create extreme spatial segregation of the professional class from the service class?

Option 2: The vision painted above is unsustainable. Something has to give (maybe a big financial crash; maybe just state-mandated upzoning that quickly increases housing supply) and the value of my investment drops by a lot.

Either way, I'm planning to save up on the West Coast and use my nest egg back in the Rust Belt.

<comment><USER6> Your view on this broadly aligns with mine (33-year old, live in Oakland).

We bought a cheap (for the area, about 670k) condo just off of BART. It's a pure consumption expense in that I expect to get 1-2% appreciation/year while carrying a manageable debt load. It might go up a bit but that's not the point. We're right off a train line, not paying too much in interest, and building equity. Plus it's a great place to live, lots of young people moving in and we're doing a lot to improve it (lots of deferred maintenance we're working through). Worst-case scenario, we'll rent it our or sell if we move somewhere else; there will always be demand as it's a small, convenient unit in a renter-friendly building, just off of transit.

I share your negative view of the Option 1 dystopia. I have absolutely zero interest in living somewhere on the peninsula like Belmont, Atherton, or even most of San Mateo at this point, where you're basically walled off from anyone of lower socioeconomic class who's your age. Not sure "moral ickiness" is the world I'd choose (maybe just bland? do you really want all your neighbors to have the same job as you?) but it does indeed suck.

I think people who are banking on tons of appreciation buying today in the SFBA really need a reality check. There's just not much higher these prices can go. The common perception is that everyone in tech makes like $300k, which is so far from reality to be laughable.

<comment><USER4> Socioeconomic integration sounded great from afar, but I don't know how how much more sidewalk urine/feces I can take. I'm learning that I'd much rather deal with traffic and drab suburbia than in-your-face extreme poverty every time I try to take advantage of walkability and transit.

<comment><USER7> So it's a binary choice between walling yourself off in an affluent gated community and slogging through human waste in a dystopian urban slum.

Really no middle ground here, huh?

<comment><USER4> If you find one in the Bay Area, please let me know.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> > Redfin, the Seattle-based home buying site/app, has been beating this drum > for years, recently stating that we will see "mass migration" from the Bay > Area based on housing. The CEO writes "Silicon Valley is going to leave > Silicon Valley… the technology companies… they're chasing talent, and talent > is chasing affordable housing." Redfin specifically identifies Denver, San > Antonio, and Houston as the next hubs newer generations will seek out.

Rather odd choice of Texas cities in my opinion. If you're going to go with Texas, I'd think Dallas and Austin are more obvious choices for technical people.

<comment><USER9> San Antonio is a bit more conservative than Austin, but much cheaper and still very nice.

My financial services firm is slowly moving everyone from NYC to Texas and Florida, for obvious reasons.

<comment> crack-the-code I don't think the price differential between San Antonio and Austin housing is high enough to offset the level of talent and appeal that Austin (or even Dallas for that matter) currently provides for the tech scene.

<comment><USER9> Not everyone in tech wants to live in Austin.

<comment><USER10> In software, isn't San Antonio pretty much a company town (Rackspace)?

<comment><USER11> Depends on your vertical. There are a number of O&G related startups. And (oddly) San Antonio rates just behind San Diego and Boston for Medical Device innovation (not software, but still, big tech business)

</comment></comment></comment></comment></comment></comment><comment><USER12> It would be interesting to calculate:

\- cost of living in the SFBA

\- cost of living somewhere other than SFBA but generally "equivalent" in the sense that living there wouldn't be seen as a negative

\- a average-ish amount of VC funds that must be invested in a company before capital is returned.

\- average amount of capital raise that goes to salary

\- what amount of salary is due to cost of living.

It is getting a little bit convoluted, but that would allow you to approximate how much VC money is going to SFBA landlords due to the chokehold on housing supply.

We're seeing a shade of this in the Amazon HQ2 process, but if you have actual physical mobility as an organization over different real estate markets and political jurisdictions it will shift the balance of power in terms of rents and taxation. I don't think it applies to small companies for various reasons, but the motive is there.

<comment><USER13> As a note, make sure cost of living is determined in real terms, not percentages. Oftentimes places with a 80% cost of living will also pay 80% the other wage, which is a bad deal for an engineer because cost of living is not the total of all expenses- so savings and discretionary income actually goes down quite a bit.

<comment><USER14> This. I split time between the Bay and up in north eastern Ca. Reality is, aside from housing, day to day costs are really no different - gas, food, utilities. I'm fortunate to have that flexibility, but percentages mask a number of things.

I was talking to someone recently - with all the "tech" going into the Reno area, housing is getting more and more expensive. The average salary is still in the mid 30k range, however.

<comment><USER15> California is expensive overall. However, other places are cheaper. I lived in Central/Eastern WA (Pasco) for a postdoc before moving to the bay and it was astronomically cheaper across the board even if you ignore housing (1800sqft house on 1/2 acre was $280k in 2014).

Biggest non-housing difference was no state income tax, so save 7-10%, then pretty much all car/gas/insurance were about half. Food was a bit cheaper but not enough to make a big difference. We didn't go out much since restaurants weren't good but thats not really a far comparison.

Where do you live in NE California? I love it up there (and SE Oregon)

</comment></comment></comment></comment><comment><USER16> Bay Area startup scene is dying as is. With few exceptions no small startup can hire talent here anymore. IMO it's a good thing that other cities will have a chance.

<comment><USER17> I'm not from the Bay Area so I'm not aware, how is it dying?

<comment><USER18> (Not OP, but I'm currently founding a startup in the Bay Area.)

I don't have the perception that the Bay Area _startup_ scene is dying, but it's perhaps true that the Bay Area startup _scene_ is dying. Basically, you can't raise a $3M seed round on "I went to (Stanford|Ivy League|other top college) and have an idea for a mobile app" anymore, nor can you raise follow- on rounds off anything but revenue growth. That means that the days where a couple 20-somethings could found a company, hire 10 people, and code by day while partying late into the night are gone.

Good riddance, IMHO.

The _startup_ scene is still healthy, but is very different demographically. Some observations:

Average founders skew older - it's more 30- and 40-somethings that worked for a big tech company and cashed out a million or so in stock options, or had a previous startup exit. (The exception is crypto, which is largely financed through ICO now.)

B2B is ascendant over B2C, and many startups are financing the company with pre-sales from paying customers.

Team sizes are smaller, and many companies are using outsourced labor where they either open an office abroad for engineering, or they use Upwork etc. to find contractors.

Startups in general have gotten cheaper and leaner and are more focused on doing the work rather than living the dream.

<comment><USER10> That's quite a positive take. When I see "lean" startups offshoring/using Upwork to build their offerings, I think the magic has left the bay and that people are trying to squeeze water from rocks. Partying all night might make investors and parents of 2.5 children wince, but that was part of what made unexpected, innovative software possible. It's ominous that startups are forced to outsource because cost of living has priced them out of local talent.

When I look at the bay now, I see a bunch of FANG drones measuring their RSU dicks. People caring more about buying a home and whining about NIMBYs than making cool shit with cool tech. Of course most startups are stodgy B2B and not moon shot B2C, you can't build B2C when your experience is so separate from a normal person's. But another JIRA/GitHub/Slack integration? Ooh, that's the good stuff we can relate to.

Maybe the bay got old, but I don't believe that when I see fresh grads falling over themselves to work at a FANG. Whatever happened, there's not much serendipity left. There will be a tipping point where enough cool stuff is coming out of Detroit/Atlanta/wherever that an investor would be a fool to fixate on the bay.

<comment><USER18> Typically the founders are building the core competencies of their businesses themselves and using Upwork to outsource programming tasks that have been commoditized, like mobile/web development or filling in the gaps once the product architecture has been built. The current funding & salary environment is not kind to non-technical founders, because the technical end of a new product now costs more than you can get in funding without a product, and because the type of ideas you can easily communicate to an outsourced dev team are the ones that have been well-commoditized over the last 8 years. (I still see a number of non-technical founders trying, but they've been struggling hard.)

I do think new startups face significant headwinds now, but they're not the ones you mention. I'm not worried about FANG drones, for example - <USER2> majority of people in Silicon Valley have _always_ been employees of big companies, and often quite self-satisfied ones (do you remember how arrogant Netscape, Sun, and Cisco were when Google was still in the garage?).

Also, significant B2C startups usually come out of nowhere, from small teams that were toiling away in obscurity for years beforehand. Do you remember 2007-2010? I was part of the Web 2.0 boomlet, folded up my startup in '08, and proceeded to watch most of my peer companies die over the next 2 years. But while we were all folding up our social networks, AirBnB (founded '06, household name '11), DropBox ('07, '10), Uber ('08, '10), Instagram ('08, '12), WhatsApp ('07, '11), and Thumbtack ('07, '13) were continuing to work on their startups, many of them breaking _a lot_ of common wisdom about what made for a successful startup. When the time was right these services exploded, but we had to go through a huge startup drought from 08-10 in the process.

The factors I'm more worried about are: 1) The average American consumer not having money, which makes B2C business models other than [advertisement, pyramid scheme, extortion, selling personal data] impractical 2) Attention being so focused on politics and tribalism that consumers are too fearful to try anything new and 3) Moore's Law disappearing. I'm not terribly worried about this last one because we can still get another factor of 10-100X out of better programming languages, OSes, and frameworks, and GPUs/TPUs continue to increase in power.

</comment></comment></comment></comment></comment><comment><USER19> Advice to talented professionals everywhere:

If you have reached the age of 30, you should already own your home. If not, buy a home immediately. NOW. If you can't afford anything decent close to your place of employment, quit your job and move somewhere where homes are more affordable. Your future happiness depends on it.

<comment><USER20> Can you elaborate on this? I'm nowhere near 30 yet, but I'm curious as to why my future happiness will depend on it.

<comment><USER9> The longer you wait, the more you're priced out of the market and reliant on the whims of a landlord.

Now, one could argue we're at the peak of the current business cycle and asset prices are overly inflated. And there might be merit to that. In that case, look for real estate bargains where you'll have equity on day one (short sales, foreclosures, assets priced below their fair market value).

<comment><USER21> > The longer you wait, the more you're priced out of the market and reliant on > the whims of a landlord.

That's only true if the value of your portfolio or salary aren't increasing faster than the market.

I've personally teared up in housing about every other year. It would have been much more difficult to do this is I owned rather than rented.

<comment><USER11> > teared up in housing

What does this mean? Moved? Every two years? Sounds horrible. Don't you have any hobbies to fill your time?

<comment><USER21> Autocorrect fail. Tiered.

Yes, moved every two years. Not ideal, but couldn't have afforded the places I moved into two years earlier and moving produces high quality of life gain.

<comment><USER11> > Not ideal, but couldn't have afforded the places I moved into two years > earlier and moving produces high quality of life gain.

Maybe it's years living in substandard student housing, or years in "not-in- the-US" housing, or even a couple of years being effectively homeless, but anytime I get more situated than living out of one suitcase and one computer bag, I find moving to be a burden that (generally) outweighs what you call the quality-of-life gain. That's me, and I'm probably inertia oriented in everything except the companies I start/assist/work-for. I love tuning the business to be better. But I often just go home, maybe to a dump or dive, and open a can of tuna fish for dinner. (My kids don't seem to understand that either - so I'm guessing this isn't normal)

EDIT: My (now) ex-wife lives in a nice house, with a fair number of upgrades, in a nice neighborhood. And my kids get to live there too - nice schools too. So, that's nice. But I don't think it is anything I would have ever invested in or developed for myself without her prodding. (Which might be why she divorced me, but I suspect it was probably slightly more complicated than that. But, still, it probably should have been enough!)</comment></comment></comment></comment></comment></comment></comment>


Can You Afford It? Real-World Web Performance Budgets - <AUTHOR> https://infrequently.org/2017/10/can-you-afford-it-real-world-web-performance-budgets/ <comment><USER2> Do we need all this JS? I'm starting to look back at classic web development where you had a server rendered mvc style app. There was a controller and templates populated on the server. Every page was a full rerender, but it was small html. Proper caching kept the minimal CSS and images on the client for a regular session under 30 minutes. This seems better.

I know we switched because front end experts told us that users found the full refreshes annoying. They said that users really wanted native desktop like seamless change pages. Never did I see proof of these claimed. Is the modern JS based design our cubicle moment? Did we get suckered in by experts making productivity claims with nothing to back them up?

<comment><USER3> "Do we need all this JS?"

I know at least one user who is asking this same question. He does not believe it is needed.

Is it possible that "what users want" and what developers want may be two different things? Could developers have wants that are unique to developers?

Purely anecdotal but I do not know any fellow users who "want javascript". I know many who do not want a number of common annoyances though. And I know these hassles are in many cases enabled via javascript.

The tactic leveraged against users is to tell them they _need_ javascript for some thing to work. Then users want it. But I think really they just want the thing to work. They have no particular affection for javascript, let alone any knowledge of _why_ they need it.

One thing I have observed over the years the web has existed early 1990's to today is that users can adapt to anything. Whether it was learning keyboard shortcuts on the console and using text-only programs like Pine, or running www searches that took minutes to finish, or communicating with 140 characters or less, or working with tiny touchscreens and horribly slow web pages and mobile apps. Many more examples if I gave it some more thought. From what I have seen, users accept what they are given and find a way to make it work.

<comment> aaron-lebo How do you notify a user of errors in input without a complete page refresh if you do not use Javascript (ignoring the most basic HTML stuff)? Without at least some scripting capability, you're talking about making the experience worse for the user to the benefit (ease of the request/response model) of the developer.

Don't throw the baby out with the bathwater. It is the responsibility of devs to use technology well. You don't want all of this JS, but you do want some of it.

Too many people are making their assumptions about what is possible and what JS is capable of based upon views of web development that are 5-10 years out of date or based on bad software. Bad software is endemic to the industry, it's not representative of any single tech stack.

<comment><USER4> You just let the page refresh. It's really not that much different. I am not saying don't use JS for UX improvements mind you. But your comment suggests that any other approach makes no sense. If you have a massive form that has 12 fields then it would be a huge help, but just a couple of text fields? Why replicate the backend validation in client side JS when it's already there on the backend? Then you would have to maintain two code pathways in two different languages in two different locations if you need to update the validation rules. Where simple works, pick simple.

5 years ago was 2013, there were some pretty great things going on in the web in 2013. Don't lose sight of lessons learned by previous work either. A new shiny framework doesn't automatically make it better practice.

While we are reinventing the wheel in client side JS we should make sure to remember that it has probably been done before, software has been around for decades, the web as well, and to think the best of it has only just happened in the last five years is a bit misguided.

<comment><USER5> This. You can't trust client-side validation anyway, so you need to have some server-side. So why not just let the page refresh, and then add a _tiny bit_ of JavaScript that'll send off the form via AJAX to validation?

Suddenly, the site becomes solid, lightweight, and supports everyone. That's what I think people used to call "progressive enhancement".

<comment><USER6> I would love to have a way to tell the browser "don't throw away the current DOM, Just apply the differences". It would work nicely in non-js page to make the experience smooth (and would probably work terribly if there was a lot of J's, of course)

<comment><USER7> This is exactly what React's virtual DOM does. Maybe the future is making the virtual DOM native to the browser?

Bundle React with Chrome? Or how about a browser package manager that could cache and reuse all these common js libraries used on so many sites?

<comment><USER8> DecentralEyes does just that.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> > 45% of mobile connections occur over 2G worldwide > 75% of of connections > occur on either 2G or 3G

this is so important. if you want growth you need to be making a product for growing markets.

<comment><USER10> No, you need to assess where your customers are and focus there. Just because a market is growing, it doesn't mean that market contains customers for your product. That depends on numerous variables including pricing.

The US will add ~$570 billion to its GDP this year. That's equal to 25% of India's entire economy. An increasingly large part of Europe is back to generating solid growth again. Even Japan is showing signs of life. You don't need to focus on 2G markets if there are few customers there for your products.

<comment><USER11> > You don't need to focus on 2G markets if there are few customers there for > your products.

as someone who used to have a poor internet access, rest assured that I will have no sleep until every review website and comment section has something about how slow your website / app / whatever is. These ones generally don't lag.

</comment></comment></comment><comment><USER12> Meanwhile, HN loads like a charm and time to interactive seems to be less than 0.5s

Seems like that's what happens when you are too deep in the js bog, and you forget what is below the thick js cover

<comment><USER13> I recently launched the landing page[1] for my startup and the designer gave us a crazy animated design.

All of my personal sites never required JS and have always worked just fine in Lynx. I didn't want any JS on the landing page (not even for analytics, we can do that server side), so decided to see what HTML + CSS can do these days.

I was pretty blown away with how easily I was able to have a half-dozen animations running in parallel with 3 videos playing and being transformed in a 3D space.

Even better, the page works perfectly fine in Lynx! I recognize that there are times with the modern web where JS is required, but I try my damnedest to minimize it. And modern web standards make it easier in ways that were impossible a decade ago (e.g. no more $.fadeIn()).

[1] [https://banter.fm](https://banter.fm)

<comment><USER14> If you add an overflow:hidden to your content section, you won't have that wonky extra space to the right. That's just a quick fix. I didn't look into why it was happening.

</comment></comment></comment><comment><USER15> It's 2017. It's shameful that our expectations for web speed should be this low.

<comment><USER16> I was going to say this but wanted to read the comments first to see if anyone else did.

The constraints on global technology sever for this budget. But I have a personal standard of 200ms for TTI on my projects, and I push hard against any requirements or suggested libs or UI features that broach this.

5 secs? You can get away with that if you're a global brand that people are already hooked into, I guess. The amazon iOS app is infuriating on a brand new iPhone 8 on gigabit WiFi. And that's an app where every second of load time is lost revenue. They do not, apparently have any kind of budget concept.

Facebook is similarly awful. They can afford to blow their load budgets because users are already locked into the network. Or at least they think they can.

When I'm bringing a new app to market, speed is my highest priority feature. And the feature backlog is organized by cost of speed, not by difficulty or time to market.

And like another poster said above, most of this is completely unnecessary. Be a dinosaur. Write "MVC" apps with server side rendering and deal with Ajax where you have to for as long as you can. Write the very little bit of js you need, and rock on.

It's not hip, and it's not always fun. But it's fucking fast.

<comment><USER17> sorry, but 200ms for TTI on the web? are you measuring the same way that he is? he includes 1600ms just for dns lookup and tls handshake

<comment><USER16> Sorry I wasn't clear about that.

The article is using some very heavy constraints on networking and hardware based on a global, mobile audience.

My constraints do not take that into account. But they would only add a max of 200ms on top of that minimum the article is talking about.

Not anything near ~4 secs. 4 secs to do anything on a web app is malpractice.

</comment></comment></comment></comment><comment><USER18> Front-end developers could solve all of this by just learning the base technologies of HTML, HTTP, CSS, and JS really well and ignoring everything else.

We're at a beautiful point in web development where browsers are finally unified on open standards, and we're all too locked into these outdated JS frameworks to take advantage of it.

<comment><USER19> It's important to strike a healthy balance between reinventing the wheel and locking yourself into a bulky framework. Whether you are building a personal project, or working on another's time, in the early phases your #1 concern should be speed of development. If a compact, properly modularized, battle- tested tool that completes your desired task is readily available, should you really be wasting your time writing something that's been done a thousand times before?

I've been around the block with popular front-end frameworks. The first one I've truly found to be a joy to use is Mithril.

Unlike React, a framework that's gotten a lot of buzz here lately, it's more than just a view library. There is a routing paradigm in place along with a few other goodies. Yet it all weighs in at <8kb gzipped and generally performs faster than React. It really feels like it hands you just the things you need to get started and steps out of the way.

Check out its performance compared to a few other popular frameworks:

[https://mithril.js.org/framework- comparison.html](https://mithril.js.org/framework-comparison.html)

<comment><USER18> But you are missing my main point: what are all these frameworks for?

I bet if you asked any front-end developer what the main benefit of their chosen framework is, they will say something like code organization or file structure.

It used to be that you _needed_ a framework to abstract away all the browser incompatibilities. But that was in 2009 -- look up any given W3 standard on CanIUse these days and you will find support across all major browsers.

What if we could just get by without a framework? And just organize our own code? Is that so far-fetched?

</comment></comment></comment><comment><USER20> It's nice of you to make your web presence work for someone with 400Kbps link with a 400ms round-trip-time ("RTT"), while you're at it, also make sure it works with JavaScript turned off! And browsers with limited CSS support. And is readable on a terminal browser. And 600x400 px resolution.

</comment><comment><USER21> It's remarkable how much js gets loaded onto a page (mainly due to libraries) vs. how much of its functions are needed for what the web developer is trying to do. There just is not a whole lot of use cases for the big libraries unless you're doing something really intensive like a drawing app.

<comment> crooked-v Tree shaking should help... eventually.

<comment><USER22> Next year, in Jerusalem

<comment><USER23> You can have tree-shaking right now, with rollup.js. You can also have purely transpiled isomorphic component library (no runtime download) running at near vanillajs speeds with svelte.js.

</comment></comment></comment></comment><comment><USER24> His argument is based on an example where he puts JS in <head>, when it's been a recommendation for ages to put JS at the very end of <body>.

<comment><USER25> It looks like he needs the JS to load first for the browser to make sense of his custom elements: "If our example document wasn't reliant on JavaScript to construct the <my-app> custom element, the contents of the document would likely be interactive as soon as enough CSS and content was available to render meaningfully."

<comment><USER26> Howdy; author of the article here.

TTI would be pushed back _regardless_ of where the script was included so long as it executed for more than 50ms (very likely). I used a trivial document that contains many pathologies I see in traces to illustrate the point, not to suggest what ideal apps will do.

</comment></comment></comment><comment><USER27> I'm sure there are niches out there where complex web apps are best built without an SPA framework, but use the right tool for the job! If I'm writing an embedded interrupt routine, I don't use slow clunky C, I use assembly. If I'm writing a complex web application, I use an SPA framework like Vue. If I'm delivering static content, I use minified html and css.

Everything comes with a tradeoff. If you pick the wrong tool, it's a big headache.

Learn to use all the tools.

</comment><comment><USER28> Most of the requirements for Google's AMP project help bring down TTI by a large margin if you follow them as well.

[https://www.ampproject.org/docs/tutorials/create](https://www.ampproject.org/docs/tutorials/create)

</comment><comment><USER29> I think the article makes some valid points, but it's important to remember that PWAs are just getting going. The existing SPA frameworks are still a little crude at the moment, but there is definite progress. For my own app ([https://usebx.com](https://usebx.com)), I eventually ended up writing my own front end framework, as existing frameworks at the time felt rather bloated. Now, however, things are starting to look better with the likes of Vue.js etc coming on the scene. I also feel that PWA development will explode once Apple ships service workers with Safari, and that will bring along with it even more motivation to innovate in this space.

<comment> crooked-v Given how much iOS restricts any kind of background thread and how service workers require being run independent of a specific page context, I would be really shocked if iOS literally ever provides support for them.

<comment><USER30> The service worker spec was deliberately designed to give the browser, not the site, control over resource consumption. The browser is permitted and encouraged to keep them on a tight leash on behalf of the user's experience. See e.g. [https://github.com/w3c/ServiceWorker/blob/master/implementat...](https://github.com/w3c/ServiceWorker/blob/master/implementation_considerations.md#event- driven-workers)

</comment></comment></comment><comment><USER31> Actually, I think it is more important to be aware of the issues and handle them than to set strict size limits. For example, a few years ago I lead a redesign project for a mobile web shop and the designer told me he was not allowed to include icons as our CIO had set the limit of the page size to 100k (including all images).

By the end of the project the page size was about 200k, but when the sales were ~20% higher (multi million $ shop) nobody asked about the size limit anymore.

So yeah, page size/load time is important, but please keep reflecting what you are doing. The best load times are no good, if (as a result) the UX is poor.

</comment><comment><USER32> It's also funny how many of my friends use $TrendyJSFramework for a portfolio site! Personally prefer to have all my content statically served unless I'm building some sort of an interactive single page application.

I run [https://discoverdev.io](https://discoverdev.io) for which I wrote my own SSG framework in python+jinja, I spit out html and push it to netlify's CDN network. It's smooth, I don't have to worry about scaling and it works like a charm! (I could still do a lot of optimisation wrt image compression and minification though)

</comment><comment><USER33> Just pushed live an app today that I had to cave and add babylon-polyfill so it would work in IE 11 after trying to polyfill a dozen missing es6 runtime features from various sources.

That made the final JS output 25% larger, a 90kb increase from the polyfill library alone, so here's a serious optimization waiting to happen (the natural dying of an older browser).

<comment><USER34> Couldn't you load babylon only in case the browser lacks the desired features?

</comment></comment><comment><USER35> How come no one monitors their speed as much as they should?

SpeedCurve and Calibre are great options listed in that article. Also suggest MachMetrics [https://www.machmetrics.com/](https://www.machmetrics.com/)

</comment><comment><USER17> i cut my personal site's TTI by 62% after reading this. I just was lazy about performance when there were some real easy wins. i do wish for more guidance on how to do PRPL in React (without necessarily doing full Next.js which is too opinionated for some of the stuff I want to do)</comment>