TypeScript 3.0 | Hacker News Reader

TypeScript 3.0

typescriptlang.org

93 pointsgmac85 comments

Previous discussion: https://news.ycombinator.com/item?id=17645799

The future of javascript - decided. Any reasonably large JS project crumbles under its own weight. TS fixes all this. So glad to see it move forward.

These days, most people seem to be ok with having a compilation step in their workflow.

I don't. I'm way more productive with a lighter stack.

I stick to plain Javascript. Sometimes I add a lightweight framework like Vue that I can simply include.

Are there more of us out there?

Do you use an IDE?

No.

I’m genuinely curious: Why are you not okay with the compilation step? I work primarily as a developer using compiled languages so I may be missing something.

There are many aspects to it. From setting up a new project to 'edit a line and reload in the browser'. Everything feels so much faster, lighter, fresher.

I'm one of many who don't seem to understand your point of view. how would editing and reloading be faster than hot reloading? I usually edit my styling live in Sublime while viewing the changes in Chrome.

Styling?

yep, as in style sheets. personally I prefer Sass before native CSS, so I usually use the broader term to avoid assumptions about the technology stack used.

I usually write down styles to some kind of Notepad and then rewrite it to sass. At the beginning it was annoying, because I was forgetting that my css will be reloaded, but I got used to it.

tsc --watch is incredibly fast.

And you don't need a bundler and hot-reloading. Just stick to JS modules, output JS modules and let the browser take care of it.

But when you use a tool like webpack it's even simpler - you just save your file and it recompiles & reloads.

You can also run 'tsc -w' (watch mode) and it will automatically recompile as soon as files change. And since doing so maintains a local cache of the compiler's state in memory it's extremely fast.

The tiny amount of time I spend waiting for compiles is several orders of magnitude less than when I had to deal with the lack of static typing, particularly when refactoring code.

Fast REPL cycle.

If you've made the right choice for your workflow and project type then you'll never be alone.

Legit question, what don't you like about it and why?

I am moving into ES6 modules and the very notion of trying to use Babel or other post compiler to support older code styles seems archaic.

It reminds me of the smell of supporting IE6.

My apps are all designed to run on the latest browsers. Maybe I am lucky this way, but I don't have to support browsers older than a few months for my key systems.

Not sure about the OP, but for me, I've been around for almost 20 years on web dev front end stuff, and every time I review a compiler, a while later a new one comes along. And eventually every compiler I have tested/or reviewed is now out of style, or the version I tested had so many bugs, or NOW the default configs are perfect! bah. Burnt way too many times on this. I use absolutely minimal external libraries, and those that are, are already minimized.

Eventually, when my systems get more wider spread and more devs involved, I think a build step for staging then to production will be useful though.

(note, we do have a build step, it just doesn't use any front end compilers like webpack/babel)

I use the native modules more and more too. They are awesome.

In my opinion the cost of setting up a compiler such as typescript ot babel is significantly lower than the benefit and organization that types, modules, and modern language features provide.

agreed. being able to rename a property with confidence is worth the setup time in and of itself, let alone all of the other benefits it brings along.

So presumably you write all your non-web stuff in machine code? Compilers are pretty common.

Server side code is different as the server usually starts an interpreter that compiles the file on-the-fly in case it changed since the last pageview.

> the server usually starts an interpreter that compiles the file on-the-fly

You may already be aware of this, but you can set up the same workflow for frontend development (if you have a compilation step). "Watch mode" seems to be the popular nomenclature for this in the JavaScript community.

In production? I think I'm misreading your comments.

What ? Interpreters are pretty common in the non-web world too…

Not all people do code anything else than JS web stuff these days.

Even if you don't use TypeScript, don't you still need a precompilation step for minimizing your source files?

I suppose can probably get away with plain, unprocessed JS files for small personal projects, but that seems rather difficult to maintain for anything serious.

I do maintain pretty big projects this way. Even though the js is not minimized, it is way smaller then what the competition uses. Companies these days throw together insane amounts of bloated code for no reason.

Do you reference all your source files separately with script tags?

Yes. And again, we usually do way less http requests then the competition.

Look at a single post on the new React based Reddit. I just did and got 65 http requests loading 1.6MB of data.

It's almost everywhere like that these days. Too much tools. Too little concern for the actual outcome.

The new reddit is also a better experience than the old reddit, so there's that

Not in my experience - it's terribly slow on mobile, still fairly slow on desktop, and wastes huge amounts of space.

Ironically it's more robust than most of sites I see on the internet.

And to expand upon pjc50's comment, the mobile experience still pushes the app, even though I'm logged in and always dismiss it.

(I know full well why they want people to the install the app, but I still find it unfortunate that they a) don't remember that I dismiss it/have an option to never ask me and b) despite the redesign and having a relatively good mobile experience (assuming you didn't first hit an `amp.` link) still push the app.

And by better you mean worse? I second 'pjc50 here - new Reddit is slow on both mobile and PC, inefficient to read (wastes a lot of space), has questionable interactions thanks to JS abuse, and generally turns what was a condensed link aggregator into a poor Facebook clone.

Wow, I've never heard anyone express that opinion before. Even my wife (a non-technical user) hates the new design.

While I do agree that your approach leads to good result, I still don't see why you wouldn't add a compilation step to minimize/tree shake/TypeScript/etc.

If you're good enough to be conservative in what you pull in, you'll still be that, except you get to benefit from all the things a compilation step can offer. It still strikes me as a somewhat arbitrary limitation to impose on yourself.

I use webpack for almost all my projects, and TypeScript for a bunch of them. I'm also very mindful of what packages I use and the result is nice little bundle. I wouldn't be able to get the results I want if I limited myself by not having a compilation step.

Same here. We have 140k monthly active users. Just using unminified JavaScript and script tags to include other JS files. Most just because I wrote it and I'm a backend engineer.

Same here. We have 1.5 million monthly active users. Still using unminified JavaScript.

I developed a 500.000 line js front-end without a build step (only a minifier/bundler for production releases, nothing in dev). We did have an on-demand loader to bring in modules as needed. It’s definitely doable though I do prefer to use typescript myself for large codebases.

there are dozens of us

To each their own, but I question the scale/stability of your work without participating in the world of JS compilation (and the subsequent benefits).

The only valid question of scale/stability is whether or not it scales/remains stable. I've personally achieved a couple million ARR with unminified, uncompiled javascript on the client.

Edit:I will grant you that our business is processing-heavy, so the ratio of client JS to backend language is very low.

Well it really depends on the size of the project. For small project I agree but for larger projects Typescript really helps to produce better and more robust code (and also faster if it's well integrated into the editor like VS Code). I am currently rewriting a Firefox Extension in Typescript that started as a simple script and grew in complexity (quite a bit) to make it easier for others to contribute (it's open source) and understand the code and I wish I had started that way, it would have saved me quite a bit of work by now.

IMHO, it depends on what you're going to build. The bigger your application, the more you profit from features like static typing or automated tests.

When building a highly interactive e-banking front end application, you may want to use some complex framework. For a mostly static website with some show/hide-toggleable areas, plain JS or jQuery is probably easier and quicker to use.

Yep. Same here. I'm not against compilation step. I have projects with compilation. But projects with minimal dependence work as well. E.g. the Firefox extension Tip Tab and Session Boss are moderate complex SPA, and I just used plain JavaScript, JQuery, and a small CSS framework to build them. Work very well.

For smaller projects - sure, but for anything bigger than that it will take more time fiddling with JavaScript quirks then just use a preprocessor. Like with css compared to sass, I can’t imagine myself writing plain css anymore for any big project, it’s a nightmare to maintain and edit

Plain CSS has actaully come a long way since SASS was first introduced. The only reason to use SASS nowadays is for their color functions (which is still a big reason unfortunately).

Lordy, what? Webpack + hot reload makes the "compilation" step almost invisible / equivalent. I'm assuming this is just a troll comment.

So this is this week's recommendation? Last I checked it was grunt, or gulp, or something like that. I am forced to dabble with Node from time to time, and the effort to track what's this week's build chain is already too mentally taxing for me.

FWIW I mostly run terminal commands defined in package.json. I agree that keeping track of the fancy build tool du jour is best avoided, if possible.

These days it's easy to type into google "typescript starter" thanks to the excellent work of other people, which will inevitably include automatic reloading. You get better code pretty much for free.

I'm not trusting those starters will remain up to "modern standards" for longer than couple of months.

I've used react-scripts for a few months. I have no idea how old it is, but it's pretty good. Maybe automatic reload isn't always working, but I can just reload the whole page if something is off and it's instantaneous.

For me, it depends on the project. I try to stick to JS for smaller, simpler projects, but anything large (or with potential to become large) I use TS. I've worked on some very large JS projects over the years and in my opinion it's really difficult to for a JS codebase to scale well.

I definitely agree with being more productive with a lighter stack, but I do find the even though TS is slower to develop due to compiling, the quality of the code is usually better (especially with multiple people on a project).

Count me in. I don't touch frontend if I can avoid it, and if I can't, I sometimes have to work with compiling to JS and bloated node-based stacks. But when I write any JS for myself, I tend to do it pure, with files delivered to the browser as written (no minification, no obfuscation).

Not sure why I do it this way. For some irrational reason, I just don't like modern web tools. I don't use LESS/SASS either, prefering LASS (S-expressions -> CSS compiler library) in Common Lisp projects, and raw CSS otherwise. Part of the reason might be that I just miss the days when you could learn from "View Source" in your browser. A different part might be is that I don't understand why modern compilation to JS requires downloading many dozens of megabytes in hundreds of Node dependencies. That's just ridiculous.

