New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blazor Server and Client side and Javascript #5556

Closed
uazo opened this Issue Jul 27, 2018 · 10 comments

Comments

Projects
None yet
8 participants
@uazo
Copy link
Contributor

uazo commented Jul 27, 2018

Blazor Server and Client side, yes, and now?

PRO CLIENT SIDE

  • Speed? N/A (firefox is ok, chrome no)
    mono interpret is slow, and there are no forecasts about compiling with AOT or directly in WASM

  • Quick startup? No

  • Remove JS? No
    WASM does not have access to the DOM yet, so JS is always in the way

  • Does it work anywhere? No
    Only latest browsers and devices

PRO SERVER SIDE

  • Speed? Yup
    The same project in Server Mode is a splinter

  • Quick startup? Yup
    Download only static elements.

  • Remove JS? No
    JS is always there. And accessing the DOM remotely (when it will be implemented) will give performance problems certainty.

  • Does it work anywhere? Yup
    Eureka!

in the medium term, therefore, for the Blazor development of enterprise applications, the Server Mode is definitely to be preferred, at least until WASM will have access to the DOM (without js) and Mono will permit it, and always that the compiler in the meantime will have WASM targets (because current performance is really low when compared to javascript).

But the biggest problem with Server Mode is to interact with the DOM to create the interfaces, which is essential. Developing a new UI library with Blazor without javascript really means starting all over again (unless there are tools from ts to c #, do they exist?).

Currently with Blazor it is not possible to reuse ready-made UI libraries, developed in javascript, except for very complicated DOTNET-JS calls (just thinking about it I get a headache).

What is missing is the ability to abstract the js portion of blazor making it extensible using typescript, to allow a dotnet side component (local or remote) to have associated a custom component in the javascript side.

At this address https://uazo.github.io/BlazorFX/StandaloneApp/ an application test that uses DevExpress components for rendering: the blazor side components are dotnet (without any reference to interop with js), while rendering is done from javascript elements (DevExtreme from the react version). The dotnet component and the javascript component talks through exchange of custom properties and events (like react). In effect, the glue is a middleware beetween blazor and react, simple to do because DevExtreme is not a native react library but the implementation is simple.

So what do you say? Have you ever thought about it? It could also be a temporary solution, which would not deny in future having even full dotnet components (as today for react, not all components are full react made)

For those who want the repo is available with all the changes to the base code of blazor (https://github.com/uazo/Blazor/tree/remove-custom-tag).

@Andrzej-W

This comment has been minimized.

Copy link

Andrzej-W commented Jul 27, 2018

PRO SERVER SIDE

  • Does it work anywhere? Yup

I have just installed Blazor 0.5.1, created Blazor (Server-side in ASP.NET Core) project and it doesn't work in IE 11 on Windows 10.
In console I see this error:
SCRIPT5009: Brak definicji „Promise” (translation: No "Promise" definition)
blazor.server.js (23,26813)

And that is true: https://caniuse.com/#feat=promises
It is time to finally forget about IE.

@danroth27

This comment has been minimized.

Copy link
Member

danroth27 commented Jul 27, 2018

Yeah, we use promises a bunch in Blazor and we haven't bothered to add the necessary polyfills for IE.

@danroth27

This comment has been minimized.

Copy link
Member

danroth27 commented Jul 27, 2018

You might have some success with https://github.com/Appizeo/Blazor.Polyfill though @Daddoon.

@Andrzej-W

This comment has been minimized.

Copy link

Andrzej-W commented Jul 27, 2018

Thank you @danroth27 for suggestion. I hope that no one will ever force me to write an IE compatible application 😄

@tiandian

This comment has been minimized.

Copy link

tiandian commented Jul 28, 2018

Currently with Blazor it is not possible to reuse ready-made UI libraries, developed in javascript, except for very complicated DOTNET-JS calls (just thinking about it I get a headache).

Before wasm can access DOM and have ready-made UI libraries(this need many years), maybe compile Blazor to javascript is another choice, just like Bridge, it can use many ready-made javascript UI libraries by use Retyped .

Or simply let Blazor can embed javascript block in the c# source file, since the Blazor has been mixed with c# and HTML in the UI file, why not mixed with c# and javascript in the source file?
I don't know whether it is feasible, but it is the only way to use the ready-made javascript UI libraries.

@chucker

This comment has been minimized.

Copy link

chucker commented Jul 28, 2018

Or simply let Blazor can embed javascript block in the c# source file, since the Blazor has been mixed with c# and HTML in the UI file, why not mixed with c# and javascript in the source file?

This is explained somewhat in the original issue that introduced disallowing script tags, #552.

@tiandian

This comment has been minimized.

Copy link

tiandian commented Jul 29, 2018

@chucker, it needn't script tags,
what i say is to embed javascript in c# code, just like embed asm in c/c++;

just like below code, below is a c# function has a javascript.

void ShowMessage(string msg)
{
       msg = "Call from c#: " + msg;
        @javascript
        {
            let msg = @msg + "call from javascript";
            window.alert(msg);
        }
 }

after compile the above code, this c# function become two file:

  1. .cs
void ShowMessage(string msg)
{
       msg = "Call from c#: " + msg;

       JSRuntime.Current.InvokeAsync<string>(
            "_funincs._showMessage",
            msg );
 }
  1. .js
window._funincs._showMessage  = function(msg) {
       let jsMsg = msg + "call from javascript";
       window.alert(jsMsg);
}

I think this will let user call javascript from c# more convenient.

@uazo

This comment has been minimized.

Copy link
Contributor

uazo commented Jul 30, 2018

As a developer, however, I would not be interested in using an existing ready-made js library, if something specifically made for Blazor existed. The problem is that developing libraries for Blazor for now is extremely difficult, because there is no simple, maintainable and scalable method to develop the js part.

About converting c # to js, I guess it's not in Blazor's target, and inserting <script> tag is not the solution, even just thinking about CSP.

Inline javascript with the generation of .js files could be a solution, but I think it's difficult, because the changes would have to be done on the razor extension (and perhaps also the VisualStudio / intellisense part), but I do not know, I'll investigate ...

The simplest smarter and fast change solution in my opinion is to associate a js component with a blazor side component:

export class BlazorDOMComponent {
    ComponentID: number;

    // from here, js component can do anything with dom
    protected getDOMElement(): HTMLElement;

    // called when blazor want to remove an attribute
    protected removeAttributeValue(attributeName: string): void;

    // called when blazor want to set an attribute
    protected setAttribute(attributeName: string, attributeValue: string | null): void;

    // called before set an attribute, ask if is a event (with default true is attributeName start with "on")
    protected isDOMAttributeEvent(attributeName: string): boolean;

    // set eventHandlerId for attribute attributeName
    protected applyEvent(attributeName: string, componentId: number, eventHandlerId: number): boolean;

    // called before and after update
    onDOMUpdating(): void;
    onDOMUpdated(): void;

    // js component can raise an default/custom event
    protected raiseEvent(eventHandlerId: number, evt: EventForDotNet<UIEventArgs>): void;

    // called after another DOMComponent is attached (useful for templates)
    onChildAttached(child: BlazorDOMElement): void;

    // called after dispose of blazor component
    dispose(): void;
}

Starting from this I created a Blazor-React layer that allows the use of DevExtreme components.

@Daddoon

This comment has been minimized.

Copy link

Daddoon commented Nov 11, 2018

You might have some success with https://github.com/Appizeo/Blazor.Polyfill though @Daddoon.

Sorry to update this thread, just to mention that i just updated my library, Internet Explorer 11 in Blazor server side mode is now supported (or btw, it works with the samples !)

@aspnet-hello aspnet-hello transferred this issue from aspnet/Blazor Dec 17, 2018

@SteveSandersonMS

This comment has been minimized.

Copy link
Member

SteveSandersonMS commented Dec 18, 2018

Since this is a discussion rather than an bug report or proposed enhancement, and the discussion stopped months ago, I'll mark it closed now to keep things tidy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment