Bridge.NET Acquires Saltarelle

[geoffreymcgill]

Hello Saltarelle Community!

I'm Geoffrey from Object.NET, and I wanted to personally let you all know that Saltarelle has been acquired by Object.NET. We've also been building an open source C# to JavaScript compiler called Bridge.NET, and now we've joined forces with Erik Källen (@erik-kallen) and the Saltarelle community.

The existing Saltarelle code base will now be merged into the upcoming Bridge.NET 2.0 release.

More information regarding the acquisition is available on the Bridge.NET and Saltarelle websites.

Questions & Answers

Q. Is the licensing changing?
A. No. We will not be changing the licensing. The upcoming Bridge.NET 2.0 release will be published with the same Apache License, Version 2.0.

EDIT: Bridge 2 is now Bridge 15.

Q. What's happening with Erik?
A. Erik has joined the Bridge.NET team and will continue his role as architect and developer.

Q. When will Bridge.NET 2.0 be released?
A. We don't have a solid time-line at the moment, but a lot of work has already been completed. There's some important new features we want to add, so once those are implemented and pass our quality assurance process, we'll have a Beta release publicly available. We're working hard on the new release, and now with a team of eight developers behind the project, progress is being made quickly.

EDIT: Bridge 15 has been released. Try live using Deck.NET.

Q. Will there be breaking changes if I upgrade from Saltarelle?
A. Yes. Breaking changes are unavoidable with the merging of these two code bases, but we're absolutely trying our best to minimize the conflicts. We're also doing our best to document all changes and will be releasing an official upgrade document with Bridge.NET 2.0. With some luck, a couple of search-and-replace sequences should take care of most conflicts.

If you have any questions or comments regarding this recent change, please feel free to ask in this thread, or send me an email ([email protected]). Both Erik and I will be available to answer questions.

We've posting news to @bridgedotnet on Twitter. Be sure to follow along if you want the latest details.

Cheers.

[dested]

While the breaking changes are a little scary, I believe this is great news!

Thanks Erik for creating a solid project that so many people use, and congratulations on the new job!

Looking forward to future releases, cheers.

[txdv]

Congratulations @erik-kallen !

[sdarnell]

Congratulations Erik, and many thanks for the amazing Saltarelle and your support of it. I'm looking forward to some great things from the team...

[nippur72]

I am a big fan of Saltarelle, using it for many years, and having contributed to it with small bugfixes and by writing libraries. I will look forward to contribute to this new project as well.

Thank you @erik-kallen.

[n9]

As far as I understand, Bridge.NET 2.0 is not yet available for Saltarelle 'users / contributors'? Should we stick with develop or roslyn branch?

And what will happen to repos with Saltarelle libraries? Are the libraries going to be ported to Bridge.NET or merged with or replaced with Bridge.NET libraries?

[geoffreymcgill]

Should we stick with develop or roslyn branch?

Was anyone here using the roslyn branch? I think the develop branch would be considered main stable branch, but does not include the Roslyn parser updates.

Bridge.NET 2.0 was forked from the roslyn branch, and eventually will be added as a branch on the main Bridge repo.

And what will happen to repos with Saltarelle libraries? Are the libraries going to be ported to Bridge.NET or merged with or replaced with Bridge.NET libraries?

All the Saltarelle authored libraries will be ported to Bridge. That will be an easy and quick process. It has already begun.

There is some overlap with the Bridge vs Saltarelle code base and libraries, but the preference is being given to the Saltarelle code. Basically we start with the Saltarelle code, we change the Namespace if required to Bridge, and then we merge in any Bridge specific features.

We're making a list of third party libraries|extensions|plugins and will do our best to contact those authors to assist with their upgrade process (if they choose to upgrade).

This whole process will take some time, and we will do our best to communicate status updates.

Feel free to ask questions here if you would like any clarification.

[n9]

Was anyone here using the roslyn branch? I think the develop branch would be considered main stable branch ...

