9 ms·

This cones as no surprise to me, as TypeScript is a transpiled language. I know this is probably an unpopular opinion at HN, but I am a huge supporter of plain

• tuckerconnelly 6y ago
  I feel the exact same. Reminds me too of Nassim Taleb's idea that, if something as already existed X years, it's likely to exist another X years. I'm skeptical of the staying power of these transpilers.
  • francis36012 6y ago
    Typescript has been around since 2012. Going by the quote, it is likely to still be around in the next 8 years.
    • AaronFriel 6y ago
      TypeScript has been around since 2012, and it has since won in the marketplace of ideas, becoming the single most popular language to transpile to ES# and beating a well-resourced competitor in Flow. The type war was "won" by TypeScript, and I expect it's just a matter of time before types make it into the standard. The benefit of winning so completely and having such enormous popularity is that its ideas are very likely to make it into the standard such that no transpilation will be necessary.
      • lioeters 6y ago
        > just a matter of time before types make it into the standard I hope so too. TypeScript has done so many things right in its design and implementation - starting from Anders Hejlsberg, with expertise in creating numerous languages; backward compatibility to allow gradual and seamless migration from JS to TS; structural typing; editor/IDE integration via language server; good documentation; corporate backing (maybe not necessary, but like React, I think it was a big factor in its wide adoption).
    • coding123 6y ago
      I don't understand. So in 2016, Typescript was around for 4 years so it only had 4 years left, yet here we are.
      • jatone 6y ago
        its 'at least another X years' so in 2016 typescript was around for 4 years, and here we are now 4 years later. its still around. seems to be holding.
  • zelly 6y ago
    Lindy effect https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect Transpilers definitely aren't Lindy. CoffeeScript, GWT, Elm, among others form a huge graveyard of de facto defunct languages targeting JS.
  • deleted 6y ago
    [deleted]
• abraxas 6y ago
  The reason those transpilers exist is that the target language is so excruciatingly awful. At least to those willing to endure the pain of transpiling. It's an unhappy situation for all involved really. JS should be a language that targets some kind of bytecode that the browser executes rather than being a direct target. Perhaps WASM will some day replace all webpage scripting allowing everyone to use languages of their choice.
• Agent766 6y ago
  My team started development of a React SPA. It was initially written with jsx. As we're starting to implement more, I'm finding more and more cases where the js code was wrong; property names that don't exist, wrong types being passed around, and non-existent props being used. How do you suggest addressing this in a 10 dev team when developing in js?
  • Andrex 6y ago
    Enforce shared ESLint rules on commit, and use Airbnb+React with most of the defaults set.
    • jakelazaroff 6y ago
      How would that catch a misspelled prop name?
      • mikewhy 6y ago
        You would end up defining PropTypes, and ESLint is capable of keeping you in check there. It's much worse than just using TypeScript (only at runtime, PropTypes aren't that useful anywhere else, PropType syntax doesn't match Flow, TS, or jsdoc, ESLint can't check any PropTypes you spread in), but it can get you by in a pinch.
      • ngerrity 6y ago
        linting wouldn't, but if you're writing unit tests, that kind of problem would be caught pretty quickly.
        • mikewhy 6y ago
          This also works in TypeScript's favor. Meaning you can skip writing tests that simply check you're giving the correct props.
          • nailer 6y ago
• tanilama 6y ago
  Typescript helps you to avoid most obvious bugs(wrong classes, non-existent properties, basically to escape the undefined hell) that is the point of it, which I really like and find enormously helpful for medium-size JS project (10k-50k LoC) Also I don't think the transpiler argument holds in today's JS ecosystem. Everything is transpiled. Unless you are developing in barebone ES5 syntax and avoid babel as a whole, then some level of transpliation is inevitable. Yet, I didn't find debugging that much difficult with correct setup.
  • cutler 6y ago
    Why? ES6 has been widely supported for quite some time now.
    • rictic 6y ago
      IE11, unfortunately, isn't _quite_ dead yet, and ES6 is definitely not the last word in useful JS language features.
    • dragonwriter 6y ago
      > ES6 has been widely supported for quite some time now. ES6/2015, sure; ES2021, though... For the latest useful JS features, you need a compiler, whether it's TypeScript or Babel or...
    • jamesgeck0 6y ago
      If you target browsers that are installed by default on operating systems that are still receiving security updates, you have to support Windows 8.1 and thus IE 11 for another two and a half years, alas.
