4 ms·

Not to diminish the achievement here, which is considerable, but I feel like a lot of these WebAssembly-based projects miss the forest for the trees. JavaScrip

by untog 7y ago

Not to diminish the achievement here, which is considerable, but I feel like a lot of these WebAssembly-based projects miss the forest for the trees. JavaScript isn't really that big of a problem or a performance killer. The DOM is. I don't know what the answer is (rendering to a canvas tag is awful for accessibility) but I'm hoping that in time we see the improvement that is to the DOM as WebAssembly is to JS.

snarfy 7y ago
JavaScript isn't a very good programming language. Just because I can develop in it doesn't mean I want to.
- untog 7y ago
  Sure. Blazor scratches a developer itch. But end users aren't likely to feel a difference one way or the other. The same bottlenecks are still the same bottlenecks.
  - belltaco 7y ago
    It isn't just about scratching an itch. It results in fewer bugs, faster development, more features etc. which are useful to end users.
    - untog 7y ago
      My experience of tools/languages that sit on top of the actual native implementations (e.g. React Native or Xamarin on mobile) is that they often lead to much slower development, since when you're Googling around trying to find answers to an issue you're looking in a much smaller community for answers. Eventually the answer usually ends up being "just do it the native way". Hopefully Blazor will avoid such issues. In any case I'm probably speaking out of turn... it clearly isn't designed for wide-scale deployments - in house/intranet tools are a different beast anyway.
      - tasogare 7y ago
        I use Xamarin Android and while you are right about the ton of googling needed, it was always to search for Android API and almost never because of Xamarin itself. Once found, it’s straightforward to convert from Java code to C# except a few cases (layout parameters for instance). The other issue is coming from a nicely design framework (WPF, Silverlight or WP7/8) the Android APIs feel ugly at times (gesture handlers for example).
      - JamesSwift 7y ago
        Assuming you are doing Xamarin.Native and not Xamarin.Forms, you can just tab-complete your way through it if you know the native side. The apis are almost 1-to-1, only making things more dotnet-y when it makes sense.
    - mdgrech23 7y ago
      That's such nonsensical marketing spin.
      - belltaco 7y ago
        I don't see how easier development does not result in better outcomes. Imagine how bad things would be if everyone had to code in Assembly.
        untog 7y ago
        But the "easier development" part is very debatable. What do I see in the browser developer console when debugging a Blazor app? Can I insert breakpoints, trace what is running and how? etc. etc. I get disliking JavaScript, but there is a strong argument to be made for using the tried and tested technologies that developers have been using for a very long time, rather than shoehorning whole new tech in just because it's in a language you prefer.
        mtcoope 7y ago
        The answer to your break point question is yes. You can debug your C# code on the front end with breakpoints. The biggest benefit is applications with a lot of domain business logic tend to have that logic copied to the front end and copied to the backend. If a object can no longer be updated if it has an expired date then you would have logic on your server to prevent that. You would also have logic on your front end to display to the user that this can not happen before even going to the server. The server would act as a backup and ensure it never happens. With Blazor, this logic only exists in one place which helps follow DRY.Logic that is duplicated tends to get missed in testing often. This provides business value.
  - asdfman123 7y ago
    The process of developing better tools for more effective software design is not just about making developers feel better. It's about prodding development teams towards the pit of success, to use a common cliche, instead of the pit of despair. Less mental overhead, less need for expertise in specific flavor-of-the-month frameworks, less churn, easier hiring (you just need to know C#), more reliance on compiler tools to prevent dumb mistakes. Stuff like that easily make the difference between success and total failure. The business stakes are actually quite high.
giulianob 7y ago
Performance is only part of it. Using a single language for the whole stack is very valuable to a lot of people. I think that's why Node gained popularity because many developers were using JS for the frontend so why not use the same language for the backend as well?
- a_wild_dandan 7y ago
  That's what appealed to me. Cross-platform desktop client? Electron/TypeScript. Front-end of a website? TypeScript. Back-end service? Node/TypeScript.
- JamesSwift 7y ago
  Yes, exactly. Xamarin is already a good cross-platform solution for "apps" and so Blazor is hopefully the missing piece for the web. The JS-based cross-platform mobile solutions are just not in the same league as Xamarin, IMO.
  - The_rationalist 7y ago
    Can you show benchmarcks of an electron app vs xamarin for a same UX?
    - JamesSwift 7y ago
      I don't have any, no. Benchmarks are going to be relative to what you want to compare though so you will likely have to take them yourself, especially if you are comparing something subjective like UX. I know Paul Betts lurks around here sometimes (well maybe he used to, it looks like xpaulbettsx no longer exists), I would take his opinion on the two frameworks over anything I come up with.