Since new issues from develop were being fixed in roslyn, I was just considering switching to roslyn.

I do not know how stable the roslyn branch is. However, I was thinking that it may not contain all new C# 6 functionality, but it can be useful to use the roslyn branch and reports bugs there.

Do you consider backporting or fixing issues in the develop branch more feasible and useful, than using the roslyn branch?

We don't have a solid time-line at the moment, but a lot of work has already been completed.

What plan do you have, will it take month, three months, six months or more? (Just to help current users to decide.) Or will be the develop branch somehow maintained by Object.NET?

There's some important new features we want to add, so once those are implemented and pass our quality assurance process, we'll have a Beta release publicly available.

Why the 'Bridge.NET 2.0' fork is not public?

Maybe someone could help you find bugs earlier during the development. Especially, when some people are using Saltarelle longer time, so they already have many or larger projects. It's quite easy to see whether and how the compiled JavaScript is changed when is compiled with new version. So they can report regressions that were not covered in tests. Moreover for student or hobby projects, compiler quality is not crucial. And these users could be also useful for you.

[geoffreymcgill]

Hi @n9,

Thanks for the questions.

The roslyn branch does not include the new C#6 syntax support, although this is being worked on right now with Bridge.NET 2.0.

Do you consider backporting or fixing issues in the develop branch more feasible and useful, than using the roslyn branch?

At this point all new functionality and bug fixes are focused on Bridge2. Critical issues in Saltarelle develop branch will be fixed. If a fix is added to develop, it will also be checked in Bridge2 and fixed (if applicable).

Our goal is support and maintain the Saltarelle develop branch for a good while: at least one year (probably longer) after the official public release of Bridge 2.0. New features will likely only be added to Bridge2, but develop will patched and technical support provided to the community.

What plan do you have, will it take month, three months, six months or more? (Just to help current users to decide.)

It's still a little tough to say 100%, but we are gathering a list of users who are willing to test a private Bridge 2.0 Beta build, which will be available on-or-about the end of July 2015. I'm suspect another month after that for further refinements and testing. We don't want to go beyond two months, so the current goal is beginning of September for the final Bridge.NET 2.0 release. Ultimately, the code will decide when it is ready. Hope this helps with your planning.

If you would like to test the early private build, please send me ([email protected]) an email and I'll make sure you're contacted. Please include your GitHub username in the email.

Or will be the develop branch somehow maintained by Object.NET?

Yes, the develop branch will be maintained. As mentioned above, at least one year beyond (likely longer) the official Bridge.NET 2.0 release.

Why the 'Bridge.NET 2.0' fork is not public?

It will be, but right at the moment things are changing too much. We will push the Bridge2 source into a v2 branch of the Bridge repo once the Beta release is available. We're really looking forward to releasing all the code publicly as soon as possible, and highly value everyone's input. We just need until the end of the month to ensure things are working well.

Hope this helps.

[n9]

Thank you for the explanation.

One more thing, when you are going to build a brand new version, I have the following suggestions:

• What about to target Bridge 2.0 to ES6 (and use traceur or TypeScript to compile that to ES5)? (a)
• What about to remove all compatibility stuff (< IE9) from mscorlib.js (or whatever name it will have). And use external polyfills for older engines. (b)

In case (a), it may then better utilize ES6 optimizations of new JS engines. (Maybe, it will be needed to merge source maps then.)
The case (b) will keep mscorlib.js a bit simpler.

[nippur72]

talking of mscorlib.js, it would be nice to a have a pluggable type system, where you can use your own implementation of the basic types (e.g. your own decimal, etc).

[txdv]

So as far as I understand correctly the github.com/bridgedotnet/Bridge repo currently is not the 2.0 version and there is no need to commit to it because it will be superseded by Bridge 2.0?

[erik-kallen]

@n9 For your two points:

