Announcement

Collapse
No announcement yet.

Angular2 support?

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

    Angular2 support?

    Are you going to provide support for Angular2 in Bridge2, Angular1.x, both or none?

    #2
    Hello,

    Angular1 has been partially implemented in Bridge1:

    https://github.com/bridgedotnet/Fram...ster/AngularJS

    This code will be simple to port to Bridge2, so it shouldn't be a problem supporting with Bridge2.

    We have not investigated Angular2 yet.

    Comment


      #3
      Originally posted by geoffrey.mcgill View Post
      We have not investigated Angular2 yet.
      Since Angular2 is written in typescript, it would be an interesting project for the typescript -> c# Generator.

      Comment


        #4
        Ok, thanks.

        I will try Angular1 when Bridge2 comes out. Recently Angular2 https://angular.io/ enters in beta and I found it very attractive since it solves many Angular1 issues. For a SPA framework I am interested in try it in conjunction with WebSockets. While I am considering using TypeScript for new development, an option like Bridge for C# would be nicer.

        Comment


          #5
          Here is a related issue on Angular for Bridge v1.
          https://github.com/bridgedotnet/Frameworks/issues/1

          And a related issue on WebSocket support.
          https://github.com/bridgedotnet/Bridge/issues/776

          Comment


            #6
            The actual problem to Bridge (v1) support frameworks like Aurelia and Angular 2 are that these frameworks needs the generated javascript to be module oriented.
            The compiler will have to change to emit JS code like the Typescript does (multi module support) or, at least, a mode to wrap all the generated code and put it in a big module which will represent the whole assembly.

            Another point is decorator metadata support.

            Comment


              #7
              I tried porting a huge typescript app which uses Aurelia to C# (using Bridge) and after to Kotlin. Each have good points but in the end they are equivalent. Kotlin has a little vantage over Bridge because of the language itself, which has some cool features than C#, but the code emitted by the Bridge is a lot more beautiful and easily to integrate with Javascript apps.

              Comment


                #8
                Hi @danfma,

                Thank you very much for the feedback.

                The actual problem to Bridge (v1) support frameworks like Aurelia and Angular 2 are that these frameworks needs the generated javascript to be module oriented.
                The compiler will have to change to emit JS code like the Typescript does (multi module support) or, at least, a mode to wrap all the generated code and put it in a big module which will represent the whole assembly.
                I am not sure I foresee all the troubles and implications, but that all should be feasible to implement. As far as I can know we are already moving to wrap emitted (and bridge.js itself) JavaScript into a closure. Yes, it is probably not going to be enough, but we'll see what to do.

                Another point is decorator metadata support.
                Could you, please, elaborate on this statement?

                I tried porting a huge typescript app which uses Aurelia to C# (using Bridge) and after to Kotlin. Each have good points but in the end they are equivalent. Kotlin has a little vantage over Bridge because of the language itself, which has some cool features than C#, but the code emitted by the Bridge is a lot more beautiful and easily to integrate with Javascript apps.
                It is great to hear such a feedback! If you can share any details on your project, we would appreciate. It is very interesting to know what people use Bridge for.

                Comment


                  #9
                  Hi Daniil ,

                  The actual problem to Bridge (v1) support frameworks like Aurelia and Angular 2 are that these frameworks needs the generated javascript to be module oriented.
                  The compiler will have to change to emit JS code like the Typescript does (multi module support) or, at least, a mode to wrap all the generated code and put it in a big module which will represent the whole assembly.
                  The new JS frameworks use a way to wrap the script in modules, which could be a simple file or an entire library. But, basically, Ng2 and Aurelia uses the SystemJS to load the scripts and the resources on demand or bundled into a big module. The SystemJS load javascripts in some of the following formats: global, amd, commonjs, umd and system. So basically, to support Angular 2 or Aurelia in a more natural way, the Bridge needs to emit the C# Files (not only the library) in some of these module formats. Or provide a way to embed the generated files and the included resources (html, images, fonts) in a single module. But one point is important: the path to these files must remain the same relative to the client base url. Give a look at this page (http://aurelia.io/) and watch the video, you will have a hint of what I am talking about.

                  Another point is decorator metadata support.
                  These new frameworks use decorators which are like, but not equal, the metadata attributes of the C#. And with use of some libraries, these frameworks can read that metadata using reflection at runtime.

                  If you can share any details on your project, we would appreciate.
                  I'm working in two projects written in TypeScript and both use the Aurelia Framework. The TypeScript is an awesome language but while it is still evolving, it's not a language so productive like C# or Kotlin, and the IDE is a big plus over it. My project is using the new .net core over mono and the .net framework and I need that because sometimes I'm on Windows, sometimes on OSX. For the frontend, I have a lot of node apps and gulp scripts to compile and bundle the application for the jspm to load.
                  Last edited by danfma; 2016-01-28 @ 12:29 AM.

                  Comment


                    #10
                    There is some support for Modules in Bridge, although I couldn't tell you at the moment whether this would help in this scenario.

                    http://bridge.net/kb/attribute-reference/#Module

                    Comment


                      #11
                      Hey geoffrey.mcgill ,

                      This will not help because it only separate the things in a Bridge package and not in some of the JS modules.

                      Comment


                        #12
                        Hi danfma,

                        We'll try to figure out some options. At the moment we're a little stretched for resources, but this is an interesting problem.

                        Comment


                          #13
                          No problem! I'm trying to figure out something too. If that come in mind before, I will post in the forum! Thanks!

                          Comment


                            #14
                            One immediate option that come in mind is to translate the bridge to typescript and use the ts compiler after or the babel, but that is something that your team needs to think about!

                            Comment

                            Working...
                            X