Moving the project forward

[theoutlander]

@nikhilk - I think there's a lot of value in exposing various JS libraries and make it more community driven. We could split the S# project into a compiler and import libraries if that makes more sense. I think the community can contribute quite a bit there. I've also wanted to create how-to docs, but I don't have a location to put it. I could fork and do the above, but it will create more confusion and people most probably won't even know about it. In addition, we should have more frequent releases. We've been using 0.8 for over a year now, but it's just painful to get new changes into existing projects because we also run into versioning inconsistencies and issues with TFS, but that's an entirely different issue.

I understand you are busy, but is it possible to give a select few members access to make changes directly to the repo so we can keep the project moving forward? Thanks!

[michaelaird]

I agree.

Although Script# has been invaluable at getting us where we are today in our project, i'm considering abandoning it in favour of TypeScript due to the extremely slow pace of updates.

The last time the "released" version of ScriptSharp was updated was August of 2012. jQuery is now 3 minor versions ahead. jQueryUI is 2 minor versions ahead. Knockout is 1 major version ahead. etc.

I know I could fork and create custom builds for these things, i prefer to be on the released versions of these sorts of tools.

On the TypeScript side, there are projects like DefinitelyTyped that provide import definitions for almost every JS library you can think of .

[nikhilk]

Hear you both on this (then hangs head in shame :))

Need to fix this situation... in particular, starting with releases and docs in short term.

That said, there could be a lot more activity even with the current suboptimal setup and core compiler capabilities - for example, contributed patches to keep existing import libraries or add new ones (eg. angular), so at least stuff moves forward, and forks are short-lived (as pull requests get merged into a single mainline branch - I agree its hard to live continually in a fork). I just haven't seen the same level of interest as say DefinitelyTyped that you've brought up. I don't want to have this come across as excuse, but speaking realistically, at the end of the day, the relative prioritization function of this project does include level of community interest in the project.

@theoutlander - I just enabled wiki editing by others ... as well as created placeholders for at least two topics I think are needed. I'll send mail offline about sync'ing up in next couple of weeks or so if you're around. I'll definitely look into getting all the current stuff out released (during thanksgiving break), i.e. updated vsix and nuget packages, so that should help/can be assumed for the wiki content.

[theoutlander]

@nikhilk - Thanks, I'll try to make wiki updates as I get a chance. And yes, I'm looking forward to the updates as well as connecting with you.

As far as the community interest goes, I think it goes hand in hand with documentation and updates. As those areas improve and the barrier to entry gets lowered, I'm certain that the interest will grow. As long as there are frequent updates (we need dot builds), I'm fine working on a separate branch and sending pull requests.

I also think that we shouldn't have restrictions on the import libraries that are accepted into the project as long they're well known JS frameworks.

[theoutlander]

I've created a couple of tutorials here:

Creating your first HTML5 Application: Hello World

Building a spreadsheet in Script# using HTML5. I also shared the source code for the tutorial in a new github repository.

I'm hoping to build a few more tutorials on top of the spreadsheet. Maybe create an import library for shuntingyard.js and utilize it to support more complex formulas in the spreadsheet along with Knockout or something.

[erik-kallen]

@nikhilk I think we should consider cooperating (my project is at https://github.com/erik-kallen/SaltarelleCompiler)

[theoutlander]

@erik-kallen - Is there an interest in your group to merge the two projects? I can fork this repo and work with you in that case.

[ProdigySim]

It seems to me that SaltarelleCompiler's features are a superset of Script#'s features--so I'm not sure what is gained by merging them. It already contains a number of backwards-compatibility features for Script# as well.

I think the community's effort would be best spent simply focusing on a single project. @erik-kallen has demonstrated over the past year that Saltarelle can support a much more quick and flexible development model. I migrated my projects from Script# to Saltarelle almost a year ago, and I would encourage other developers to do the same. Script# did a great job demonstrating how amazing C# to Javascript translation could be, but for all intents and purposes I can see, Saltarelle obsoletes it. It would be nice to get everyone working on the same project :)

[erik-kallen]

@theoutlander I think my compiler is already lightyears ahead of Script# (IMHO, of course), and it should be compatible (at least it used to be until Nikhil changed the name of all attributes in the System.Runtime.CompilerServices namespace), but Script# has the better tooling and probably community, so my idea of how a merge should be is pretty much to keep my compiler but Script#'s name and tools. But that, of course, is up to Nikhil. Merging the two compilers is out of the question, since they do not share a single line of code.

[theoutlander]

@erik-kallen @ProdigySim I haven't tried Saltarelle mainly because I'm not sure what to expect. I think it's safe to assume that it will be challenging for existing large projects. I agree that the compiler is ahead primarily because of support for the latest .NET. Script# certainly has good tooling.

I don't think Script# is attracting new users lately because the ramp-up is just too steep along with lack of documentation and a user friendly site filled with examples (like KnockoutJS) and infrequent updates. There's a similar rampup/tooling issue with Saltarelle IMO. The plan on Script# was to bring it up to speed with the latest .NET and one of the options was using NRefactory - which you guys are already doing.

I think @nikhilk is generally very busy and that combined with his new role at Google I think it might be unlikely that he will work on S# much. That means script# users like myself and several other teams that myself and others convinced to use Script# get left back with no compiler / external library updates. However, I think there's so much more we can do with it.

I think that there's certainly value in taking the best from both the projects and creating something better. Happy to chat further if there's any interest. Thanks.

[erik-kallen]

@theoutlander I moved my large project without any major issues (that's why I tried to make it as compatible as possible; I'm lazy and I needed a better tool for what I was doing). I agree with you that Saltarelle is missing a nice website, I have been meaning to create one but there have always been other things to do. If you are interested in helping, please drop me an email. I also think the tooling from Script# is nice, but I have never used it as I have only ever used it as a code translation tool. I don't think Script# will ever be compatible with the latest (or later) .NET, as I think the refactoring required would be huge.

As I said, I think the best solution would be to merge the projects and take my compiler and Script#'s tooling and name, but that would require Nikhil's involvement..