• Targeting ES6 and then use some compiler ES6 -> ES5: I am not a big fan. I like the idea in the future to have an ES6 target, but I don't really see the point of making it the only available target. But maybe. I don't see how browsers could possibly optimize ES6 compiled by traceur to ES5 better than code we compile to ES5 directly. Source maps, as you say, are an issue when adding in extra steps in the compilation pipeline.
• For IE9 compatibility: There isn't that much IE9 compatibility code in mscorlib at all There are polyfills for Array.some and Array.map because those are required by mscorlib.js, but I think that's it. If these two methods are too much of an issue, I think we can get rid of their use in mscorlib.js.

@nippur72 I think we need to do work on modularizing mscorlib. I don't really see the point of using your own implementations, but I absolutely see that it could be a good idea to have decimal support. Today there are two reasons to not do it: 1) that it means a bigger mscorlib so everyone has to pay for this feature, and 2) that it has just not been done. If we have a more modular mscorlib, reason 1 is gone and the only remaining issue is 2 (that it needs to be implemented).

EDIT: Decimal is fully supported in Bridge.

@nippur72 I think you might also need to sign some kind of CLA in order for your work on source maps to be incorporated. I hope you are willing to do that, it is a great feature to have.

[nippur72]

@erik-kallen yes of course I will sign it, just tell me what to do. Regarding why one would want to modify types, some examples:

• Getting rid of DateTime and use only Date (and not JsDate)
• Implement a 64 bit version of Int64
• Implement the number data type
• Implement the variant data type (that implicitly casts to int, double, etc.)

[erik-kallen]

@nippur72 I leave the instruction duty to @geoffreymcgill for this. Your other points should probably be their own issues, but here are my 5c on them anyway:

• what is the problem with JsDate? It maps directly to Date in JS. Is it the name? The name was chosen because we need DateTime for .net compatibility, and IMO the difference between a Date and a DateTime should be something about time, not something about eg. months being zero-based.

EIDT: The JsDate class is not supported in Bridge. Please use Date, or DateTime.

• a custom Int64 has a big potential to cause problems. In vNext, we have clipped types, so an Int32 is (at least optionally) constrained to fit in 32 bits. Therefore any API that requires a JS number larger than 32 bits should use Int64, and those APIs will expect a regular number there, not a custom type.

EDIT: Int64, UInt64 and Decimal types are fully supported with same-as-.NET-native functionality in Bridge.

• what do you need it for, and can't you declare it in another library of yours? I am hesitant to add it to mscorlib because I personally found it very hard to understand the relationship between number and the numerical types when I used competing products that did have number in the core library.

• isn't your variant === dynamic?

[n9]

@erik-kallen

Concerning ES6, I have not described it properly: ES6 code will be used in case, users will target ES6 engine (iojs/node, cef, or web browser that will support it). (But now it is not crucial, as there is no full ES6 support yet.)

Regarding IE9, something is already done in 6ccb2d4. But I think that n9@5817b8d was not included in 3.0 (as it was not in a patch branch).

[sdarnell]

Is the plan to target typescript or vanilla JS?

[n9]

As far as I understood, the plan is to target vanilla JS.

[erik-kallen]

Yes, the plan is to target vanilla JS, but to (optionally) allow generating a TypeScript definition file (.d.ts)

[geoffreymcgill]

Bridge.NET 1.7.0 was released yesterday and includes optional generation of TypeScript Definition files (.d.ts). Read more.

This same TypeScript support will be included in Bridge.NET 2.0.

[txdv]

Any news on the beta builds?

[nippur72]

What's the status of the merge? I see that Bridge 1.9 has been released, is there any foreseeable date for the 2.0? Will 2.0 be the next release?

[geoffreymcgill]

Hello Everyone,

We got a little distracted with the Bridge 1.8 and then with 1.9. We did not foresee the importance of those releases as part of our community building process. We've had a lot of interest in Bridge lately and in order to ensure the Bridge1 community remained well fed while Bridge2 is under development, we had to focus on feeding them first.

