LinkedIn NYC JavaScript Tech Talk Meetup Recap


Chad then explained how the introduction of technologies such as WebAssembly (WASM) and projects like the Glimmer VM enable the compilation of JavaScript source code into much lower level code to reduce the parse and compile time in the browser. Furthermore, since Ember owns the entire stack, none of the app code needs to be changed to take advantage of WASM within Glimmer VM, and we should be able to reap the benefits with shorter parse and compile times.

The Joy of TypeScript

“I have a very severe open source addiction,” Robert Jackson announced in his introduction. However, Robert admitted to not knowing much about TypeScript initially, when he argued against it with Tom over his blog post, “What’s the Deal with TypeScript?” back in April 2017.

Since then, Rob became a TypeScript convert. In his talk, Rob took us through the joys of TypeScript and where we might want to hold off on it.

Before we go into that, what is TypeScript? It is an open source compiler of TypeScript syntax into vanilla JavaScript, which adds features as well as optional static types. It contains numerous built-in types, such as Array, Enum, Tuple, and void, and allows you to declare your own Interfaces or contracts within your code.

“How is this different from CoffeeScript?” Robert rhetorically asked the Tech Talk audience.

Robert posits that four key TypeScript Design Goals explain the safeguards it provides when we use it. TypeScript must:

  1. Impose no runtime overhead on emitted programs.
  2. Emit clean, idiomatic, and recognizable JavaScript code.
  3. Align with current and future ECMAScript proposals.
  4. Use a consistent, fully erasable, structural type system.

TypeScript can be leveraged for minimal cost because it produces no overhead while still allowing the code to be readable for debugging purposes and future-proofing the language. There are, however, some caveats to it.

“We’re not going to take a major version bump because there was a bug in the compiler where it failed to identify early errors, even though that’s technically a breaking change,” wrote Ryan Cavanaugh in a GitHub issue about TypeScript.

The reason for this is that “any compiler change could result in a breaking change,” said Rob. This is similar to fixing a bug in an ESLint plugin, where the linting bug might be fixed, but then you end up breaking someone else’s real-life work because of it. He believes this is a messaging issue that needs to be resolved, but not a deal breaker.

Another caveat we encounter is that “contributing typings to a JavaScript project is like giving the maintainers a puppy,” Robert said. It is a tradeoff in the cost for upkeep, so package maintainers need to be clear and upfront about why types are wanted or not wanted in a project and provide clear guidelines.

The upkeep costs, however, are a fair price to pay for the benefits, from syntax discoverability, which allows us to catch errors before execution, to editor type integrations, which provide features such as autocompletion, to finding file definitions and the actual file itself.



Source link