Question about h5 progress

[Ali1Jamal]

Hello I am currently using BridgeDotNet but they stopped developing two years ago on the project . so I am thinking of moving to h5. May I know how much you have improved from BridgeDotNet ? how much you have been able to support .net 5 ? Is the project safe now for me to move to ? is this an experimental project or a serious project ?

[theolivenbaum]

Hi @Ali1Jamal and thanks for the interest.

We started h5 because we were also users of Bridge and were very disappointed by their decision to abandon and then stop development. We actively use h5 to develop our software, and also develop an open-source component library on top of it.

Regarding changes, the main one is updating the compiler to run on net5.0 - this was a huge blocker for us in the past as Bridge only supported the old NET framework on Windows (or using Mono). We have also fixed a few issues on the way, simplified some things, and significantly improved the performance of the compiler (3-5x or more for complex projects) due to better caching and reusing a compiler instance (available on Windows only for now).

Regarding the language support (i.e. new language features post C# 7.3 and of net5.0) - we haven't yet put the effort in adding them, but is on our roadmap for future versions of h5. This means your h5 projects should still target netstandard2.0. Also open for contributions if you're interested!

Hope this helps!

[ghost]

You need to play with it. It is open source area... Maybe you can join to community :)

@theolivenbaum

available on Windows only for now

Can you explain that part? I plan to migrate build server to Linux.

[theolivenbaum]

Hi @hardhub,

That's only for the "reusable compilation server" - it speeds up compilation because it keeps a cache of your nuget packages (including the h5 library) in memory for reusing across compilations. On other platforms we just load it from disk on every compilation.

This is also disabled by default if we detect running inside a CI - as it makes no sense there :) You can see this logic here: https://github.com/theolivenbaum/h5/blob/97bd5fc2630674993411bfa7ed7900bb4f5d6978/H5/Compiler/Compiler/Program.cs#L581

Otherwise, all is supported anywhere net5.0 runs - including macOS, Linux and even running on Apple Silicon.

[Ali1Jamal]

@theolivenbaum I will give it a try ,and try to report issues ....... I hope you can support c# 9 as soon as possible.... in my opinion BridgeDotNet it is better than blazor in several things, which is the page load size because I target users who have bad internet speed like 50kb/s , so I prefer to use BridgeDotNet because the size in network from cdn is 154kb,also I feel latency when typing on the keyboard in blazor due to poor performance. and also in BridgeDotNet and h5 is the ability to deal directly with the html elements. So I see my future with h5 if the results of my experience with it are good. My greetings

[theolivenbaum]

Completely agree regarding your points about Blazor - I've followed it since it was first released and till this day I don't fell like it provides a nice dev experience... Feel free to open any issue you might encounter along the way!

[ghost]

have bad internet speed like 50kb/s , so I prefer to use BridgeDotNet because the size in network from cdn is 154kb,also I feel

You can be sure it will be 3-5 times more if you need reflection and locales. If application itself is big then its JS will be also significant. My app (minified, without framework JS) eats 500 KB. Though I do not think it makes sense to use vanilla JS to save 20% of that. Any high-res image will add much more traffic from an app.

And bridge solves a lot: intellisense, "static" typing, encapsulation (at least at compile time), tasks and async calls, and many other things.

Blazor also has killer-feature, it supports server-side rendering. It makes sense from point of view of SEO and others.
But it is MS, they ruined Silverlight instead of transforming that to HTML5 based framework. There was no Silverlight -> Blazor roadmap. So I do not like MS lotteries since that time. "Did you spend money for Silverlight A? Try our Silverlight B." Skype is ruined, Windows is next, GitHub is OK but it is under "attack".

That's only for the "reusable compilation server" - it speeds up compilation because it keeps a cache of your nuget packages (including the h5 library) in memory for reusing across compilations.

OK, good )) I think on SSD disk it does not matter a lot.
At least I experienced full CPU utilization before and that was bottleneck.
I will experiment with building using new 16-cores CPU in nearest future...

[Ali1Jamal]

@hardhub you mean blazor well be 3-5 times bigger or bridge.net .......if you mean bridge.net then i always disable reflection and make classes , methods and inheritance to reduce the duplicated this things will reduce the size of code ...i dont love use freamworks just i use something like ploty , swiper , jQuery for http request ... nothing big .... blazor server side is good but i also target mobile apps and there are many clients using static hosting so this thing well not help me....i use js and tried TypeScript but i found bridge.net better choice for me then TypeScript... if i need to use lib just make js function and call it from c# and that's it .....i'm now work on lib build by bridge.net for effects and data-binding when i complete it maybe i will make it open source in the near future

[ghost]

No I mean bridge with reflection and locales will increase significantly size, I am using Newtonsoft.Json and DI containers, so I cannot avoid reflection. Also we support 8 languages, so I have to bundle all that.

I have bindings for KnockoutJS and some other libraries, though I have some ideas regarding Template attribute changes, but it is later.

[Ali1Jamal]

@hardhub Yes, the size will increase a lot if you use these things....so I try as much as possible to stay away from increasing the size eg I don't use newtosoft because it needs reflection to work so I use JSON.stringify and JSON.Parse To avoid reflection and just use type casting .As<>() to deal with him

[ghost]

@Ali1Jamal

To avoid reflection and just use type casting .As<>() to deal with him

But it will not create Bridge C# objects. It will be just plain JS object and it can produce a lot of troubles.

In other words the following will not work:

public class Program
{
    class A
    {
        public string Test;
    }

    public static void Main()
    {
        Global.Set("somevar", "{ Test: 'some text'}");

        dynamic somevar = Global.Get("somevar");

        var test = JSON.Parse(JSON.Stringify(somevar));

        Console.WriteLine(test.As<A>());
    }
}

Variables test and somevar are equal, I just parsed it using your method to be sure I did that right way.
So test is still plain object and you will get Uncaught TypeError: test.As is not a function

I have not found any other way to instantiate C# objects from JSON in Bridge except Newtonsoft.JSON pkg.

[Ali1Jamal]

@hardhub i am know its not the perfect way.. There may be some errors in some cases as you explained ..but you can make it work in the following ways :

   A a = new A();
   a.Test = "its work";
   A test = JSON.Parse(JSON.Stringify(a)).As<A>();
  Console.WriteLine(test.Test);

[Ali1Jamal]

@hardhub I have edited the comment more than once. Now I understood you very well. You have clarified many things to me, thank you.