TypeScript: New Compiler and Moving to GitHub
blogs.msdn.com
blogs.msdn.com
574 open issues exist for TypeScript on Codeplex. https://typescript.codeplex.com/workitem/list/basic
"Please note: since we’re moving to a new issue tracker and a new codebase, we are not copying all issues over. If you have issues in the current CodePlex issue tracker, please try them against the new codebase and file them in the GitHub issue tracker if they still repro."
Github is back up to 117.
Managing an open source community is something that the TypeScript leadership still have yet to learn. They weren't concerned about coordinating with TC39 on module syntax (they shipped 1.0 with an arbitrary snapshot), they were never very interested in accepting code, and they don't value the time users take to document bugs and edge cases.
tl;dr the move to Github is lipstick on a pig. It is a distraction from the real changes they must make on order to collaborate well with others.
I mean, really? Less than 600 bugs, and they couldn't be bothered? Even with a small team. this could have been done in a day.
And it's not like it would be extra work, because going through the bug tracker and trying to get a broader view of the issues raised should be a thing which happens continually anyway.
They will have no choice but to change the Typescript module system,or it will stop being compatible for Ecmascript. Right now afaik Typescript doesnt support generators either.
It's a great language but the way they handled module in Typescript was a mistake.
A lot are duplicates. There are two or three issues for type unions, atleast two issues for ABCs, and so on. Also a some of the issues are for VS integration.
>Github is back up to 117.
I only glanced at the GH issues but it seems they're actually internal issues discovered by the devs themselves, not from the Codeplex tracker.
It's rare to see a GitHub-hosted project that offers proper releases, proper planning for those releases, proper documentation, and the organization and project management efforts that enable such things.
The lack of such basic project management structure leads to projects that see very erratic development, or outright abandonment. Many GitHub-hosted projects are barely more than a hobby, rather than an ongoing concern. Their code may be somewhat usable, but it's rarely comparable to what we see from more organized projects.
Those projects do not get erratic development or get abandoned because they lack "proper planing". That is reversing cause and effect. They lack heavy planing because their development depends too much on free time of one or two people, who have other life priorities. No amount of planning will change that.
A great example of this is djangopackages.com. Looking at thumbnailing packages[2] even though there are a dozen packages, only three are popular. And taking a glance at the commit sparklines only two are under active development. So I know to start with them.
It's not like Gnome/GTK and KDE managed such issues so much better...
This means I can make a lateral (stack) move without having to revert back to "junior" status. Hey, I love me some C# and .NET but the offers from the open-source community are just too tempting.
I booked an interview.
Early web technologies like CGI, PHP, JSP, ColdFusion, ASP and ASP.NET arose due to real-world needs.
Ruby on Rails, on the other hand, arose mainly due to hype.
From a technological perspective, there really wasn't anything special about Ruby on Rails. Many of us who had been doing web development for some time had already built or used proprietary/in-house frameworks that offered the same functionality, but were written in Perl, Python or Tcl instead.
If it weren't for strong and very loud personalities within the Ruby on Rails community, combined with some very lucky timing with respect to the rise of the so-called "Web 2.0", it likely wouldn't have been seen as "special", and wouldn't have garnered the hype that it did.
Technologies that come out of an environment of hype, rather than solving real problems, tend not to stick around as long. Systems built using technologies that solve real problems continue to be used and maintained. Systems built using technology chosen purely because some manager or executive saw a webcast full of nice-sounding buzzwords tend not to survive very long.
I remember Pythonistas at the time raised similar complaints about how Python already had all this stuff — but the thing is, Rails did a nice job of packaging it up in a way that was easy for disaffected Java jockeys to get into and start having fun, while the Python approach at the time was more along the lines of "take this thing and that thing — or maybe one of these five other things, we can't decide — then make this other piece yourself and stick them together with chewing gum."
Rails did come to prominence largely through social channels rather than technical superiority, but it wasn't a marketing-driven hype train targeted at nontechnical managers — it appealed to hackers who wanted to have fun but did not already have a homebrew Perl stack at the ready.
That's how I remember it, anyway.
I've made several stack switches without issue. Usually it involves switching languages at your current company, then using your current salary as leverage to get the next.
The main barrier is HR, which you can get around using this method.
I wouldn't read too much into that though - huge company, a bunch of projects and different audiences. CodePlex has an audience - there's a bunch of cool projects on there, too.
It is, however, the only repo under the "Microsoft" GitHub user AFAICT (https://github.com/Microsoft).
https://github.com/firebase/blaze_compiler
Typescript has been a joy to develop in. The codebase is a mix of typescript and plain JS for some of the parsing.
There are a few interesting architectures patterns like a work around for no subclassing of Error by wrapping an error with a backwards chained decorator
https://github.com/firebase/blaze_compiler/blob/master/src/e...
(thanks to mindplay for that idea here https://typescript.codeplex.com/discussions/465345)
That product is still in it's infancy so gradually being refactored towards full modularisation, so its still a work in progress.
FYI: I use pycharm with the node.js plugin, and typescript compiles in the background without intervention, and I can step debug the program, and the line at the top off all the files transparent changes the stack traces back into TS.
I also just finished building this app [1] for homeless youth in Minnesota using TypeScript and Angular.
[0]: https://github.com/JudahGabriel/ravendb/tree/master/Raven.St...
[1]: http://ysnmn.org
I hope that they implement in-memory compilation, so that the compiler can work properly with Gulp (which would also increase build times). I also hope that they'll support automatic generation of ambient external declaration files. TypeScript doesn't work well with npm modules just yet because of that.
Stuff just worked better on all accounts: Language, tooling, fast compilation, good error messages, not having to touch JavaScript-related mess, etc.
In-memory compilation already exists. I wrote a Gulp wrapper for TS for my own project [0] that supports both normal compilation and incremental compilation (i.e., watch functionality).
The real issue with TS is that it doesn't export a programmable compiler API by default, necessitating either a process.exec to the shell script or adding an export statement using the vm module. I gather that was a low priority for the devs because they wanted to get the compiler API in shape first.
[0] https://github.com/Arnavion/libjass/blob/master/gulplib/type...
Well, it seems that it requires quite a lot of code. Perhaps you should publish the gulp wrapper as a Gulp plugin.
By the way, does your Gulp wrapper load files from the disk, or are the files given to it as in-memory streams? That's what I mean by "in-memory compilation".
The latter. The TS compiler (TypeScriptCompiler) internally works with string sources and outputs strings. The official sources use a wrapper around it (BatchCompiler) that converts input file names to input file contents and output JS+sourcemaps to files. My wrapper uses file contents from gulp.src for the same.
>Well, it seems that it requires quite a lot of code
Yes. The first part of my code is basically a reimplementation of BatchCompiler. But my code also does other things - for example I fiddle with the AST to generate automatic JSDocs, etc.
a) good SDK and package system (pub.dartlang.org)
b) clean break from JS (what if future JS will be incompatible with current TS ?)
c) perf - realted to b) you can't eg. add property on the fly accidently and will not get perf penalty for this
d) proper IDE for ALL mainstream OSes (vs. best IDE on Windows and substandard on OSX/Linux => various plugins)
Latency makes Eclipse unusable on every machine I've tried, including a current Haswell MBA with 8GB RAM and a half terabyte SSD.
Also: how many web developers do you know that use Eclipse?
neither do I - just say Dart has good dedicated (npm is for JS AFAIK) package system
>Latency makes Eclipse unusable on every machine I've tried
It's not as good as lets say IntelliJ (best IDE I've ever seen) but it's "good enough"
Besides - it seems long term goal for Dart team is chromedeveditor https://github.com/dart-lang/chromedeveditor (another point for Dart it's open source) which will be pretty fast when DartVM will come to Chrome
class Greeter { greeting: string; constructor(message: string) { this.greeting = message; } greet() { return "Hello, " + this.greeting; } }
Compiled to the following:
var Greeter = (function () { function Greeter(message) { this.greeting = message; } Greeter.prototype.greet = function () { return "Hello, " + this.greeting; }; return Greeter; })();
So I have a question about this: what is the reason why it doesn't become the following instead?
function Greeter(message) { this.greeting = message; } Greeter.prototype.greet = function () { return "Hello, " + this.greeting; };
In other words, why is the extra function put around it? There must be a good reason... Thanks!
It doesn't seem to be needed here, but their transpiler could use the same structure for more evolved classes/module too, where it would make sense.
Typescript seems pretty cool, lack of dead code analysis and the inability to write my own compiler passes (I have looked for this, but it does not seem to be an option - would love to stand corrected) puts me off it.
I cant speak for anyone else but on github I will now almost always submit a pull request for a fix instead of filing bugs.
Great move for typescript~
I have no doubt that the slowness is a major complaint they get from TypeScript users, but at their current level of success/failure, they probably should be listening more to TypeScript non-users than users.
I suspect they had this in the works for a while and couldn't make build.