I'd say it's mostly irrational, but I do sort of get the feeling.

It's true that many people who use, say, webpack will also just indiscriminately use heavy packages, complicated SASS/LESS setups, and whatnot.

But that doesn't mean that using webpack means you have to do the other things. It's possible to use webpack and various other 'fancy' stuff without going crazy on the packages, and with sourcemaps you still get to 'view source'.

Personally I find that the benefits of at least some degree of compilation are well worth the potential drawbacks. I am quite conservative in pulling in packages, I regularly use tools that show me visually which things increase the size of my payload, and the result is pretty nice. I can't imagine going back to using multiple script tags to include multiple js files.

EDIT: I'll add that I do understand wanting to avoid all this. It probably does take a bunch of domain-specific knowledge to know what to do and not to do, and I myself have also been trying to avoid much of it by moving to the back-end.

I'd love to read a guide into modern web that focused on establishing a leanest possible solid foundation for further work. Like, "this is the minimum setup to get minification of your JS and CSS; add this to get auto-refresh on file change; ...". Everything I've read so far jumps straight into downloading hundreds of megabytes of NPM modules. I just don't feel comfortable with all that code doing God knows what, God knows why.

Yeah, agreed. It's definitely true that going down the Webpack/compilation road sort of automatically sends you down a path of heavy, complicated solutions. Maybe what you describe could be something I could finally decide to blog about :).

For the sake of all that's beautiful in this world, please do.

I like this one when it comes to avoiding Gulp/grunt and the like: https://css-tricks.com/why-npm-scripts/

Typescript is a boon to large projects.

It isn't just about having a compilation process or something, but it's about the fact that a good type system (even like that of TypeScript) is like getting the compiler to do a lot of error checking for you without having to write the unit tests for it.

But if the project itself is so small that you don't care about writing unit tests, then sure fine use vanilla JS.

Well when you say “I” do you mean that you work alone? I find when I do, I do not need type systems, safety checks, etc. to understand the code, but if I need to review others code them having type annotations replaces the documentation that they didnt write.

What is the most effective way to get into TypeScript for programmer with pretty solid Java background? Are there any canonical books, educational OSS projects or perhaps another references?

Thanks in advance!

The main documentation is a good place to start. Really all you need is that and Visual Code https://code.visualstudio.com/ and you should be good to go.

Assuming you know JS already, TypeScript is quite easy, IMO, and the integration with VSCode is really nice. Just open up a .ts file and let the compiler teach you.

TypeScript's own docs are pretty friendly and in-depth for both reference or getting started: https://www.typescriptlang.org/docs/home.html

Alternatively, Basarat's guide is excellent, and works well as an intro followed by a detailed guide that you can work through step by step: https://basarat.gitbooks.io/typescript/docs/getting-started....

Ex Java Developer Here, settled to full time Typescript now. For me it was the main documentation. Typescript will feel similar.

Start with a project in vanilla JavaScript (try to write your code in an idiomatic JavaScript style). Keep building on it until it gets difficult to manage, then go add TypeScript to it.

If you're not a JavaScript developer then that exercise will help you understand what a typical JavaScript project look like and where TypeScript adds value. I think that, as a Java dev, if you just start by writing TypeScript you're liable to write code that looks a lot like Java. Doing it this way helps you see TypeScript as "JavaScript with Types" instead of "Java in the browser"

I'll second this approach provided you have some 'downtime' to work it all out. Things are much better now than when I started with TS, but it can still be a lot to take on all at once.

Using TS from the start probably affects how you write your code, and it's definitely easier and less daunting to be faces with a ton of 'problems to fix'. But learning how to add TS to an existing project is a valuable skill to have.

Do try to remember that the Javascript build tooling mess is not Typescript's fault.

If you just want to play with and learn Typescript, don't try to figure out the "right" way to build your project - just do whatever works for you while you're learning.

What's the best IDE to use with TypeScript on a macbook?

Probably vscode or a Jetbrains IDE.

I personally use sublime. In-editor error messages and intelligent autocomplete are a godsend.

VSCode

VS Code is great.

But "best" is pretty subjective.

Agreed but VS Code has been mentioned a few times. I'll go with that one for now.

VS Code works well for me. Both TypeScript & VS Code are made by Microsoft so they work pretty well together.

I've been using WebStorm on Windows and Linux, it is also available for macOS. Can really recommend all the JetBrains IDEs!

Personally I use Sublime these days, but Atom and Visual Studio Code are also excellent choices. I'd say they're all tied pretty closely for the leading spot, so the choice is really a matter of personal preference.

I thought this was announced months ago.

Yep, it was. Not sure why it's appearing on the front page now.

Types Obsession Syndrome?

There is a typo in the first subheading: "Project Refrences"

> This site uses cookies for analytics, personalized content and ads. By continuing to browse this site, you agree to this use.

Reply on news.ycombinator.com