Context is incredibly important. The author is writing from the standpoint of a startup trying to fine tune an MVP. Of course it doesn't matter if it lasts if you don't know what you're building and rewriting everything isn't hard.
Code-first matters a lot when you're trying to make a 15 year old cobbled-together system last another 15 when you don't have the resources to stop everything for the many engineer-years it would take to do a full rewrite. Anything you touch is going to have to last too and people have to care about adding more technical debt because it's already the 500lb sled they have to drag behind them every single day.
That's still not code first. It's always product-first, just with different timelines. If you're working on a system that need to last, you should still optimize for the product, but over a longer time span. The code is just the means to the end.
I must have missed the parts where South Korea and Taiwan were bombed into the stone age for years and then forced to repeatedly fight their neighbors for continued survival.
From the virtually complete annihilation of civilian infrastructure in the north to the widespread deforestation, poisoning, and unexploded ordinance in the south, the US barely left a country behind. Such comparisons are incredibly disingenuous without a view of how long Vietnam had to spend just rebuilding functioning infrastructure, education, etc and all without wealthy foreign investment. The Vietnamese people and government should be applauded for everything they have achieved.
Some chiropractors do have the education and experience to operate as physical therapists. When I was doing competitive weight lifting, I saw a chiro who had a masters in sports medicine and had spent years as a college football trainer. He ran his office like a rehab clinic, and a lot of his clients were high school, college, and amateur athletes like me. He wasn't just popping some bones and moving on, he was working to keep his patients healthy through identifying weaknesses and imbalances and making training recommendations to correct them. Being a chiro got people in the door who didn't understand what their problem was to begin with, just that they needed relief.
I realize the industry is full of snake oil practitioners, but some of them are actual professionals.
Working for a for-profit company is a completely different labor relationship than working for an OSS org or other non-profit. You absolutely should fight to prevent management from extracting more of the value you generated just because you cut your personal costs, but you may be able and willing to accept less income in order to contribute to an organization that you believe in that isn't profiting off your labor. One is adversarial theft, the other is the willing donation of your time to a cause.
> but you may be able and willing to accept less income in order to contribute to an organization that you believe in that isn't profiting off your labor.
But there are plenty of organizations profiting off of the dev’s labor. Why is it different just because those organizations are users and not their employer?
Wasting massive amounts of mostly carbon-producing electricity as the planet dies to do absolutely nothing productive is a pretty cyberpunk evil megacorp thing to do, agreed.
Neat project, awful name. Overloading Flow, an already important part of the React ecosystem, just makes it harder to both find information about your project and find information about Flow.
Yes, there's an active albeit small community there.
I don't think I'd recommend it over TS for a new project by default, unless the person has some specific pain points with TS that Flow would fix. But Flow does still have some neat features - exact types, nominal types, explicit strict variance rules etc. - and performance benefits in large projects that could make one choose it over TS. And they have been streadily improving stuff like editor support, even though admittedly it's still a long long way behind TS.
Our team just migrated (3 mil+ LOC) from Flow to TS in large part due to performance issues with Flow, especially in local development. Our fans have been running a lot quieter since the migration, happy to share more.
Please do if it's not too much trouble. We have gone back and forth with this idea but never did make the jump.
A few random questions off of the top of my head...
Did you use a tool like flow-to-ts to help with some of the rewrites? What version of Flow were you using before? Did you take some special steps to get the TS perform well in the project or was it just better out of the box?
How's the experience been apart from the performance improvement - is there Flow features that you miss and have you done something to accommodate?
Namely, I'm personally a bit sad to loose local function parameter inference, exact types and explcit type assertion syntax.
I'm a bit afraid of bugs coming from excess properties or misspelled optional properties, or from the abuse of TS "as" keyword (which is not the same as Flow's `(foo: Foo)` assertion syntax).
> and performance benefits in large projects that could make one choose it over TS
[citation needed]
A medium size app using Flow would take 10 seconds to type check in an IDE. It's possible we had some issues with circular dependencies but Flow was such a burden to deal with. Not to mention issues where the flow server would chew CPU resources on a dev machine.
Typescript on a much much larger project has had zero issues with performance.
I don't have anything but own anecdotial evidence to provide. Would be cool if there were some good, recent benchmarks between the two, but I wasn't able to find any.
Maybe I've just configured something wrong, but I keep facing this issue where autocomplete stops to think suggestions and might just freeze the whole VSCode for a second. This is in a small project that has some fairly large library definition files (namely, aws-sdk).
If you search for "TypeScript performance", you'll find a bunch of issues and posts discussing the subject, so I don't think I'm totally alone in calling it out.
Granted, Flow gets it's share of similar search results and I have also experienced similar issues where a recheck sometimes takes long and CPU usage jumps very high. This side of Flow has been consistently improving between almost every release, though. Most recently, a couple months back, their switch to this new "types-first" architecture [1] is supposedly unlocking something like 50%-90% perf improvements compared to what they vere before.
My point with this isn't to question your experience with Flow, I've sometimes faced similar issues. I'm just saying that, depending on the Flow version you were using, things may have changed a lot for the better.
Just so that I'm not talking _completely_ out of my ass here, as a quick very unscientific test I cloned the Tutanota project's repo [2]. SCC says there's 967 JS files, consisting of 205433 lines of code in there. Flow version is 0.136, which is a little behind, but they are using the new types first mode.
time node_modules/.bin/flow check
Found 0 errors
node_modules/.bin/flow check 1,00s user 0,11s system 9% cpu 11,905 total
AFAICT at this point it's basically just Facebook projects (since they use it internally) and some older libraries that pre-date TypeScript popularity. I'm not sure there is much reason to choose Flow over TypeScript for a new project in 2021.
Yikes; alternate uses for _two_ already-overloaded terms ("flow" and "node") in the tagline? Naming things isn't _that_ hard. Less of a nitpick and more of a red flag wrt wisdom and experience of the lib's authors.
“Node-based interface” is common for that kind of UI though, the author didn't invent it. It's a shame that NodeJS chose such a common word as its name, but “node” can't be erased from CS just because NodeJS exists (one would have to remove graph theory, cluster grapes, many UIs concepts [tree UI, nodes UI, ...], many 3D jargon, etc.).
I think a fair few of us have been burned by companies where this level of respect absolutely did not and could not exist and engineers were treated equivalent to you, an amateur, calling a plumber to your house and then hovering over them telling them everything they're doing wrong. Informal PTO would have just made the situation even worse.
Something I never see mentioned in these discussions is the surprisingly high hurdles to actually operating a distributed company. You'd think in 2021 it wouldn't be difficult to have employees doing knowledge work in multiple US states without running face-first into laws governing conducting actual business in multiple states, but that's not at all the case. International is even worse. The additional complexity and costs of having non-local employees can absolutely be prohibitive, leading some companies to just abuse 1099 status.
This obviously isn't a problem if you're FAANG or Salesforce, but for a company of 20 it is.
I've worked in a ~50 person distributed company - the practical contracting steps weren't a big issue.
You pay everybody outside your local jurisdiction as contractors, and you pass on the significant savings to them as salary, so they can approximate the normal employee benefits purchased directly for themselves. I understand this is a bit more complicated in the US as health insurance is a key benefit, but not impossible, and that's not a problem in most of the rest of the world.
Employees do need to register locally as freelancers, file invoices & do taxes, but that's a relatively simple process for such cases everywhere I'm aware of, and any costs can be included in the salary bump. We made it work with no big problems or complaints for anybody in the 2 years I was there.
I don't know all the details but even having distributed employees as W-2 workers with full benefits can't be that hard. I worked for a 10 person company with employees in a few different states plus the UK and they were able to make it work.
The vast, overwhelming majority of "independent" contractors on 1099s do not actually qualify for that status as defined by the law. Most of them should be W2 employees per the law.
The only reason most companies get away with this arrangement is because the government has refused to enforce it except in egregious cases, and ignorance on the part of the employee.
But it's a pretty tenuous situation. See Uber in CA.
so as a 1099 the employee has to pay all of the standard taxes a business would pay and they’re entitled to far less of the employment social safety net.
when you 1099 an employee you force them to bear your tax and benefit burden. people who take the 1099 job do so because they don’t have a w2 offer or don’t understand. a 1099 has far less net profit at the same salary as w2. this is how contractors maker more money but have less real income
So to be specific there’s a very negligible tax arbitrage which actually favors the employee not the employer but conceptually in the compliance case described above the employer would actually be net neutral to paying the tax adjusted rate (aka their outflow) to the employee and it’s not set out to be some great scam.
Even with passing on the tax savings, there's also things like health insurance and some form of retirement matching.
An employer paying a group rate for health insurance will pay less per person than an individual paying an individual rate.
Even if the employer were to pass on the savings of not having the person in the group health insurance, the 1099 contractor would need to pay more to get the same coverage.
And beyond that there are things like a 401k matching or a pension that a full time employee has that a contractor doesn't have access to.
Health insurance is a big one and a lot of people just aren't going to take a job that doesn't come with a good health insurance plan. Many companies also offer things like dental insurance, short term disability, and long term disability. Individuals (may) be able to obtain some of those things on their own but, as you say, the cost may be prohibitive.
You can at least get health insurance with pre-existing conditions now but it can be very expensive. You may not be able to get disability insurance.
Being a 1099 contractor is mostly not a good deal for someone who actually wants a stable long-term full-time job.
I used to do contracting all over EU.... and it was pure bliss. Even with VAT "complexities", it's still about a million times easier to do taxes as a contractor in EU/UK, than it is to do your own taxes in US.
The final thing about contracting in US is that average employer cost of health insurance is over $20k per employee. If you don't fall under someone else's employer sponsored healthcare plan, your self employment income will be greatly diminished. (In US freelancers don't get huge bumps in hourly rates, just because they're not full time benefited employees)
There are rules around who's allowed to be classified as a 1099. If you're employed full time and told how to perform your job, the government is likely going to determine you're a W2. This is likely what OP meant by "abusing" the 1099 status.
I can attest to this. There was a delay in my hiring process because the company that hired me needed to set up some kind of entity for tax purposes in my state - they had nobody else operating out of there at the time.