Bridge1 is now in a good place, and the team has refocused onto Bridge2.

Bridge1 and Bridge2 while being similar experiences from an end-users (you) experience, they are quite different code bases. Erik (@erik-kallen) has done an awesome job, and we've all learned a lot from his work, but it's taken some time for the rest of the team to work through both finishing up Bridge1 development, and getting up to speed with the Bridge2 code base.

From the beginning, there was a goal to merge the best features and experiences of both libraries into one. There's many great ideas coming to Bridge2 that originated in Bridge1, there's brand new features for Bridge2, and there's places where the original Saltarelle required some attention.

Bridge2 is not ready for public consumption. We still have some big ideas to implement, but the good news is, things are happening. We're really getting rolling now. Ya, it sucks it took this long, but I'm feeling good about where we're at and where we're headed.

While Bridge2 is not ready for public consumption|release, I am going to send out invites this week to access the private Bridge2 GitHub repo. Anyone that requested early access will get an invite. If for some reason you do not get an invite, make you let me know.

WARNING: Bridge2 is going to see some massive changes in the coming months. Anyone with access to the private Bridge2 repo will be playing with very unstable bits. Expect things to change rapidly and unexpectedly. This is fair warning.

We are opening the private repo to some members to follow along with development because we value you as a critical piece of the conversation.

Hope this status update helps, and I apologise for the delays.

[n9]

@geoffreymcgill Thank you for the update! (The project looked dead.)

[n9]

Anyone has got the invite to the private repo?

[geoffreymcgill]

The Bridge2 repo has a new Community team and invites are going out now.

I will stress again, Bridge2 is going through massive changes. Breaking Changes may happen at any time.

There are some important CI infrastructure pieces we're working on. I was hoping those new processes would have been in place before the end of the previous week, although it appears they will be delayed by at least another week, maybe two by the time we complete some internal testing.

All Feature Requests and Defects should be logged as Issues.

All your feedback is very welcome.

[DanTup]

