> After the user downloads 2MB of JavaScript, waits for it to parse, waits for it to execute, waits for it to hydrate, waits for it to fetch data, waits for it to render... yes, then subsequent navigations feel snappy. Congratulations.
In my experience, a lot of SPAs transfer more data than the front-end actually needs. One team I worked on was sending 4MB over the wire to render 14kb of actual HTML. (No, there wasn't some processing happening on the front-end that needed the extra data.) And that was using graphql, some dev just plunked all the fields in the graphql query instead of the ones actually needed. I've seen that pattern a lot, although in some cases it's been to my benefit, like finding more details on a tracking website than the UI presented.
even for "downloads 2MB of JavaScript", it is often simply because the site is badly written (e.g. not careful about managing dependency), not necessarily because "JAVASCRIPT BAD".
Just look at the source code of amazon.com. It's a mess. But I bet it is more of an organizational problem than a tech stack problem, for a website worked on by literally hundreds of teams (if not more) where everyone crams their little feature in the website home page
> it is often simply because the site is badly written
I find that some techs tend to cause badly written code. I have junior coworkers that can write clear Python after a short intro, but can't write clean R after a year using it daily. I don't know if it is caused by the philosophy behind the language, the community, the tutorials and docs...
Could use projectors to display the feed directly onto the ground or a building wall, in some ways that may be more impactful. You'd have to stay with the projector and power source, but easier to move to the next location, and less of a chance of getting in trouble for defacing public property, etc.
My N900 was one of my favorite computing devices that I've owned. The keyboard was good enough for my needs, I could open a terminal quickly, battery life was fine. If someone came out with a modern version that had a slide out keyboard and similar size, maybe running a raspberry-pi level CPU, I'd buy it in a heartbeat.
Airframes have a limited lifetime, partially defined by takeoffs and landings (and pressurization cycles). Cargo planes experience fewer cycles than passenger airlines since cargo carriers' aircraft usually only make a one or two flights a day, whereas passenger aircraft a flown back to back as frequently as possible. Historically, cargo carriers would buy used aircraft and convert them, but that's changing.
This particular aircraft was acquired by UPS in 2006 and converted for cargo missions. It was originally delivered as a passenger aircraft to Thai Airways International in 1991. [1] I actually saw this exact aircraft at RDU International in August of this year and took a photo, since tri-engine aircraft in general are not very common these days.
The gist is correct, but the subtleties are hiding in the details.
Wide-body (long-haul) airplanes are generally limited by flying hours since they rarely reach their maximum allowed flight cycles.
In contrast, wide-body cargo planes typically fly shorter legs compared to when they are used as passenger carriers. And as a result, they are much more likely to hit their critical cycle limit.
I used to own an MG B GT, which was always in a state of disrepair I have become accustomed to with older British vehicles. One day I drove it to a nicer restaurant where I learned they only allowed valet parking. I urged the attendant to make an exception for me, but he refused. I shrugged, got out and it immediately stalled. I explained a few things to him, like not being shy about using the choke even after it was warmed up and running and a quick shot of throttle before putting it in gear to keep it from stalling, etc. Then I stood back and watched the poor guy lurch it past the rows of cars to the edge of the lot.
When I came back out, the attendant that had parked it was nowhere to be seen. I handed him the tag, he retrieved the key and a few minutes later off in the distance I heard him trying to start it. He managed to get it out of the parking spot before he gave up and motioned for me to walk down to him. After some discussion, he gave up and let me drive it out of the lot.
That must have been a while ago. The last time I encountered a "valet only" parking lot, I told the 20-something valet it was a manual, and his face turned white, he paused for a few seconds, and then he said, "go ahead, you can park it yourself."
> a state of disrepair I have become accustomed to with older British vehicles.
Figures. You MG owners! Did you have a hammer with you for when the points in the fuel pump needed smacking? ;) I drove a '65 Triumph Spitfire for about five years back in the early 00's and it was reliable as a top (after I repaired all the hack work that previous owners had done to it).
I've also found my work MacBook Pro heating up my backpack sleeve a number of times because it didn't properly go to sleep. Likely culprit is some "security" spyware the company installs.
There are a few members in my amateur radio club that have a (~200) collection of CW keys. Bugs, paddles, straight keys, etc. Some very obscure ones (only one or two made), some old ones, strange designs, etc. They'll occasionally bring one to a club meeting and pass it around for people to examine and try.
In my experience, a lot of SPAs transfer more data than the front-end actually needs. One team I worked on was sending 4MB over the wire to render 14kb of actual HTML. (No, there wasn't some processing happening on the front-end that needed the extra data.) And that was using graphql, some dev just plunked all the fields in the graphql query instead of the ones actually needed. I've seen that pattern a lot, although in some cases it's been to my benefit, like finding more details on a tracking website than the UI presented.
reply