vcarl

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.

Yes, you stand behind your comments so strongly you created an anonymous throwaway account just to share them.

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.

This looks like a good overview of efforts in the medical space: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8455774/

And this looks like an okay high-level survey of use in manufacturing and construction: https://www.sciencedirect.com/science/article/pii/S240589631...

> 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.

[0]: https://en.m.wikipedia.org/wiki/NLRB_v._Mackay_Radio_%26_Tel...

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.

Bob Glickstein wrote a really phenomenal writeup https://medium.com/interstellar/understanding-the-stellar-co...

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.

https://www.styled-components.com/docs/tooling#babel-plugin

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...

Very excellent writeup of some tricky concepts. Nothing in here is terribly new (or, I would even argue, particularly controversial among those familiar with Redux), but until now it has mainly been available through a combination of Twitter threads, Reddit comments, StackOverflow answers, and Gists. I was fortunate enough to have followed Redux from the initial talk releasing it and was able to discover and parse these in real time, but for new users attempting to get up to speed, that's not viable.

To have a pair of documents that consolidates all of the ideas that have trickled out regarding Redux from creators, maintainers, and others who "get" the concepts is absolutely fantastic. Kudos, Mark.

I didn't realize that so many of the React team had worked together, let alone on a project as well known as MooTools. Some of their answers mirror my perception of React, especially:

    We were so focused on the API design, rather than building
    something that people could actually use and adopt.

It's good that they found more people who shared their ideals and a company willing to give them the time to implement them.

Turns out hardware is hard. My view of it is scope creep that caused delays in starting environmental testing, ultimately leaving us with too little time to properly address the problems that we discovered.

We tried to use 3d printed cases for the prototype units, but it turns out 3d printed material (at least the type we used) is porous and doesn't respond well to heat expansion when left out in the sun. We spent far too long trying to get our 15 printed cases to be watertight, and once we finally did, they expanded in the sun and cracked. But we couldn't afford injection molding and didn't properly explore cheaper plastic casting methods.

We spent a bunch of money on tooling for cast aluminum parts that ended up being about 1/32" too tight and complicated fitting components in. And we had a major scope creep in the form of wanting to support mid-rental lockup (we were "stationless" in that the bikes had all the tech, there was still a rack that rentals started/ended at) via a retractable pin and chain, that ended up causing electrical issues with detecting lockup, condensation issues due to the larger openings, much more complicated mechanical workings... I honestly think that if we had cut that single feature, things might have turned out differently.

No, I was in my early twenties, didn't know how to scope a project, didn't know how to effectively push back on scope creep, and didn't really have the technical chops for what we were attempting. I learned a ton and wouldn't make the same mistakes again, but none of us had any prior startup experience. These guys have a lot of startup experience, and being well connected is being skilled at networking. I'm not being self deprecating, this team is objectively more experienced than we were.

Hey, I tried to do this! I was CTO of a little student startup called A2B Bikeshare for a while. We called it "stationless" though :)

We got a prototype working with a custom Android device with touch, 3g, GPS, and built in credit card swiper in Lansing MI, but ultimately we b it off more than we could chew. The team collapsed in mid 2015, and the company was just recently completely shuttered. It's validating to see a more skilled team put together a solid product, but damn it would have been fun to be that team haha.

Best of luck!

Great questions, great answers.

Sam's comments on Meetups mirror my experiences, though I'm not in a tech hub area. It depends really heavily on the person organizing and what kind of outreach they've done to people, existing groups, and organizations in the area. I've seen a few groups flare up really enthusiastically, then dwindle over a few months. I've also tried joining some existing meetups that feel most like people are sticking around more to hang out with the other people than because of value from the meetup.

Likewise for finding a technical cofounder. As a technical person I've spent some time thinking about the other direction, and (after a rough experience) there's no way I'd try to get funding with somebody I didn't know very well.

> in a HandBrake-based video transcoding task, Ryzen scored a narrow win [against a stock i7-6900k]

Man, if that holds true in more benchmarks, that's fantastic news. AMD chugged along by "competing" further and further down Intel's product line more or less since Sandy Bridge, if they can genuinely compete with the i7 now I can't wait to see the next few years. Intel has always seemed content to release incremental improvements until they get kicked in the pants by somebody else, I wouldn't be surprised if they have a bunch of stuff waiting in the wings to maintain their edge over AMD.

Clients can use it to request exactly what they need. Since it's a graph, you can just keep grabbing nodes to get the fields you need in the shape that works for your client. GitHub added a GraphQL endpoint for their API, the improvements they cited were reduced overfetching of data the client didn't use e.g. urls to linked resources, and fewer underfetches e.g. using the results of the first request to populate a second or third request.

http://githubengineering.com/the-github-graphql-api/

It's not really GraphQL vs SQL, it's GraphQL vs RESTful APIs.

> large, open questions on basic stuff.

I've commented on this subject before[0], I think the past few years of web development has largely been about answering basic questions. Now there are well tested answers to those questions. I'm sure people will still reinvent these wheels, but now you don't have to when working on a large project.

Babel, Webpack et al are more useful when you're building a web-app, something generally comparable to a native app. The toolchain is complex, sure, but no more complex than what xcode or Android Studio do for you. I think the difference is that this has been a community effort, rather than a corporation assembling a product, so a) there are more people sharing opinions and b) the disagreements and exploration has been more public.

[0] https://news.ycombinator.com/item?id=12828042

The best I've found is reddit.com/r/neutralpolitics. It's strictly moderated, with minimum comment lengths and required source links when making factual claims.