I'm currently learning React and I think I understand it pretty well. However, there's one thing that's been bothering me regarding development of robust React applications - what tools do developers use for static type checking?
I really like TypeScript. I think it reduces the pain of developing JavaScript applications quite a lot, thanks to type checking and other neat features. Visual Studio Code also offers a really nice code completion. And I know that I can make it work with React by using typings + DenifitelyTyped.
The thing is, there aren't many tutorials about using React + TypeScript. There also doesn't seem to be many articles about developing using this combo. On the other hand, many people seem to be using Flow, which is a project backed by Facebook (and I guess they also use it).
I've managed to find a discussion on Reddit with pros and cons about going the React + TypeScript / React + Flow way. However, to me, it appears to be quite outdated as it is about 10 months old now. I think a lot has changed since then.
I've also found two articles about using React + Flow and React + TypeScript. The author states some issues he's run into when using both of the options and concludes that TypeScript is "the best bet right now" (November 2015), especially because the Flow project has many issues and receives low developer activity from Facebook. He also mentions it doesn't play well with Babel?
So, I guess the question would be: Is it safe to use the React + TypeScript combo, or will I run into some difficulties? What about Flow? Are there some other similar tools I should check out? Which approach would you recommend?
Update September 2017:
Having more than a year of experience with daily use of TypeScript, and playing with Flow for a while, I've came to the following conclusions:
TypeScript is still painful to use to this very day. The problem is that the JavaScript world just moves so fast that TypeScript keeps lagging behind. Thinking about using that fancy new ES7 stage 3 feature? Nope, you can't. Wishing to get type hints for the latest version of some library? Wait a month, or two, maybe more...
Flow has come a long way, it has been improved a lot, it can catch some things that TS can't. Best of all, it finally works on Windows. Also, there's great plugin for VS Code (no idea why it has only 3/5 rating). And it works 100 % with React Native, TypeScript is not even 50 % there yet.
Most of the time, you don't need types at all. All the additional typing is rarely worth it. JS is a dynamically typed language, get over it :)
TL;DR: If you plan to use any type checker, I recommend using Flow.
Update February 2019:
I believe the recommendation above got out of date and is no longer relevant. Three reasons:
React Hooks are here. They make type-checking your code much easier. In most situations, no additional code is needed.
TypeScript's type inference has improved.
TypeScript has much bigger community than Flow. Even yarn, Facebook's package manager, is moving away from Flow, to TypeScript.
So, I think TypeScript is a much more pragmatic choice than Flow in 2019.
As to whether it's even worth using any type checker at all, I'd say it depends on the project size. Small projects probably don't need it.
I'm going to start this answer saying that I have never used Flow, so I can't say much about it. But, we are using React and TypeScript at work and it works great.
We have all the benefits I imagine you already know about, like refactoring, type safety, autocompletion, etc.
Sure, for what I have seen, the Flow syntax is cleaner than TypeScript, but you can add your types using TypeScript incrementally. I think, this is more a matter of taste. Some people prefer to have the code explicitly typed, others prefer to type less and have a stronger type inference.
About, the technologies I'd say TypeScript is a safe bet, Microsoft is pushing the language (there will be a version 2 soon), Angular is using it as well and there are a lot of Angular developers. Even here on SO, the tag TypeScript has more than 4K followers and it's rare to have an unanswered question.
The big issue with TypeScript, at least for us is that from time to time, we decide to use a component or a library that does not have the type definitions, so we have to create them ourselves. But I guess, that's a way to contribute back to the community.
I just asked myself the same question (though not with React) and found the following articles useful in evaluating the two:
http://michalzalecki.com/typescript-vs-flow/ (2016-07-15)
https://blog.wearewizards.io/flow-and-typescript-part-2-typescript (2015-11-20)
https://blog.wearewizards.io/flow-and-typescript-part-1-flow (2015-11-13)
The approach taken by the flow designers feels more functional with better type inference and a better approach for nulls. However, TypeScript has better community support especially with respect to pulling in types for third party libraries via http://definitelytyped.org/ which is important for having types flow through all your code for maximum type safety. TypeScript is created by Microsoft which has a rich history in writing compilers and evolving the technology in favorable directions - notable here is C# and the fact that they are already adding non-null types (2016-07-11): https://blogs.msdn.microsoft.com/typescript/2016/07/11/announcing-typescript-2-0-beta/
TypeScript seems like the safer bet today.
And for those trying TypeScript out in an existing codebase I found the following settings in my tsconfig.json file really helpful in allowing TypeScript to co-exist nicely with JavaScript (allowing transition one file at a time):
{
"compilerOptions": {
"allowJs": true,
"isolatedModules": true,
...
}
}
In my React development, I have quite a complex Babel / Webpack / Flow / Mocha toolchain set up and never had any issues with Flow. Takes some effort to set everything up (Webpack can be daunting at first), but afterwards, it just works. Flow is definitely the way to go as it is a narrower and more focused technology and as such more likely to play well with other tools. In contrast, TypeScript tries to be a lot more than just a type inference / static type checker tool and so it brings additional baggage and assumptions. So React is a specialized tool that does one thing well while TypeScript is effectively a language layered on top of JavaScript. To make sure Microsoft drives its point home, TypeScript files customarily have a different extension as well (.ts instead of .js) because you are now using a different language, got it?
TypeScript uses code generation to spit out JavaScript whereas in Flow the annotations are simply stripped off, there's no code generation as such. In the past, the Microsoft people promoting TypeScript used to make a statement to the effect that code generation is "file-local" (I don't remember the exact terminology used). This was supposed to provide a soothing reassurance that the TypeScript compiler isn't doing anything too magical. At any rate I can't find that statement prominently displayed any more. With Flow you don't need such assurances as you write in plain JavaScript (or whatever ECMA version you've configured Babel for) and the annotations are, like I said, simply stripped.
Not to mention that TypeScript is coming from a company that specializes in unethical and questionable technical practices (I don't rule out that TypeScript may eventually turn out to be the Mother of all Embrace-Extend-Extinguish ploys). Let's not forget that Microsoft did everything in their power to cause Javascript to fail as they (rightly, if belatedly) foresaw what a threat it represented, and still represents, to their crappy operating system and their bloated office suite.
Additionally, Flow's type system was much more powerful last time I bothered to evaluate TypeScript (circa 2015) and it was much easier to apply it incrementally or even sporadically in the sources. For integrating third party libraries I am using flowtyped and it is very rare that I need to complement those found there with my own definitions.
Finally, the fact that Angular uses TypeScript means absolutely nothing as Angular is not really relevant for new projects. React has won hands down, time to move on.
If you want type checks but would prefer to keep plain old javascript (to avoid compiling, or for portability, etc), here's one important distinction between the two (for React or in general):
With Flow the initial setup can run static analysis on vanilla js (it infers many types):
function square(n) {
return n * n; // Error!
}
square("2");
With TypeScript there's a migration effort and only some vanilla js static analysis without it:
noImplicitReturns which prevents you from forgetting to return at the end of a function.
noFallthroughCasesInSwitch which is helpful if you never want to forget a break statement between cases in a switch block.
TypeScript will also warn about unreachable code and labels, which you can disable with allowUnreachableCode and allowUnusedLabels respectively.
More Benefits To Flow
Flow's Comment Types and Error Suppression take support for vanilla js a step further, by allowing you to gradually incorporate type checks through legal js comments that annotate the type or suppress specific checks you might not be ready for yet. Comment types have been a feature request in TypeScript for quite some time, and only recently has there been a PR for it (see previous link).
Downsides To Flow
That said, all of Flow's simplicity does come at the cost of some pretty complex configuration with some annoying caveats, like how it type checks 3rd party libraries, etc. The best advice someone can give about Flow: try to cross-reference anything you read in their documentation as it's outdated and in some cases can be a little misleading.
Related
I really want to start learning Angular2 but the thing is I don't like the idea of having typescript. I want to do it using pure Javascript. But it seems like there is no proper documentation made for it. Do you have any recommended links where I could start with? 2nd question will be: Is it really worth learning Angular with Javascript since it has no docs for it? Or should I just embrace Typescript?
Or should I just embrace typescript?
Yes.
As a practical matter, you are going to find very few, if any, code examples, gists, tutorials, or blog posts that describe Angular without using TypeScript.
The reason is that 95%, or probably more like 99.9%, of Angular users are using TypeScript. That is because it brings a lot of benefits with very few drawbacks. You should re-examine your reasons for not liking the idea of having TypeScript. Yes, there's a learning curve, but it's also an investment in your future, one that will start paying dividends from day one in the form of improved productivity and code quality.
The only really compelling reason for trying to use Angular from JavaScript is if you want to use some subset of Angular's functionality, such as perhaps DI, from a non-Angular application.
It is possible to develop an application with ES5, ES6 or ES.next (transpiled with Babel). The difference between them and TypeScript is how DI and modularity are implemented. This example shows how it's done. And this document in Angular 2 documentation explains the differences.
JavaScript is currently considered second-class citizen in Angular development.
Almost all learning resources use TypeScript, which is not a problem if a developer knows how this code translates to JavaScript; the conversion involves the removal of types and refactoring DI annotations. If a developer doesn't use Babel for transpilation, he/she should be aware of modern JS features that are supported by TypeScript but not target browsers.
The problem is that JavaScript isn't supported by official Angular CLI tool and Ahead-of-Time compilation. This seriously limits the usage of Angular JavaScript applications in production.
I'm adding another answer here with some real technical points.
It is possible to get something running using JavaScript and not TypeScript. But you will have two major problems which mean you shouldn't do it:
You will need to do a lot of configuration. Here is a good article explaining how it can be done, but you'll have to make some changes to get it working with the latest version of babel and webpack, which is not trivial.
You will never be able to get the production bundles down to a sensible size. This is because you won't be using the angular-cli to do your builds, but will instead be using purely webpack. angular-cli appears to do some intelligent building with webpack and the typescript compiler to output much smaller, production bundles. For this reason alone, it's a non starter. The smallest bundle I've managed to get for a hello world app is over 800kB. The equivalent app built with typescript is about 140kB.
I feel that the angular team should update their documentation to point this out.
I'm modeling a JavaScript app. The main feature of this app is to consume a REST API to configure and show forms with some custom input types. I'm thinking of use TypeScript to take advantage of types and classes. But after some Google searches I realized that I can reach a very similar result with JavaScript ES6 + Flow (and Babel maybe).
My questions are:
These two approaches are really similar or I'm making a mess?
What I should consider to make a good decision choosing between ES6 + Flow or TypeScript?
Thanks for help.
Disclaimer: I work on the Flow team.
In general, I believe that Flow is more focused on soundness, while Typescript is more focused on ease of use. As such, Flow will disallow things that could cause runtime errors, while Typescript, in some cases, decides that in practice, certain behavior is not likely to cause an error, and preventing an unlikely error is not worth the inconvenience to the developer.
Here is a concrete example:
type Foo = {
x: string;
}
type Bar = {
x: 'foo';
}
const b: Bar = { x: 'foo' };
const f: Foo = b;
f.x = 'asdf';
This code is incorrect -- b.x is now 'asdf' even though the type says that it should be 'foo'!
Typescript allows this. Flow complains with a confusing error.
(typescript playground) (try flow)
With regards to tooling, Typescript wins, hands down (as much as it pains me to say it, as the person primarily responsible for integrating Flow into Nuclide). The setup process is simple and things just work. For Flow, you need to install and configure Babel (since Flow is not a compiler, you need something to strip out the types). For Typescript, all you need to do for editor support is download VSCode and you are done -- you don't even need to download Typescript separately. For Flow, if you want to go the recommended route, you need to install Atom+Nuclide and download Flow separately. Once you are set up, the Flow editor support works quite well, but the initial setup is time consuming.
I haven't used VSCode+Typescript enough to be able to accurately compare them but I do know that a lot of people are very happy with it, and based on my limited experience with it, it is very polished. The feature set is larger, too -- for example, Typescript supports automated refactoring.
Typescript's DefinitelyTyped (a set of type definitions for libraries, so you can use npm modules while retaining type safety) is larger and more mature than Flow's similar flow-typed -- although flow-typed is growing.
Statically typed systems help
I'm a big fan of statically typed languages, in particular Haskell. I have dabbled with both TypeScript and Flow. The draw to a statically typed technology is to build better code with the help of a compiler (or some equivalent). With improved validation tools, I can clarify my thinking to get to a more sophisticated, more self-evident design. This is a quality of the code that also pays off when it comes time to refactoring and maintenance. That's the benefit.
The cost is where the choices differentiate themselves the most
In this choice, cost is where the rubber hits the road because this is where the biggest differences between Flow and TypeScript appear. What makes Haskell powerful is the ability to infer the types. While it is a best practice to annotate the function definitions with a type signature, it is not required.
Furthermore, and this is key, I lean on the type inference engine the most while writing the code, i.e., while trying to figure out the best way to design the type signature. Once I have code "that types", I actually don't need the statically typed capacity... job done, per what the compiler compiler does by stripping all the type information away.
Given when I need the statically typed information the most, the inability to infer types was the biggest issue I experienced with TypeScript. When I needed the type capacity the most, I could be inadvertently baking in mistakes without any guidance on how to resolve it when I most needed it. Furthermore, by not having the option to let the compiler infer the information, I increase my workload, I increase the complexity of the problem in ways I know are unnecessary. That's where an inference engine is key; it reduces the user having to be explicit. It enables a linear process while designing my code (cause and effect).
Punch line
The source of the benefit is well defined (types help). How much benefit likely depends on the project. In my experience, there are more projects where the benefits outweigh the costs of using a statically typed approach using Flow.
Regarding the setup of Flow, I was already using a transpiler and found the extra configuration required to be nominal. The benefit of this configuration approach is the ability to incrementally use the technology, and within the project only where you think you need the type-driven "guidance" the most.
Finally, I have not mentioned the syntax benefits of using Flow. It's bad enough I'm having to track various flavors of JS (all good changes), using Flow I avoid what I consider a large departure from JS for TypeScript.
- E
I'm wondering how much benefit a CRUD-centric web application can benefit from Haskell's type system, particularly when the front end is built with a Javascript MVC framework like AngularJS which passes around typeless data objects.
It seems to me that as soon as you transform Haskell datatypes into JSON objects which you pass to a heavy JavaScript MVC framework layer, the benefits of having Haskell's type system as part of the web stack start eroding dramatically, as there is no way to let the type checker ensure the type-integrity of the data flow through the whole web application.
For example, you could change the database schema and the associated Haskell types, but the type checker won't be able to tell you what parts of the JavaScript MVC front-end need updating as well. I see this as a problem.
Am I stating the problem correctly, and if so, what advice could Haskell web application developers give on this point?
We've been wrestling with this exact same question quite a bit since we recently started a project with a substantial javascript front end. My anecdotal observation has been that we have a lot more bugs in the javascript application than we had with previous applications that just used Snap and generated HTML with Heist. We haven't decided on anything yet, but here are some of the possible solutions we've been considering:
Thin Javascript Wrapper
CoffeeScript
TypeScript
Dart
These are pretty unsatisfying solutions to me. The improve slightly on Javascript, but don't come close to giving me the things that I get with Haskell.
Much more functional and type safe front-end language
Fay is a proper subset of Haskell that compiles to Javascript. It definitely has some appeal, but doesn't give you access to all of Haskell. Last I heard it didn't support type classes, which I imagine would become an obstacle pretty quickly.
Elm
Roy
The problem with these solutions (as well as with the previous group) is that if your back end is written in Haskell, you still have the impedance mismatch because your front end language is not Haskell. This makes your code less DRY because you have to end up defining the same data structures in Haskell and the front end language. And when you change them in Haskell, you don't get errors indicating where your front end code needs changing. The app just breaks.
Compile Haskell to Javascript
The new game in town here is ghcjs. This is a very promising project, but I don't consider it to be viable for production at least until GHC 7.8 is released. That will hopefully happen within the next week. Once 7.8 is out the door, you still have to take into consideration that ghcjs is still very new. And even in the hypothetical scenario that it was 100% feature complete and the first release worked perfectly, you still have to remember that a fair amount of infrastructure has to be built before Haskell+ghcjs is as effective as high level javascript frameworks like Angular, Ember, etc.
UPDATE September 2016: Now, almost three years after I originally wrote this answer, GHCJS has improved greatly. There is still room for more improvements, but I have used it for production applications and it worked very well. It's especially powerful when combined with the Reflex FRP library that makes it much easier to build reactive UIs.
Generate Javascript from Haskell with an EDSL
If you have a relatively constrained problem, it might be possible to do all your application work on top of an EDSL that generates javascript. We already have the fantastic jmacro package to take care of the low level concerns of generating Javascript. You could leverage that and generate code that uses whatever other javascript libraries are appropriate for your application. That could be javascript + jquery, D3.js, or even code using a higher level javascript framework like Angular or Ember. I tend to think that Angular would be much easier to generate code for than Ember because of its simplicity and stronger encapsulation.
Greenfield a bytecode VM designed for functional languages in the browser
This is just a pie in the sky idea of mine. I don't think it's really practical because it would take a huge amount of work and be very difficult to gain adoption. But I like to at least mention the idea for completeness. Others have pointed out that asm.js is almost like this already. That may be the case, but it would be nice to have things like tailcall optimization designed into the VM level from the start.
In my opinion, easy solution - generate typescript interfaces from haskell data declarations(or another api scheme descriptions) and use TypeScript for front-end part.
it gives the opportunity to work on a project for people who do not know haskell, but who knows Javascript.
For example
data RpcResponse = RpcResponse { number :: Int, string :: Maybe String }
compile to
interface RpcResponse {
number : number,
string?: string
}
and function parseRpcResponseJson has Typescript type
parseRpcResponseJson(response: string): Option<RpcResponse>;
I want to improve my Coffeescript coding style. When I program in Scala, I can write a module in an hour or two, run it and have only a few minor bugs that I can quickly identify and fix.
In Coffeescript, I spend about the same time up front but I end up having a staggering amount of small bugs that would have been caught by a static type checker and I end up having to compile, reload the browser, step through some code, add some break points, etc. It's an infuriating experience and takes significantly longer.
It's much harder to abstract and encapsulate functionality due to the lack of interfaces and many other OO-features.
Are there design patterns that replace the encapsulation/abstraction generally provided by OO? Or is there a primer/guide on how to think in a more Coffeescript-y way (or how to solve problems using a prototypical approach)?
What have you done to become more productive in Coffeescript (or Javascript - perhaps even any dynamically typed languages)?
If you're coming from a statically-typed, class-centric language like Java or Scala, learning JavaScript/CoffeeScript is going to be a challenge. The compiler doesn't help you nearly as much, which means that it takes you minutes to discover small mistakes instead of seconds.
If that's your major bottleneck, then I'd suggest embracing a more test-driven coding methodology. Use a library like QUnit to write small tests for each piece of functionality you develop. Used properly, this style gives you the same benefits as a static compiler without compromising the flexibility of a dynamic language.
Don't go straight to Coffee Script. Learn the core concepts from prototype and Javascript OO. IMMO You can learn both at the same time, but you will benefit much more if you get Vanilla Javascript first. Based on my personal experience, Coffee Script syntactic sugar for classes can be a trap if you don't understand prototypical inheritances (it's easy to get stuck on a bug).
Coffee Script debugging is still not a completely solved matter in terms of tools, the only way I know it can be done is to write tests (a pain when you're just starting) or look at the generated code (at least for the more obscure bugs).
It was odd for me too; in my case coming from a C/C++ background.
What clicked for me is that you can reduce your iteration time significantly with a few tweaks of your work environment. The idea is to reduce it enough that you can write code in small chunks and test your code very very frequently.
On the lack of compile time checks: You'll get used to it. Like significant white space, the lack of compile time type checking just melts away after a few weeks. It's hard to say how exactly, but at least I can tell you that it did happen for me.
On the lack of interfaces: that's a tricky one. It would be nice to get a little more help in larger systems to remind you to implement entire interfaces. If you're finding that you really are losing a lot of time to that, you could write your own run time checks, and insert them where appropriate. E.g. if you register your objects with a central manager, that would be a good time to ensure that the objects qualify for the role they're being submitted to.
In general, it's a good to bear in mind that you have decent reflection abilities to hand.
On the lack of encapsulation: Given that coffeescript implements a very nice class wrapper to the prototype scheme, I'm assuming you mean the lack of private variables? There are actually a number of ways you can hide details from clients, if you feel the need to, and I do; usually to stop myself from shooting my foot in the future. The key is usually to squirrel things away in closures.
Also, have a look at Object.__defineGetter__ / Object.defineProperty? Getters and setter can help a lot in these situations.
On reducing iteration time:
I was using the built in file watcher in coffee to compile the scripts on change. Coupled with TextMate's ability to save all open files on losing focus, this meant that testing was a matter of switching from textmate to chrome/firefox and hitting refresh. Quite fast.
On a node.js project though, I've setup my views to just compile and serve on the fly so even the file watcher is superfluous. They're cached in release, but in the debug mode they're always reloaded from disk, recompiled, and on encountering errors I just serve them up instead. So now every few minutes I switch to the browser, hit refresh and either see my test running, or the compiler errors.
I am developing my first ASP.NET MVC application and I beleive that Script# can help me a lot. But it cannot find the resource necessary to support my development.
I could not find The codeplex site;
There is only one manual, which is very good, but it is not enough;
I could find very few tutorials;
I know that Script# was used to develop ASP.NET MVC scripts and that the source of MVC distributes the library.
But it seems that it is used only internally in Microsoft.
Where can I find other resources???
Do you really think that Script# will be continued and new versions will be deployed and it should be used by third-party projetcs ???
Thanks in advance
Don't be afraid of Javascript, it's a beautiful and powerful language. And with frameworks like jQuery, Prototype and Dojo, DOM manipulation and AJAX are greatly simplified and cross-browser issues are mostly history.
About Script#, I agree with this answer by mcintyre321. Last release over a year ago + closed source = no go for me.
UPDATE Jan/2010: there have been new Script# releases since the original writing of this answer. It's still closed-source but the author mentions open sourcing it after 1.0
UPDATE May 2011: Script# is now open source.
In short, my answer is: if you like powerful IDEs that run on Windows, OOD and C#, use ScriptSharp. It is more maintainable and structured, and demonstrably stable enough to use on serious projects. It can also be easily extended, as illustrated below and by other projects.
Since this is yet another Google indexed thread where people refer to Script# and jQuery as mutually exclusive I just wanted to point out some people are merging these two worlds, and in my case unleashing a lot of power by doing so. I'm offering a completely free and reusable library to access jQuery 1.4 from Script# projects, and full source code for the solution that generates it (almost exclusively from jQuery's own API documentation file):
http://www.christophercrooker.com/visual-studio-2010-rc-custom-tool-for-code-generation-and-jquery14-with-intellisense-for-scriptsharp
IMHO Script# fits well for large projects only, with really "rich" web client. Participating in such kind of project, I could only say that Script# helped us much. josephhemingway's remark about strongly typed is 100% true for such case. Also it allowed us to introduce new .NET developers without any JS background quickly. Assuming Nikhil Kothari's plans to open-source it in the summer 2008, we even decompiled (don't tell anybody! it's illegal) it and introduced generics, operators overloads, various bug fixes, etc.
BUT. Then Script# support faded away. Project on CodePlex with discussions and issue tracking was closed (interesting that parts of framework were published there shortly before). No updates, no future plans, no explanations. After such thing I'd consider Script# only after it goes open source to give the community ability to support it. E.g. on CodePlex.
I use Script#, I think it is great. You can use it with any framework, jQuery, dojo whatever, you would however have to wrap the framework, this could be a big job...
It's only benefit as I see it is that it allows you to develop javascript in a strongly typed environment. I think this is a HUGE benefit. I refuse to develop in weakly typed languages as maintenance is a nightmare.
If however you like to work in a weakly typed language then you wont need Script#.
Short answer NO. Wait for TypeScript.
Script# is really cool, but MS decided not to support it at all. The reason for that turns out to be that they were working on a better version of that - TypeScript (http://www.typescriptlang.org/)
It adds support for everything you need in a static language (intellisense, type checking, interfaces, classes etc.), but still looks very much like JS, and more importantly - confirms to the upcoming ECMA Script 6 standard. (unlike Script# or google's Dart)
Like the others have I would recommend some JavaScript (namely jQuery). Should you wish to continue with Script#, Nikhil Kothari's blog may be a good resource for you. http://www.nikhilk.net/ScriptSharpIntro.aspx -- That being said, I think you'll find that you are more productive with jQuery. There is a large database of community written plugins so you wouldn't necessarily have to reinvent the wheel on everything you want to do. jQuery plugins instead of ASP.NET Controls
Wow Val you got generics to work in
it, I'm impressed, was it hard?
Generics support would be great, so
would method and operator overloading.
josephhemingway
The whole point is that ScriptSharp's parser supports full C# 2.0 syntax. The only thing needed is to generate the proper JS. Not much work, considering JS dynamic nature. Generics would act as Java-style ones, i.e. no generation for each closed type argument set, just one class.
Are you sure that it is illegal to
decompile it, I will have to have a
look to see if it is the terms of use.
josephhemingway
Yep, it's illegal. EULA showed in setup clearly mentions that.
A release went out today, so it is good to see that it is still active.
Regardless of the previous lack of updates and that it not been open sourced I would still use it over plain js. You can stop using Script# at any time and more forward with the 'compiled' js if you don't like it.
I agree with you Val though that it really only fits large js based projects. I don't think you would get much benefit out of using it to perform basic page functionality like validate form input etc. It probably wouldn't be worth setting it up.
If however you are heavily using javascript and need to replicate OOP then I think it is a must. Things like refactoring becomes so easy, with plain js I would never refactor because it was just too hard to implement, over time my code became a mess.
Wow Val you got generics to work in it, I'm impressed, was it hard? Generics support would be great, so would method and operator overloading. Are you sure that it is illegal to decompile it, I will have to have a look to see if it is the terms of use.
The other advantage of using ScriptSharp that no one has mentioned is that if you need to interact with C# (using AJAX/REST/SOAP) you can use the same class definitions in both places and be sure that you have the interface defined properly, because it's the same source file! I have tried to use logic in shared source files with minimal success due to the way ScriptSharp's corelib is not 100% compatible with the C# corelib. But it works great for data file definitions.
I am using jQuery. It is really good. But I beleive that It is more confortable to me to work with C#. Even if it is a subset.
Also I would like to add that you certainly should use ScripSharp when you are planning to develop multiplatform projects. For example, at present time I write my image processing library code for .NET, JavaScript (ScriptSharp), Android (Mono) platforms on C#. Also I am planning to port my code on iOS (Mono) and Windows Phone in the future. And I think it's great code reusing and developer time minimization!