2008 után nem sok minden történt ezen a téren, mert Kothari a Silverlight fejlesztéssel volt alapvetően elfoglalva. Az utóbbi hónapokban viszont lényeges változások történtek azzal, hogy a MIX’11-en Kothari alapos promóciós előadást tartott, majd azt követően folyamatba helyezte nyílt forráskódú projektként való továbbvitelét a GitHub-on keresztül. Maga is viszonylag gyorsan lépked tovább a Script# fejlesztésével. A MIX’11 idejére megjelentetett 0.7-es változat már 0.71 és 0.72 változatként fejlődött tovább.
Az alábbiak a jelenlegi helyzetet tekintik át angol nyelvű kivonatok gyűjteménye formájában.
Nikhil Kothari: “on the Bing team as architect on the mobile experiences team (worked on Silverlight, RIA Services and ASP.NET before), Script# creator” http://www.nikhilk.net
Getting Started with Script# [April 28, 2011]
Hello World with Script# – a 101-style walkthrough on authoring and deploying scripts compiled from c#, while using the HTML DOM APIs, XMLHttpRequest, and jQuery.
This blog post covers the Hello World demo, which will show how you can get started with script#, and deploy scripts authored using this approach. It doesn’t go into more advanced topics, but hopefully it will also demonstrate a couple of key principles at play:
- Script# doesn’t introduce some new and odd abstractions. You’re still very much authoring script against the DOM and standard APIs, and existing knowledge of web development carries forward.
- The generated script is similar to script you might have authored directly, and can be distributed or deployed into a web application like any other script library, without a dependency on the compiler at runtime.
Script# enables you to leverage Visual Studio, C# syntax and existing familiar and robust set of .NET tools to scripting. In my MIX talk, I demonstrated some of this. In this post, you’ll see some basic benefits such as intellisense and compile errors.
Posted on 4/28/2011 @ 8:50 PM
This is an interesting project. I’ve been watching it for a while.
But honestly, I just can’t imagine how anyone could invest any serious resources developing with Script#.
It’s written by one guy, when he finds the time. There’s no timetable for important features. There’s no roadmap to speak of, and no source code. If he gets hit by a bus or something (let’s hope not), your project is dead.
Hey, I understand this isn’t your day job. Is there any reason it can’t become a “real product”, ie, get some support for adding it to VS, or open-source it?
Posted on 4/28/2011 @ 9:07 PM
The plan has always been to open source it. And its already on the path to being set up that way… see the MIX11 announcement first.
That said lots of teams have used it successfully for some large apps. The two things that helped: the productivity benefits outweighed the issues, and second, and this has been most important for the large teams – they could walk away from the tool with their latest snapshot of compiled scripts (which closely resembles their original source code), if there came a day where they decided directly working on the script in fact worked better. In other words they weren’t betting the farm by picking up a development-time tool, rather than a dependency they need to carry around in their deployed product.
Posted on 4/29/2011 @ 9:40 AM
I really don’t think the useful question is “why the project exists”
The real question IMO is why users use it (and there are many users building large and very real projects… also listed in my past blog posts). Only they can ultimately answer that particular question, since each team has unique requirements, and unique ways script# is providing value to the team… at the 10,000 ft level, these reasons converge into increased productivity and maintainability of code base. For many of the teams, this tool has been indispensable.
Of course, everyone’s mileage and experience differs, based on your needs, your opinions etc. You’re free to decide for your own situation. Not every tool is meant for everyone.
Posted on 4/29/2011 @ 1:38 PM
key1: “Some string”,
and you want to transform it, and all 50+usages of it, to
first: “Some String”
Posted on 5/1/2011 @ 10:48 AM
If anyone needs a good reason why scriptsharp might exist : recently jqgrid ( a very good grid plugin for jquery ) changed some methods from old syntax to new syntax:
old method : jQuery(”#grid_id”).jqGrid(‘getPostData’)
new method : jQuery(”#grid_id”).jqGrid(‘getGridParam’,’postData’)
if I had written everything with scriptsharp in my project, I could have changed this quite easily… just remove the old method and compile, and all places where the code would be broken just show up in the compiler output as errors…
Posted on 5/2/2011 @ 1:21 AM
I’d rather write my own grid control using Script# than using jqgrid(Im really considering this). 😛
I have really bad experience with jqgrid, awful setup, configuration, lots of overhead, and then u dont know why something is not working….
Posted on 5/2/2011 @ 7:41 AM
Script# is going in the right direction, but the one-person development model is hopeless. No offense to the NK: you’ve done a yeoman’s job but after 6 years there are still huge gaps, and HTML itself is changing every few months. One person working really really hard will never keep up.
Posted on 5/2/2011 @ 8:32 AM
Would love to see components built in script# rather than just a wrapper. Eventually, I hope there will be ability to do static linking, it will help to have code rather than just stubs, that can be static linked.
Hence the reason for open sourcing. Hopefully the new community around the web is one where everything doesn’t have to be baked in into VS, i.e. its a bit different from the typical .net/windows enterprise customer set. If open sourcing also doesn’t motivate the right community, then yes, you’re right, the only way to move it forward would be for script# to be a product, not a project, a topic on which I am not going to comment on over here. I’m going to give it a chance and see where it goes.
Posted on 5/2/2011 @ 4:47 PM
Script# controls are exactly what the company I currently work for are focusing on – the only way to go!
Keep up the good work Nikhil! I don’t care whether it goes open source or not, so long as you can keep it alive!
Script# at MIX11 [April 19, 2011]
As full-fledged script-based development becomes widespread with the HTML5 wave, a couple set of interesting questions emerge – what are the development tools you and your team uses to productively author and manage a code base? Shouldn’t you write code in a model that is optimized for development and productivity and let a compiler do its magic and produce code that is optimized for deployment and runtime?
In my demo, I highlighted some of these tooling experiences (things like refactoring, static analysis, unit testing and IDE tools). I also demo’d how you can get started with the traditional “hello world” scenario and how you can continue to use frameworks like jQuery, as well as write your own jQuery plugins using Script#.
I have published the code and slides. I will be blogging a more detailed post on each demo over the course of the next few blog posts, so stay tuned.
Script# has been used successfully to develop various applications. These include Bing maps, Bing mobile, and the Messenger/Web IM integration within Hotmail.
If you’re building an application using Script#, I’d love to hear about it, and reference it in an upcoming revamp of the project’s site.
You can now download the latest release of Script#, v0.7 off the Script# project site. It comes with the ability to consume generic types, a new script loader, and improved asp.net mvc integration, as well as nuget support to get you started on that. As always I look forward to hearing from you on your use of Script#.
Posted on 4/20/2011 @ 8:27 AM
Script# looks really great. But do we have support for calling any jquery plugins. E.g. jquery.imgareaselect.js. How can we write a wrapper for that. Is there any tool which can compile a js plugin to create a c# wrapper.
Posted on 4/20/2011 @ 12:30 PM
You can use jQuery plugins with script# – for example, out-of-the-box there is support for the jQuery BBQ and templating plugins. There is nothing automagic to build the wrapper, but it isn’t rocket science either.
I’d suggest checking out the sources on http://github.com/nikhilk/scriptsharp to see the code for those plugins as examples… and furthermore if you do build any, perhaps share them as well. Hopefully that sets up a pattern of the community helping itself, and overall will ensure everyone doesn’t have to build a wrapper from scratch every time for every plugin.
Posted on 4/22/2011 @ 12:37 AM
When will there be language support for c#4? All the sweet syntax sugar that makes C# outstanding, is not yet supported. Writing code in Scriptsharp looks more like writing .net 1.1 Code to me(Now with generics its a little more pleasant ;P). Im really anticipating you finally releasing the source code, and so maybe advancement goes faster in the future.
What do you think about SharpKit(which is open source and free now), which does the same and has full C#4 support? Their source on google code doesnt seem to be complete either and their .cs files are bloated and roughly about 2000 lines long each with lots of commented out methods.
I also really wonder how the ms teams went with script# for building things like maps and bing mobile and stuff. How did they organize the code and most importantly what did they say about the missing “var” statement? 😀
Also what about debugging? Wouldnt it be possible to actually debug against the .net dll, maybe using proxy types that do js calls against the browser? This would also greatly enhance prouctivity(I hate to debug js in IE).
Posted on 4/22/2011 @ 1:39 AM
I too would like to see more support for language constructs from newer c# versions, and am evaluating couple of different approaches in terms of how the script# compiler is built (the current approach is to parse c# source code). Both of those approaches require some underlying foundation work that isn’t ready yet. As those become ready, and I pick one, I will start opening up the source code. Opening up the source code to compiler before, and then doing a major shift in approach isn’t going to be helpful.
While that is happening, the current focus is to first optimize the generated script further, as that results in better runtime characteristics (size, perf etc.) and in some ways is more interesting to teams using script#. As for teams using script# without c# 4 support, the productivity wins with using the overall approach far outweigh the pain from absence of specific language constructs.
Debugging – yes, theoretically its possible to build what you’re referring to. It would be a nice subproject of its own, and perhaps something the community can get started. 🙂
Posted on 4/30/2011 @ 6:15 AM
I see your priorities. This seems to stand on much better fundamentals than other similar projects imo, and its an important project, just about to really start off.
I wonder what compiler approaches you are thinking about, i would think of the 3 possibilities of either directly parsing source code, parsing the il(like in jsc), or using some external ast provider or whatever(like “Compiler as a service” in the coming .net rewrite of the c# compiler)?
After I just started with Sharpkit, seeing it doesnt feel like its exactly brilliant, I might have a look at script# again, maybe I get it to work this time. 😀
GWT vs. ScriptSharp Pros and Cons [July 21, 2010]
We’ve been playing with GWT, but one of our developers wants to use Script#. We are already a Microsoft-based shop, and do all of our server-side work in C#.
I don’t consider java to be a show-stopper for GWT, as it’s extremely similar to C#.
My initial concerns with Script# primarily revolve around support and documentation.
On one hand we have Google, on the other… “Some Dude”. Script# is also closed-source… so if the developer stops working on it, are we S.O.L.? I also feel GWT has more documentation and community support.
Anyways, have you worked with both? Thoughts? Pros/Cons?
(To head this off at the pass: the question is not whether to go with a compiler or not… the question is which compiler)
Similar, but different, questions:
answered Jul 21 ’10 at 21:19 chris.r
I have been using GWT for several years. I have never heard of Script# so I will just tell you why you should stick with the Google solution.
- Active development. Google has a paid team of engineers both actively fixing defects and working on new functionality. I am currently in discussions with some other developers on how to implement a new feature for GWT.
- Large institution. Google has invested this project and used it to implement large-scale solutions. They’re eating their own dogfood, in other words. They have a vested interest in not letting it stagnate or become obsolete.
- Community. There are plenty of people working on add-ins/third-party/etc libraries and APIs to use alongside the vanilla distribution. These same people are also testing, filing, and fixing defects.
- Open. You touched on this yourself.
Notice how I didn’t touch on issues of language choice. I don’t think that’s really relevant at the level you describe. Remember that the first time you run into a limitation or road block with Script# you’ll become quickly stuck due to the things that both you and I described.
Of course, I recommend GWT just because of the track record.
answered Jul 27 ’10 at 20:48 chum of chance
I use Script# and previously used GWT. They’re really two different things. GWT is meant to provide a client and server solution, with RPCs and everything else. It is definitely more mature and you can get going on complex applications faster. Simply put, there’s a lot more code and examples in the wild.
However, I think if you’re developers are both server side and client side, using two different languages and two different platforms can be very, very burdensome. This is why I moved to Script#. Everything I do is in C# and in Visual Studio, it allows me to be a lot more productive. If you’re not taking advantage of GWT’s backend capabilities, it is really overkill.
Don’t let Script# lack of community support fool you. While it is a problem, the product is very mature and feature rich. If your developers are using C#/VS why make them use a separate program for the clientside? I found that was a huge productivity hit.
answered Mar 26  at 6:21 DuckMaestro
Personally, I’m already intimately familiar with jQuery, WCF, and am beginning to use new HTML5 capabilities directly. Script# is the perfect missing piece because I can continue to use jQuery and WCF very easily, and I don’t need to go through the hassle of switching to or integrating with the paradigms or requirements of GWT.
Also, on the UI building side of things, you might consider Sharp UI that I recently open-sourced, which makes it easier to build reusable controls in a jQuery+Script# setting.
Sharp-UI / README [May 9, 2011]
Sharp UI is a control building framework for Script# (https://github.com/NikhilK/scriptsharp) and jQuery. The goal of the project is to enable basic reusability and encapsulation (a la the "user control" paradigm in WPF or ASP.NET) when building client-side HTML user interface controls in Script# with jQuery. For live sample application see here: http://files.duck17.net/AnimationEditor/Default.htm. Features (or beneficial consequences) include: * Ability to construct reusable controls using HTML fragments and C# (Script#) codebehind. * Ability to separate logic from layout by using .html(.cs) file pairs and partial classes. * Support for locally-scoped CSS through CSS rewriting. * Support for locally-identified elements through ID rewriting. * Automatic binding of member fields to named elements. * Support for nested instantiations -- controls can declare instances of other controls. * Support for container controls and preservation of nested/inner content. * AddedToDocument & RemovedFromDocument events. * Replication of standard "mouse capture" behavior. Detailed documentation is pending. In the mean time please inspect the example code, or contact me on Twitter at @duckmaestro.
Script# Programming in the Large [Oct 29, 2008]
Some large-scale Ajax apps and frameworks – the Live Framework and Office 14, both announced at PDC – built using Script#…
Yesterday’s PDC keynote featured a number of interesting products and technologies, such as Office 14 and Live Services, that today involve fairly large-scale (code size, team size and project length) Ajax development. The demos were just amazing – Kudos to the product teams!
Behind the scenes, on the engineering front, Script# provided the toolset and script authoring model. I’ve been working with both teams for quite a while now, and am really excited to be able to finally share these particular uses now that they are public (since to be honest, I was myself quite pleasantly surprised to see the model of compiling down to script scale up in this manner).
Live Mesh features an online desktop experience within the browser to enable remotely accessing files from any browser. The Live Framework exposes the underlying platform to .NET applications and script applications alike. The script framework portion of the SDK, like the UI, is based on Script#. The documentation for this framework on msdn was built from doc-comments in the originating c# code, which double up to enable script intellisense in Visual Studio.
The devs clearly recognized the value from using standard .NET tools and C# for engineering the thousands of lines of script and Ajax code that power these great consumer and developer experiences.
From the latest Twitter messages:
– “it’s not about source language first and foremost. It’s about tools support associated with language + static typing”
– 22 May: “Released v0.7.2.0 of script# with #jQuery 1.6.1 + #knockout support & bug fixes http://bit.ly/aZTm2r … also on github http://bit.ly/hJrbv3 … #Nuget package for @scriptsharp – scriptlets, script loader integration with asp.net mvc simplified … http://bit.ly/lMTuGo”
– 17 May: “still in the process of rolling out”
– 2 May: “Posted Script# 0.7.1 with various github reported issues fixed along with couple new features (nullables, observables). http://bit.ly/aZTm2r”
– 29 Apr … when S# will become an “officially supported” product instead of a side project? It’s hard to sell to my mana’s. Answer: “Script# will be an oss project. See http://bit.ly/hJrbv3 (with more to come over time). Hopefully that will grow a better community.”
– 25 Apr: “Just checked in the sources for ScriptSharp.Web.dll (script# and asp.net mvc integration) into github project at http://bit.ly/hJrbv3”
– Will MS contribute to script# once it’s on github? Answer: “If I can recruit some volunteers… hoping to sign up couple of devs I know.”
nikhilk Nikhil Kothari
TomMathias Tom Mathias
@nikhilk How does JSLint fit into ScriptSharp?
in reply to @TomMathias ↑
@nikhilk Nikhil Kothari
@TomMathias you can run script tools on generated script, but even better, you can now run tools like FxCop and StyleCop on the original c#.
joeriks jonas.eriksson Ⓤ
in reply to @joeriks ↑
@nikhilk Nikhil Kothari
@joeriks my thought: it’s not about source language first and foremost. It’s about tools support associated with language + static typing.
Posted Script# 0.7.1 with various github reported issues fixed along with couple new features (nullables, observables). http://bit.ly/aZTm2r
nikhilk Nikhil Kothari
chadbr chad br
@nikhilk I just want to know when S# will become an “officially supported” product instead of a side project? It’s hard to sell to my mana’s
in reply to @chadbr ↑
@nikhilk Nikhil Kothari
Just checked in the sources for ScriptSharp.Web.dll (script# and asp.net mvc integration) into github project at http://bit.ly/hJrbv3
woodjoe Joe Wood
@nikhilk cool. You also said you had a new job, but didn’t say where…
in reply to @woodjoe ↑
@nikhilk Nikhil Kothari
@woodjoe I’m on the bing team as architect on the mobile experiences team …
woodjoe Joe Wood
@nikhilk Enjoyed your mix talk. Will MS contribute to script# once it’s on github?
in reply to @woodjoe ↑
@nikhilk Nikhil Kothari
@woodjoe thanks. If I can recruit some volunteers… hoping to sign up couple of devs I know.