this post was submitted on 08 Oct 2023
28 points (73.3% liked)

Programming

17418 readers
28 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 1 year ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
MaungaHikoi@lemmy.nz
28
How do you feel about TypeScript? (lemmygrad.ml)
submitted 1 year ago* (last edited 1 year ago) by sagethesagesage@lemmygrad.ml to c/programming@programming.dev
66 comments fedilink hide all child comments
 

Specifically, do you worry that Microsoft is going to eventually do the Microsoft thing and horribly fuck it up for everyone? I've really grown to appreciate the language itself, but I'm wary of it getting too ingrained at work only to have the rug pulled out from under us when it's become hard to back out.

Edit: not really "pulling the rug", but, you know, doing the Microsoft classic.

you are viewing a single comment's thread
view the rest of the comments
[–] spartanatreyu@programming.dev 1 points 1 year ago (1 children)

This comment just seems weird no matter which angle I try to approach it from.

immature tooling ecosystem

It's over a decade old now. I wouldn't call that immature.

Looking at your linked comment...

following a basic tutorial somehow ended up spending multiple seconds just to transpile and run “Hello, World!”.

  1. Install deno
  2. Create hello.ts containing: console.log("hello world");
  3. deno run hello.ts (time taken to run command: 0.037s)

[...] 3 different ways of specifying the files and settings you want to use [...] 3 incompatible ways to define and use a “module”

Yes, that tends to happen as ecosystems evolve over time. Typescript allows developers to use modern standards-compliant modules, while maintaining backwards compatibility for older code.

embracing duck typing means [...]

One of typescript's strengths is that its type system isn't all or nothing. Typescript will support duck typers, but it isn't forced or limited to that. You can add as much or as little typing as you want. In theory, this means that the language supports simple beginners up to experts creating turing-complete theorem solvers at compile time. In practice, this means a much smoother onboarding and porting experience.

Have a “generalized fibonacci” module taking 3 inputs [...]

I'm not sure if this is the basic problem challenge or the hello world example was. It seems a bit ambiguous as to what you really want, but it's easy to create a module that takes inputs and produces outputs while running on backend servers, in browsers, and in CLIs.

[–] o11c@programming.dev 0 points 1 year ago (1 children)

Obviously the actual programs are trivial. The question is, how are the tools supposed to be used?

So you say to use deno? Out of all the tutorials I found telling me what tools to use, that wasn't one of them (I really thought this "typescript" package would be the thing I was supposed to use; I just checked again on a hot cache and it was 1.7 seconds real time, 4.5 seconds cpu time, only 2.9 seconds if I pin everything to a single core). And I swear I just saw this week, people saying "seriously, don't use deno". It also doesn't seem to address the browser use case at all though.

In other languages I know, I know how to write 4 files (the fib library and 3 frontends), and compile and/or execute them separately. I know how to shove all of them into a single blob with multiple entry points selected dynamically. I know how to shove just one frontend with the library into a single executable. I know how to separately compile the library and each frontend, producing 4 separate artifacts, with the library being dynamically replaceable. I even know how to leave them as loose files and execute them directly (barring things like C). I can choose between these things all in a single codebase, since there are no hard-coded project filenames.

I learned these things because I knew I wanted the ability from previous languages I'd learned, and very quickly found how the new language's tools supported that.

I don't have that for TS (JS itself seems to be fine, since I have yet to actually need all the polyfill spam). And every time I try to find an answer, I get something that contradicts everything I read before.

That is why I say that TS is a hopelessly immature ecosystem.

[–] spartanatreyu@programming.dev 3 points 1 year ago* (last edited 1 year ago)

It sounds like to me that you've taken your knowledge of your commonly used languages for granted, and assumed a new language would be just as easy. But if you watch a developer who is dipping their toe into that ecosystem for the first time you'll find them making mistakes and running into footguns you didn't know were possible.

Regardless of the language, not having a proper guide leaves devs susceptible to the incorrect blogospam that's out there, where engagement is rewarded over correctness.

Ignore all of the blogospam.

The two things you need to know:

  1. C/C++/Java/Go/Python have all gone through changes, growth and churn just like JS.
  2. Knowing the history of the ecosystem will go a long way towards helping you. If you understand why things have changed, then you'll know how to ignore the bad advice out there.

Here's my shortened version of number 2.

The beginning:

  • JS starts as a scripting language embedded into a browser
  • Different browsers try to copy each other but put in their own "features" pulling the language in different directions.
  • The amorphous blob that is JS starts to congeal and language standards are solidified. This standard is known as ECMAScript (named for legal reasons). ES1 is the first version, followed by ES2 and ES3, each adding useful features.
  • ES3 (released in 1999):
    • This is what you could consider the first long term stable baseline widely supported version of the language, where you can make anything you want.
    • Almost everything you can make in future versions of the language can be backported to ES3.
    • If you want to go by analogy, you can think of ES3 as javascript's C99.

