Turn off Hamilton, let's talk about $$$

Issue #3.July 6, 2020.2 Minute read.
Bytes

TypeScript 4 goodies, VC is bad for OSS hot takes, and the best way to connect with attractive singles near you.

TypeScript 4: Tuples 4 Days

Christian Bale

Look at that labeled tuple element. The tasteful readability of it.

Types on types… The TypeScript team announced the new features for the upcoming TypeScript 4 release last week, with an anticipated public release date in mid-August. Many of these new features will give additional functionality to the tuple type, so here’s a quick rundown on what that will look like:

  • Wtf is a tuple? Valid question. Tuples don’t exist in JavaScript (array destructuring doesn’t count), so many frontend developers aren’t familiar with them. Simply put, tuples are special arrays that can contain elements of different types. Ex: let x: [string, number];.

  • Variadic tuple types: First proposed almost 5 years ago, this new feature will let TypeScript give types to higher-order functions that take a variable number of parameters. Check out the docs if you want a better idea of what this actually looks like in practice. Tl;dr - library maintainers are hyped about this.

  • Labeled tuples: TypeScript 4 will let you label your tuples, because it’s way easier to directly label them than it is to comment out your own DIY labels. Cleaner, more readable code 🙏.

Other quick highlights:

  • Three new assignment operators: &&= , ||= , and ??=.

  • Class property inference from constructors: Control flow analysis will determine the types of properties in classes when noImplicitAny is enabled.

  • Partial editing mode at startup: Allows for faster startup times when working with TypeScript in VS Code.

The Bottom Line

TypeScript doesn’t follow SemVer (I know), so TS4 is not as significant of a major release as you might expect. None of these features look particularly groundbreaking on their own, but together they should make life easier for TypeScript devs. Look for the first beta to come out sometime this week.

VC and OSS

Money on Fire

Everything is fine

It’s been kind of a slow week in JS land so here’s me improvising.

Developers love to throw around “it depends” and “tradeoffs” when making technical decisions. Naturally some frameworks/libraries are better suited for certain projects than others. The goal is to avoid the dreaded “we chose the wrong technology 2 years ago and now we’re screwed because of it” Medium think piece. However, one data point that developers never seem to take into consideration when making this decision is the financing of the company behind the technology.

Remember Famo.us? It was a JavaScript framework that specialized in building a fancy Periodic Table of Elements HTML5 performance. It raised a $1MM seed round, then a $4MM Series A, then a $25MM Series B, then it died pivoted. If you bought the hype and built on top of Famo.us, you, well, probably died with it.

What about Meteor? It raised $20MM, then it died its growth stalled and it sold to Tiny Capital for what I assume was pennies on the dollar. If you bought the hype and built on top of Meteor, you, well, probably died with it.

We’re good now though. It’s 2020, Kanye is running for president, we’re partying like we’re not in the middle of a global pandemic, and all the OSS we use is backed by healthy companies with solid financial fundamentals.

Wait, what’s that? Nothing has changed? Oh.

The Bottom Line

I’m not saying VC is always bad - Cloudflare, Firebase, MongoDB all come to mind as successful, VC backed tech platforms. What I am saying is that companies backed by VC either grow or die trying and you should consider the current and future financial health of a company when making technical decisions.

Also, if someone knows the story behind how Apollo was able to raise a Series C after Meteor flopped, I’d love to hear it. I’ve asked and… didn’t get a response

Cool bits

  1. Matteo converted the old Particles.js library into TypeScript (dependency-free), with wrappers for every major framework. Long live particles.

  2. Johannes wrote an in-depth beginners’ guide to writing automated tests in React that’s actually in-depth.

  3. This video series on binary from Low Level JavaScript will make you feel smarter than your friends.

  4. Leonardo curated a list of helpful resources related to finite state machines.

  5. Node.js released v14.5.0 with an updated engine (v8.3) and a new experimental DOM-like API called EventTarget. Suck it, Deno.

  6. Textures.js is a new JavaScript library for creating SVG patterns. Because we could all use a little more… texture.

  7. Ben Lesh wrote about his biggest regrets in building RxJS (spoiler: the API is really big) and what the road for the library looks like going forward

  8. This Academind video argues that the “always learn vanilla JavaScript first” approach might be wrong.

This week in history

7 years ago this week, the first public version of React was released. It’s come a long way since then, but fundamentally it’s still pretty much the same.

/** @jsx React.DOM */
var HelloMessage = React.createClass({
  render: function() {
    return <div>{'Hello ' + this.props.name}</div>;
  }
});

React.renderComponent(
  <HelloMessage name="John" />,
  document.getElementById('container')
);

Here are a few quotes from how it was first received.

  • “There’s already a library named react.js” - wycats
  • “This breaks code editors, static analysis tools like jshint etc. I think Web Components is landing soon, and this seems like it could leverage that.” - amasad
  • “I’m confused, every example is 100 times the code I would write using straight html… Is there a benefit I’m missing?”- darkchasma
  • “Do templates have to live inside the application logic? If so, this is a really poor decision.” - dpham
  • “This is terrible, so did we really not learn anything from PHP days? Are we seriously going to mix markup and logic again?” - mavdi
  • “OMG, JSX.. why? just why?? Stop ruining js people!” - lardissone
  • “Mixing js and xml syntax, variables in docblocks, DOM components that are not really DOM components (‘React.DOM components look like browser DOM elements, they differ in a few ways’), undocumented/obscure OO features (React.createClass?). Yikes. Thank you, but no, thank you.” - leecGoimik7

Shoot your shot, kids.