tomgp

This is a great overview of common mistakes in data viz I will be sharing it with my colleagues. As a good supplement I highly recommend Kennedy Eliot's "39 studies about human perception in 30 mins" https://medium.com/@kennelliott/39-studies-about-human-perce...

... a whistle stop tour around the research basis for a lot of claims around data viz best practice (esp interesting re the dogma around not using pie charts which seems to be a consistent bugbear of designers going back to the 1930's but around which the research is inconclusive at best)

[edit: fixed a typo]

A beter example might have been the lack of funding available to alzheimers researchers not looking into the dominant (and now increasingly shaky) amyloid hypothesis. which to me looks like a genuine case of a "prefered narative" which may have held back progess for a decode or more.

Yeah, thats correct. He also threw his co-authors (many early in their career and now potentially reputationally compromised by association) under the bus to get his moment in the spotlight before leaving academy. The whole thing was pretty unedifying.

This feels short on facts high on opinion (almost like the WSJ has some pre-aproved narative!). I can't speak to the other pieces mentioned but I think it's worth noting that Brown's claims about a 'prefered narative' in Nature are rather undermined by some of the peer reviewers comments which encouraged him to broaden the scope of the research in precisely the way he claimed that Nature tacitly discourages.

A more indepth look at the claims and counter claims... https://www.carbonbrief.org/factcheck-scientists-pour-cold-w...

No law, but it is an incredibly dickish thing to do (quelle surprise!). Also, maybe sort this kind of thing out before announcing a rebrand?

Looks interesting! Just a heads up as you seem to be a UK registered limited company :

>On business letters, order forms and websites, you must show:

>the company’s registered number >its registered office address >where the company is registered (England and Wales, Scotland or Northern Ireland) >the fact that it’s a limited company (usually by spelling out the company’s full name including ‘Limited’ or ‘Ltd’)

https://www.gov.uk/running-a-limited-company/signs-stationer...

I've recently noticed a few places screen-grabbing tweets rather than embedding them. Presumably for this reason.

I’ve had my Steel for years (it’s nokia branded so pre 2018) and would buy another in a snap if it broke or i lost it. my battery life tends to be closer to a month or more (though recently that’s been creeping down)

I’m not sure, but possible legibility? Like if you have a bunch of nested nodes it’s nice to be able to see where one ends at a glance.

As someone who has over the last 20 or so years been both a senior front end dev and a designer I don't think this is the case. For me designing in the the browser is fine for details but high level stuff; overall aesthetic, content design, user flow etc. etc. (the primary value of design per se) is better done, at least initially, with dedicated tools. Not necessarily because they're quicker (though they often are) but because different parts of my brain are needed for the different tasks and different tools fit better.

This change to Figma makes me less likely to choose it as my primary tool either as a designer or a developer. Though I guess this is a minority position as I'm compelled to use it all the time as Figma's become a kind of defacto standard in many sectors these days.

Assumed "cage fight" was some kind of macho business metaphor but no, apparently not.

stores are nice (i’ve found the transitions especially useful) but very much optional. i’ve used redux with svelte with good results and as the article says, it’s easy to get svelte to work with any pure js libraries

And 25 years ago :D (though we did the linked list implementation too)

TBH I'm not sure the argument that only women and those under 5 were dying young in large numbers is a great rebuttal to the idea that we were better off in 1023.

Yes! It also means privileging exploration over combat and discouraging min/max type character builds. I think it's a really great addition and ditching it would make BOTW a very different (and IMO much worse) game

Nice! Really interesting to see the difference between the two implementations, comparing the frameworks in something more than the usual toy examples is instructive. FWIW I agree that the Svelte version looks much easier to maintain!

Don't worry! No one's forcing you to try a new framework, it's not mandatory. Part of maturing as a developer is working out what you want to spend your time doing or learning and what you're happy ignoring or leaving to others.

Yes, clearly in that case performance is important but is performance always the most important thing?

I read the article and didn't find it convincing, I would argue that it's clearly not always the most important thing. This isn't an "excuse" it's a calculation that teams make, the author feels that people make the tradeoff at the wrong point but instead of making that argument he frames decisions not to prioritise performance as "excuses" which is bullshit. There's always more performance optimisations one can make and there always comes a point where it just doesn't make sense to do so for all manner of reasons.

A trivial example: I have a script which downloads a few thousand GIS Shape files and converts them into geoJSON. It runs automatically once a month, usually whilst I sleep. A run takes about 5 minutes at the moment but there are a couple of things I could do to make it run in a fraction of that time but then the script would be two or three times longer and more complex, and I'd have to spend a couple of hours writing and testing code, (there'd also be some edge cases that I'd need to account for which the current setup allows me to ignore). I judge that to be a waste of time which would make anyone who has to take ownership of this script in the future's life more difficult. So that's my "excuse" and I'm sticking to it.

Yes. Imagine creating a platform that facilitates the kind of things that article recounts and instead of dedicating all possible resources to fixing the problem being like; nah, let's just pour millions upon millions of dollars into making "the metaverse".

Truly a moral void.

I’ve never seen anyone make the argument that performance is not important. I have seen people make the argument that performance is less imprtant than some other property (maintainability, extensibility, legibility etc. etc.) given certain aims and constraints.

There are certain sporting events which are required to be broadcast free on terrestrial TV. Wimbledon and the FA cup final are the two that I can remember this applying to off the top of my head.

Cushty and cozy are not the same thing at all!

But BCE comes before CE

Lovely site but it got my hackles up right off the bat ...

> "The library for web and native user interfaces"

_A_ library, it's _a_ library not _the_ library.

And yet thay all apparently lack basic human empathy?

Yeah, but atleast in Svelte it's explicit, and you can if you wish write svelte as if ste were immutable. Anecdotal, but still, I've had fewer bugs (particularly wierd UI glitches) in Svelte than I ever did in React. I just like Svelte for the types of project I work on.

Tangent: the idea that "we all agreed to say no thanks to that" is kind of symptomatic of broader issues I have with web dev. i.e. that there's very little recognition that different tools have different uses and knowing when to pick which is part of the job. Working with wood you wouldn't apply the same practices and methods to building the timber frame of 2 story house as you would to making an intricately carved toy elephant. Why when working with the materials of the web, HTML/CSS/JS, do we assume there's a best and right why to do it: "you must write tests!", "avoid using z-index!", "separate content and form", "immutable state!"; these are all the right answer in some situation and not in others.

Sorry, reading this back I see where that might be confusing. It's a few days later now but I think I was referring to React in the round as deployed in the real world, the community norms etc. rather than just the core library. In my experience the way that React projects tend to develop is that "tried and tested" libraries get added to to solve particular issues, most commonly state and styling (codified in meta-frameorks like NextJS etc.) but also UI transitions, wrappers around common non-react libraries like Leaflet or threeJS etc. The reason being that it's actually quite hard to sensibly integrate vanila JS libraries into a React code base so if someone has done the hard work why would you not use that. But of course this comes at a cost. More recent libraries (in my experience svelte but i understand this is a common feature) mitigate the issue by 1. having a builtin approach to state and styling 2. making it easier to drop down to the underlying HTML/CSS/JS without making a mess.

"Direct comparison with general public driving was impossible due to unclear crash severity thresholds in the manufacturer’s reports, but analysis showed that controlling for driver age would increase reported crash rates by 11%. These results establish the need for detailed crash data, crash definitions, and exposure and demographic data in order to accurately assess automated vehicle safety."

My position isn't that we should be using a new library per se. It's that we should be more selective about what 3rd party code we use and espescially what we ship to end users. React has tended towards a kitchen sink approach and this is exacerbated by initial design shortcomings/decisions i.e. no built in state management or method for encapsulating styles has lead to a deluge of libraries that promise to fill the gaps, none of which quite work with one another. This I guess is why we've seen the rise of meta-frameworks like Next which fill this gaps in a predictable way. But these just meta frameworks just shift developers another step further from the underlying HTML/CSS/JS making it harder to debug things and harder to fix issues when you stray from the framework's happy path.

(All that said, I don't blame people for choosing React for certain classes of projects, the economics of hiring new devs, the relative maturity and stability , the large community etc all make for powerful incentives to choose React)

> I'm not sure I'd ever expect a framework, React or anything else, to stop that behavior. If a child component signals to a parent that the state has changed then I would always expect that to cascade down the node tree. That could cause further updates. And more renders. That behavior is on me. If the framework decided not to cascade some updates that would be weird.

It's not that the properties shouldn't be updated it's that in React the whole subtree gets completely re-rendered, with a potentially big performance cost. Svelte just changes the relevant bit of the DOM, like a single class attribute or whatever, and leaves everything else be, this feature alone is what made me switch. In addition to baseline performance benefits certain things which are really awkward in React (e.g. animated transitions) become non-issues.

>Feeling like you have to stick with React is a state of mind - you can change that with enough effort.

I really appreciate your optimism about switching to a different framework/ etc. and I would have felt the same earlier in my career where I didn't have so many non work commitments, financial and otherwise. But to me now this reads as wishful thinking; switching track is difficult, especially when your existing skill set represents a large chunk of the demand in the marketplace. (And I say this having recently sucessfully made the switch from React to Svelte)