Why Do I need call JS Code in Blazor apps?

[Pragrammist]

Is there an existing issue for this?

• [X] I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

I see the problem: You need to call JS code in Blazor Apps. Blazor is a feature of ASP.NET for building interactive web UIs using C# instead of JavaScript. So why do I need to call JS code? For simple problems, like when you click on button A and send data somewhere, Blazor works well. But if I need to make Blazor Auto Scroll (https://stackoverflow.com/questions/67011354/blazor-auto-scroll-textarea-to-bottom), I need to create a JS function and call it in JSRuntime. It makes Blazor useless, in my opinion. I want to make a frontend in C#, but I need to use JS. It's stupid. I tried to find some library that allows me to use JS functions without JS, but I didn't find it.

Describe the solution you'd like

I'd like to have some class or something similar that allows me to interact with UI in C# code without using any JS code. Without needing to create JS functions and call them in JSRuntime

Additional context

No response

[KennethHoff]

WebAssembly still does not have access to the DOM, so everything that actually affects the website has to be through a JavaScript interop layer. The dotnet team could of course create tons and tons of helper functions but there'll always be something they haven't done

[javiercn]

@Pragrammist thanks for contacting us.

It makes Blazor useless, in my opinion. I want to make a frontend in C#, but I need to use JS. It's stupid. I tried to find some library that allows me to use JS functions without JS, but I didn't find it.

That's somewhat of an extreme view. The question is more whether you prefer to write 100% of your front-end code in JS or 1% of it. Having to use JS code in a Blazor app is the exception, not the norm. In the same way that sometimes you need to wrap a native library to make it callable from .NET. I don't think anybody ditches .NET framework for that reason.

Blazor runs in a browser environment, it's virtually impossible to completely abstract the underlying platform, so at some point, you'll have to use JS interop for very specific things in the same way you do so when calling native functionality in the OS on other contexts.

[Pragrammist]

1) It's not just a prefer, it contradicts the idea of what a blazor. It's not 1%. And if it even 1% this 1% refers to features that users are accustomed to seeing everywhere 2) It's not exceptions. Actions with a browser and dom are not specific, for example use camera or micro make you need to use js. 3) It messes Codebase. I hope i don't need explain why all codebase, exclude devops, in one language is good 4) It greatly impairs development efficiency, you need mess c# with js.While you using BlazorBlazor has potential to compete js frameworks in, but it's outside. And if think about blazor in that way, like you, blazor will continue to be outside. 5) Blazor is positioned as a substitute for js, but js still remains. Blazor doesn't eliminate the hassles of js because you still need to write in js 6) There are situations where js is appropriate to use with other languages ​​in development, for example k6, since k6 is not closely related to the application, but not Blazor

[hypeartist]

I agree with @Pragrammist. There is too much of JS all around Blazor. It would be great having something like https://github.com/curiosity-ai/h5 under the hood.

[Pragrammist]

WebAssembly still does not have access to the DOM, so everything that actually affects the website has to be through a JavaScript interop layer. The dotnet team could of course create tons and tons of helper functions but there'll always be something they haven't done

Yeah but why not wrap common and most popular. I dont tell to create a wrapper over each document property. The fact that there is no full access to the DOM is okay, but why not wrap over the browser api. This may seem like a small thing, but it's not a small thing, it's as big of a problem as the long wasm loading times that were present in previous versions of .net.

[javiercn]

It's not just a prefer, it contradicts the idea of what a blazor. It's not 1%. And if it even 1% this 1% refers to features that users are accustomed to seeing everywhere

There is a diminishing point of return here between the cost of creating these abstractions and maintaining them and their usefulness.

I don't think it contradicts Blazor's mission in any way. Blazor's goal is to support development of web apps using C# and .NET, which it does. It doesn't mean replacing JavaScript like other approaches like Dart take. You write your UI code in C# and .NET for the most part and can use JS interop when you need to reach for platform capabilities that aren't built into the framework or leverage a third party package that already provides those abstractions.

It's not exceptions. Actions with a browser and dom are not specific, for example use camera or micro make you need to use js. It messes Codebase. I hope i don't need explain why all codebase, exclude devops, in one language is good

Of all the sites on the internet, the vast majority of them won't require things like your camera or microphone except for those that are tailored to solve a specific set of problems (meetings, etc.). The cost of creating and maintaining these APIs is too high for the reduced number of users that will reach for them. For cases like this, the community normally already offers a wrapper package that you can consume, and if that's not the case there's an opportunity for you to support the community in that way.

• For example, here is a package for camera support https://github.com/baltermia/blazor-camera-streamer

• Here is another one for media capture https://www.nuget.org/packages/KristofferStrube.Blazor.MediaCaptureStreams

I don't entertain the idea that using an additional language makes the codebase worse, that is highly up to how you organize your codebase. There are mechanisms to encapsulate and abstract the JS interop into a self-contained library that the rest of your app can transparently consume.

It greatly impairs development efficiency, you need mess c# with js.While you using BlazorBlazor has potential to compete js frameworks in, but it's outside. And if think about blazor in that way, like you, blazor will continue to be outside.

Your codebase has already three languages in it. Html, CSS and .NET.

Blazor is positioned as a substitute for js, but js still remains. Blazor doesn't eliminate the hassles of js because you still need to write in js

I don't agree with this statement, there's a huge difference between having 1 million lines of JS in your app as opposed to having a few hundred. This argument is akin as saying that .NET is a failure because you have to write 100 lines of C and some interop code to call into an unmanaged API.

The time you spend writing JS vs the time you would spend otherwise its vastly inferior for most apps unless your app has very specific requirements. In an ideal world you would write 0 JS, but the cost of getting there becomes exponentially expensive, so I don't think completely trying to avoid JS is a goal, in the same way than completely avoiding native code is a goal in .NET.

There are situations where js is appropriate to use with other languages ​​in development, for example k6, since k6 is not closely related to the application, but not Blazor

It's totally ok to use JS with Blazor in the same way it is ok to use C, rust or anything else along with interop to call native libraries in .NET running on other platforms. Why is it ok in that case and not ok on the Blazor case?

I hope you understand that we are not trying to dismiss your ideas, however we do not think it is realistic or a goal for Blazor to completely abstract away the underlying platform and we don't see that as a failure on our mission or our goals. While we strive to minimize the amount of JavaScript that web apps need to author, it's not our goal to completely eliminate it and for the time being, we don't plan to provide out of the box support for every API available on browsers. JS interop is our defined extensibility mechanism for such scenarios, and we expect users to leverage that to access browser functionality not provided by the framework.

[dotnet-policy-service[bot]]

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.