chalupa-man

The Starbucks app in Edge is _miles_ faster than Amazon.com or eBay.com for me on my slow satellite connection. I think this is one often underlooked feature of SPAs. SSR stuff is a blank white screen about 50% of the time for people on slow connections, SPAs have a slower initial load and then from then on are either faster or _feel_ faster because they don't go completely blank for 5+ seconds every time you click something. Even a slowly-loading SPA feels better than any SSR site for that reason, IMO.

I couldn't possibly disagree more. Voice comms are _hideously_ inefficient and limited compared to chats and virtually always an inferior option in a group context, in a professional context, and especially for a professional team. They always interrupt one person, and every additional person involved is a decision about how much more time and attention to take and how many more interruptions to make balanced against who to leave out of communication. They are slower for groups over around 4 people, they are more likely to produce misunderstandings, more likely to omit details. They make it harder to refer back to things, they leave less of a window for people to gather their thoughts and word things clearly. They are far more likely to be rushed through because the communication is fully synchronous. They cannot divert into simultaneous side conversations. I struggle to think of situations where I'd rather have a voice call than a text conversation.

If a potential employer told me they relied on VoIP phones over Slack/Discord I would consider that a _major_ point against them.

It is generational, rather than tied to education. Even very well-educated Koreans born before around 1980 tend to believe in this. I would say it is close to 100% of people over 40. My parents, grandparents, aunts and uncles would call you stupid for not believing in it. My doctor believed in it. Younger people believe in it less often but it is still very common.

One of the increasingly popular uses of JS is to save bandwidth. Using JS, you can ask the browser if the user is on a metered connection or an unlimited one, what their estimated bandwidth capacity is, what their real resolution is, and load appropriate assets (or conditionally load content). With JS disabled, a user on a pay-per-kilobyte 360x640 cellphone is going to get assets deemed acceptable on the manager's 1440p desktop. There are already quite a few websites where disabling JS more than doubles your bandwidth usage -- and sites that are only even usable in third world countries because of JS like this -- and that's going to increase as screen and media quality grow.

Not to mention the huge accessibility benefits that can come from changing the way a site behaves (not just visually but in terms of things like tab and focus behaviour or separating components out) for disabled users. Doing that reliably and effectively for all content on all devices is much easier if you can identify the needs before downloading the content which means JS-loaded content and so it can come down to deciding whether to annoy NoScript users or disabled users.

Firefox recently switched to a design that tends towards a higher base memory usage than Chrome, but a lower usage for each new tab. With the same 30 tabs open and no extensions, the current Firefox uses ~30% less memory than Chrome. But opened only to one tab, Chrome uses ~60% less memory than Firefox. It's an interesting tradeoff.

There are dozens of fully-automated train lines, some with attendants but many with absolutely zero personnel onboard, and the number is expected to quadruple within 10 years.

https://en.wikipedia.org/wiki/List_of_automated_urban_metro_...

This is surprising, I've never seen anyone say that IDEA is faster than VSC. In my experience it's _vastly_ slower.

It applies to men and to women, and not to blemishes or colours but to reshaping silhouettes. It's worth taking thirty seconds to read something before attacking it as stupid based on your imagination.

"Than any other large country" is a big stretch. The US is ranked 43rd on this year's Press Freedom Index.

It is worth noting though that those figures are American, but Netflix and the Disney decision are global. The US is a bit of an outlier in terms of both the cost and popularity of cable TV. For example in Australia, a country very similar to the US in terms of pop culture and entertainment, only around 25% of homes have cable TV and the most popular package is US$39. In the US the cost can be looked at as '5 services to replace cable TV' but in most countries it does instead look like broadcast-TV content being moved behind new paywalls, with increasing costs to watch the same shows.

I'd say that's a bad example, because the US is a bit of an outlier in struggling with adoption. Most developed countries switched without a hassle a long time ago (25 years ago in some cases). I actually wasn't aware there was something _other than_ EMV until I came to the US.