• NetOpWibby 6y ago
  I find TypeScript incredibly useful in reminding me my code is terrible. I use it to save me from myself.
• irjustin 6y ago
  At this point, I don't believe it would be unrealistic for MSFT to make TS to get its own engine or a fork of V8 similar to how PHP became HACK over time for FB. I think that'd be super cool.
• karatestomp 6y ago
  One of the best things about TypeScript is that it compiles to very normal-looking JS. Its compilation step is almost entirely just stripping out type data, by design. I went through coffeescript pain before and like many didn’t expect to ever be happy to use a compiles-to-JS language, but TS really is different. If they change direction and start to add tons of stuff that doesn’t translate cleanly, I’ll get worried. Until then it’s very nice and comes with an escape hatch of just taking its output and making that your new codebase. It’s that clean-looking.
• jeffmcmahan 6y ago
  Amen. I don't transpile to JS anymore. If the client is IE (no updates for 7 years?) and doesn't feel like installing FF, Chrome, Edge, or whatever, then it is what it is. Modern static ESModule JS is quite good. I have several projects north of 30KSLOC written in modern JS. I'm not living in "undefined hell" because I use named-export ESModules, I check types all over, and I write quality tests. A little discipline goes a long way.
  • smichel17 6y ago
    Modules are my favorite part of js (and ts, mostly). One file = one module with all imports/exports explicit is so incredibly right. `git grep`ing to figure out which other file a random implicit import came from is a real PITA.
  • fardelian 6y ago
    >I check types all over Which is something you rarely need to spend time on if you're using TypeScript.
    • jeffmcmahan 6y ago
      That's true. But with TS I have to declare types, import typings, maintain a build process to run the TS compiler, and so on. Moreover, static typing comes with added tediousness, and I personally feel that it's not worth the freight.
• jdxcode 6y ago
  Do you use Babel to polyfill JS? Minify? Concatenate? You’re transpiling. And not much more than TS. There is very little logic change that TS does and most of it is essentially the same as what Babel would do for polyfill reasons.
  • jeffmcmahan 6y ago
    I'm not OP, but in my case, no. I don't. I write a roughly ES7, and if you're on an ancient phone/PC, oh well. I really don't care. Not because people using those devices don't matter, but because I am writing code for a company in which I have a say in what hardware/software is provided to employees. I don't have to support IE. That's true of a lot of developers, for whom Babel is a waste of time.
• marmada 6y ago
  Have you used TS? Calling it a DSL seems incorrect.
• anonytrary 6y ago
  Erring on the side of simplicity is a good rule of thumb. Sometimes the simpler thing to do in a million-line codebase is to statically type the code.
• zerubeus 6y ago
  This is valid when you write java(scripts) a code base that don't expend to multiple files and become a whole Application like we have today in the front end landscape. You solve scripting language problem with better code organization? While in the first place the language was designed to solve scripting problems, DOM manipulations, now you can use JavaScript to build backends and SPA's hybrid apps, and most importantly some huge code base of libraries like Gatsby, vscode, where large teams are collaborating in the same project. How would you solve all the runtime errors? How would you solve expending the capability of your code editor? How would you solve refactoring? Just to name very few of what something like Typescript is capable of.
• pkukkapalli 6y ago
  I think there is a way to get all of the "good parts" of Typescript, mainly type checking, without introducing the bad, mainly transpiling. I recently started just running Typescript on Javascript files, where all of the types are specified via JSDocs. It was a refreshing experience, and I highly recommend. The Typescript website[1] has pretty good documentation for it. [1]: https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html https://www.typescriptlang.org/docs/handbook/jsdoc-supported...
  • biomene 6y ago
    Came here to upvote typescript with jsdocs too. We use it in our project and it’s been really helpful. No overhead and you get the nice dev experience of typed code. Been doing it for 2 years, have yet to encounter a situation that would be solved by using ts compilation.
    • joquarky 6y ago
      I much prefer JS+JSDoc over Typescript when writing my own code. Typescript makes me feel overly constrained. Also, I've been doing web dev for 25+ years now and I don't like the trend backward to waiting for code to "compile". Although if you're going to have to compile, Svelte looks like a nice middle-ground.
  • itsnotlupus 6y ago
    Unfortunately their jsdoc stuff only exposes a subset of their typing capabilities, so you're leaving some advanced type goodies on the table.
    • kiliancs 6y ago
      They've been adding features on every release for at least a couple releases. Not sure when you last checked, but regardless, it's getting better.