@geoffreymcgill It's not clear from your previous message whether the invites should've already gone out, or if the "at least another week" part refers to that too (we haven't had anything yet).

We'd rather raise issues against v2 than distract you with anything more in v1! :)

[m5x]

Where should one ask for the invite? I've written an email to Geoffrey asking for invite three days ago but haven't received any reply yet. Please, add me to the invites list as well.

[geoffreymcgill]

A few invites have gone out. I'm reviewing each request on a case by case basis. The general policy I'm following is:

1. You have been a long time Saltarelle community member
2. You have actively participated in the Saltarelle community in the past (submitted issues, pull-request, participated in the discussions, etc)
3. You have requested an invite, either here in this thread or by emailing me ([email protected]).

If you are just interested to see how your existing project will be affected by the new Bridge2 development, you'll need to wait. You want to wait. At this point, Bridge2 is still going through a lot of changes and we really don't need, nor want, many people working with the project. Just a little feedback is all that we have time to handle at this point.

If you haven't received an invite to the Bridge2 repo, please just hang tight. We're doing our best to open this up as quickly as possible, but it's going to take time.

[fabi0]

Looks very promising joining Bridge + Saltarelle technologies.
What is the current timeframe for the Bridge2 release?

[DaniilVeriga]

In my understanding there is no time frame yet. Bridge2 development takes time and we don't want to provide fake time frames. Most likely we'll have better understanding on time frame soon.

[m5x]

Has anyone from Saltarelle community got the invite to the private repo and can confirm that Bridge.NET 2.0 is really happening and it is not becoming big inefficent pile of code like Ext.NET is? I asked for the invite six weeks ago but I was told that they "don't need another prying eyes".

[geoffreymcgill]

The core Bridge team are meeting in person all next week, and the main topic of discussion is Bridge2. We've been flipping between working on Bridge1 support releases and continued development of Bridge2. More than 1000 new unit tests were added during the recent Bridge 1.10 release, and all those unit tests will get ported to Bridge2 soon.

After our hack-week is complete, we should have a much better feel for when Bridge2 will be ready to open up.

Hope this helps. Cheers.

[geoffreymcgill]

Hi all. We just completed a productive round of team meetings and work on Bridge2, and now we have a much better feel for the status of the project. As a basic summary, there are awesome parts of Bridge2, and there are pieces that need help. We are working hard on upgrades and new features for Bridge2, although it's going to take time for us to accomplish our goals.

Bridge2 will be available publicly in Q2 2016.

Hope this helps.

[volkanceylan]

@m5x i also got a similar answer, don't think any other got invitation. maybe its time to fork or consider typescript.

[juanka881]

@volkanceylan i ditch the idea of using C#/saltarelle/bridge.net for now as it just too hard to leverage all the existing libraries and tools in the js ecosystem, I tried I really tried. For a simple app its doable but I wouldn't recommend for anything of decent size. I am now using typescript with Atom + AtomTypescript as my IDE and its working out very well. Combine with the typescript definition files and you can have static typing, output JS and still leverage the whole node/js ecosystem. I highly recommend.

my front end stack looks like this right now:
Atom + AtomTypeScript for editing
gulp.js for task automation
TS outputting es6
Webpack to bundle js + transpile es6 from TS
React for views
Immutable.js for data structures

Good luck

[dested]

@juankakode brings up many valid points, but I will give you my experience from the other side.

I have built a few large scale c# projects using saltarelle and by and large my experience has been wonderful. The lack of third party library support is real, but I have found as I needed to implement a third party library the process is trivial. Ideally there will come a day that we can pump out c# classes from typescript definitions, and hopefully with Bridge behind the project that will become a reality.

Typescript is wonderful, especially in its latest version, but it has many of the same issues that come from working with saltarelle, namely the pisspoor state of sourcemapping in browsers.

In the end I believe it boils down to using what you're most comfortable with. ES6 is coming but the support is abysmal cross browser. Typescript has a few gaps along the way, but presumably they will sort them out (async/await only works in node). The tooling for typescript is also subpar at best compared to visualstudio + resharper. It's a hard sell going either way, and you have to choose what's best for you and your team, but I wouldn't count saltarelle/bridge out.

[geoffreymcgill]

@dested: namely the pisspoor state of sourcemapping in browsers.

Confirmed.

@juankakode: Nice stack. Excellent tools in your list.

[juanka881]

@dested completely agree. still eagerly awaiting the new version :D

[mattyork]

Any updates, @geoffreymcgill?

We have a very large application built on Saltarelle, and we're weighing our options for what to do in the future. The lack of visibility into Bridge2 is making us nervous.

[volkanceylan]

I have successfully converted my app platform using Saltaralle to TypeScript without breaking backward compatibility. It's possible to use a large part of Saltaralle output and convert remaining parts to TypeScript manually.

And you can go progressively, e.g. don't have to convert all code, they are interoperable anyway.

I admire Erik's work, it was more professional than most commercial packages. I also have a very large code base in Saltaralle, but i felt its time to move on.

Not everything is so shiny in TypeScript world. It has its own set of little problems, but i'm more than happy with my decision.

[m5x]

I am currently also evaluating what technology to use instead of Saltarelle. For the time being I have come to the same conclusion as @volkanceylan. In the long term I plan on using webassembly but that will be good fit for single-page applications only. For multi-page websites a way to use browser's built-in runtime is still needed (as opposed to downloading its own) so that pages can be kept slim and load fast. Typescript is the most meaningful solution - it does not need a runtime of its own and it brings most language features that are needed for larger-scale development.

But as @volkanceylan said, not everything is so shiny in TypeScript world and I keep thinking that if I am to transpile, why not to transpile from C# instead of TypeScript? Thanks to Erik's design decisions the extra payload for the runtime is quite small in case of Saltarelle (as opposed to JSIL that took different approach) and it's a small price to pay for being able to use proper object-oriented language with most of its great features inside browser.

Saltarelle name cannot be used anymore but as I understand it, it is completely ok to fork Saltarelle, rename it and put it in a new Github repository where the community could drive its further development. I'd be happy to take on a task to refactor the Roslyn branch and class libraries with a new name and put it in on Github. I would not however be able to solve compiler issues nor drive its further development because of my other engagements and because I am no expert in the field of language compilers. I'd contribute to class libraries and plug-ins but that makes no sense unless there is somebody capable enough to carry on Erik's work.

[geoffreymcgill]

@m5x & @mattyork - Give Bridge 1.14 a try. It should be released publicly tomorrow. Roslyn and Reflection support for Bridge are still on track and will be available June 2016. If there's something in the old Saltarelle that you're missing, just let us know and we'll do our best to support.

[nippur72]

I was a big supporter of Saltarelle in the past, having converted many external libraries (Angular, React, Polymer, Riot etc), and contributed to solve small bugs.

But over time I realized that (C# for web) was not a smooth experience, at least not as smooth as with desktop apps. It was a continuous fight with types and its JavaScript counterpart.

To make it brief, I converted to TypeScript. At first I hated it, I kept wondering why MicroSoft people had decided to drop C# for a total different language. But over the period of about six months it all started to make sense. Now I like it even more than C# because of its dynamical and functional nature.

As other said, not everything is shiny but things keeps improving constantly as there is a big commitment from MicroSoft and the open source community. So I would recommend it.

My big app is now translated in TypeScript. It was converted directly from C# source, the result is quite nice, much less verbose than C# and fits perfectly the web platform.

I still use C# for a big desktop app, but for the web IMO it's best to use the technologies that are expressly made for it.

[n9]

@nippur72
What are you using to transpile async/await?
I don't like the structural typing of TypeScript for larger projects. What do you think about FlowType?
Could you please share your TypeScript setup (IDE, webpack, etc)?

I have tried TypeScript, but I am still using Saltarelle because of nominal typing, await/async and reflection. I am missing Roslyn support there. I am still believing in Bridge 2, since June 2016 is here. (It does not need to be bug free. Erik was always capable to fix bugs very fast.)

Does anyone know whether Erik is involved in Bridge 2 development?

[nippur72]

@n9 the 2.0 release of TypeScript coming in the next weeks (expected in mid June) will address async/await and will give strict null checks similar to Flow, so no reason to look for Flow anymore (I've even heard rumors of a convergence of the two).

My IDE is VS2015 but occasionally I use Visual Studio Code for quick edits. I have webpack in "watch" mode that compiles and bundles in the background, but the webpack experience is still not pleasant. Another not-so-good experience is the management of external typings (.d.ts files).

I use react, react-templates and lodash as libraries, no jquery. On the server side it's a mix of node and ASP.Net (C#). Debugging node.js in VS requires a plugin and sometimes it's problematic.

There are things that I miss from Saltarelle of course. The quick compile, the [InlineCode()] attributes, the sound type system, the self contained Visual Studio experience with no weird build tools.

[n9]

@nippur72 Thanks.

Are you using typings/tsd? In Saltarelle, it was quite easy to prototype custom stub directly in my project (e.g. add missing jQuery function or add missing class), then move it and push to forked repo and create PR.

I tried this also in TypeScript. I was playing with react-native (for Android), .d.ts was not complete. I added some stubs directly to my project. TypeScript however did not allow that (I do not remember the message exactly, but it was saying something that I cannot modify external module.)

How do you develop t.ds in TypeScript? [Do you need to create changes directly in your fork of e.g. DefinitelyTyped, commit the changes, run typings to update e.g. ambientDependencies (in case of react). Then build the project. See errors and again commit fixes, ...]

[nippur72]

(sorry people for the OT)

@n9 recent versions of typescript have a feature called "module augmentation" by which you can extend a module (the same way you augment an interface), so you might want to re-check it again. The idea is that you first get what types are available (none or outdated) and then augment them for your local project.

Regarding DefinitelyTyped, yes you have to fork it and submit PRs. Quite annoying. But the typings scenario is changing, I've heard they will be managed directly from npm with next release.

If you have other questions, please write me privately (email is on my profile)

[m5x]

@n9

Unfortunately Erik is not involved in Bridge.NET development and he probably never had been except maybe for a short period of time right after the acquisition. You can confirm that by looking at http://object.net/#team page. Erik had been there at the time of Saltarelle acquisition announcement but he has been removed since.

[geoffreymcgill]

The Bridge team is looking to help upgrade an original Saltarelle line of business type application to Bridge. If your organization has built such an application in Saltarelle, and would like to upgrade the app to Bridge, please get in contact with me ([email protected]).

[n9]

Great news! I am looking forward to try Bridge in a spare time.

Is there something that is supported by Saltarelle but not yet by Bridge?

[geoffreymcgill]

During our Saltarelle integration process, we integrated the original Saltarelle Unit Test project. The test coverage within Saltarelle was decent, and we felt if the original unit tests were supported, developers could be assured that upgrading to Bridge will get them very close.

We've been using the portarelle tag to track open Saltarelle issues.

For Bridge 15, we integrated the original 14943 unit tests from Saltarelle. Of those original tests, 14067 (94.1%) were successfully integrated. The remainder break down into three categories documented in Issue #1672 and listed as follows:

1. 381 (2.5%) failing tests correspond to open portarelle issue. These have been documented into 42 Defects and 13 Features, and are being fixed in batches or as community members request.
2. 163 (1.1%) failing tests correspond to features deemed low priority, or where an alternative exists in Bridge.
3. 332 (2.2%) failing tests correspond to functionality within Saltarelle determined to be in error. This includes non-standard functionality added to the Saltarelle JavaScript API, or the inverse with .NET API functionality being added to Saltarelle that is not actually available in .NET. These non-standard Classes or Members will not be added to Bridge.

We've planned another push during the Bridge 16.0 cycle to support and close the 42+13 issues in Group1 above. At this point it's hard to tell for sure if we'll get 100% of these closed, but we'll try. Again, much of the priority for these will depend on feedback from the community. So far they seem like low priority items for the community.

The issues in Group2 are unlikely to be supported in Bridge 16, unless the community requests something specific.

Group3 are defects in the Saltarelle API and will not be ported to Bridge. There may be useful functionality within these removed API members, and we'll review on a case-by-case basis, if requested by the community. There may be an option to reproduce the functionality elsewhere, but no matter what decision is made, this would likely cause a breaking change if upgrading from Saltarelle to Bridge.

The 14067 original Saltarelle tests were added to the Bridge Test project and currently we're sitting at 52,800 total unit tests.

We're also about to kick off a project to develop an automated upgrade tool, based on the rules documented in our Upgrade from Saltarelle wiki.

The upgrade tool will be open-source a published to a [yet to be determined] GitHub repo. Community members upgrading Saltarelle projects could contribute by submitting pull-requests implementing new rules. I'll post an update here once there's some code in the repo.

Hope this helps.

[n9]

Thank you for the information.

Where to discuss Saltarelle -> Bridge migration stuff?

[geoffreymcgill]

Hi @n9,

Both the Bridge forums and GitHub Issues for the Bridge repo are closely monitored.

Feel free to post any questions or comments to either.

As Salterelle-to-Bridge upgrade issues are found, the wiki document will be updated.

The portarelle label is being used to track upgrading Issues.

[n9]

Ok, I have created https://github.com/bridgedotnet/Bridge/issues/2285 to track support of SaltarelleWeb features.