Re: Creating a browser-based product

[David Connors]

On Wed, 22 Nov 2017 at 21:06 David Gardiner  wrote:

> I assume you're referring to Steve Sanderson's Blazer project - "Experimental
> UI framework running .NET in the browser via webassembly"?
> https://github.com/SteveSanderson/Blazor
>

No - interesting to see that. Unsure how practical it is.
-- 
David Connors
da...@connors.com | @davidconnors | https://t.me/davidconnors | LinkedIn | +61
417 189 363

Re: Creating a browser-based product

[Greg Keogh]

Blazor still runs in a browser, and you will notice it contains the words
Razor, HTML and JS, which worries me it's not really "transformational".
I'm also worried that it starts as a hobby that another guy has taken over
as a hobby. And it still runs in a bloody browser! However, it's heading in
a better direction that just producing yet another JS framework -- *GK*

Re: Creating a browser-based product

[Greg Harris]

Blazor sounds like a good starting point, but it is not yet ready to do
real world work.

I must admit, I had not looked at Blazor until now because I had been told
"it is just a toy, an experiment".  After looking at it, I feel that it has
the potential to be the basis of something transformational.



You can see more of the story at:
http://blog.stevensanderson.com/2017/11/05/blazor-on-mono/

Which has a link to a video of his demo app from NDC Oslo:
https://www.youtube.com/watch?v=MiLAE6HMr10=youtu.be=31m45s which
is seriously worth watching!



Then reading: https://github.com/SteveSanderson/Blazor

"An experimental web UI framework using C#/Razor and HTML, running
client-side via WebAssembly

The arrival of WebAssembly creates the possibility of building client-side
web applications using languages and runtimes that are more typically used
for native app development. Blazor runs .NET code in the browser via the
Mono runtime, which itself is compiled to WebAssembly and asm.js.

The programming model will be familiar to anyone who's worked with Razor
(the C#/HTML page format used by ASP.NET MVC and ASP.NET Pages)."



Which all looks really promising, until you read…



Can I build a real production app with this?

No. It's very incomplete. There isn't yet any support for producing
optimised production builds or connecting a debugger.



Why isn't there an issue tracker? How do I file issues?

You don't file issues. There's no support for this. It's experimental.


This is all bleeding edge stuff, that blog post is from 5-Nov

I will wait a little longer before making any bets on this...

But I repeat...

I feel that Blazor has the potential to be the basis of something
transformational!

Re: Creating a browser-based product

[Greg Keogh]

>
> After all this time it means that the browser is ripe for disruption, and
> it might not even be a variant of what we've been doing so far... But what
> is it?What would it look like?
>

A 21st century version of Java Applets would be a start. Run them in
something like a VM window. There are probably people in this group with
the skills to design the instruction set, generate compilers, write a
virtual cross-platform player, write designer plug-ins for popular IDEs
and get it ratified by ISO, IEEE, FIPS, NSA, FBI, GCHQ and the PTA -- *GK*

Re: Creating a browser-based product

[David Gardiner]

I assume you're referring to Steve Sanderson's Blazer project - "Experimental
UI framework running .NET in the browser via webassembly"?

https://github.com/SteveSanderson/Blazor

David

On 22 November 2017 at 21:20, David Connors  wrote:

> WebAssembly? You could port the clr to it so you can run webforms in a
> browser. Greg will want to have your babies as a result.
>
> On Wed., 22 Nov. 2017, 8:48 pm Tony Wright,  wrote:
>
>> After all this time it means that the browser is ripe for disruption, and
>> it might not even be a variant of what we've been doing so far... But what
>> is it?What would it look like?
>>
>> On 22 Nov 2017 8:38 PM, "Ken Schaefer"  wrote:
>>
>>> *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@
>>> ozdotnet.com] *On Behalf Of *Greg Harris
>>> *Sent:* Wednesday, 22 November 2017 3:44 PM
>>> *To:* ozDotNet 
>>> *Subject:* Re: Creating a browser-based product
>>>
>>>
>>>
>>> Plugins like Silverlight and Flash made web apps open to using a lot
>>> more of the client machine’s resources to provide an interactive
>>> experience.  But, the industry has not supported these plugins for some
>>> reason I fail to fully understand.
>>>
>>> Because Adobe Flash was more bugs than actual working code? The cost of
>>> supporting Flash made it unappealing to people who pay the bills?
>>>
>>> If we cannot use Silverlight or Flash and fat clients are too hard /
>>> expensive to install, you are back to the dumb terminal browser plus
>>> Javascript again.
>>>
>>> Yes, and no. There’s offline storage, and some execution, that can be
>>> offloaded to browsers.
>>>
>>> Look at compute intensive apps like 3D modelling or video editing, they
>>> could never be done properly with today’s browser technology!
>>>
>>> Nothing is binary. At some point, the benefit of running a thick client
>>> native app is greater than the cost of maintaining it.
>>>
>>> But those use cases seem to be shrinking year-on-year.
>>>
>>> Or maybe even a win forms app, because it is fast, I have 100% control *and
>>> it is not really that hard to install*!
>>>
>>> The technical cost of your one app isn’t that much. But the total cost
>>> of supporting a desktop does not increase linearly with the number of apps.
>>> It increases exponentially, and thus doesn’t scale.
>>>
>>>
>>>
>> --
> David Connors
> da...@connors.com | @davidconnors | https://t.me/davidconnors | LinkedIn
>  | +61 417 189 363
>

RE: Creating a browser-based product

[Ken Schaefer]

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Harris
Sent: Wednesday, 22 November 2017 3:44 PM
To: ozDotNet 
Subject: Re: Creating a browser-based product

Plugins like Silverlight and Flash made web apps open to using a lot more of 
the client machine’s resources to provide an interactive experience.  But, the 
industry has not supported these plugins for some reason I fail to fully 
understand.
Because Adobe Flash was more bugs than actual working code? The cost of 
supporting Flash made it unappealing to people who pay the bills?
If we cannot use Silverlight or Flash and fat clients are too hard / expensive 
to install, you are back to the dumb terminal browser plus Javascript again.
Yes, and no. There’s offline storage, and some execution, that can be offloaded 
to browsers.
Look at compute intensive apps like 3D modelling or video editing, they could 
never be done properly with today’s browser technology!
Nothing is binary. At some point, the benefit of running a thick client native 
app is greater than the cost of maintaining it.
But those use cases seem to be shrinking year-on-year.
Or maybe even a win forms app, because it is fast, I have 100% control and it 
is not really that hard to install!
The technical cost of your one app isn’t that much. But the total cost of 
supporting a desktop does not increase linearly with the number of apps. It 
increases exponentially, and thus doesn’t scale.