It's definitely a defensive statement, proactively covering the situation as "normal". Normal it may be, but emphasizing that in the limited space of a tweet thread definitely indicates where their mind is on this, I'd think.
Phenomenal answer. No, you don't need it, but if you build something long enough you'll avoid a couple categories of common problems by starting with it (and choose a different set of common problems)
I'm not sure breadth of adoption and retention are the right metrics here — the use cases I've heard about are highly specialized, so I wouldn't expect it to be massively and quickly adopted, the same way it took a long time for robotic surgery tools or CAD to become widely used.
I've heard of it used in e.g. surgeries, for visualizing data like MRI scans, or building schematics for electrical/steam/wastewater/etc but don't know of specific instances where products are used.
> all this VR/AR hype has yet to deliver something... anything... anything at all
…in the consumer space. There have been some really incredible tools I've seen in industrial or medical spaces, and I think that's unlikely to change in the near term.
I meant this as a commentary on the strike as a tactic for tech workers generally. SREs and Ops are the teams that seem most able to effectively use a strike to disrupt revenue, to be sure. Many services, though, would be able to operate for months or longer without intervention.
Cheers for the correction, though I'm loathe to learn that's the state of labor law.
> Mackay Radio has been called "the worst contribution that the U.S. Supreme Court has made to the current shape of labor law in this country."
> Nearly every criticism of Mackay Radio is aimed at the Court's "duplicitous distinction" between firing and permanently replacing striking workers.
Interesting, too, that the decision apparently contracts the laws it was interpreting. This is a grim section to read[0]. Reading this, it seems like the case was approached with a predetermined result in mind, and apparently 2 of the justices declined to participate.
I know that the Tech Workers Coalition (TWC) has done some significant organizing against Amazon, in the form of protests/drawing media attention, and in deeper/less visible aspects that more directly work towards warehouse worker protections. Definitely a good group to reach out to if this is a cause that's important to you.
One significant change since that era of unionization is that programmers can't actually shut down the business with a strike. If programmers stop working, that doesn't actually directly impact revenue—if a group of factory, warehouse, or service workers strike, then the business halts until the strike is resolved. SRE/Ops could take down revenue generation, but that starts to be something with legal liability. Laws prevent businesses from hiring new workers to break a strike, but if you sabotage the code, then my understanding is that there could be criminal charges against you.
That's not really relevant in the context of Amazon's _warehouse_ workers unionizing, but I think it's an interesting constraint for us as software developers.
Well, you still can't do that—WASM doesn't have DOM bindings, you'd still have to ship out to JS. I believe that's a goal, so yes eventually that could be a benefit, but not at the moment.
Web assembly is generally an optimization, not an app alternative. Think of it the way you would the C bindings Node.js has. If you've got a compute-heavy code path, writing it in C (or Rust etc) and shipping it as web assembly could be a dramatic perf improvement, but there's not really a substantive benefit to writing your entire app with it.
This reads like you're equating collective bargaining with salary negotiation, but there are a ton of other dimensions where negotiating as a group would be beneficial. I've worked at a number of companies where I was well paid, but had an expectation of overtime. The environment of crunch produced a product that was so unstable I had to be on call, and was occasionally awoken in the middle of the night by things that would never have made it to production if there had been industry-standard practices in place.
That's where collective bargaining could come in handy in software. There needs to be some recourse for when shitty companies abuse its employees.
Vocational training absolutely could be done in tech, web/app development is much closer to carpentry than it is to computer science in my view.
Unions are definitely complex, it's not a silver bullet to solve issues in the workplace. But at its core it's a group of people negotiating as a unit: the rest is just the natural evolution of a group where some power has been attained. More members means more organization needed to keep everything straight, and more organization means more barriers to joining. Once there's a real structure to the power a union gets, it's subject to the same people problems as an other organization.
Not sure where "tying pay to tenure" came up, unless that's how you view what unions do? A union just means a group of employees negotiating as a unit, what changes they ask for isn't dictated in advance.
Not sure where you're getting that it's deprecated. Both the repo itself and the styled components website list it as a highly recommended (but optional) addition.
That "worst sentiment of 2018" comment was directed specifically at
> Things like that (CSS into JS/ typed JS/Elm) are done because the developers are not competent enough in their field, and instead of learning about it, they try to create their own solution for it
Broadly calling developers incompetent because they've developed/use tools that you don't like is not "disagreement," it's just an ad-hominem. It has no place in a technical discussion.
We've not run into any performance issues in our 80k LoC JS app using styled components 100%. I'm not sure it's accurate to say it's ditched static styles exporting, with babel-plugin-styled-components we're getting a handful of style tags on the page that are generated at build time.
We use styled-components, which is one of the most commonly used css-in-js libraries, and it supports both pseudo-classes and browser breakpoints. I'm not sure how applicable this argument is, my experience runs counter to the premise.
I've also done animations in JS using react-motion and react-flip-move and had a pleasant experience with both.
React has extremely careful versioning with a precise internal definition of what a "breaking change" is. Judging React by Angular's terrible version numbers doesn't seem fair to me.
They're on v16 because they increment the number any time they make a change that isn't 100% drop-in backwards compatible with the previous version, with a deprecation cycle when possible beforehand. Apps that function without deprecation warnings can update immediately when a new release drops.
Ultimately they are where they are because they were of a change they made when they released v15. Really, it's more like v3, but they kept the numbering consistent with how people talked about it. https://reactjs.org/blog/2016/02/19/new-versioning-scheme.ht...