• yakshaving_jgt 6y ago
  > This cones as no surprise to me If your comment were code, TypeScript would have caught your typo at compile time, versus JavaScript where your users would have experienced this (potentially catastrophic) error at runtime.
  • ddek 6y ago
    Had the original typo been corrected, TS would have also caught your reply and told you to update it. This is the main value we get out of TS. If we rename a property on a viewmodel, we then update a TS file containing all the models. In this trivial example an auto refactor might propagate the change, but if it didn’t we get type errors all over the application telling us to change this. In JS, there’s an overwhelming possibility we miss one of these, and it isn’t picked up until production.
    • smichel17 6y ago
      Worse, it might even work properly in production for many common use cases, then blow up in your face somewhere down the line. Real-life example: I recently came across some code that checked for a rare error. It was in the form, if (object.property === CONST_ERR_CODE) { /* handle it */ } At some point, `object` had been refactored and `property` was no longer on it, effectively turning the statement into "if (false)". This class of issue is probably my least favorite thing about js at any type of scale. It's so incredibly permissive that even simple tweaks need to be scrutinized carefully, whether by human eyes or unit tests. Using human eyes means I can't write js when I'm tired at the end of the day (otherwise the perfect time for small, no-functional-changes refactoring), and unit tests for trite details are boring -- I'd rather spend that effort up front, to appease the compiler. On the other hand, js is incredibly nice for prototyping, before I have to care about edge cases.
• pjmlp 6y ago
  Same here, exactly for those reasons. Non platform languages introduce those extra layers, while bringing along their own FFI issues, idiomatic libraries and other set of issues to care about. I only use TypeScript alongside Angular, as one could somehow consider Angular to be the platform, for anything else Web related, pure JavaScript with script tags (yes I don't bother with JavaScript transpilers either).
• Vinnl 6y ago
  I think if you call it a DSL and are comparing it to CoffeeScript, you might be misunderstanding what TypeScript is/does for you, and you might be missing out. If you're using ESLint, I'm quite sure you'd like TS as well, so if that is the case, you might want to give it an actual chance.
• nickbauman 6y ago
  The problem with this argument is you're already compiling your JavaScript to JavaScript anyway. You already can't paste ES6 into the JS console. And don't even start if you're using JSX. I think the opposite: nobody should write JavaScript. You should write in any other language than JavaScript, there are hundreds to choose from. https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS https://github.com/jashkenas/coffeescript/wiki/List-of-langu...
  • capableweb 6y ago
    The problem with your argument here is that you're assuming that the person you're replying to is using ES6 and/or JSX when they outright said they prefer just using "plain old JavaScript" which is neither of those things, so you're bypassing their argument fully. Their point seem to be that no matter what language you prefer to be compiled to JS, in ends up being JS anyway so you might as well write JS directly, because of the reasons provided in the last post. I don't agree with them (ClojureScript is the language of choice for me), but you're not arguing with good faith here.
    • Dragory 6y ago
      ES6 is plain old JavaScript. I think the parent commenter's point was that even when you're writing plain JS, if you target browsers (and old browsers specifically) or e.g. a large range of Node.js versions, you often still need to transpile it. This naturally doesn't apply if you target a specific runtime version (e.g. a specific Node.js version). That being said, the commenter above them could've also been referring to old old JavaScript where no transpilation is needed to reach practically every target environment.
      • hootbootscoot 6y ago
        ES6 implies transpiling, or polyfilling, IF you want to support most browsers still currently used. It seemed to me that the author was describing the (somewhat common?) practice of writing client code directly in ES5 and perhaps polyfilling any missing features for any targeted browsers that required specific fills. I, personally, find ES6 to be ugly and requires me to pretend all sorts of things that are not true for the targeted runtime. It's like a whole fake world, so I'll prefer to avoid it unless there's some obvious reason to use it, as in an existing front-end build toolchain and a spec to use ES6, etc. Greenfield? I guess Svelte and such will use it, but if Typescripting, then one will just write Typescript, right?