Slightly off topic, but can anyone share a link to a large, well designed (open-source) codebase written in TypeScript? Github incorrectly/mistakenly tags C projects at TypeScript thanks to the `.ts` files present (thanks for picking a unique TLA Microsoft ;)
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
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.
Mozilla's Shumway replacement for Flash uses TypeScript. Shumway's TypeScript translates ActionScript to JS. The Shumway team chose TypeScript for a few reasons. TypeScript's syntax is pretty close to ActionScript's, which simplifies the mapping from ActionScript to Shumway's implementation of Adobe's Flash APIs. Using three languages (AS, JS, and TS) also helps enforce modularity between the content (AS), compiler, runtime, and JITted (JS) code.
I like to think that my BrowserFS [0] codebase is a relatively well-designed TypeScript codebase, but I'm a bit biased. Not sure what you view as 'large', though.
I have anyways seen git submodules (and svn-externals before) to be a quick and dirty workaround for managing dependencies between modules.
I've been under the impression that using an artifact management tool such as Apache Ivy or Bower provides a more manageable and scalable solution, especially in projects with 20+ developers.
How does the solution proposed by the author compare? Does it compliment a managed artefact based solution?
I've seen this style of library come up quite a few times whilst hacking away in JavaScript where developers try to introduce a sense of strict typing (I even wrote a similar one myself when I first moved over from ActionScript). In the end I learned to stop worrying and love the <strike>bomb</strike> duck typing[0].
For me; one of the "joys" of coding JavaScript is the expressiveness that comes with a dynamic languages; should you throw an ArgumentError when your function that expects a number is invoked with a String? Maybe - sure it can help catch problems early and effectively "stop-the-line" in your public API, but then again it will probably end up throwing the classic `TypeError: Object foo has no method 'bar'` for you anyway.
For "public" methods which form part of an API (especially when that API is going to be shared outside of my team) I try to make my functions handle failure early (before they delegate off to the "private" internal methods), even better if the public methods can repair any unexpected usage, ie:
function convertToHex(value) {
var result;
if (typeof value !== "number") {
result = convertToHex(parseInt(value, 10));
}
else {
result = "0x" + value.toString(16);
}
return result;
}
Also, with regards to default argument values, I've always felt the "native" JavaScript approach was fairly compact and descriptive when required:
function doFoo(bar) {
bar = (bar !== undefined) ? bar : "default_value";
}
I'm not sure that embracing a languages dynamic nature should get in the way of leveraging libraries to write more readable code. One advantage of using a standard approach (be it a third party library, or something bespoke) is that you could enable / disable the 'type checking' depending on the build environment. I wouldn't be surprised if your existing toolchain isn't already bringing some static inference to your development - are you using jsdoc and an IDE with autocomplete, for example?
Trusting you find Dart, Typescript, et al agreeable you have to concede that some people are working with legacy code and can only make iterative changes to their codebase?
Yes, the second option is better in most cases. I'd spend more time reading the first one to understand what is going on compared to the second option.
Keep in mind that you will have to go for the first option (or other better options) if you expect 'falsy' values to be passed as arguments.
For me it was partly about providing type errors, but also very much about providing easy to write and easy to read type testing and sorting. Type testing in javascript can be a bit tough on the eye and this hopefully makes it easy to see what parameter types a function will accept.
The DNS320 has been my home server for just over a year (replacing a LinkStation). You can install Fonz FunPlug in about 5 minutes and get a solid, mirrored server for about £20.
ECMAScript 4 was implemented in ActionScript 3[1]; a very nice language to work with IMHO. The members of the ECMAScript steering group launched into a public fracas on their respective blogs[2] which eventually ended in the draft being canned, despite the fact both ActionScript and Silverlight were already based on the standard... shame.
> The second system syndrome is that evil effect that often happens when redesign a small, working system so that it becomes a huge leviathan built by piling new features over new features.
> Today I was reading the overview of ECMASCript 4 from ecmascript.org, and I got this very bad feeling that maybe the fourth version of ES, is suffering of an extremely strong case of this problem.
I dont know who is that guy , but what a load of cr*p ... it's people like him that got us stuck with what is javascript today. People often complain that Flash prevented Javascript from being widely adopted , the truth is that Macromedia/Adobe tried to push a better Javascript that would have helped the language then and today.
Imagine we had ES4 and HTML5 today. Nobody would be complaining about how much javascript sucks , and there would be no need for typescript, coffeescript ,etc ...
I wrote it many years ago, but if you think it's wrong I'd be happy to understand why.
I have never been against Flash nor ActionScript(which I don't know enough to criticize) but my understanding was that ES4 was vastly more complex than even AS ever was, rather than being an incremental change as ES6 is.
And please note I wrote
"""
ECMAScript 4 seems cool, I want to use a lot of those things (yay for multi method dispatch!), but maybe it is changing the language a little bit too much .
"""
And I wish I could influence what the dev world does, but I believe it is unlikely.
This is a small jQuery plugin that I have been maintaining for a few months now. It provides a bit of sugar when using both jQuery and Mustache templates.
True, but I find the lack of Micro-SD Card Slot to be particularly galling, especially as it's becoming an increasingly popular trend with Android handset manufacturers looking to add a hefty markup between otherwise identical models. Just ends up hurting us consumers who want to carry their music collections around with them :(
