Announcement

Collapse
No announcement yet.

Bridge.NET v2.0 in hiding?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    Bridge.NET v2.0 in hiding?

    Originally posted by geoffrey.mcgill View Post
    Update: As planned, Bridge 15.0 was publicly released on September 12th, 2016.
    I am considering technologies to use as we refresh an ancient (ASP.NET AJAX) app, and the vaporware status of v2.0 is a huge roadblock to even considering Bridge.NET.

    At this point you should add a FAQ entry explaining the rationale behind the closed-door re-implementation of Bridge.NET, particularly as the community seems to be gaining more and more momentum. Either that or go skunk-works on the project and erase all mention of it anywhere and just surprise everyone with its amazing-ness when the cone of silence is removed!

    Just wanted to let you guys know that you are recreating an AngularV1 -> AngularV2 style hesitation here for many potential users.
    Last edited by JSpraul; 2016-10-05 @ 04:33 PM. Reason: Bridge.NET v2.0 released!

    #2
    Hi JSpraul,

    Thanks for the feedback. I'll take your comments into consideration and we'll try to respond in some way with an update soon. I believe we've made public comments mentioning the next major release is planned for Q2 2016, so there's that.

    the vaporware status of v2.0 is a huge roadblock to even considering Bridge.NET
    Can you elaborate on this statement? I don't really have an opinion here, just genuinely interested in why not having status information on the next major release would be such a roadblock for you?

    Is there functionality missing from the current release that you require? Maybe you could be submitted as a feature request issue and we'll assess the feasibility of implementing now. Or, start a thread in the forums to discuss a missing feature.

    explaining the rationale behind the closed-door re-implementation of Bridge.NET
    I'm not entirely sure why we would have to provide an explanation? Again, I'm just genuinely interested in why you feel we need to explain?

    Comment


      #3
      Thanks for taking the time to respond, Geoffrey.

      the vaporware status of v2.0 is a huge roadblock to even considering Bridge.NET
      My impression from what has been shared already is that Bridge.NET v2 is a ground-up re-write. (I don't have time to document this but I also got the general feeling that the expected release date has slipped.) Without any understanding of what v2 will break, I have no reason to invest in v1. Especially not to get started right now with something scheduled to be replaced within the next few months.

      I specifically mentioned the situation with Angular v1 -> v2 (edit: linking another view) because it is a concrete example of a potentially similar situation with another project. Perhaps this comparison isn't relevant because of how much they've promised to break, but I must have missed the Bridge.NET v2 backwards-compatibility road map - I don't know what to expect at all (since it is all happening behind closed doors).

      explaining the rationale behind the closed-door re-implementation of Bridge.NET
      First, It's tough for a company to survive on supporting an open-source product. Something like the re-write is a chance to change the license since everything has been re-written. Call it paranoia or whatever but a rational explanation can go a long way towards assuaging these types of fears.

      Second, it's tough to transition from an open-source development process where users can contribute fixes and whole new chunks of functionality over to nothing but Bridge.NET's word that something is happening (the normal closed-door commercial development process). For me, this is a part of evaluating how much Bridge.NET values its open-source community.

      --

      All things considered, I hope this discussion can remain constructive as I try to share my perspective as a potential user since Bridge.NET will always be looking for more developer mind-share. I do look forward to re-evaluating Bridge.NET once v2 is available.
      Last edited by JSpraul; 2016-03-01 @ 06:11 PM.

      Comment


        #4
        Thanks for the feedback.

        I look at the Angular situation and think to myself; isn't that a perfect example of why you would not want to develop in the open? Open source licensing does not mean developing in the open.

        The Bridge2 compiler will be more a merging of Saltarelle and Bridge1. Certainly nowhere close to a complete re-write. We're trying our best to ensure backwards compatibility with Bridge1. In an ideal outcome, Bridge2 would a drop-in replacement for Bridge1. We're not far enough along, so I can't tell if that will happen.

        Bridge1 compiler and Saltarelle compiler were both licensed as Apache 2. I really like that license, and we have absolutely no intention on changing. The Bridge2 compiler will be released under the Apache 2 license; we've never stated to the contrary.

        I do look forward to re-evaluating Bridge.NET once v2 is available.
        Excellent, thanks. Subscribing to our email newsletter or Twitter feed should get you notified once Bridge2 is available. See you then.

        Update: The versioning scheme changed, and Bridge 2.0 is now Bridge 15.0, released on September 12th, 2016.
        Last edited by geoffrey.mcgill; 2016-09-13 @ 06:11 AM.

        Comment


          #5
          I imagine it's pretty frustrating to you guys hearing people pushing for v2.0 news, but I can definitely see where the concern comes from. The statement that

          the vaporware status of v2.0 is a huge roadblock to even considering Bridge.NET
          is understandable if considered in the light of what's happened with Angular (possibly another comparison you may be sick of!), there is a real worry for people that they may buy into a technology and write code for it that will then break in unpredictable ways with a future release - will Bridge 1.x code still work with 2.0 or will it need some attention? Will this be a few tweaks, according to a well-written migration guide or will they be more significant and have to be identified through testing of the application?

          These aren't questions that I'm asking you to answer now, they're just the sorts of the things that run through the heads of people weighing up potential technology options. And with the so-called "JavaScript Fatigue" caused by the feeling that there are so many frameworks and architectures and libraries and approaches rising into popularity, or hanging round the outskirts, or falling back towards obscurity, it's so difficult to give them all the experimentation time that they probably deserve that. With these time constraints on evaluating technologies, it doesn't take much to mean that something won't even make the cut into the evaluation pool and I can see why the Bridge v2 concern would prevent them from trying it out.

          From my selfish point of view, I'm hoping basic Bridge code written in 1.x will work unaltered in 2.0 and that my React bindings will and that the "lifting lambdas into named functions" behaviour is all maintained. However, there has been no word that this will be the case. I'm holding tight and being optimistic for now, but I'm a big fan and I hope that it's understandable why someone less enthusiastic about Bridge might be more worried. If the React bindings do have to change for 2.0 then there may have to be parallel NuGet packages created, both of which may have to be maintained for a while if Bridge 1.x continues to get updates and React continues to move ahead. This wouldn't be the end of the world but it would be inconvenient.

          Finally, to add my two cents to the Angular "arrangement" - I think that they've been in an awkward situation but that they've done the best that they could. I think that the 1.x (was it 1.3? I forget now) was an example of a framework that was very helpful for people to write their web applications more easily than they used to, it's why it got such great traction. But there were limitations (after a certain number of elements, the two-way data binding became too expensive and performance tuning would entail disabling it in some places - at least, that's what I understand second-hand from talking to people who used it and reading articles about it, I have very little experience with Angular). In order to remain competitive (particularly with React changing the game so significantly) and address other problems with the framework they almost had to make a huge break. This put people off the framework, it put my company off it when evaluating technology options last year due to the uncertainty - with Angular, it was almost guaranteed that much of your 1.x code would have to be re-written for 2.0. However, I still believe that they should have done this publicly. If making these big changes was the right thing to do (which they believe and I believe) then there would have been much larger, angrier backlash from their users if it came out of the blue. If they had known for a year, two years, whatever.. that 1.x was going to go and that 2.0 would replace it and that 2.0 would be hugely different, it would have been a slap in the face to the developers who had committed to it to find this out suddenly. People hugely appreciate transparency, even when it's transparency about changes that they might not be that thrilled about having to deal with!

          I'm not trying to play devil's advocate as such here, I'm just trying to expand on concerns that I've heard from numerous sources (a couple of people where I work mention it from time-to-time, for example, simply because we don't know yet what impact it's going to have on us).

          I've got a faint (imagined?) recollection that the plan is for 2.0 to not be a huge change for Bridge users, instead it will be a larger change for Saltarelle users (I seem to recall reading in a Saltarelle forum that you might give users there beta access first since there is more for them to come to terms with?), but I don't think that it says this officially any where. I'm not sure what official information there is at all, to be honest! While you, of course, have the right to develop behind closed doors, any information that can be made public is likely to be helpful (or, at least, reassuring) because most people have a tendency to presume that worst for any unknown! :D

          In summary, I think that this quote summarises the potential schism -

          Is there functionality missing from the current release that you require? Maybe you could be submitted as a feature request issue and we'll assess the feasibility of implementing now. Or, start a thread in the forums to discuss a missing feature.
          The Bridge feature set is pretty fantastic at the moment (the most notable absence being C# 6 syntax support, which we know is coming in Bridge 2.0), the most likely concern (IMO) from someone trying to look into Bridge and seeing this 1.x / 2.0 "situation" is what will change, rather than things that are missing currently.

          Comment


            #6
            Thanks for the comments.

            This comparison to Angular is not really moving me. If we were asking you to rewrite your apps from C# into VB for Bridge2, then yes, the comparison would have some validity in my mind. Angular2 was a revolutionary change from Angular1, not an evolutionary change. The next major update of the Bridge compiler will be an evolutionary change.

            A much better comparison would be the change Microsoft implemented with .NET compilers in moving from the old C# parsing engine to Roslyn. Did your app code have to change when upgrading a project from Visual Studio 2013 to Visual Studio 2015? Maybe you had to make a few adjustments here and there, but I suspect very little required attention. What you did get was a bunch of cool new features, and backwards compatibility was maintained.

            With the compiler upgrade in Bridge, any breaking changes to your C# app code will likely be trivial and well documented. That is the goal. Another goal is to support 100% of Bridge1 features, obviously including the recent lambda lifting, which was an awesome idea, and I have no idea why we would ever drop that functionality. These would be the same goals for all major version releases of Bridge, including upgrading from v1 to v2, or a future v2 to v3 upgrade.

            If everything goes well, the transition to the next compiler will be as transparent as the lambda lifting implementation was. You'll get everything you had before, plus a bunch of cool new features and efficiencies. The thousands of unit tests we're running against will be ported to the next release and will help validate backwards compatibility. Plus we'll be adding thousands more.

            Hope this helps.

            Comment


              #7
              That does help. Very much! :)

              The description of it as an evolutionary change and the reassurance that all functionality and unit tests will be maintained is a big deal. I'm not sure that this has been publicly stated elsewhere and people DO tend to fear the worst, particularly in such a potentially huge upheaval as a merge with a separate product.

              If you don't have a FAQ somewhere with this information then I would suggest you add one and alleviate the "v2 fear" and the Angular comparisons. (To be honest, I think that your response here will be enough for the people that I work with, who had voiced concern about what might happen with v2, but clearly new developers are thinking the same sort of thing and an FAQ somewhere might be easier for them to find than this thread).

              Comment


                #8
                Hi ProductiveRage ,

                reassurance that all functionality and unit tests will be maintained
                I would like to clarify something regarding your statement. We are not guaranteeing that all functionality and unit tests will be maintain. As I stated above, our goal is to maintain all functionality and unit tests. What I can say at this point is that we will try our best.
                Last edited by geoffrey.mcgill; 2016-03-20 @ 07:30 AM.

                Comment


                  #9
                  I think that often to improve (the "model", the API, performance, ... ) you need some breaking changes. Bridge.NET is quite young and in my opinion interesting. Better at this stage than later.

                  Comment


                    #10
                    Hi @pl2,

                    Thank you for sharing your feedback!

                    Comment


                      #11
                      Just a question - because I did not find anything about v2 exept this disscussion. Q2 is over. Are there any new plans for V2?

                      Comment


                        #12
                        Hi Markus

                        We're working hard on the next release and plan to make announcements soon. We've decided to delay the release a little in order to get in some extra testing, build a few cool new features, and tidy up some bugs.

                        Support for C#6, Reflection and much more is now complete.

                        It's all coming along nicely.

                        Hope this helps.

                        Comment


                          #13
                          Awesome news...!!!

                          Does the C# 6 support include ? (String Interpolation, Await in catch/finally)

                          When you say soon ? Are we days/weeks/months away ?

                          Is there a new roadmap ? with items like vs maps for debugging ? tsd -> c# wrapper translation ?


                          Comment


                            #14
                            Hi CastleSoft,

                            All C#6 syntax options are supported in the next release, including String Interpolation and Await in catch/finally.

                            Here's an Await in catch/finally sample I was testing with:

                            public class App
                            {
                                public static  void Main()
                                {
                                    App.Run();
                                }
                                
                                public static async void Run()
                                {
                                    try
                                    {
                                        await Service.InitializeAsync();
                                    }
                                    catch (Exception e)
                                    {
                                        await Service.LogAsync(e);
                                    }
                                    finally
                                    {
                                        await Service.CloseAsync();
                                    }  
                                }
                            }
                            
                            public class Service
                            {
                                public static async Task InitializeAsync()
                                {
                                    Console.WriteLine("InitializeAsync");
                            
                                    await Task.Delay(1000);
                                
                                    throw new Exception("Init Failed");
                                }
                            
                                public static async Task LogAsync(Exception e)
                                {
                                    Console.WriteLine("LogAsync");
                            
                                    await Task.Delay(1000);
                                    
                                    Console.WriteLine("  Message: " + e.Message);
                                }
                            
                                public static async Task CloseAsync()
                                {
                                    Console.WriteLine("CloseAsync");
                                }
                            }
                            All this functionality will be publicly released in September.

                            No roadmap is available at this point. Currently we are focused on wrapping up C#6 and Reflection support.

                            Update: As planned, Bridge 15.0 was publicly released on September 12th, 2016.
                            Last edited by geoffrey.mcgill; 2016-09-13 @ 06:12 AM.

                            Comment


                              #15
                              Hows the progress on the September release going ?
                              Still on track for this month ? Super keen to give the C# 6.0 features a solid run.

                              Comment

                              Working...
                              X