Live data from Hacker News

TypeScript and the Road to 1.0

blogs.msdn.com

91–93 of 93 posts

Re: TypeScript and the Road to 1.0

#91
post #81
post #80

Earlier quoted context omitted.

> File headers? No. > Interfaces? Implicit interfaces. It's kinda handy. > Java-style OOP in my JS? I'm not sure what qualifies as "Java-style" OOP. Is the stuff from ES7 also "Java-style"? How about the stuff from CS? Well, you don't have to use classes. You can do everything with functions if you want. > I think we're both just stating subjective opinions [...] The difference is that I actually tried it.

So have I, chief. I've used heavy IDEs before with Java, and I much prefer a simpler text editor like Vim or Sublime. I tried out TS a while back. All the examples I've seen were overweight, much like classical enterprise Java. Too much cruft. Anyway, enjoy TS.

> heavy IDEs

If your machine has 6+ GB of RAM, it doesn't really matter if some IDE uses like half a gig of that. I mean, that's why you bought all that RAM in the first place, isn't it? The point was to use it, right?

Same deal with all those beefy cores. Giving one of them a little bit of work won't hurt one bit.

The only actual downside is that start up takes quite a bit longer than 100msec. However, if you're using it all day, it doesn't really matter if it took 15s to start, does it?

I believe that one should automate as much as possible. Offloading as much brain-dead repetitive work as possible to machines is always a good idea.

So, check if I use the right kind of arguments. Check if that thing has that field or method. Tell me if there are any methods which start with "foo" and if so, tell me their exact names, arguments, and return values. Tell me if the change I just did broke something.

That's the nice thing about machines. They will happily do this stuff over and over again, a thousand times a second. They'll never get tried of it. They'll never complain.

One thing I really dislike about JS is having to check documentation. If you want to use some library/plugin/whatever, you always have to go to its website, navigate to the docs, and then navigate to the specific section. Just to look up the arguments or the names/types of that config object you have to pass to that function.

It's so much nicer and also way faster to do that kind of thing directly in the IDE.

> enjoy TS

I use Dart. And yes, I do enjoy it. It's very pleasant to use.

Re: TypeScript and the Road to 1.0

#92
post #59

Earlier quoted context omitted.

If you have to introduce a build sequence to move to coffeescript then moving to coffeescript is definitely a net negative. I work on a >300k line JS codebase, and our tooling means you can make a change and hit f5 and you always get the latest version of the code. No file watching latency, no run-an-external-tool latency. We /could/ do the auto-reload thing, except that I think that for large applications with lots…

I'd be really interested to see what you're doing that uses >300k lines of javascript all at once.

I'm not sure what you mean by 'all at once', since rather obviously not all of those lines of code are running at once. The 'S' in SLOC does not stand for simultaneous.

The application has been continuously developed for nearly 10 years now, and small parts of the current codebase are 5 years old. A little while ago, I was very pleased to find and remove some code that was weird in order to work in IE4, but these days I'm enjoying removing IE6 and IE7 specific code. IE8 is the last non es5 browser we have to support and it's painful. The whole application runs in the browser, and connects to services it needs via streaming connections.

Once you take into account the fact that it's not just a couple of pretty forms for a back end application, plus the fact that in the browser you have to write things that come as standard in many other environments, plus the fact that you used to have to write extra code to work on different browsers, plus the fact that the javascript ecosystem was not up to the task back then so lots of things that would be generic now had to be written in house, plus the fact that it's extremely well tested both with unit tests, acceptance tests and integration tests, then a large codebase is really not all that surprising.

Re: TypeScript and the Road to 1.0

#93
post #66
post #63

Earlier quoted context omitted.

> That sounds like an IDE/editor feature, not a language feature. Being toolable is a language feature. You can't do these things with JS or CS, because your tools don't have a clue what's going on. You can only do some guessing.

By "autocomplete" you mean when you're writing code in an editor and you can type "fu", hit and it'll complete to "function() {}", for example? If that's the case, autocompletion exists for JS and CS for most of the editors that I've used (Notepad++, Vim, SublimeText, TextMate). CS is a better JS, but doesn't enforce any design decisions like static typing, or OOP (with interfaces apparently?). I like CS, because I l…

That would be "snippet expansion" (pioneered in TextMate, if I'm not mistaken — well, that's where I saw it first).

"Autocompletion" is… "automatic": you type the beginning of a method name and you get a contextual menu following your cursor showing a list of suggestions. Many editors have that feature, either built-in or via plugins, but it's definitely an area where IDEs shine. If the editor/IDE has a way to infer scope, you get good completion, if not, you get mediocre completion.

But "snippet expansion" or "templates" as they are called in some IDEs is very easy and doesn't require statical analysis or whatever.

Post reply on HN