_pmf_ 7y ago
> JavaScript isn't really that big of a problem or a performance killer. The DOM is. I'm using QML, which is JS without DOM. JS is absolutely a performance killer. Migrating stuff from JS to C++ in a dumb way (no architectural change) makes things 20x - 200x faster.
- untog 7y ago
  I don't doubt C++ is faster than JS, but JS in modern browsers is more than "fast enough" no matter how much faster C++ may be. If you're doing the kind of things most web pages do (render some UI, information and inputs, adjust UI, take responses from those inputs, validate and send) then JS is very, very rarely a bottleneck in performance. What JS engine does QML use? Because if it's a relatively modern one (V8, JavaScriptCore etc) and you're experiencing huge slowdowns just creating and modifying UI components then I'd seriously question the JS code you're running.
  - nwienert 7y ago
    I’ve got to be honest I thought this was the right take but I doubt it now. At least with React. Ive been doing performance on a large app now for months and JS is very often the problem. If you’re re-rendering anything that’s more than a few components wide and a few deep, say 20-40 in total, you’re already over your frame (16ms) budget. To me that’s insane. You can’t render more than 20 components at a time? And this is using a really fast computer. I almost can’t believe it. But often just the logic for a single component that’s a few levels deep takes 4ms. I really do feel that should be about 10x faster but for some reason it isn’t.
    - around_here 7y ago
      You probably need to learn how do either design a better app, or write better react if you’ve got that much of the DOM updating at once.
      - nwienert 7y ago
        A computer shouldn't struggle updating 30 smaller components. It's not DOM I'm talking about it's React, so not sure you even understood me. I've written more React than most people, and am very intimately familiar with the internals, optimization and more. With enough effort you can usually mitigate most of it, but I'm going as far as doing static compilation optimizations just to get it to feel good.
asdfman123 7y ago
The problem with JavaScript is it's a separate programming language. If you could use C# on both the front and back end, that would be a game-changer for enterprise shops, and very useful for everyone else too.
- SigmundA 7y ago
  It used to be this way back with thick clients(Winforms) and then for a short time Silverlight. It was a very productive time, not sure if I have have ever been as productive as I was with C# and Winforms. Run code on the client, run it on the server, whatever.
fortran77 7y ago
I use Elm and by having a language that puts constraints on what ultimately is executed in JavaScript and manipulations to the DOM, you can manage to write complex programs and have them be relatively efficient in size and operation. Of course Elm isn't without its problems, too, but I think it may be on the right path for web applications.
tabtab 7y ago
The solution is a new CRUD-friendly markup language & standard. Why does JavaScript have to reinvent common and expected GUI idioms that have been around since the late 1980's? That to me seems irrational. Slap the industry and wake them up! We are downloading an entire (buggy & leaky) GUI engine for every app. That kicks D.R.Y. in every organ. HTML was originally intended for static documents. We have been shoe-horning it to act like a real GUI and faking state, and it's been grunting and groaning under the strain for 2+ decades. Give up already. Make CRUD Normal Again! #MCNA!
thrownaway954 7y ago
it's not about the performance or replacing javascript. It's about being able to program the DOM in the same language you use on the backend, whatever that might be. Blazor is a game changer in my opinion. C# is a sold language and this project solidifies that.

by untog 7y ago

snarfy 7y ago

JavaScript isn't a very good programming language. Just because I can develop in it doesn't mean I want to.

untog 7y ago
Sure. Blazor scratches a developer itch. But end users aren't likely to feel a difference one way or the other. The same bottlenecks are still the same bottlenecks.
- belltaco 7y ago
  It isn't just about scratching an itch. It results in fewer bugs, faster development, more features etc. which are useful to end users.
  - untog 7y ago
    My experience of tools/languages that sit on top of the actual native implementations (e.g. React Native or Xamarin on mobile) is that they often lead to much slower development, since when you're Googling around trying to find answers to an issue you're looking in a much smaller community for answers. Eventually the answer usually ends up being "just do it the native way". Hopefully Blazor will avoid such issues. In any case I'm probably speaking out of turn... it clearly isn't designed for wide-scale deployments - in house/intranet tools are a different beast anyway.
    - tasogare 7y ago
      I use Xamarin Android and while you are right about the ton of googling needed, it was always to search for Android API and almost never because of Xamarin itself. Once found, it’s straightforward to convert from Java code to C# except a few cases (layout parameters for instance). The other issue is coming from a nicely design framework (WPF, Silverlight or WP7/8) the Android APIs feel ugly at times (gesture handlers for example).
    - JamesSwift 7y ago
      Assuming you are doing Xamarin.Native and not Xamarin.Forms, you can just tab-complete your way through it if you know the native side. The apis are almost 1-to-1, only making things more dotnet-y when it makes sense.
  - mdgrech23 7y ago
    That's such nonsensical marketing spin.
    - belltaco 7y ago
      I don't see how easier development does not result in better outcomes. Imagine how bad things would be if everyone had to code in Assembly.
      - untog 7y ago
        But the "easier development" part is very debatable. What do I see in the browser developer console when debugging a Blazor app? Can I insert breakpoints, trace what is running and how? etc. etc. I get disliking JavaScript, but there is a strong argument to be made for using the tried and tested technologies that developers have been using for a very long time, rather than shoehorning whole new tech in just because it's in a language you prefer.
        mtcoope 7y ago
        The answer to your break point question is yes. You can debug your C# code on the front end with breakpoints. The biggest benefit is applications with a lot of domain business logic tend to have that logic copied to the front end and copied to the backend. If a object can no longer be updated if it has an expired date then you would have logic on your server to prevent that. You would also have logic on your front end to display to the user that this can not happen before even going to the server. The server would act as a backup and ensure it never happens. With Blazor, this logic only exists in one place which helps follow DRY.Logic that is duplicated tends to get missed in testing often. This provides business value.
