As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Coffeescript looks pretty cool. Has anyone used it? What are its Pros & Cons?
We've started to use CoffeeScript in our product - a non-public facing website which is basically an app for browsing certain kinds of data.
We use CoffeeScript as a command-line compiler (not on the server, which we'd eventually like to do).
PROS (for us):
It gets rid of a lot of needless clutter in javascript (eg braces, semi-colons, some brackets) to the extent that the code is cleaner & easier to comprehend at-a-glance than javascript
20-30% less lines of code than javascript (to do exactly the same thing)
CoffeeScript not only removes noise but adds keywords, classes, and features like heredocs to make coding cleaner and somewhat more enjoyable
Given the previous points, it is undoubtedly faster to code in CoffeeScript once you learn the ropes
CONS
When using the command-line compiler: to debug, you're looking at different code when solving the problem (javascript) as when writing the fix (coffeescript). However, somewhat unbelievably, our CoffeeScript is so awesome we've never needed to debug it!
Importantly, we can turn back at anytime. Our coffeescript compiler is just producing readable javascript, so if anyone changes their mind or can't figure something out, then we can just drop back to using the javascript that coffeescript produced - and keep coding.
We use coffeescript for all of the javascript in BusyConf. A large portion of BusyConf is a client side application that runs in browers, including support for offline mode.
All of our coffeescript code is fully tested. The tests themselves are written in coffeescript, and use the Qunit framework (which is written in javascript). We also wrote an extension to the Qunit framework that makes the tests nicer. The Qunit extension is written in CoffeeScript. Our application has a mobile version which is written in CoffeeScript, and it uses the Sencha Touch framework (which is written in javascript).
The take away from that is that you can freely intermix javascript dependencies in your application, but all of the code you write (your application code, tests, etc) can (and should!) be coffeescript.
Almost a year later, it's worth posting some updates:
Ruby on Rails 3.1 is incorporating official CoffeeScript support, which means it's going to see far more real-world use. I gave a talk at RailsConf last month, where most of the attendees hadn't heard of CoffeeScript before and—given dhh's strong endorsement—were eager to get into it.
There's a book on CoffeeScript, currently in eBook and soon to be in print from The Pragmatic Bookshelf. It's called CoffeeScript: Accelerated JavaScript Development, and it's by yours truly. It's based on CoffeeScript 1.1.1.
The language has actually changed very little in the six months between 1.0 and 1.1.1; nearly all of the changes qualify as "bugfixes." I had to make very few tweaks to the code in the book for the transition from 1.0.1 to 1.1.1. However, I'm sure the language will see more significant changes in the future.
The most definitive list of CoffeeScript projects is on the CoffeeScript wiki's In the Wild page.
I'd say that most of the production use of CoffeeScript so far is in conjunction with Appcelerator to create iPhone/Android apps. (Wynn Netherland of The Changelog blurbed my book by describing CoffeeScript as "my secret weapon for iOS, Android, and WebOS mobile development"), but there's going to be a lot more use in production Rails apps—and, I hope, elsewhere—in the coming months.
Coffeescript was used in the Ars Technica reader for iPad http://arstechnica.com/apple/news/2010/11/introducing-the-ars-technica-reader-for-ipad.ars
I really love Coffeescript these days. Essentially the entire HotelTonight iPhone application is written in it (using Appcelerator Titanium, which lets you write "native" apps in JavaScript - they are not web apps, say like Phonegap). I chose to use Coffeescript in this case because it makes organizing and maintaining a large amount of JS a lot easier. I also find it simply a lot more pleasurable to write code with Coffeescript (vs. JavaScript). We also use Coffeescript for the JS in our Rails app, but this is incredibly minor/small amount of code in relation to the entire phone app.
The pros mostly have to do with just being a nicer syntax, but also that it standardizes an OO mechanism, and then adds some nice additions (list comprehensions, some scope things, etc.).
The cons are almost zero for me. The primary one is that it's an extra layer to debug. You will need to look at the generated JS (which is VERY readable and nice), and then map that to your Coffeescript code. For us, this hasn't been an issue at all, but YMMV.
In the end, my take is, there is zero risk in terms of using it on a production app, so, don't let that be a blocker. Then, go try it out. Write some code with it, compare that to what you'd write in JS, look at the generated code to see if you are comfy with being able to read that for debugging needs. Also, hang out in the #coffeescript IRC, people are good there. And finally, see how it would integrate with your app, e.g. what's your "build" process (e.g. for Rails, try Barista, for something standalone, just use the included "coffee -w", etc.).
Coffeescript really just makes writing JS easier. You end up with cleaner, more efficient code.
That being said, you still can only do whatever you can do in vanilla JS. Once you use coffeescript enough, it does become a lot easier to write (good) JS.
So if you haven't used JS a ton, I'd suggest learning coffescript instead. You'll get better, cleaner, less buggy code. If you're already really fluent in JS, it might not be a good idea to start using coffeescript on a "real" app.
(Also, coffeescript does irk me a bit in that it seems to encourage rather "floofy" code. I don't know if it's a good thing or a bad thing, but it seems an extreme case of TMTOWTDI)
Note that although there is a compiler, you don't get static checking due to JavaScript's dynamic nature. As written in the FAQ:
Static Analysis
CoffeeScript uses a straight source-to-source compiler. No type
checking is performed, and we can't work out if a variable even exists
or not. This means that we can't implement features that other
languages can build in natively without costly runtime checks. As a
result, any feature which relies on this kind of analysis won't be
considered.
IDE support is less mature than that of JavaScript (Cloud9 has syntax highlight support, but Eclipse JSDT has refactorings and more): https://stackoverflow.com/questions/4084167/ide-or-its-add-in-for-coffescript-programming
Related
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>;
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I recently learned JavaScript an all of the sudden I hear about Python...
Should I go learn Python or just stick with my basic JavaScript knowledge?
If you have some "facts" I would love to hear them! Like efficiency, difficultylevel and so on, an so on...
Thanks :)
The two are generally used quite differently. Javascript is primarily used as a client side scripting language vs python which is a server based language. So in a website you could use both. But not sure if this is what you were wondering.
If you're just learning a language, then there is none better than Python. It's an easy language to pick up. It's well documented. It's associated with a large, active, and friendly community. Since it's a scripting language, you can easily try stuff out and immediately see the results. You can also build up from programming basics, starting by learning functions and then moving into classes.
Javascript is the bane of many a programmer's existences. It's easy enough to learn, and is good for small scripts which is what is was designed for. But once you start making anything big, it becomes hard to keep track of. That's why language modifications like CoffeeScript, Typescript and Dart have emerged.
As noted by spinon, these programming languages were used in very different ways. Python is a general scripting language, which can sometimes be used to do server-side work. Javascript used to be solely used for building interactivity on web pages. Nowadays, however, it also becomes popular in server-side and desktop applications as Node.js.
The key fact is that Javascript is very hard to ever change (because of billions of old implementations existing in browsers), so design errors made in early (and frantically hurried;-) stages are still with the language today. (See Crockford's Javascript: the good parts for a reasonable discussion by a JS expert and enthusiast about the good and bad parts thereof). This might change if something like a use strict; directive ever makes its way into ECMAscript (though programming in ways that support old, and often buggy, browsers, will still be like pulling teeth -- like writing Python code that runs unchanged all the way from Python 1.0 to 3.1 would be!-).
Python is deployed in more traditional ways, so gradual language changes have enhanced it over the years (it was also designed with less hurry, and [[arguably, not "a fact";-)]] ended up with a better design from the start, in many respects).
As a result, Javascript (so far) has not enjoyed much success "server side", where programmers get a choice (even though they still have to use JS for "browser side" code). But there's nothing intrinsic to that. JS is by far the most widely deployed language in the world (those billions of browsers...), huge investments are made in it by many companies and open source groups in competing implementations and supporting frameworks (Python's no slouch at that either, but the difference is still there), practical improvements (speed, warnings) keep piling up on JS's side as a consequence (even though the language proper can't improve).
With strict self-imposed programming discipline (enforced e.g. by Crockfor's "lint" program for JS) and a good supporting framework (jQuery, Dojo, Closure, ...) and tools (Firefox has maybe the best add-ons for JS tracing and debugging, but other browsers are rushing in that direction too), JS has become usable in recent years. Probably one of these days a fast server-side implementation (probably with "use strict;" or the like enforced, once that's officially blessed;-) will start gaining a substantial foothold, just because so many web programmers already have some JS knowledge (they have to, to make good web apps).
Note that much of JS's bad rep (beyond the acknowledge "bad parts that can't be removed";-) comes from stuff that doesn't really "belong" to JS as a language: buggy implementations, the mess that the HTML DOM can often be (esp. with buggy browser impementations), etc. There is no reason a future server-side deployment should reproduce these maddening defects!-)
Python’s a good second language to learn after JavaScript, as they have a reasonable number of similarities, e.g.
they’re both memory-managed
they have similar data structures — JavaScript’s objects and arrays are much like Python’s dictionaries and arrays
they’re both used quite a lot for web-related work — JavaScript in the browser and in server-side contexts like node.js, Python in web frameworks like Django.
However, Python’s object-oriented... stuff is quite different to JavaScript’s protoype-based object-oriented stuff.
If the only programming you do is manipulating web pages within the web browser, then Python won’t be of any direct use to you (only JavaScript runs in browsers at the moment). But learning another programming language generally gives you new ways to think about the languages you already know. Learning Python could help you write better JavaScript.
JavaScript is usually used as a client-side scripting language - that is, it gets downloaded and executed by your browser. Python, however, is usually not coupled to the web. it can be used as a server-side scripting language, and for scripts and applications of any kind. But it is not a client-side language, and is therefore not directly comparable to Javascript, which has an entirely different audience.
Looking at the language level, Javascript is terrible and dysfunctional (hard to debug, clumsy object-orientation) while Python is beautiful and expressive. This is, of course, subjective :-)
Javascript is primarily for client-side ( browser ), Python is primarily used for server-side - so they serve different needs ( disregarding the Python to JS converters and all ).
I would recommend learning Python though, as it influenced ECMAScript and the syntax is very similar, both are object oriented, both are great languages.
2018 Update: I would still recommend learning Python over Javascript as a first language because it's just that much of a more beautiful, elegant language... although Javascript can now be used for both server-side and client-side thanks to node.js thus making it more useful all-around.
http://hg.toolness.com/python-for-js-programmers/raw-file/tip/PythonForJsProgrammers.html
IMO Python may be easier to learn (having taught both to intro classes).
Also, one major annoyance of JavaScript is that in runs in your browser. This inherently makes it much harder to debug problems.
In terms of a production-level language, Python is more of a general purpose programming language, while JavaScript is targeted at building dynamic web applications.
If you want to get into programming, you should definitely learn a more general purpose language such as Java or Python.
For what purpose? Javascript is king in some circles (web development, for instance).
Javascript and Python are not mutually exclusive. Why not learn both?
JavaScript and Python are both great languages that are geared toward different problems.
JavaScript knowledge is invaluable when dealing with the web, writing web pages, and poking around in html DOM.
Python is a scripting language that is great for a host of things on any machine.
It depends.
Do you want to program in a language that specifically targets web browsers? Stick with Javascript
Do you want to write... well anything besides for web browsers? Learn Python.
Python is an excellent beginner language that's not just a beginner language. Google uses it, NASA uses it, and many, many other organizations use Python.
Along with Python generally being server-side and JavaScript client-side, Python was designed to not only be easy to learn, but also easy to read, and to encourage a more productive environment.
If you need to ask, then I would say no since you don't have a need in mind for its usage.
I'm curious what's the view on "things that compile into javascript" e.g. GWT, Script# and WebSharper and their like. These seem to be fairly niche components aimed at allowing folks to write javascript without writing javascript.
Personally I'm comfortable writing javascript (using JQuery/Prototype/ExtJS or some other such library) and view things like GWT these as needless abstractions that may end up limiting what a developer needs to accomplish or best-case providing a very long-winded workaround. In some cases you still end up writing javascript e.g. JSNI.
Worse still if you don't know what's going on under the covers you run the risk of unintended consequences. E.g. how do you know GWT is creating closures and managing namespaces correctly?
I'm curious to hear others' opinions. Is this where web programming is headed?
Should JavaScript be avoided in favor of X? By all means!
I will start with a disclaimer: my answer is very biased as I am on the WebSharper developer team. The reason I am on this team in the first place is that I found myself a complete failure in writing pure JavaScript, and then suggested to my company that we try and write a compiler from our favorite language, F#, to JavaScript.
For me, JavaScript is the portable assembly of the web, fulfilling the same role as C does in the rest of the world. It is portable, widely used, and it will stay. But I do not want to write JavaScript, no more than I want to write assembly. The reasons that I do not want to use JavaScript as a language include:
There is no static analysis, it does not even check if functions are called with the right number of arguments. Typos bite!
There is no or a very limited concept of libraries, namespaces, modules, classes, therefore every framework invents their own (a similar situation to that of R5RS Scheme).
The tooling (code editors, debuggers, profilers) is rather poor, and most of it because of (1) and (2): JavaScript is not amenable to static analysis.
There is no or a very limited standard library.
There are many rough edges and a bias to using mutation. JavaScript is a poorly designed language even in the untyped family (I prefer Scheme).
We are trying to address all of these issues in WebSharper. For example, WebSharper in Visual Studio has code completion, even when it exposes third-party JavaScript APIs, like Ext Js. But whether we have or will succeed or fail is not really the point. The point is that it is possible, and, I would hope, very desirable to address these issues.
Worse still if you don't know what's
going on under the covers you run the
risk of unintended consequences. E.g.
how do you know GWT is creating
closures and managing namespaces
correctly?
This is just about writing the compiler the right way. WebSharper, for instance, maps F# lambdas to JavaScript lambdas in a 1-1 manner (in fact, it never introduces a lambda). I would perhaps accept your argument if you mentioned that, say, WebSharper is not yet mature and tested enough and therefore you are hesitant to trust it. But then GWT has been around for a while and should produce correct code.
The bottom line is that strongly typed languages are strictly better than untyped languages - you can easily write untyped code in them if you need to, but you have the option of using the type-checker, which is the programmer's spell-checker. Why wouldn't you? A refusal to do so sounds a bit luddite to me.
Although, I don't personally favor one style over another, I don't think that abstraction from Javascript is the only benefit that these frameworks bring to the table. Surely, in abstracting the entire language, there will be things that become impossible that were previously possible, and vice-versa. The decision to go with a framework such as GWT over writing vanilla JavaScript depends on many factors.
Making this a discussion of JavaScript vs language X is fruitless as each language has its strengths and weaknesses. Instead, do an objective cost-benefit analysis on what is to be gained or lost by going with such a framework, and that can only be done by you and not the SO community unfortunately.
The issue of not knowing what goes on under the hood applies to JavaScript just as much as it does to any translated source. How many people do you think would know exactly what is going on in jQuery when they try to do a comparison such as $("p") == $("p") and get back false as a result. This is not a hypothetical situation and there are several questions on SO regarding the same. It takes time to learn a language or framework, and given sufficient time, developers could just as well understand the compiled source of these frameworks.
Another related aspect to the above question is of trust. We continuously build higher level abstractions upon lower level abstractions, and rely on the fact that the lower level stuff is supposed to work as expected. What was the last time you dug down into the compiled binary of a C++ or Java program just to ensure that it worked correctly? We don't because we trust the compiler.
Moreover, when using such a framework, there is no shame in falling back to JavaScript using JSNI, for example. It's all about solving the problem in the best possible manner with the tools at hand. There is nothing sacred about JavaScript, or Java, or C#, or Ruby, etc. They are all tools for solving problems, and while it may be a barrier for you, it might be a real time-saver and advantageous to someone else.
As for where I think web programming is headed, there are many interesting trends that I think or rather hope will succeed such as JavaScript on the server side. It solves very real problems for me at least in that we can avoid code duplication easily in a web application. Same validations, logic, etc. can be shared on the client and server sides. It also allows for writing a simple (de)serialization mechanism so RPC or RMI communication becomes possible very easily. I mean it would be really nice to be able to write:
account.debit(200);
on the client side, instead of:
$.ajax({
url: "/account",
data: { amount: 200 },
success: function(data) {
..
}
error: function() {
..
}
});
Finally, it's great that we have all this diversity in frameworks and solutions for building web applications as the next generation of solutions can learn from the failures of each and focus on their successes to build even better, faster, and more awesome tools.
I have three big practical issues I have with websharper and other compilers that claim to avoid the pain of Javascript.
If you won’t know Javascript well you can’t understand most of the examples on the web of using the DOM/ExtJs etc., so you have to learn Javascript whatever. (For the some reason all F# programmers must be able to at least read C# or VB.NET otherwise they cannot access most information about the .net framework)
On any web project you need a few web experts that know the DOM and CSS inside out; would such a person be willing to work with F# rather than Javascript?
Being tied into the provider of the compiler, will they be about in 5 years’ time; I want full open source or the tools to be supported by Microsoft.
The 4 big positives I see with these frameworks are:
Shareing code between the server/client
Having fewer languages a programmer needs to know (javascript is a real pain as it looks like Jave/C# but is not anything like them)
The average quality of a F# programmer is a lot better than a jscript programmer.
My opinion for what it's worth is that every framework has its pros/cons and a project team should evaluate their use cases before including one. To me any framework is just a tool to be used to solve a problem, and you should pick the best one for the job.
I prefer to stick to pure JavaScript solutions myself, but that being said I can think of a few cases where GWT would be helpful.
GWT would allow a team to share code between the server/client, reducing the need to write the same code twice (JS and Java). Or if someone was porting a Java client to a web UI, they may find it easier to stick to GWT ( of course then again it may make it harder :-) ).
I know this is a gross over-simplification, because there are many other things that frameworks like GWT offer, but here is how I view it: if you like JavaScript, write JavaScript; if you don't, use GWT or Cappuccino or whatever.
The reason people use frameworks like GWT is not necessarily the abstraction that they give--you can have that with JavaScript frameworks like ExtJS--but rather the fact that they allow you to write web applications in something other than JavaScript. If I were a Java programmer who wanted to write a web application, I would use GWT because I would not have to learn a new language.
It's all preference, really. I prefer to write JavaScript, but many people don't.
Recently several tools have been released such as pyjamas and Scheme2js that allow one to take code in a language such as Python or Scheme and compile it to Javascript.
But how practical is such a tool?
I could see debugging being quite painful as you would have to debug the compiled javascript code itself, and correlate any bugs in that code with the corresponding lines in the original python/scheme/etc source code. Even with an intelligent stack trace such as the pyjamas -d option provides, this still seems tedious.
Also, libraries such as jQuery make writing Javascript much more fun and productive. But for many developers Javascript is still a new language to learn.
Has anyone worked with compiled Javascript in a production environment? Any recommendations or comments on the practicality of compiling to Javascript instead of writing your code directly in Javascript?
I believe GWT, based on Java, may be the most popular product of this kind, though I wouldn't describing it as "compiling Java to JS" but rather as "generating JS code". While I personally share some of your doubts, and would rather code JS directly, I have to admit that it is indeed an extremely practical as well as popular tool, entirely production-ready: I observe that, internally, many web apps that are rich and complex enough to warrant a front-end / back-end split are more and more often ending up as a Python back-end and a Java front-end -- the latter specifically to allow GWT (of course there are also plenty of Python front-ends, and plenty of Python back-ends, but I think this is a trend).
Google Wave uses GWT and is probably the most talked-about web app using it so far; together with the huge number of GWT-using web apps listed here, I think it establishes beyond any doubt that the approach is practical (as well as popular;-). Whether it's optimal (vs. writing actual javascript with a good framework in support) is a harder question to answer.
One of the more heavily used JavaScript compilers is GWT. This compiles Java to JavaScript, and is definitely used in production. The web interface to Google Wave is written in this system.
Also, Skydeck wrote Ocamljs, in order to make it easy for them to write FireFox extensions. That also worked quite well.
In summary, if you can write a good compiler, there is no showstoppers keeping you from writing a good JavaScript compiler.
Google Web Toolkit does it (Java to Javascript compiling), and GWT is used widely by Google (duh) and many others, so it definitely is practical.
Since the code is autogenerated, you debug problems in Java - assumption that the problem is in your code, and not in the compiler code, is true in 99% of all cases.
List of languages that compile to JS
As an another example Haxe could be mentioned. Haxe is a independent language and compiles to Flash 6-10, JavaScript, NekoVM and also to c++ - source code. Why is this practical?
you could use features the language itself could not offer
recompile code on multiple platforms (e.g.: form check in JavaScript and on server side)
there is a remoting package for communication between the platforms, and its genius.
autocompletion through the compiler
compile time type checks
If you are interested, you could start reading here.
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!