It's the word or similar to the word for the USA in a few languages, like Esperanto ("Usono": the USA, "Usonano": a USA citizen, "Ameriko" already being used for the continent and "Amerikano" for people from that continent). It was a term introduced in the 1800s without a lot of success, then after its use in Esperanto it was mildly popularised by American architectural legend Frank Lloyd Wright, who embraced the term and described his work as "Usonian architecture" and wrote at length about "Usonian character."

Note though that disabling JavaScript can also slow down many sites. One good use of JavaScript is to detect the speed of the user's connection and then load in smaller and lower-quality assets. Disabling JavaScript can result in the default assets being loaded, which rapidly offsets the benefit of not loading that JS. Other sites will load in portions of the content first and use JS to load in extra chunks as requested, but load in the entirety of available content if JS is disabled, slowing down initial pageload enormously.

Elm is a language, but it's sort of automatically a framework as well. There's a function in the standard library called Html.program that takes four functions as arguments and returns a React+Redux style application from them. The Elm runtime exists solely in the browser and expects your main function to return some HTML, which it will display using a virtual DOM. They call this pattern 'the Elm Architecture' (TEA) and recommend that everyone use it. So it's like having a really lightweight framework baked into the standard library and indistinguishable from it.

Those four functions are view (take a model and return some HTML, like a React top-level component's render method), update (take a model and a msg/action and return a new model, like a Redux reducer), init (an initial state) and subscriptions (a list of things to watch for changes and automatically create msgs/actions from, like mouse movement or websockets). When you run a program, it feeds the initial model into the view, and renders it. HTML elements can create messages (dispatch actions) based on DOM events, and subscribed things (like websockets) can also create messages. Every time a message is created, it gets fed into the update function with the existing state, and you branch on the message type to figure out what the new state should be. Then that new state is fed into the view function again and the result is diffed against the virtual DOM and the optimal update made.

The biggest differences between React and Elm are that you don't mess with lifecycle hooks and that you don't repeat this pattern for every sub-component. Instead, you just write lots of small functions that take a model and return some HTML, and you can call those from your top-level view function -- a bit like building everything out of React stateless components.

Writing any Elm code feels a lot like writing React, but with much less boilerplate, reduced complexity, excellent error-catching, and static typing.

I find it really fortunate. SPAs can use much much less data for the same content, which is a big plus when you're on a data-limited connection, as most users in the developing world are. If you spend much time on a site they also demand less CPU and thus less battery life (vdom updates are less intense than new page renders), which helps when you're on a mobile connection, and they feel much more responsive when you're on a high-latency connection, which you are again if you're in the developing world or on mobile. Server-side rendering feels like getting a faster and lighter initial load in exchange for heavier, slower, more battery-draining usage overall.

You can stream anything at any bitrate, but 2x 720p on 5 Mbps would be a very extreme case. That would be a third to a quarter the bitrate of a 20-year-old DVD, or 3.5 - 7% the bitrate of a Blu-ray disc. That's less than half the 'Extremely Low' preset of the Sorenson encoder, the lowest you can go without defining custom options.

You'd want to stream more than one movie at a time if you had more than one person in a house.

For example, I used to live in a house where there were 5 of us. I really wanted to subscribe to Netflix, because it was 1/10th the cost of cable TV and suited my needs even better. But the connection just wasn't strong enough for two people to stream video at once so it meant we had to work out a timetable of who could watch movies/TV when, swap blocks if some live event one of us wanted to watch came on, etc, and it just wasn't worth the inconvenience.

Most people live with other people.

They've sold 63.3 million 3DS units (counting the 2DS) and 14.7 million copies of Pokemon X & Y, the bestselling Pokemon game on the platform. So while it's undoubtedly a very popular game I don't think you can rank it above cost as the reason so many people were buying handhelds to use at home.

I have an iPhone 6S and my battery life when 3D gaming is about smack in the middle of the Switch's range. Admittedly the Switch is presumably going to run better graphics, but still -- its battery life is about the same as cellphone battery life.

I think something had to change eventually. When the 3DS was announced, iPads weren't on the market (so tablets were still a very niche thing) and smartphones were still quite new. In the 7 years since, they've become omnipresent, and it didn't take long for them to become massively more powerful and capable than the 3DS while also being much more portable. I think Nintendo were justifiably worried that if they stayed on their current path, the next handheld wouldn't survive 7 years, just being utterly demolished by phones and tablets. At the same time, the Wii U was a relative failure, and it looked unlikely that they'd ever recapture the audience that made the Wii a phenomenon -- for related reasons, the Wii was an affordable novelty smash with people who weren't big game fans, and that market has all their needs satisfied by their phones and tablets now. So it makes total sense for them to fuse the handheld and console worlds together and focus all their efforts on one platform.

To my disappointment, personally. I wish it were a home console rather than a handheld for reasons that are entirely based on my own needs and tastes (I'll never take it outside so it adds cost for no benefit, the need for portability means games can never really make great use of the motion controls, a lot of multiplayer seems based on the joycons which look absurdly small for adult man hands).

The PS2 beat the GCN to market by a year and had not only analogue shoulder buttons, but analogue face buttons too. Even the d-pad was analogue -- everything except Start/Select/L3/R3. It wasn't very widely used, and causes some problems in porting games that relied on analogue face buttons (like Metal Gear Solid 2 and 3).

I do want to point out that it matches current consoles in the US, but is actually going to be significantly more expensive than anything on the market in many countries. Where I am, for example, if they release at exactly the US price -- which they won't, prices always get inflated -- a Switch will cost more than a PS4 that comes packed with Fallout 4, Skyrim, and Dishonored 2, three hit games.

On top of this, I think they've made a fatal flaw when it comes to handheld pricing. If you remember, the 3DS launched at $250, tanked hard, and received a whopping 33% price cut only 4 months after it launched, followed by the announcement of the new 2DS which would be even cheaper. One of the things Nintendo produced the 2DS is because they found, to their great surprise, that almost 80% of 3DS customers outside Japan never took their 3DS outside the home. They weren't buying it for portability, like Japanese customers usually did; they were buying it because it was the cheapest way to play videogames, only a third the price of a console and with games that were half the price of console games (in many countries even less). Right now I can buy a 2DS for 105 and brand-new games for 40 where an Xbox One is 400 and games are 80 - 100. That's a big reason many of my friends have one.

Then note that they've also priced the Switch above the iPad Mini. Most handhelds are bought by parents for kids. If parents see that they can get an iPad for less than the price of this new console, they're very likely to: iPads are seen as luxury products with a wider variety of uses and many cheap games, and the iPad Mini is even more portable. This is the first handheld Nintendo have announced since iPads hit the market and I worry they haven't taken this into account.

For those customers, who make up a majority of 3DS customers worldwide, the Switch is a non-starter; it's likely to be considerably more expensive than its rivals, and those rivals happen to have either larger libraries, greater popularity, free online, and better graphics (Xbox One/PS4) or a luxury image, greater portability, lower software costs, and a wider variety of uses including educational uses (iPad Mini). I'm really hoping Nintendo succeeds, because I'm a big fan of theirs, but I worry they have totally killed the big draws to handhelds.

I'm surprised to see JS described as easier than Python. I'd say it's considerably harder and more complex. The first reason being that it forces you to think about asynchronosity constantly, and that's something a beginner's going to struggle with -- not just the idea that your code won't run in order, but that there are so many ways to deal with it (callbacks, promises, async/await, event emitters) all with their own tradeoffs. The second being that the standard library is anemic, so a ton of what you'd just hit the Python Stdlib for you have to either write yourself or sift through npm to find. Then there's the wildly varying code styles: this person/book encourages the traditional imperative style using loops and mutations, this other person encourages a functional style using folds and maps to do the same things. Prototype-based inheritance is less intuitive than class-based inheritance. There are multiple ways to do everything, even things as simple as variable assignment (var, let, const, implicit global, function foo() vs let foo = function() vs const foo = () =>), weird invisible things that trip you up like hoisting and how creating a global variable looks exactly the same as reassigning an existing local variable. New users will inevitably encounter the multiple competing module systems and either confuse syntax or fret about which to use.

I agree that it's cancerous, and that making the server side more accessible to front-end developers isn't worth all the problems Node introduces long-term. My dream is still a statically-typed version of Erlang.