- asdfman123 7y ago
  The process of developing better tools for more effective software design is not just about making developers feel better. It's about prodding development teams towards the pit of success, to use a common cliche, instead of the pit of despair. Less mental overhead, less need for expertise in specific flavor-of-the-month frameworks, less churn, easier hiring (you just need to know C#), more reliance on compiler tools to prevent dumb mistakes. Stuff like that easily make the difference between success and total failure. The business stakes are actually quite high.

giulianob 7y ago

Performance is only part of it. Using a single language for the whole stack is very valuable to a lot of people. I think that's why Node gained popularity because many developers were using JS for the frontend so why not use the same language for the backend as well?

a_wild_dandan 7y ago
That's what appealed to me. Cross-platform desktop client? Electron/TypeScript. Front-end of a website? TypeScript. Back-end service? Node/TypeScript.
JamesSwift 7y ago
Yes, exactly. Xamarin is already a good cross-platform solution for "apps" and so Blazor is hopefully the missing piece for the web. The JS-based cross-platform mobile solutions are just not in the same league as Xamarin, IMO.
- The_rationalist 7y ago
  Can you show benchmarcks of an electron app vs xamarin for a same UX?
  - JamesSwift 7y ago
    I don't have any, no. Benchmarks are going to be relative to what you want to compare though so you will likely have to take them yourself, especially if you are comparing something subjective like UX. I know Paul Betts lurks around here sometimes (well maybe he used to, it looks like xpaulbettsx no longer exists), I would take his opinion on the two frameworks over anything I come up with.

_pmf_ 7y ago

> JavaScript isn't really that big of a problem or a performance killer. The DOM is. I'm using QML, which is JS without DOM. JS is absolutely a performance killer. Migrating stuff from JS to C++ in a dumb way (no architectural change) makes things 20x - 200x faster.

untog 7y ago
I don't doubt C++ is faster than JS, but JS in modern browsers is more than "fast enough" no matter how much faster C++ may be. If you're doing the kind of things most web pages do (render some UI, information and inputs, adjust UI, take responses from those inputs, validate and send) then JS is very, very rarely a bottleneck in performance. What JS engine does QML use? Because if it's a relatively modern one (V8, JavaScriptCore etc) and you're experiencing huge slowdowns just creating and modifying UI components then I'd seriously question the JS code you're running.
- nwienert 7y ago
  I’ve got to be honest I thought this was the right take but I doubt it now. At least with React. Ive been doing performance on a large app now for months and JS is very often the problem. If you’re re-rendering anything that’s more than a few components wide and a few deep, say 20-40 in total, you’re already over your frame (16ms) budget. To me that’s insane. You can’t render more than 20 components at a time? And this is using a really fast computer. I almost can’t believe it. But often just the logic for a single component that’s a few levels deep takes 4ms. I really do feel that should be about 10x faster but for some reason it isn’t.
  - around_here 7y ago
    You probably need to learn how do either design a better app, or write better react if you’ve got that much of the DOM updating at once.
    - nwienert 7y ago
      A computer shouldn't struggle updating 30 smaller components. It's not DOM I'm talking about it's React, so not sure you even understood me. I've written more React than most people, and am very intimately familiar with the internals, optimization and more. With enough effort you can usually mitigate most of it, but I'm going as far as doing static compilation optimizations just to get it to feel good.

asdfman123 7y ago

The problem with JavaScript is it's a separate programming language. If you could use C# on both the front and back end, that would be a game-changer for enterprise shops, and very useful for everyone else too.

SigmundA 7y ago
It used to be this way back with thick clients(Winforms) and then for a short time Silverlight. It was a very productive time, not sure if I have have ever been as productive as I was with C# and Winforms. Run code on the client, run it on the server, whatever.

fortran77 7y ago

I use Elm and by having a language that puts constraints on what ultimately is executed in JavaScript and manipulations to the DOM, you can manage to write complex programs and have them be relatively efficient in size and operation. Of course Elm isn't without its problems, too, but I think it may be on the right path for web applications.

tabtab 7y ago

The solution is a new CRUD-friendly markup language & standard. Why does JavaScript have to reinvent common and expected GUI idioms that have been around since the late 1980's? That to me seems irrational. Slap the industry and wake them up! We are downloading an entire (buggy & leaky) GUI engine for every app. That kicks D.R.Y. in every organ. HTML was originally intended for static documents. We have been shoe-horning it to act like a real GUI and faking state, and it's been grunting and groaning under the strain for 2+ decades. Give up already. Make CRUD Normal Again! #MCNA!

thrownaway954 7y ago

it's not about the performance or replacing javascript. It's about being able to program the DOM in the same language you use on the backend, whatever that might be. Blazor is a game changer in my opinion. C# is a sold language and this project solidifies that.