4 ms·

While I definitely can't see this being useful for general websites/web applications, I guess I could see it being useful for "line of business" internal web ap

While I definitely can't see this being useful for general websites/web applications, I guess I could see it being useful for "line of business" internal web apps for businesses? But then, I don't understand why you wouldnt just make it with web tech to begin with and 'port' it to native platforms with Electron.

baq 6y ago
because web tech isn't really the best solution for quick and dirty UIs. source: been involved in quick and dirty UIs in a business for the past decade
- SiVal 6y ago
  So what has that decade taught you is the best solution for quick and dirty UIs?
  - qzw 6y ago
    VisualBasic, back in the day.
  - baq 6y ago
    haven't found a universally good option yet; delphi was close 15 years ago, but the world forgot about it mostly. hoping for WASM+compiled language framework somewhat like this one to fit the bill so I don't have to worry about supporting multiple browsers, multiple browser versions, cross platform support, css... WASM (language independence) on electron (fixed, controlled browser version) with delphi-like UI designer could work, maybe.
  - SenHeng 6y ago
    PowerBuilder, in the EMR industry.
  - acuozzo 6y ago
    HyperCard.
  - 0x10c0fe11ce 6y ago
    Beeware!
merb 6y ago
btw. one can also use blazor server-side for business line of applications, which is way more smooth and only needs websockets. so I have no idea which target c# client-side wasm (uno/blazor/whatever) has at the moment, because it simply is too big.
kevingadd 6y ago
Historically, the companies with large line of business apps that were interested in using JSIL to run C# in the browser were interested specifically because rewriting their software from scratch in Electron was an expensive and time-consuming undertaking. This made it worthwhile to invest in alternatives that would let them reuse existing code. We're talking massive WPF or Silverlight codebases with decades worth of developer time invested that would all go out the window. The same logic applies now and it's even more compelling since the tooling and performance are better now with the full LLVM WASM toolchain and more robust C# AOT compilation available, vs the dark ages when people had JSIL, Saltarelle and Bridge to choose from. I'll also note that every major company I'm aware of that made a C# -> Browser move for their tooling eventually regretted it and started shifting away to something better, partly due to platform churn and partly due to how much was outside of their control. Electron may change the equation there enough to be good enough, we'll see - I don't know of any companies that have taken that route yet.

baq 6y ago

because web tech isn't really the best solution for quick and dirty UIs. source: been involved in quick and dirty UIs in a business for the past decade

SiVal 6y ago
So what has that decade taught you is the best solution for quick and dirty UIs?
- qzw 6y ago
  VisualBasic, back in the day.
- baq 6y ago
  haven't found a universally good option yet; delphi was close 15 years ago, but the world forgot about it mostly. hoping for WASM+compiled language framework somewhat like this one to fit the bill so I don't have to worry about supporting multiple browsers, multiple browser versions, cross platform support, css... WASM (language independence) on electron (fixed, controlled browser version) with delphi-like UI designer could work, maybe.
- SenHeng 6y ago
  PowerBuilder, in the EMR industry.
- acuozzo 6y ago
  HyperCard.
- 0x10c0fe11ce 6y ago
  Beeware!

merb 6y ago

btw. one can also use blazor server-side for business line of applications, which is way more smooth and only needs websockets. so I have no idea which target c# client-side wasm (uno/blazor/whatever) has at the moment, because it simply is too big.

kevingadd 6y ago

Historically, the companies with large line of business apps that were interested in using JSIL to run C# in the browser were interested specifically because rewriting their software from scratch in Electron was an expensive and time-consuming undertaking. This made it worthwhile to invest in alternatives that would let them reuse existing code. We're talking massive WPF or Silverlight codebases with decades worth of developer time invested that would all go out the window. The same logic applies now and it's even more compelling since the tooling and performance are better now with the full LLVM WASM toolchain and more robust C# AOT compilation available, vs the dark ages when people had JSIL, Saltarelle and Bridge to choose from. I'll also note that every major company I'm aware of that made a C# -> Browser move for their tooling eventually regretted it and started shifting away to something better, partly due to platform churn and partly due to how much was outside of their control. Electron may change the equation there enough to be good enough, we'll see - I don't know of any companies that have taken that route yet.