The false start:

  • Work starts on ES4 with a massive feature list (including static typing, classes, modules, algebraic data types, generators, embedded xml/xhtml known as JSX/TSX today, etc...). It fails due to political infighting, and for basically being too ambitious in a single version.
    • This sucks up years of progress between released versions.
    • This version is commonly seen as being poisoned by 90's/00's Micro$oft and the dark ages of Internet Explorer
    • But the spirit of ES4 was released spread out over future versions anyway.

The resumption:

  • The v8 JS engine is released, making JS really fast and worth programming in. This is used in Chrome and Node.
  • ES5 (released in 2009):
    • Adds native json support, reflection, and a strict mode to avoid some footguns with ES3
    • Think of this as C11
    • Some developers being experimenting with a more consise syntax in CoffeeScript that compiles down to ES5.
  • 2012: Typescript is released adding an optional and gradual typing system to JS (inspired by C# and ES4) designed for both Humans and Computers.
    • In effect, this brings IDE-style support for JS
  • ES6 (released in 2015):
    • With the lessons learned from CoffeeScript, a whole bunch of syntactical sugar is added to make the language more pleasant to write in.
    • With the lessons learned from community made modules, an official module spec is released and added to the language.
      • Known as ESM (EcmaScript Modules)
      • The community starts moving away from unofficial modules (CJS, AMD, UMD)
    • Babel is created to allow any developer to create and share their their own language extensions.
      • The faster feedback cycle from Babel allows for smaller and more frequent language updates.
      • Javascript moves to a yearly release cycle and ES6 is renamed ES2015
  • ES2016
    • Adds block scoping as an alternative to hoisting
  • ES2017
    • Adds async/await/Promise() syntax sugaring, to make asynchronous programming easier
  • ES2018
    • Adds ... (rest/spread operator) syntax sugaring, to make destructuring and variadic functions easier
    • Ryan Dhal (creator of Node) releases his famous 10 Things I Regret About Node.js talk. Announces his intention to create a "modern reset" of Node known as Deno.
  • ES2019
    • Minor changes
    • Deno is released
  • ES2020
    • Adds ?? Nullish coalescing operator syntax sugaring
  • ES2021
    • Adds ??=/&&=/||= Logical assignment syntax sugaring
  • ES2022
    • Adds top level await, making asynchronous programming easier
    • Adds private field syntax sugaring
  • ES2023
    • Minor changes

The current state of things

  • Language-wise

    • Javascript has added a whole bunch of syntactical sugar since 2009 making it really pleasant to code in.
    • Typescript adds some really nice IDE support to Javascript and the vast majority of all libraries and frameworks are written in it giving that IDE support to Javascript developers.
    • Babel allows developers to create their own language extensions, which are frequently put forwards at for other developers to give feedback on. Useful proposals are added to the language on a yearly basis.

  • Runtime-wise

    • Node is considered the older slow-moving most-stable release of running JS outside of the browser
      • Think Debian
    • Deno is considered the friendly Node, coming with all the tools a developer needs (linter, bundler, tester, ts support, etc...). In the last 5 years it has reached almost complete feature parity and compatibility with Node.
      • Think Ubuntu
    • Bun is a brand new kid on the block prioritising speed over compatibility.
      • Think nightly linux

  • Standard workflow

    • Write in typescript
    • Let your editor check your typescript while you're typing live so you don't need to go through a compile cycle
    • Let your project's stack compile your typescript for you.
      • If you're writing a new project from scratch, Deno will run typescript for you.
      • If you want to build a new stack from scratch with no assistance, use the typescript project itself to check and compile your code into js, or use esbuild to strip out the typescript types to turn your typescript into js. (most developers elect to strip types since your editor/ide should be live checking your typescript anyway allowing you to skip a redundant compile check cycle)
      • If you're using an existing stack, your build tools will compile/strip-out typescript for you.

  • Tooling wise

    • Most projects use Vite / rollup / and other "zero-config" tools to build and bundle their applications. Some older projects still use Webpack (which does the same thing, but with a more complicated config file).
    • Everyone uses ESM modules now, almost no one uses the older modules.

For your simple fibonacci example:

  1. Create your fibonacci module that exports your fibonacci function
  2. Import module
  3. Call function in module
  4. Pick your endpoint:
  • Browser endpoint: Output result in console.log() and see result in browser's console.
  • Server-side endpoint: Output result in Deno.serve() and see result in network requests/responses
  • CLI endpoint: Output result in console.log() and see result in terminal