RE: Creating a browser-based product

[djones147]

Greg K, 

I suggest you install nodejs via Chocolatey. After uninstalling it from add / 
remove programs. 
https://chocolatey.org/

it’s based on nuget and installs windows apps. 

Here’s a command line to install choco. 

@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object 
net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" && SET 
PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin

Then from an admin command prompt do. 

choco install nodejs --version 8.7.0 --allow-downgrade -y

the reason that you allow downgrades is to keep the version the same as 
required with angular 4,  in my case that’s 8.7.0

Here’s a sample of my choco package loader.   (D:\choco is a shared network 
drive, used to download a package just the once but install over multiple 
machines )

Echo setting the cache
choco config set cacheLocation d:\choco
choco source remove -n=chocolatey -s=https://chocolatey.org/api/v2/
choco source remove -n=choco -s=d:\choco
choco source add -n=choco -s=d:\choco
choco source add -n=chocolatey -s=https://chocolatey.org/api/v2/
echo installing packages
choco install nodejs --version 8.7.0 --allow-downgrade -y

hth

Davy.

Sent from Mail for Windows 10

From: Greg Keogh
Sent: 29 November 2017 01:40
To: ozDotNet
Subject: Re: Creating a browser-based product

Yes you need to install node js. And it's not just angular - it's javascript in 
general.

I've added the Node.js component to my VS2017 installation.

But now what? Is the Node.js server part of VS2017, or do I install it 
separately? Does it run continuously as a service of some kind, or do I run it 
manually while developing, or does something else host it automatically? What's 
it serving anyway while I'm developing (I have no intention of using it)?

Greg K

Re: Creating a browser-based product

[Nathan Schultz]

As a .Net programmer, if you detest Javascript (as I do), you can also use
F# and Fable to write single page web-applications. It won't save you from
the vagaries of HTML and CSS though - you still need to know this.
I personally use Elm (which is similar to F# + Fable) - but it's far more
bullet-proof (run-time errors are exceptionally rare), although you're no
longer in the Microsoft eco-system (for better or worse).

If you're writing web-applications for a company though, I still think
Angular or React is the easier sell to management; yes it's more complex,
more clunky, and will take longer to write - but at least finding other
Angular or React resources is fairly trivial.

On 29 November 2017 at 13:53, Greg Keogh  wrote:

> I strongly recommend this course: https://app.pluralsigh
>> t.com/library/courses/angular-fundamentals/table-of-contents
>>
>
> Thanks, I've watched about an hour so far. They seem to use a more
> *classic* approach with a simpler project structure, and they use VS Code
> instead of Studio so there's no projects and solutions.
>
> The amount of unusual markup required to plumb all the parts together is
> really irritating. This is a very complex infrastructure just to render an
> app browser-side. I blame the JavaScript language for this as it lacks
> everything one would expect in a modern robust language ecosystem.
> Everything looks like a hack, workaround or add-on just to hoist the whole
> vast slogging mess up to make it work. I'm still not impressed.
>
> *Greg*
>

RE: Creating a browser-based product

[Tony Wright]

It really comes down to what you are trying to achieve. If you are writing
an enterprise app, then you want an opinionated framework where most of the
decisions have been made for you.

That's usually because you want the ability to hire people that have the
required skill and can hit the ground running. They don't have to learn
your unique structure first.

Angular (and Aurelia) do this, but React and Vue are only the view layer,
so you will need to build up the tech stack yourself. I have heard people
say that no two React applications are the same.

Of course if you're writing something smaller, then you have a lot more
latitude to choose whatever you want.

On 29 Nov 2017 5:05 PM, "Nic Roche" <nicro...@hotmail.com> wrote:

> Hey Will,
>
>
>
>- From what I've been reading, vue.js would be much quicker to pick up
>compared to Angular which has a much steeper learning curve.
>
>
>
> Vue in its simplest (vanilla JS) form, yes.
>
>
>
> To do anything more complex, you need to use the Vue CLI/toolchain.
>
>
>
> Once you hit this point, I find the latest approach in Angular more
> intuitive…
>
>
>
> Regards,
> Nic Roche
>
>
> --
> *From:* ozdotnet-boun...@ozdotnet.com <ozdotnet-boun...@ozdotnet.com> on
> behalf of William Luu <will@gmail.com>
> *Sent:* Wednesday, November 29, 2017 3:43:45 PM
> *To:* ozDotNet
> *Subject:* Re: Creating a browser-based product
>
> Hi Greg,
>
> I've been following this thread a little bit. I'm a bit like you in that I
> haven't really been keeping up with the latest JS developments and am also
> looking at creating a new app soon which makes use of one of these new JS
> frameworks and am heavily leaning towards either React or Vue.
>
> I think this article is useful for getting to know what the various pieces
> of the modern JS world are (and what they do). https://medium.com/the-
> node-js-collection/modern-javascript-explained-for-dinosaurs-f695e9747b70
>
> From what I've been reading, vue.js would be much quicker to pick up
> compared to Angular which has a much steeper learning curve.
>
> Some more reading material:
>
>- https://medium.com/corebuild-software/vue-js-and-net-mvc-b5cede228626
>
>- https://laravel-news.com/jquery-vue
>- https://blog.kloud.com.au/2017/02/14/running-vuejs-on-
>aspnet-core-apps/
>- https://vuejs.org/v2/guide/
>- https://vuejs.org/v2/guide/comparison.html
>
> From my understanding, in your ideal world, you want to utilise your
> existing knowledge (ASP.NET MVC etc) and then add on a bit of JavaScript
> to make the page more interactive.
>
> Of course, this is just my opinion as someone who has no experience in any
> of these modern JS frameworks. I've chatted with a few guys who have
> experience with all 3, and their general consensus these days is towards
> Vue and React over Angular.
>
>
> Will
>
>
>
> On 17 November 2017 at 09:14, Greg Keogh <gfke...@gmail.com> wrote:
>
>> Folks, we have a serious decision to make about the future directions of
>> our 10 year old Silverlight product that is in wide use in some big
>> companies. I told the boss I'd poll this forum for advice, so I'd really
>> appreciate serious comments from people in-the-know.
>>
>> The large companies using the Silverlight product are now locking down
>> security, so Internet Explorer is being banned and Edge adopted, which
>> means Silverlight is out (some employees are already being forced to use
>> the product from home). Our product is available as Xamarin authored tablet
>> and phone apps for three platforms, but they won't even allow our apps on
>> their company devices.
>>
>> So for the first time we are forced to produce a "browser based" version
>> of our product, which apparently is acceptable to their security policies
>> and audits. Here are some issues swirling in my head:
>>
>>- The backend services to drive the product are established.
>>- The UIs of other product versions are explorer (master-detail)
>>style, so it would be nice to maintain that feel in the browser.
>>- We have to display data in Excel-like tables and a variety of
>>charts (the richer and more interactive the better).
>>- Should we use server-side ASP.NET Web Forms or MVC to drive it?
>>- Should it be browser-side SPA? (you know I hate JS everything, so
>>there is personal resistance there).
>>- Could server-side and browser-side be combined to produce a better
>>hybrid experience? Are there things to help you do that?
>>- There are development platforms such as GTK and m

RE: Creating a browser-based product

[Nic Roche]

Hey Will,


  *   From what I've been reading, vue.js would be much quicker to pick up 
compared to Angular which has a much steeper learning curve.

Vue in its simplest (vanilla JS) form, yes.

To do anything more complex, you need to use the Vue CLI/toolchain.

Once you hit this point, I find the latest approach in Angular more intuitive…

Regards,
Nic Roche


From: ozdotnet-boun...@ozdotnet.com <ozdotnet-boun...@ozdotnet.com> on behalf 
of William Luu <will@gmail.com>
Sent: Wednesday, November 29, 2017 3:43:45 PM
To: ozDotNet
Subject: Re: Creating a browser-based product

Hi Greg,

I've been following this thread a little bit. I'm a bit like you in that I 
haven't really been keeping up with the latest JS developments and am also 
looking at creating a new app soon which makes use of one of these new JS 
frameworks and am heavily leaning towards either React or Vue.

I think this article is useful for getting to know what the various pieces of 
the modern JS world are (and what they do). 
https://medium.com/the-node-js-collection/modern-javascript-explained-for-dinosaurs-f695e9747b70

>From what I've been reading, vue.js would be much quicker to pick up compared 
>to Angular which has a much steeper learning curve.

Some more reading material:

  *   https://medium.com/corebuild-software/vue-js-and-net-mvc-b5cede228626
  *   https://laravel-news.com/jquery-vue
  *   https://blog.kloud.com.au/2017/02/14/running-vuejs-on-aspnet-core-apps/
  *   https://vuejs.org/v2/guide/
  *   https://vuejs.org/v2/guide/comparison.html

>From my understanding, in your ideal world, you want to utilise your existing 
>knowledge (ASP.NET<http://ASP.NET> MVC etc) and then add on a bit of 
>JavaScript to make the page more interactive.

Of course, this is just my opinion as someone who has no experience in any of 
these modern JS frameworks. I've chatted with a few guys who have experience 
with all 3, and their general consensus these days is towards Vue and React 
over Angular.


Will



On 17 November 2017 at 09:14, Greg Keogh 
<gfke...@gmail.com<mailto:gfke...@gmail.com>> wrote:
Folks, we have a serious decision to make about the future directions of our 10 
year old Silverlight product that is in wide use in some big companies. I told 
the boss I'd poll this forum for advice, so I'd really appreciate serious 
comments from people in-the-know.

The large companies using the Silverlight product are now locking down 
security, so Internet Explorer is being banned and Edge adopted, which means 
Silverlight is out (some employees are already being forced to use the product 
from home). Our product is available as Xamarin authored tablet and phone apps 
for three platforms, but they won't even allow our apps on their company 
devices.

So for the first time we are forced to produce a "browser based" version of our 
product, which apparently is acceptable to their security policies and audits. 
Here are some issues swirling in my head:

  *   The backend services to drive the product are established.
  *   The UIs of other product versions are explorer (master-detail) style, so 
it would be nice to maintain that feel in the browser.
  *   We have to display data in Excel-like tables and a variety of charts (the 
richer and more interactive the better).
  *   Should we use server-side ASP.NET<http://ASP.NET> Web Forms or MVC to 
drive it?
  *   Should it be browser-side SPA? (you know I hate JS everything, so there 
is personal resistance there).
  *   Could server-side and browser-side be combined to produce a better hybrid 
experience? Are there things to help you do that?
  *   There are development platforms such as GTK and many others I guess that 
I'm not familiar with. Are they viable?
  *   Other issues I'm forgetting?

I'm personally familiar with ASP.NET<http://ASP.NET> Web Forms and MVC, but not 
with quality JS, layout or styling. Perhaps I could write a black-and-white 
skeleton of the working product and then give it to someone to style and script 
(I have done that once before).

So in summary (I know this is a very broad question) ... if you were in my 
position, how would you proceed to produce a browser based version of a product?

Cheers,
Greg K

Re: Creating a browser-based product

[Greg Keogh]

>
> I strongly recommend this course: https://app.pluralsight.com/library/
> courses/angular-fundamentals/table-of-contents
>

Thanks, I've watched about an hour so far. They seem to use a more *classic*
approach with a simpler project structure, and they use VS Code instead of
Studio so there's no projects and solutions.

The amount of unusual markup required to plumb all the parts together is
really irritating. This is a very complex infrastructure just to render an
app browser-side. I blame the JavaScript language for this as it lacks
everything one would expect in a modern robust language ecosystem.
Everything looks like a hack, workaround or add-on just to hoist the whole
vast slogging mess up to make it work. I'm still not impressed.

*Greg*

Re: Creating a browser-based product

[William Luu]

Hi Greg,

I've been following this thread a little bit. I'm a bit like you in that I
haven't really been keeping up with the latest JS developments and am also
looking at creating a new app soon which makes use of one of these new JS
frameworks and am heavily leaning towards either React or Vue.

I think this article is useful for getting to know what the various pieces
of the modern JS world are (and what they do).
https://medium.com/the-node-js-collection/modern-javascript-explained-for-dinosaurs-f695e9747b70

>From what I've been reading, vue.js would be much quicker to pick up
compared to Angular which has a much steeper learning curve.

Some more reading material:

   - https://medium.com/corebuild-software/vue-js-and-net-mvc-b5cede228626
   - https://laravel-news.com/jquery-vue
   - https://blog.kloud.com.au/2017/02/14/running-vuejs-on-aspnet-core-apps/
   - https://vuejs.org/v2/guide/
   - https://vuejs.org/v2/guide/comparison.html

>From my understanding, in your ideal world, you want to utilise your
existing knowledge (ASP.NET MVC etc) and then add on a bit of JavaScript to
make the page more interactive.

Of course, this is just my opinion as someone who has no experience in any
of these modern JS frameworks. I've chatted with a few guys who have
experience with all 3, and their general consensus these days is towards
Vue and React over Angular.


Will



On 17 November 2017 at 09:14, Greg Keogh  wrote:

> Folks, we have a serious decision to make about the future directions of
> our 10 year old Silverlight product that is in wide use in some big
> companies. I told the boss I'd poll this forum for advice, so I'd really
> appreciate serious comments from people in-the-know.
>
> The large companies using the Silverlight product are now locking down
> security, so Internet Explorer is being banned and Edge adopted, which
> means Silverlight is out (some employees are already being forced to use
> the product from home). Our product is available as Xamarin authored tablet
> and phone apps for three platforms, but they won't even allow our apps on
> their company devices.
>
> So for the first time we are forced to produce a "browser based" version
> of our product, which apparently is acceptable to their security policies
> and audits. Here are some issues swirling in my head:
>
>- The backend services to drive the product are established.
>- The UIs of other product versions are explorer (master-detail)
>style, so it would be nice to maintain that feel in the browser.
>- We have to display data in Excel-like tables and a variety of charts
>(the richer and more interactive the better).
>- Should we use server-side ASP.NET Web Forms or MVC to drive it?
>- Should it be browser-side SPA? (you know I hate JS everything, so
>there is personal resistance there).
>- Could server-side and browser-side be combined to produce a better
>hybrid experience? Are there things to help you do that?
>- There are development platforms such as GTK and many others I guess
>that I'm not familiar with. Are they viable?
>- Other issues I'm forgetting?
>
>
> I'm personally familiar with ASP.NET Web Forms and MVC, but not with
> quality JS, layout or styling. Perhaps I could write a black-and-white
> skeleton of the working product and then give it to someone to style and
> script (I have done that once before).
>
> So in summary (I know this is a very broad question) ... if you were in my
> position, how would you proceed to produce a browser based version of a
> product?
>
> Cheers,
> *Greg K*
>
>

Re: Creating a browser-based product

[David Burstin]

Hi Greg,

I strongly recommend this course:
https://app.pluralsight.com/library/courses/angular-fundamentals/table-of-contents

It's an excellent course including some Plunkr exercise files, so you can
see each part in action.

On first view, the project structure is bewildering, but once you
understand it, it all makes sense, I think it is an excellent example of
SRP - each component has it's own section in the app folder dealing with
its single responsibility.

There is an initial learning curve, but in my experience it is not very
big. After the first section of the linked course it should all make sense
and stop your eyes bleeding.

Regards
David

On 29 November 2017 at 12:23, Greg Keogh  wrote:

> I am not really sure what VS 2017 does, I always just install Node
>> separately. Node is not a webserver, although you can build a webserver on
>> it, it is a runtime. So it is not serving anything. The Angular CLI and
>> tools are built on it.
>>
>
> I installed Node.js from the main site's MSI download. The Angular project
> I generated earlier now compiles (with 150 conflicts) and runs and shows a
> Hello world web page in a browser. It throws the equivalent of a null
> reference exception each time I navigate, but it seems to keep running
> (it's alarming that the throw is in a js file that has 92879 lines of code).
>
> The structure of the project is bewildering. It contains an 'app' folder
> which seems to contain the Angular code, it also contains Razor files, C#
> code and WebApi controllers. It's a complete jumble. Is this just because
> it's a demo or would you really develop with this structure?
>
> I've been reading MSDN magazine articles on JS development regularly, but
> the project and code and structure is unlike anything I expected when I
> dive in. It's a gigantic muddle. I still can't figure out what the hell the
> Node.js runtime is doing.
>
> I haven't yet watched any Angular tutorial videos (which I might do
> today), but first impressions are important, and my first impression of
> everything I've seen so far with Angular/JS is like a dumpster bin full of
> burning nappies.
>
> I was hoping to do a crash course on Angular and perhaps get started, but
> there is no obvious guidance about how to proceed into the morass of
> components and files. It's an order of magnitude more complex than any
> development environment I've seen in 30+ years ... why?
>
> *GK*
>

Re: Creating a browser-based product

[Greg Keogh]

>
> I am not really sure what VS 2017 does, I always just install Node
> separately. Node is not a webserver, although you can build a webserver on
> it, it is a runtime. So it is not serving anything. The Angular CLI and
> tools are built on it.
>

I installed Node.js from the main site's MSI download. The Angular project
I generated earlier now compiles (with 150 conflicts) and runs and shows a
Hello world web page in a browser. It throws the equivalent of a null
reference exception each time I navigate, but it seems to keep running
(it's alarming that the throw is in a js file that has 92879 lines of code).

The structure of the project is bewildering. It contains an 'app' folder
which seems to contain the Angular code, it also contains Razor files, C#
code and WebApi controllers. It's a complete jumble. Is this just because
it's a demo or would you really develop with this structure?

I've been reading MSDN magazine articles on JS development regularly, but
the project and code and structure is unlike anything I expected when I
dive in. It's a gigantic muddle. I still can't figure out what the hell the
Node.js runtime is doing.

I haven't yet watched any Angular tutorial videos (which I might do today),
but first impressions are important, and my first impression of everything
I've seen so far with Angular/JS is like a dumpster bin full of burning
nappies.

I was hoping to do a crash course on Angular and perhaps get started, but
there is no obvious guidance about how to proceed into the morass of
components and files. It's an order of magnitude more complex than any
development environment I've seen in 30+ years ... why?

*GK*

Re: Creating a browser-based product

[Tony Wright]

Node needs to be installed separately.

You don't have to do anything else, it gets used behind the scenes. Its not
a service. Some packages hook into it.




On 29 Nov 2017 11:40 AM, "Greg Keogh"  wrote:

Yes you need to install node js. And it's not just angular - it's
> javascript in general.
>

I've added the Node.js component to my VS2017 installation.

But now what? Is the Node.js server part of VS2017, or do I install it
separately? Does it run continuously as a service of some kind, or do I run
it manually while developing, or does something else host it automatically?
What's it serving anyway while I'm developing (I have no intention of using
it)?

*Greg K*

Re: Creating a browser-based product

[Greg Keogh]

>
> Yes you need to install node js. And it's not just angular - it's
> javascript in general.
>

I've added the Node.js component to my VS2017 installation.

But now what? Is the Node.js server part of VS2017, or do I install it
separately? Does it run continuously as a service of some kind, or do I run
it manually while developing, or does something else host it automatically?
What's it serving anyway while I'm developing (I have no intention of using
it)?

*Greg K*

Re: Creating a browser-based product

[Craig van Nieuwkerk]

Having said that, you shouldn't need to deploy Node in production, it is
just for the tooling.

On Wed, Nov 29, 2017 at 9:38 AM, Craig van Nieuwkerk 
wrote:

> All the Angular (and almost every Js framework) tooling is built with
> Node, so on you dev machines at least you are unlikely to be able to get
> away from it. Going forward, unless you are planning on building something
> bare bones with no framework I think there is not much chance of being able
> to not have a dependency on Node.
>
> https://i.redd.it/tfugj4n3l6ez.png
>
> On Wed, Nov 29, 2017 at 9:21 AM, Greg Keogh  wrote:
>
>> Folks, just a heads-up for the unprepared.
>>
>> Following a suggestion from Craig I used the command "dotnet new angular"
>> to create a fresh Angular Visual Studio project. I've had no need to use
>> .NET Core since it came out, so it's interesting to look at the help for
>> the various options. The Angular project is generated with 45 files in 19
>> folders. After you open it in VS2017 it runs a quiet frenzy of downloads
>> into the node_modules folder, this produces 13478 files in 1715 folders
>> containing roughly 1.7 million lines of JavaScript.
>>
>> Now pardon me ... but is this crazy?! What I mean is, is this typical of
>> an Angular project or is the default project incompletely or incorrectly
>> configured? It's like creating a .NET traditional project and having the
>> complete Framework source code included. I don't recall any concept of a
>> "compiled library" for JavaScript, so I'm guessing such a thing hasn't been
>> invented yet, is that right?
>>
>> I tried running the project but after giving me 150 package conflict
>> warnings it stops and tells me "Node.js is required to build and run this
>> project". Now I'm confused, as why on earth would that be needed? I was
>> hoping to avoid Node.js completely as the backend of our proposed app is a
>> working WebApi.
>>
>> I will be posting a formal request in here soon for anyone who can help
>> us develop a browser-based product.
>>
>> *Greg K*
>>
>> On 17 November 2017 at 10:13, Craig van Nieuwkerk 
>> wrote:
>>
>>> If you backend services are well established and you could easily put a
>>> WebAPI over them, then it makes sense to do a SPA and mainly Javascript
>>> front end.
>>>
>>> If it is an enterprisey type app then it is hard to go past Angular,
>>> Pluralsight is your friend to learn. I would also talk to ssw.com.au,
>>> they have some good courses that will get you running in the right
>>> direction quickly.
>>>
>>> Craig
>>>
>>> On Fri, Nov 17, 2017 at 9:14 AM, Greg Keogh  wrote:
>>>
 Folks, we have a serious decision to make about the future directions
 of our 10 year old Silverlight product that is in wide use in some big
 companies. I told the boss I'd poll this forum for advice, so I'd really
 appreciate serious comments from people in-the-know.

 The large companies using the Silverlight product are now locking down
 security, so Internet Explorer is being banned and Edge adopted, which
 means Silverlight is out (some employees are already being forced to use
 the product from home). Our product is available as Xamarin authored tablet
 and phone apps for three platforms, but they won't even allow our apps on
 their company devices.

 So for the first time we are forced to produce a "browser based"
 version of our product, which apparently is acceptable to their security
 policies and audits. Here are some issues swirling in my head:

- The backend services to drive the product are established.
- The UIs of other product versions are explorer (master-detail)
style, so it would be nice to maintain that feel in the browser.
- We have to display data in Excel-like tables and a variety of
charts (the richer and more interactive the better).
- Should we use server-side ASP.NET Web Forms or MVC to drive it?
- Should it be browser-side SPA? (you know I hate JS everything, so
there is personal resistance there).
- Could server-side and browser-side be combined to produce a
better hybrid experience? Are there things to help you do that?
- There are development platforms such as GTK and many others I
guess that I'm not familiar with. Are they viable?
- Other issues I'm forgetting?


 I'm personally familiar with ASP.NET Web Forms and MVC, but not with
 quality JS, layout or styling. Perhaps I could write a black-and-white
 skeleton of the working product and then give it to someone to style and
 script (I have done that once before).

 So in summary (I know this is a very broad question) ... if you were in
 my position, how would you proceed to produce a browser based version of a
 product?

 Cheers,
 *Greg K*


>>>
>>
>

Re: Creating a browser-based product

[Craig van Nieuwkerk]

All the Angular (and almost every Js framework) tooling is built with Node,
so on you dev machines at least you are unlikely to be able to get away
from it. Going forward, unless you are planning on building something bare
bones with no framework I think there is not much chance of being able to
not have a dependency on Node.

https://i.redd.it/tfugj4n3l6ez.png

On Wed, Nov 29, 2017 at 9:21 AM, Greg Keogh  wrote:

> Folks, just a heads-up for the unprepared.
>
> Following a suggestion from Craig I used the command "dotnet new angular"
> to create a fresh Angular Visual Studio project. I've had no need to use
> .NET Core since it came out, so it's interesting to look at the help for
> the various options. The Angular project is generated with 45 files in 19
> folders. After you open it in VS2017 it runs a quiet frenzy of downloads
> into the node_modules folder, this produces 13478 files in 1715 folders
> containing roughly 1.7 million lines of JavaScript.
>
> Now pardon me ... but is this crazy?! What I mean is, is this typical of
> an Angular project or is the default project incompletely or incorrectly
> configured? It's like creating a .NET traditional project and having the
> complete Framework source code included. I don't recall any concept of a
> "compiled library" for JavaScript, so I'm guessing such a thing hasn't been
> invented yet, is that right?
>
> I tried running the project but after giving me 150 package conflict
> warnings it stops and tells me "Node.js is required to build and run this
> project". Now I'm confused, as why on earth would that be needed? I was
> hoping to avoid Node.js completely as the backend of our proposed app is a
> working WebApi.
>
> I will be posting a formal request in here soon for anyone who can help us
> develop a browser-based product.
>
> *Greg K*
>
> On 17 November 2017 at 10:13, Craig van Nieuwkerk 
> wrote:
>
>> If you backend services are well established and you could easily put a
>> WebAPI over them, then it makes sense to do a SPA and mainly Javascript
>> front end.
>>
>> If it is an enterprisey type app then it is hard to go past Angular,
>> Pluralsight is your friend to learn. I would also talk to ssw.com.au,
>> they have some good courses that will get you running in the right
>> direction quickly.
>>
>> Craig
>>
>> On Fri, Nov 17, 2017 at 9:14 AM, Greg Keogh  wrote:
>>
>>> Folks, we have a serious decision to make about the future directions of
>>> our 10 year old Silverlight product that is in wide use in some big
>>> companies. I told the boss I'd poll this forum for advice, so I'd really
>>> appreciate serious comments from people in-the-know.
>>>
>>> The large companies using the Silverlight product are now locking down
>>> security, so Internet Explorer is being banned and Edge adopted, which
>>> means Silverlight is out (some employees are already being forced to use
>>> the product from home). Our product is available as Xamarin authored tablet
>>> and phone apps for three platforms, but they won't even allow our apps on
>>> their company devices.
>>>
>>> So for the first time we are forced to produce a "browser based" version
>>> of our product, which apparently is acceptable to their security policies
>>> and audits. Here are some issues swirling in my head:
>>>
>>>- The backend services to drive the product are established.
>>>- The UIs of other product versions are explorer (master-detail)
>>>style, so it would be nice to maintain that feel in the browser.
>>>- We have to display data in Excel-like tables and a variety of
>>>charts (the richer and more interactive the better).
>>>- Should we use server-side ASP.NET Web Forms or MVC to drive it?
>>>- Should it be browser-side SPA? (you know I hate JS everything, so
>>>there is personal resistance there).
>>>- Could server-side and browser-side be combined to produce a better
>>>hybrid experience? Are there things to help you do that?
>>>- There are development platforms such as GTK and many others I
>>>guess that I'm not familiar with. Are they viable?
>>>- Other issues I'm forgetting?
>>>
>>>
>>> I'm personally familiar with ASP.NET Web Forms and MVC, but not with
>>> quality JS, layout or styling. Perhaps I could write a black-and-white
>>> skeleton of the working product and then give it to someone to style and
>>> script (I have done that once before).
>>>
>>> So in summary (I know this is a very broad question) ... if you were in
>>> my position, how would you proceed to produce a browser based version of a
>>> product?
>>>
>>> Cheers,
>>> *Greg K*
>>>
>>>
>>
>

Re: Creating a browser-based product

[Tony Wright]

Yes you need to install node js. And it's not just angular - it's
javascript in general. Node_modules is the destination for any javascript
libraries installed via the npm (node package manager).  You then reference
library scripts directly from their location under node_modules. These
aren't generally source controlled either. Javascript does get compiled to
.map files but that's as far as it goes.

On 29 Nov 2017 9:22 AM, "Greg Keogh"  wrote:

Folks, just a heads-up for the unprepared.

Following a suggestion from Craig I used the command "dotnet new angular"
to create a fresh Angular Visual Studio project. I've had no need to use
.NET Core since it came out, so it's interesting to look at the help for
the various options. The Angular project is generated with 45 files in 19
folders. After you open it in VS2017 it runs a quiet frenzy of downloads
into the node_modules folder, this produces 13478 files in 1715 folders
containing roughly 1.7 million lines of JavaScript.

Now pardon me ... but is this crazy?! What I mean is, is this typical of an
Angular project or is the default project incompletely or incorrectly
configured? It's like creating a .NET traditional project and having the
complete Framework source code included. I don't recall any concept of a
"compiled library" for JavaScript, so I'm guessing such a thing hasn't been
invented yet, is that right?

I tried running the project but after giving me 150 package conflict
warnings it stops and tells me "Node.js is required to build and run this
project". Now I'm confused, as why on earth would that be needed? I was
hoping to avoid Node.js completely as the backend of our proposed app is a
working WebApi.

I will be posting a formal request in here soon for anyone who can help us
develop a browser-based product.

*Greg K*

On 17 November 2017 at 10:13, Craig van Nieuwkerk  wrote:

> If you backend services are well established and you could easily put a
> WebAPI over them, then it makes sense to do a SPA and mainly Javascript
> front end.
>
> If it is an enterprisey type app then it is hard to go past Angular,
> Pluralsight is your friend to learn. I would also talk to ssw.com.au,
> they have some good courses that will get you running in the right
> direction quickly.
>
> Craig
>
> On Fri, Nov 17, 2017 at 9:14 AM, Greg Keogh  wrote:
>
>> Folks, we have a serious decision to make about the future directions of
>> our 10 year old Silverlight product that is in wide use in some big
>> companies. I told the boss I'd poll this forum for advice, so I'd really
>> appreciate serious comments from people in-the-know.
>>
>> The large companies using the Silverlight product are now locking down
>> security, so Internet Explorer is being banned and Edge adopted, which
>> means Silverlight is out (some employees are already being forced to use
>> the product from home). Our product is available as Xamarin authored tablet
>> and phone apps for three platforms, but they won't even allow our apps on
>> their company devices.
>>
>> So for the first time we are forced to produce a "browser based" version
>> of our product, which apparently is acceptable to their security policies
>> and audits. Here are some issues swirling in my head:
>>
>>- The backend services to drive the product are established.
>>- The UIs of other product versions are explorer (master-detail)
>>style, so it would be nice to maintain that feel in the browser.
>>- We have to display data in Excel-like tables and a variety of
>>charts (the richer and more interactive the better).
>>- Should we use server-side ASP.NET Web Forms or MVC to drive it?
>>- Should it be browser-side SPA? (you know I hate JS everything, so
>>there is personal resistance there).
>>- Could server-side and browser-side be combined to produce a better
>>hybrid experience? Are there things to help you do that?
>>- There are development platforms such as GTK and many others I guess
>>that I'm not familiar with. Are they viable?
>>- Other issues I'm forgetting?
>>
>>
>> I'm personally familiar with ASP.NET Web Forms and MVC, but not with
>> quality JS, layout or styling. Perhaps I could write a black-and-white
>> skeleton of the working product and then give it to someone to style and
>> script (I have done that once before).
>>
>> So in summary (I know this is a very broad question) ... if you were in
>> my position, how would you proceed to produce a browser based version of a
>> product?
>>
>> Cheers,
>> *Greg K*
>>
>>
>

Re: Creating a browser-based product

[Greg Keogh]

Folks, just a heads-up for the unprepared.

Following a suggestion from Craig I used the command "dotnet new angular"
to create a fresh Angular Visual Studio project. I've had no need to use
.NET Core since it came out, so it's interesting to look at the help for
the various options. The Angular project is generated with 45 files in 19
folders. After you open it in VS2017 it runs a quiet frenzy of downloads
into the node_modules folder, this produces 13478 files in 1715 folders
containing roughly 1.7 million lines of JavaScript.

Now pardon me ... but is this crazy?! What I mean is, is this typical of an
Angular project or is the default project incompletely or incorrectly
configured? It's like creating a .NET traditional project and having the
complete Framework source code included. I don't recall any concept of a
"compiled library" for JavaScript, so I'm guessing such a thing hasn't been
invented yet, is that right?

I tried running the project but after giving me 150 package conflict
warnings it stops and tells me "Node.js is required to build and run this
project". Now I'm confused, as why on earth would that be needed? I was
hoping to avoid Node.js completely as the backend of our proposed app is a
working WebApi.

I will be posting a formal request in here soon for anyone who can help us
develop a browser-based product.

*Greg K*

On 17 November 2017 at 10:13, Craig van Nieuwkerk  wrote:

> If you backend services are well established and you could easily put a
> WebAPI over them, then it makes sense to do a SPA and mainly Javascript
> front end.
>
> If it is an enterprisey type app then it is hard to go past Angular,
> Pluralsight is your friend to learn. I would also talk to ssw.com.au,
> they have some good courses that will get you running in the right
> direction quickly.
>
> Craig
>
> On Fri, Nov 17, 2017 at 9:14 AM, Greg Keogh  wrote:
>
>> Folks, we have a serious decision to make about the future directions of
>> our 10 year old Silverlight product that is in wide use in some big
>> companies. I told the boss I'd poll this forum for advice, so I'd really
>> appreciate serious comments from people in-the-know.
>>
>> The large companies using the Silverlight product are now locking down
>> security, so Internet Explorer is being banned and Edge adopted, which
>> means Silverlight is out (some employees are already being forced to use
>> the product from home). Our product is available as Xamarin authored tablet
>> and phone apps for three platforms, but they won't even allow our apps on
>> their company devices.
>>
>> So for the first time we are forced to produce a "browser based" version
>> of our product, which apparently is acceptable to their security policies
>> and audits. Here are some issues swirling in my head:
>>
>>- The backend services to drive the product are established.
>>- The UIs of other product versions are explorer (master-detail)
>>style, so it would be nice to maintain that feel in the browser.
>>- We have to display data in Excel-like tables and a variety of
>>charts (the richer and more interactive the better).
>>- Should we use server-side ASP.NET Web Forms or MVC to drive it?
>>- Should it be browser-side SPA? (you know I hate JS everything, so
>>there is personal resistance there).
>>- Could server-side and browser-side be combined to produce a better
>>hybrid experience? Are there things to help you do that?
>>- There are development platforms such as GTK and many others I guess
>>that I'm not familiar with. Are they viable?
>>- Other issues I'm forgetting?
>>
>>
>> I'm personally familiar with ASP.NET Web Forms and MVC, but not with
>> quality JS, layout or styling. Perhaps I could write a black-and-white
>> skeleton of the working product and then give it to someone to style and
>> script (I have done that once before).
>>
>> So in summary (I know this is a very broad question) ... if you were in
>> my position, how would you proceed to produce a browser based version of a
>> product?
>>
>> Cheers,
>> *Greg K*
>>
>>
>

RE: Creating a browser-based product

[Ken Schaefer]

Well, I guess from VMWare’s PoV – they weren’t consulted or involved, have no 
idea how the thing was built, so why would you commit to supporting or 
certifying it?

On the other hand, there’s various other parties that involved VMWare formally, 
and their platforms are certified – AWS and IBM spring to mind:
https://cloud.vmware.com/vmc-aws
https://www.ibm.com/cloud/vmware


From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of mike smith
Sent: Friday, 24 November 2017 8:59 AM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: Re: Creating a browser-based product

https://www.itnews.com.au/news/microsofts-vmware-azure-stack-neither-certified-nor-supported-478352?eid=1=20171124_source=20171124_AM_medium=newsletter_campaign=daily_newsletter

But yeah, VMware would say that, I guess.

On Wed, Nov 22, 2017 at 5:12 PM, David Connors 
<da...@connors.com<mailto:da...@connors.com>> wrote:
On Wed, 22 Nov 2017 at 12:43 Ken Schaefer 
<k...@adopenstatic.com<mailto:k...@adopenstatic.com>> wrote:
I haven’t seen the latest list, but my current (and previous two) employer was 
on the list a couple of years ago. And whilst we can probably get hardware 
pretty cheap, that’s not the bulk of the cost of running something on-premise. 
Talking about hardware costs is talking about the wrong thing. I’m not saying 
that cloud is cheaper (it probably isn’t), but it gives you agility and 
flexibility, and time-is-money.

Correct; and I have come to be 180 degree opposed to where I was on cloud 5-6 
years ago.

It is very easy for the anti-cloud people to point to a piece of tin and say 
'that hardware was $400K and it lasts us 3-4 years'. It is much harder to point 
to all of the operational staff costs, downtime from hardware not being run 
properly, full suites of ops software that are just built into cloud solutions.

I could stand you up a global data centre in Azure with BGP routing and all the 
active fail over DR you want in a couple of hours. Try doing that with tin and 
wan service providers.

The article says:
"First and foremost, Fortune 500-size corporations that can’t negotiate pricing 
for servers and storage comparable to what Amazon and Microsoft pay for the 
gear they use to run AWS and Azure just aren’t trying very hard. They have 
access to the same technology management tools, practices, and talent, too."

Which is just bullshit for IaaS and REALLY bullshit for PaaS solutions like 
Azure SQL Database.

--
David Connors
da...@connors.com<mailto:da...@connors.com> | @davidconnors | 
https://t.me/davidconnors | LinkedIn | +61 417 189 363

Re: Creating a browser-based product

[mike smith]

https://www.itnews.com.au/news/microsofts-vmware-azure-stack-neither-certified-nor-supported-478352?eid=1=20171124_source=20171124_AM_medium=newsletter_campaign=daily_newsletter

But yeah, VMware would say that, I guess.


On Wed, Nov 22, 2017 at 5:12 PM, David Connors  wrote:

> On Wed, 22 Nov 2017 at 12:43 Ken Schaefer  wrote:
>
>> I haven’t seen the latest list, but my current (and previous two)
>> employer was on the list a couple of years ago. And whilst we can probably
>> get hardware pretty cheap, that’s not the bulk of the cost of running
>> something on-premise. Talking about hardware costs is talking about the
>> wrong thing. I’m not saying that cloud is cheaper (it probably isn’t), but
>> it gives you agility and flexibility, and time-is-money.
>>
>
> Correct; and I have come to be 180 degree opposed to where I was on cloud
> 5-6 years ago.
>
> It is very easy for the anti-cloud people to point to a piece of tin and
> say 'that hardware was $400K and it lasts us 3-4 years'. It is much harder
> to point to all of the operational staff costs, downtime from hardware not
> being run properly, full suites of ops software that are just built into
> cloud solutions.
>
> I could stand you up a global data centre in Azure with BGP routing and
> all the active fail over DR you want in a couple of hours. Try doing that
> with tin and wan service providers.
>
> The article says:
> *"First and foremost, Fortune 500-size corporations that can’t negotiate
> pricing for servers and storage comparable to what Amazon and Microsoft pay
> for the gear they use to run AWS and Azure just aren’t trying very hard.
> They have access to the same technology management tools, practices, and
> talent, too."*
>
> Which is just bullshit for IaaS and REALLY bullshit for PaaS solutions
> like Azure SQL Database.
>
> --
> David Connors
> da...@connors.com | @davidconnors | https://t.me/davidconnors | LinkedIn
>  | +61 417 189 363
>



-- 
Meski

 http://courteous.ly/aAOZcv

"Going to Starbucks for coffee is like going to prison for sex. Sure,
you'll get it, but it's going to be rough" - Adam Hills

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 <da...@connors.com> 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, <tonyw...@gmail.com> 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" <k...@adopenstatic.com> 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 <ozdotnet@ozdotnet.com>
>>> *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 <ozdotnet@ozdotnet.com>
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.

Re: Creating a browser-based product

[Tony Wright]

It will keep us in a job for a few years longer!

On 22 Nov 2017 5:16 PM, "Greg Keogh"  wrote:

> Sorry, another Greg rant to follow…
>>
>
> I'm somewhat comforted that I might not be completely mad or grumpy.
>
> Yes, really! It's 2017, and the best way to distribute an app is to
> clumsily cobble together HTML, CSS and JavaScript and cram it into a web
> browser. There is no duplex communication, no rich UI design, we can't even
> pick which development kit to use, app appearance and behaviour is
> inconsistent, JavaScript is someone's hobby mess that we need to generate
> it or build other languages over just to make it writable ... and so on to
> repeat myself.
>
> The current state of distributed app development using "the web" is a
> joke. After 25 years I can't see anything to replace it. The web is still
> barely better than tin cans with strings.
>
> The mobile world is a similar problem due to the three competing
> ecosystems which use different tools, standards, UIs and company cultures.
> It's nice of Xamarin to attempt to plug this gap, but it's barely working.
>
> Software development is such a stinking mess that I'd retire now in
> disgust if I could. I've said before that my gravestone will read
> "Everything F***ing Doesn't Work".
>
> *Greg K*
>

Re: Creating a browser-based product

[Greg Keogh]

>
> Sorry, another Greg rant to follow…
>

I'm somewhat comforted that I might not be completely mad or grumpy.

Yes, really! It's 2017, and the best way to distribute an app is to
clumsily cobble together HTML, CSS and JavaScript and cram it into a web
browser. There is no duplex communication, no rich UI design, we can't even
pick which development kit to use, app appearance and behaviour is
inconsistent, JavaScript is someone's hobby mess that we need to generate
it or build other languages over just to make it writable ... and so on to
repeat myself.

The current state of distributed app development using "the web" is a joke.
After 25 years I can't see anything to replace it. The web is still barely
better than tin cans with strings.

The mobile world is a similar problem due to the three competing ecosystems
which use different tools, standards, UIs and company cultures. It's nice
of Xamarin to attempt to plug this gap, but it's barely working.

Software development is such a stinking mess that I'd retire now in disgust
if I could. I've said before that my gravestone will read "Everything
F***ing Doesn't Work".

*Greg K*

Re: Creating a browser-based product

[David Connors]

On Wed, 22 Nov 2017 at 12:43 Ken Schaefer  wrote:

> I haven’t seen the latest list, but my current (and previous two) employer
> was on the list a couple of years ago. And whilst we can probably get
> hardware pretty cheap, that’s not the bulk of the cost of running something
> on-premise. Talking about hardware costs is talking about the wrong thing.
> I’m not saying that cloud is cheaper (it probably isn’t), but it gives you
> agility and flexibility, and time-is-money.
>

Correct; and I have come to be 180 degree opposed to where I was on cloud
5-6 years ago.

It is very easy for the anti-cloud people to point to a piece of tin and
say 'that hardware was $400K and it lasts us 3-4 years'. It is much harder
to point to all of the operational staff costs, downtime from hardware not
being run properly, full suites of ops software that are just built into
cloud solutions.

I could stand you up a global data centre in Azure with BGP routing and all
the active fail over DR you want in a couple of hours. Try doing that with
tin and wan service providers.

The article says:
*"First and foremost, Fortune 500-size corporations that can’t negotiate
pricing for servers and storage comparable to what Amazon and Microsoft pay
for the gear they use to run AWS and Azure just aren’t trying very hard.
They have access to the same technology management tools, practices, and
talent, too."*

Which is just bullshit for IaaS and REALLY bullshit for PaaS solutions like
Azure SQL Database.

-- 
David Connors
da...@connors.com | @davidconnors | https://t.me/davidconnors | LinkedIn | +61
417 189 363

Re: Creating a browser-based product

[Tony Wright]

Ha! In fact I'd say we've gone backwards. We're back to directly
interacting with configuration files and running from the command line for
everything because someone said that was what smart developers do. Yea,
like memorising a few command lines for something though hardly ever do
somehow makes one smarter.

On 22 Nov 2017 3:43 PM, "Greg Harris" <harris.gre...@gmail.com> wrote:

> Sorry, another Greg rant to follow…
>
>
> Web based apps are a slightly better form of dumb terminal app that you
> could have had running on your DEC VT-100 (https://en.wikipedia.org/
> wiki/VT100) or IBM 3270 (https://en.wikipedia.org/wiki/IBM_3270) terminal
> in the 1980’s.  I first used a VT-100 in 1979, the modern browser has added
> graphics and Javascript.  We have not moved that far forward in 38 years!
>
>
> I have used reasonable interactive programs on VT-100 and 3270 terminals,
> but programs that use the full power of the client machine’s power, provide
> a significantly improved end user computing experience.
>
>
> 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.
>
>
> 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.
>
>
> Look at compute intensive apps like 3D modelling or video editing, they
> could never be done properly with today’s browser technology!
>
>
> Web Assembly (https://en.wikipedia.org/wiki/WebAssembly) may be a logical
> sandboxed solution to these problems.  But I see Web Assembly as an
> immature technology that needs evolution to be production application ready.
>
>
> In the meantime, I will continue to program as much as I can, with as much
> of the logic as possible running on the server where I have 100% control.
> The client can ask for additional chunks of UI (html) to be sent down the
> wire (AJAX) and I will avoid as much logic as possible in the client UI.
>
>
> Or maybe even a win forms app, because it is fast, I have 100% control *and
> it is not really that hard to install*!
>
>
> Silverlight looked like such a logical solution to this problem.  Ten
> years after Silverlight, we are not yet at the point where we can provide a
> solution anywhere near as good.
>
>
> Frankly when I look at the way this technology has moved in the last 20
> years, I am very *VERY* disappointed by our industry!
>
>
> All the best
>
> Greg Harris
>
>
>
> On Wed, Nov 22, 2017 at 3:34 PM, Tony Wright <tonyw...@gmail.com> wrote:
>
>> Well in the javascript world we don't have dll hell so much anymore, we
>> have package hell.
>>
>> On 22 Nov 2017 2:43 PM, "Ken Schaefer" <k...@adopenstatic.com> wrote:
>>
>>> Inline
>>>
>>>
>>>
>>> *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@ozdot
>>> net.com] *On Behalf Of *Greg Low
>>> *Sent:* Wednesday, 22 November 2017 2:09 PM
>>> *To:* ozDotNet <ozdotnet@ozdotnet.com>
>>> *Subject:* Re: Creating a browser-based product
>>>
>>>
>>>
>>> Agreed but you’re running it in the environment provided by your thick
>>> client (ie the browser) which you did already deploy and which continues to
>>> be patched.
>>>
>>>
>>>
>>> I didn’t say thick clients don’t work – I said that they don’t work “at
>>> scale”
>>>
>>> If you have just one, (or maybe two or three) clients, then life is
>>> manageable.
>>>
>>>
>>>
>>> The browser provides a kludgy sandbox for apps to run in. The browser
>>> was never designed for this purpose and does it pretty poorly. Surely we
>>> could have had a better purpose built sandbox.
>>>
>>>
>>>
>>> Then we’re back to something David touched on earlier. The idea that a
>>> small group of people can build a universally used system, that will work
>>> for the varied use cases of the entire world, both now and into the future,
>>> resulted in something we call “Microsoft Windows”. Think of this as a
>>> centrally planned economy
>>>
>>>
>>>
>>> The only other alternative we have is an imperfect, un-optimised,
>>> de-centrally built system, like web delivered apps that run in browsers.
>>> Think of this as “the invisible hand of the free market”
>>>
>>>
>>>
>>&

Re: Creating a browser-based product

[Greg Harris]

Sorry, another Greg rant to follow…


Web based apps are a slightly better form of dumb terminal app that you
could have had running on your DEC VT-100 (
https://en.wikipedia.org/wiki/VT100) or IBM 3270 (
https://en.wikipedia.org/wiki/IBM_3270) terminal in the 1980’s.  I first
used a VT-100 in 1979, the modern browser has added graphics and
Javascript.  We have not moved that far forward in 38 years!


I have used reasonable interactive programs on VT-100 and 3270 terminals,
but programs that use the full power of the client machine’s power, provide
a significantly improved end user computing experience.


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.


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.


Look at compute intensive apps like 3D modelling or video editing, they
could never be done properly with today’s browser technology!


Web Assembly (https://en.wikipedia.org/wiki/WebAssembly) may be a logical
sandboxed solution to these problems.  But I see Web Assembly as an
immature technology that needs evolution to be production application ready.


In the meantime, I will continue to program as much as I can, with as much
of the logic as possible running on the server where I have 100% control.
The client can ask for additional chunks of UI (html) to be sent down the
wire (AJAX) and I will avoid as much logic as possible in the client UI.


Or maybe even a win forms app, because it is fast, I have 100% control *and
it is not really that hard to install*!


Silverlight looked like such a logical solution to this problem.  Ten years
after Silverlight, we are not yet at the point where we can provide a
solution anywhere near as good.


Frankly when I look at the way this technology has moved in the last 20
years, I am very *VERY* disappointed by our industry!


All the best

Greg Harris



On Wed, Nov 22, 2017 at 3:34 PM, Tony Wright <tonyw...@gmail.com> wrote:

> Well in the javascript world we don't have dll hell so much anymore, we
> have package hell.
>
> On 22 Nov 2017 2:43 PM, "Ken Schaefer" <k...@adopenstatic.com> wrote:
>
>> Inline
>>
>>
>>
>> *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@ozdot
>> net.com] *On Behalf Of *Greg Low
>> *Sent:* Wednesday, 22 November 2017 2:09 PM
>> *To:* ozDotNet <ozdotnet@ozdotnet.com>
>> *Subject:* Re: Creating a browser-based product
>>
>>
>>
>> Agreed but you’re running it in the environment provided by your thick
>> client (ie the browser) which you did already deploy and which continues to
>> be patched.
>>
>>
>>
>> I didn’t say thick clients don’t work – I said that they don’t work “at
>> scale”
>>
>> If you have just one, (or maybe two or three) clients, then life is
>> manageable.
>>
>>
>>
>> The browser provides a kludgy sandbox for apps to run in. The browser was
>> never designed for this purpose and does it pretty poorly. Surely we could
>> have had a better purpose built sandbox.
>>
>>
>>
>> Then we’re back to something David touched on earlier. The idea that a
>> small group of people can build a universally used system, that will work
>> for the varied use cases of the entire world, both now and into the future,
>> resulted in something we call “Microsoft Windows”. Think of this as a
>> centrally planned economy
>>
>>
>>
>> The only other alternative we have is an imperfect, un-optimised,
>> de-centrally built system, like web delivered apps that run in browsers.
>> Think of this as “the invisible hand of the free market”
>>
>>
>>
>> I think the real free market has spoken as to what model it finds more
>> attractive, regardless of its imperfections.
>>
>>
>>
>>
>>
>> Regards,
>>
>>
>>
>> Greg
>>
>>
>>
>> Dr Greg Low
>>
>> 1300SQLSQL (1300 775 775) office | +61 419201410 <+61%20419%20201%20410>
>> mobile│ +61 3 8676 4913 <+61%203%208676%204913> fax
>>
>> SQL Down Under | Web: www.sqldownunder.com
>> --
>>
>> *From:* ozdotnet-boun...@ozdotnet.com <ozdotnet-boun...@ozdotnet.com> on
>> behalf of Ken Schaefer <k...@adopenstatic.com>
>> *Sent:* Wednesday, November 22, 2017 2:00:21 PM
>> *To:* ozDotNet
>> *Subject:* RE: Creating a browser-based product
>>
>>
>>
>> I think people have been l

RE: Creating a browser-based product

[Tony Wright]

Well in the javascript world we don't have dll hell so much anymore, we
have package hell.

On 22 Nov 2017 2:43 PM, "Ken Schaefer" <k...@adopenstatic.com> wrote:

> Inline
>
>
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@
> ozdotnet.com] *On Behalf Of *Greg Low
> *Sent:* Wednesday, 22 November 2017 2:09 PM
> *To:* ozDotNet <ozdotnet@ozdotnet.com>
> *Subject:* Re: Creating a browser-based product
>
>
>
> Agreed but you’re running it in the environment provided by your thick
> client (ie the browser) which you did already deploy and which continues to
> be patched.
>
>
>
> I didn’t say thick clients don’t work – I said that they don’t work “at
> scale”
>
> If you have just one, (or maybe two or three) clients, then life is
> manageable.
>
>
>
> The browser provides a kludgy sandbox for apps to run in. The browser was
> never designed for this purpose and does it pretty poorly. Surely we could
> have had a better purpose built sandbox.
>
>
>
> Then we’re back to something David touched on earlier. The idea that a
> small group of people can build a universally used system, that will work
> for the varied use cases of the entire world, both now and into the future,
> resulted in something we call “Microsoft Windows”. Think of this as a
> centrally planned economy
>
>
>
> The only other alternative we have is an imperfect, un-optimised,
> de-centrally built system, like web delivered apps that run in browsers.
> Think of this as “the invisible hand of the free market”
>
>
>
> I think the real free market has spoken as to what model it finds more
> attractive, regardless of its imperfections.
>
>
>
>
>
> Regards,
>
>
>
> Greg
>
>
>
> Dr Greg Low
>
> 1300SQLSQL (1300 775 775) office | +61 419201410 <+61%20419%20201%20410>
> mobile│ +61 3 8676 4913 <+61%203%208676%204913> fax
>
> SQL Down Under | Web: www.sqldownunder.com
> --------------
>
> *From:* ozdotnet-boun...@ozdotnet.com <ozdotnet-boun...@ozdotnet.com> on
> behalf of Ken Schaefer <k...@adopenstatic.com>
> *Sent:* Wednesday, November 22, 2017 2:00:21 PM
> *To:* ozDotNet
> *Subject:* RE: Creating a browser-based product
>
>
>
> I think people have been looking to make deployment viable, and we’ve
> ended up at the best solution we’ve been able to come up with. A server
> delivers text to a pre-installed presentation/execution engine
>
>
>
> Offline document editing: what do I need to deploy to get that working? It
> works within the existing client I already have, doesn’t it?
>
>
>
>
>
>
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@
> ozdotnet.com <ozdotnet-boun...@ozdotnet.com>] *On Behalf Of *Greg Low
> *Sent:* Wednesday, 22 November 2017 1:35 PM
> *To:* ozDotNet <ozdotnet@ozdotnet.com>
> *Subject:* RE: Creating a browser-based product
>
>
>
> Lots of people tried to fix deployment of thick client apps, but the
> dependencies of those were such a mess. In fact, I’d largely blame
> Microsoft for that. Breaking out DLLs separately, having them initially
> identified only by name (even across versions), and then putting them in
> the same folder. What could possibly go wrong with that?
>
>
>
> It’s not that it’s just deployment. Couldn’t we have come up with an app
> building strategy where deployment was easy? I’m not suggesting making
> deployment of the existing ones easy. I’m saying designing for ease of
> deployment.
>
>
>
> And if Google was 100% happy with email in the browser, they wouldn’t have
> responded by adding offline editing of the documents (which is just another
> form of thick client).
>
>
>
> Regards,
>
>
>
> Greg
>
>
>
>
>
>
>
>

Re: Creating a browser-based product

[Greg Low]

Agreed but you’re running it in the environment provided by your thick client 
(ie the browser) which you did already deploy and which continues to be patched.

The browser provides a kludgy sandbox for apps to run in. The browser was never 
designed for this purpose and does it pretty poorly. Surely we could have had a 
better purpose built sandbox.

Regards,

Greg

Dr Greg Low
1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax
SQL Down Under | Web: www.sqldownunder.com

From: ozdotnet-boun...@ozdotnet.com <ozdotnet-boun...@ozdotnet.com> on behalf 
of Ken Schaefer <k...@adopenstatic.com>
Sent: Wednesday, November 22, 2017 2:00:21 PM
To: ozDotNet
Subject: RE: Creating a browser-based product

I think people have been looking to make deployment viable, and we’ve ended up 
at the best solution we’ve been able to come up with. A server delivers text to 
a pre-installed presentation/execution engine

Offline document editing: what do I need to deploy to get that working? It 
works within the existing client I already have, doesn’t it?



From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Low
Sent: Wednesday, 22 November 2017 1:35 PM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: RE: Creating a browser-based product

Lots of people tried to fix deployment of thick client apps, but the 
dependencies of those were such a mess. In fact, I’d largely blame Microsoft 
for that. Breaking out DLLs separately, having them initially identified only 
by name (even across versions), and then putting them in the same folder. What 
could possibly go wrong with that?

It’s not that it’s just deployment. Couldn’t we have come up with an app 
building strategy where deployment was easy? I’m not suggesting making 
deployment of the existing ones easy. I’m saying designing for ease of 
deployment.

And if Google was 100% happy with email in the browser, they wouldn’t have 
responded by adding offline editing of the documents (which is just another 
form of thick client).

Regards,

Greg


From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>] On 
Behalf Of Ken Schaefer
Sent: Wednesday, 22 November 2017 1:28 PM
To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
Subject: RE: Creating a browser-based product

Deployment is part of TCO, and the TCO sucks when you have lots and lots of 
thick client apps. And you can’t just say “that’s deployment” – lots of people 
have tried to solve the deployment problem, and no one has.

Web-based isn’t driven by “IT sick of deploying apps” – web based is driven by 
the people who pay the bills.
Whether that be the buyer, or the producer.  Google sees no value in writing a 
thick-client email client, and CIOs see Gmail as working just fine without one.


From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Low
Sent: Tuesday, 21 November 2017 7:26 PM
To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
Subject: Re: Creating a browser-based product

Again all of that is largely about deployment Ken. Yes thick client apps were a 
pain in the neck to test and deploy. But surely we could have improved the dev 
experience even further, while building something trivial to deploy. Web apps 
were largely driven by IT admin folk who were sick of trying to test and deploy 
apps. But for example, if you sat a user in front of say Outlook thick client 
and the Outlook web apps, it’d be a rare person who’d choose the web version 
for the UI. And how many business apps are built better than Outlook OWA? It’s 
not great but it’s better than the web based business apps in most companies.

Regards,

Greg

Dr Greg Low
1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax
SQL Down Under | Web: www.sqldownunder.com<http://www.sqldownunder.com>

On Tue, Nov 21, 2017 at 7:11 PM +1100, "Ken Schaefer" 
<k...@adopenstatic.com<mailto:k...@adopenstatic.com>> wrote:
We used to have everything as thick-client apps. And then every time we had to 
upgrade an OS, we have to regression test, and sociability test 1000+ apps. 
That’s a huge waste of time.
Then there’s the deployment issues of pushing thousands of apps out to 
thousands/tens of thousands/hundreds of thousands of endpoints.

When you talk about building a LoB app – well, that works when you have 1, or 2 
apps. It doesn’t scale.

Instead, we’re now using a browser as a virtual OS (with hardware, networking 
etc. abstracted away to the real OS), with an application UI and some logic 
delivered as text at run-time, and the non-GUI parts centralised.

And when we look at all the possible ways of building apps, and the choices 
being made by both deve

RE: Creating a browser-based product

[Ken Schaefer]

I think people have been looking to make deployment viable, and we’ve ended up 
at the best solution we’ve been able to come up with. A server delivers text to 
a pre-installed presentation/execution engine

Offline document editing: what do I need to deploy to get that working? It 
works within the existing client I already have, doesn’t it?



From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Low
Sent: Wednesday, 22 November 2017 1:35 PM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: RE: Creating a browser-based product

Lots of people tried to fix deployment of thick client apps, but the 
dependencies of those were such a mess. In fact, I’d largely blame Microsoft 
for that. Breaking out DLLs separately, having them initially identified only 
by name (even across versions), and then putting them in the same folder. What 
could possibly go wrong with that?

It’s not that it’s just deployment. Couldn’t we have come up with an app 
building strategy where deployment was easy? I’m not suggesting making 
deployment of the existing ones easy. I’m saying designing for ease of 
deployment.

And if Google was 100% happy with email in the browser, they wouldn’t have 
responded by adding offline editing of the documents (which is just another 
form of thick client).

Regards,

Greg


From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>] On 
Behalf Of Ken Schaefer
Sent: Wednesday, 22 November 2017 1:28 PM
To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
Subject: RE: Creating a browser-based product

Deployment is part of TCO, and the TCO sucks when you have lots and lots of 
thick client apps. And you can’t just say “that’s deployment” – lots of people 
have tried to solve the deployment problem, and no one has.

Web-based isn’t driven by “IT sick of deploying apps” – web based is driven by 
the people who pay the bills.
Whether that be the buyer, or the producer.  Google sees no value in writing a 
thick-client email client, and CIOs see Gmail as working just fine without one.


From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Low
Sent: Tuesday, 21 November 2017 7:26 PM
To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
Subject: Re: Creating a browser-based product

Again all of that is largely about deployment Ken. Yes thick client apps were a 
pain in the neck to test and deploy. But surely we could have improved the dev 
experience even further, while building something trivial to deploy. Web apps 
were largely driven by IT admin folk who were sick of trying to test and deploy 
apps. But for example, if you sat a user in front of say Outlook thick client 
and the Outlook web apps, it’d be a rare person who’d choose the web version 
for the UI. And how many business apps are built better than Outlook OWA? It’s 
not great but it’s better than the web based business apps in most companies.

Regards,

Greg

Dr Greg Low
1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax
SQL Down Under | Web: www.sqldownunder.com<http://www.sqldownunder.com>

On Tue, Nov 21, 2017 at 7:11 PM +1100, "Ken Schaefer" 
<k...@adopenstatic.com<mailto:k...@adopenstatic.com>> wrote:
We used to have everything as thick-client apps. And then every time we had to 
upgrade an OS, we have to regression test, and sociability test 1000+ apps. 
That’s a huge waste of time.
Then there’s the deployment issues of pushing thousands of apps out to 
thousands/tens of thousands/hundreds of thousands of endpoints.

When you talk about building a LoB app – well, that works when you have 1, or 2 
apps. It doesn’t scale.

Instead, we’re now using a browser as a virtual OS (with hardware, networking 
etc. abstracted away to the real OS), with an application UI and some logic 
delivered as text at run-time, and the non-GUI parts centralised.

And when we look at all the possible ways of building apps, and the choices 
being made by both developers of apps, and buyers of apps, it seems the 
market’s been pretty unequivocal about the preferred method.

Why it’s not much better/faster than before, is probably down to immaturity. If 
you want an app that does something that we were able to do 20 years ago, then 
that’s trivial to implement. But what the market wants is apps to do things 
that haven’t been done before.

From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Low
Sent: Tuesday, 21 November 2017 5:51 PM
To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
Subject: RE: Creating a browser-based product

But when a business just wants a line of business app, are these good answers 
now? Do th

RE: Creating a browser-based product

[Ken Schaefer]

I haven’t seen the latest list, but my current (and previous two) employer was 
on the list a couple of years ago. And whilst we can probably get hardware 
pretty cheap, that’s not the bulk of the cost of running something on-premise. 
Talking about hardware costs is talking about the wrong thing. I’m not saying 
that cloud is cheaper (it probably isn’t), but it gives you agility and 
flexibility, and time-is-money.

The article also doesn’t address the rate of investment required to ensure you 
keep up-to-date with what AWS and Azure bring to the table. Figuring out what 
to buy, how to buy it, how to deploy it, and do it all in a way that makes 
commercial and technical sense is really, really hard. Doing it “at speed” is 
even harder. Doing it in context of the complexity of a Fortune 500 company is 
almost impossible to do with the skills/resources we have internally. That’s 
why we pay specialists to do it for us. Infrastructure is no different in this 
respect to many other services we buy from external specialists.


From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of mike smith
Sent: Tuesday, 21 November 2017 10:18 PM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: RE: Creating a browser-based product

http://issurvivor.com/2017/11/20/opinionization-in-the-cloud/

On 21 Nov. 2017 22:15, "mike smith" 
<meski...@gmail.com<mailto:meski...@gmail.com>> wrote:
Browsers as virtual OSes, or VMs themselves as virtual environments to separate 
the applications or services?

I was reading an article suggesting that fortune 500 companies that bought 
Amazon, MS style cloud services were being lazy, and should be building their 
own.

I'll look up the link

On 21 Nov. 2017 19:11, "Ken Schaefer" 
<k...@adopenstatic.com<mailto:k...@adopenstatic.com>> wrote:
We used to have everything as thick-client apps. And then every time we had to 
upgrade an OS, we have to regression test, and sociability test 1000+ apps. 
That’s a huge waste of time.
Then there’s the deployment issues of pushing thousands of apps out to 
thousands/tens of thousands/hundreds of thousands of endpoints.

When you talk about building a LoB app – well, that works when you have 1, or 2 
apps. It doesn’t scale.

Instead, we’re now using a browser as a virtual OS (with hardware, networking 
etc. abstracted away to the real OS), with an application UI and some logic 
delivered as text at run-time, and the non-GUI parts centralised.

And when we look at all the possible ways of building apps, and the choices 
being made by both developers of apps, and buyers of apps, it seems the 
market’s been pretty unequivocal about the preferred method.

Why it’s not much better/faster than before, is probably down to immaturity. If 
you want an app that does something that we were able to do 20 years ago, then 
that’s trivial to implement. But what the market wants is apps to do things 
that haven’t been done before.

From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>] On 
Behalf Of Greg Low
Sent: Tuesday, 21 November 2017 5:51 PM
To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
Subject: RE: Creating a browser-based product

But when a business just wants a line of business app, are these good answers 
now? Do they care if it could be used by billions of people? The odd one might 
care. Most won’t.

Won’t they be more concerned with taking 6 or 8 times longer, and costing 
proportionately more?

Not every app is at the high-end. Most aren’t.

And now I watch daily nightmares around deploying web apps too.

What exactly have we done to ourselves?

Regards,

Greg

Dr Greg Low

1300SQLSQL (1300 775 775<tel:1300%20775%20775>) office | +61 
419201410<tel:0419%20201%20410> mobile│ +61 3 8676 4913<tel:(03)%208676%204913> 
fax
SQL Down Under | Web: www.sqldownunder.com<http://www.sqldownunder.com/> 
|http://greglow.me<http://greglow.me/>


From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>] On 
Behalf Of Craig van Nieuwkerk
Sent: Tuesday, 21 November 2017 4:46 PM
To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
Subject: Re: Creating a browser-based product

I'm not sure this is much more of an issue now than it was. Back in the day we 
had to decide between Delphi, VB, Powerbuilder, C++ among others when building 
a Windows app. And once we decided that we had to work out which third party 
libraries we wanted to use with them.

If I take an old 15 year old Delphi app I have it would take me the best part 
of a week to get it compiling again now if I had to build the dev machine from 
scratch.

On Tue, Nov 21, 2017 at 3:53 PM, Greg Low 
<g...@greglow.com<mailto:g...@greg

RE: Creating a browser-based product

[Greg Low]

Lots of people tried to fix deployment of thick client apps, but the
dependencies of those were such a mess. In fact, I’d largely blame
Microsoft for that. Breaking out DLLs separately, having them initially
identified only by name (even across versions), and then putting them in
the same folder. What could possibly go wrong with that?



It’s not that it’s just deployment. Couldn’t we have come up with an app
building strategy where deployment was easy? I’m not suggesting making
deployment of the existing ones easy. I’m saying designing for ease of
deployment.



And if Google was 100% happy with email in the browser, they wouldn’t have
responded by adding offline editing of the documents (which is just another
form of thick client).



Regards,



Greg





*From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
*On Behalf Of *Ken Schaefer
*Sent:* Wednesday, 22 November 2017 1:28 PM
*To:* ozDotNet <ozdotnet@ozdotnet.com>
*Subject:* RE: Creating a browser-based product



Deployment is part of TCO, and the TCO sucks when you have lots and lots of
thick client apps. And you can’t just say “that’s deployment” – lots of
people have tried to solve the deployment problem, and no one has.



Web-based isn’t driven by “IT sick of deploying apps” – web based is driven
by the people who pay the bills.

Whether that be the buyer, or the producer.  Google sees no value in
writing a thick-client email client, and CIOs see Gmail as working just
fine without one.





*From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com
<ozdotnet-boun...@ozdotnet.com>] *On Behalf Of *Greg Low
*Sent:* Tuesday, 21 November 2017 7:26 PM
*To:* ozDotNet <ozdotnet@ozdotnet.com>
*Subject:* Re: Creating a browser-based product



Again all of that is largely about deployment Ken. Yes thick client apps
were a pain in the neck to test and deploy. But surely we could have
improved the dev experience even further, while building something trivial
to deploy. Web apps were largely driven by IT admin folk who were sick of
trying to test and deploy apps. But for example, if you sat a user in front
of say Outlook thick client and the Outlook web apps, it’d be a rare person
who’d choose the web version for the UI. And how many business apps are
built better than Outlook OWA? It’s not great but it’s better than the web
based business apps in most companies.



Regards,



Greg



Dr Greg Low

1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax

SQL Down Under | Web: www.sqldownunder.com



On Tue, Nov 21, 2017 at 7:11 PM +1100, "Ken Schaefer" <k...@adopenstatic.com>
wrote:

We used to have everything as thick-client apps. And then every time we had
to upgrade an OS, we have to regression test, and sociability test 1000+
apps. That’s a huge waste of time.

Then there’s the deployment issues of pushing thousands of apps out to
thousands/tens of thousands/hundreds of thousands of endpoints.



When you talk about building a LoB app – well, that works when you have 1,
or 2 apps. It doesn’t scale.



Instead, we’re now using a browser as a virtual OS (with hardware,
networking etc. abstracted away to the real OS), with an application UI and
some logic delivered as text at run-time, and the non-GUI parts centralised.



And when we look at all the possible ways of building apps, and the choices
being made by both developers of apps, and buyers of apps, it seems the
market’s been pretty unequivocal about the preferred method.



Why it’s not much better/faster than before, is probably down to
immaturity. If you want an app that does something that we were able to do
20 years ago, then that’s trivial to implement. But what the market wants
is apps to do things that haven’t been done before.



*From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com
<ozdotnet-boun...@ozdotnet.com>] *On Behalf Of *Greg Low
*Sent:* Tuesday, 21 November 2017 5:51 PM
*To:* ozDotNet <ozdotnet@ozdotnet.com>
*Subject:* RE: Creating a browser-based product



But when a business just wants a line of business app, are these good
answers now? Do they care if it could be used by billions of people? The
odd one might care. Most won’t.



Won’t they be more concerned with taking 6 or 8 times longer, and costing
proportionately more?



Not every app is at the high-end. Most aren’t.



And now I watch daily nightmares around deploying web apps too.



What exactly have we done to ourselves?



Regards,



Greg



Dr Greg Low



1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax

SQL Down Under | Web: www.sqldownunder.com |http://greglow.me





*From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
*On Behalf Of *Craig van Nieuwkerk
*Sent:* Tuesday, 21 November 2017 4:46 PM
*To:* ozDotNet <ozdotnet@ozdotnet.com>
*Subject:* Re: Creating a browser-based product



I'm not sure this is much more of an iss

RE: Creating a browser-based product

[Ken Schaefer]

Deployment is part of TCO, and the TCO sucks when you have lots and lots of 
thick client apps. And you can’t just say “that’s deployment” – lots of people 
have tried to solve the deployment problem, and no one has.

Web-based isn’t driven by “IT sick of deploying apps” – web based is driven by 
the people who pay the bills.
Whether that be the buyer, or the producer.  Google sees no value in writing a 
thick-client email client, and CIOs see Gmail as working just fine without one.


From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Low
Sent: Tuesday, 21 November 2017 7:26 PM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: Re: Creating a browser-based product

Again all of that is largely about deployment Ken. Yes thick client apps were a 
pain in the neck to test and deploy. But surely we could have improved the dev 
experience even further, while building something trivial to deploy. Web apps 
were largely driven by IT admin folk who were sick of trying to test and deploy 
apps. But for example, if you sat a user in front of say Outlook thick client 
and the Outlook web apps, it’d be a rare person who’d choose the web version 
for the UI. And how many business apps are built better than Outlook OWA? It’s 
not great but it’s better than the web based business apps in most companies.

Regards,

Greg

Dr Greg Low
1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax
SQL Down Under | Web: www.sqldownunder.com<http://www.sqldownunder.com>


On Tue, Nov 21, 2017 at 7:11 PM +1100, "Ken Schaefer" 
<k...@adopenstatic.com<mailto:k...@adopenstatic.com>> wrote:
We used to have everything as thick-client apps. And then every time we had to 
upgrade an OS, we have to regression test, and sociability test 1000+ apps. 
That’s a huge waste of time.
Then there’s the deployment issues of pushing thousands of apps out to 
thousands/tens of thousands/hundreds of thousands of endpoints.

When you talk about building a LoB app – well, that works when you have 1, or 2 
apps. It doesn’t scale.

Instead, we’re now using a browser as a virtual OS (with hardware, networking 
etc. abstracted away to the real OS), with an application UI and some logic 
delivered as text at run-time, and the non-GUI parts centralised.

And when we look at all the possible ways of building apps, and the choices 
being made by both developers of apps, and buyers of apps, it seems the 
market’s been pretty unequivocal about the preferred method.

Why it’s not much better/faster than before, is probably down to immaturity. If 
you want an app that does something that we were able to do 20 years ago, then 
that’s trivial to implement. But what the market wants is apps to do things 
that haven’t been done before.

From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Low
Sent: Tuesday, 21 November 2017 5:51 PM
To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
Subject: RE: Creating a browser-based product

But when a business just wants a line of business app, are these good answers 
now? Do they care if it could be used by billions of people? The odd one might 
care. Most won’t.

Won’t they be more concerned with taking 6 or 8 times longer, and costing 
proportionately more?

Not every app is at the high-end. Most aren’t.

And now I watch daily nightmares around deploying web apps too.

What exactly have we done to ourselves?

Regards,

Greg

Dr Greg Low

1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax
SQL Down Under | Web: www.sqldownunder.com<http://www.sqldownunder.com/> 
|http://greglow.me<http://greglow.me/>


From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>] On 
Behalf Of Craig van Nieuwkerk
Sent: Tuesday, 21 November 2017 4:46 PM
To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
Subject: Re: Creating a browser-based product

I'm not sure this is much more of an issue now than it was. Back in the day we 
had to decide between Delphi, VB, Powerbuilder, C++ among others when building 
a Windows app. And once we decided that we had to work out which third party 
libraries we wanted to use with them.

If I take an old 15 year old Delphi app I have it would take me the best part 
of a week to get it compiling again now if I had to build the dev machine from 
scratch.

On Tue, Nov 21, 2017 at 3:53 PM, Greg Low 
<g...@greglow.com<mailto:g...@greglow.com>> wrote:
So then we’re back to why business apps take so very long to build nowadays, 
and why no-one can seem to decide which tools to use. Either way, as an 
industry, our productivity when building apps is poor.

RE: Creating a browser-based product

[Tony Wright]

Yep it was a configuration nightmare. I originally learnt on visual code
(as well as Webstorm, bracket, and I think an ide called atom?) I think you
lose tooltips as well, right? Can't right click and go to implementation
etc. It's all about the experience.

On 22 Nov 2017 1:09 AM, <djones...@gmail.com> wrote:

> Hi,
>
>
>
> We’ve just created a front end application in angular 4, the front end
> developer did everything in Code. When it came to deploying there was a
> hell of a configuration mess.
>
> There were node dependencies all over the place, with NPM and Node
> versions being different on the server than on the development machine.
>
> It took us 5 days of trying to coax node and npm to play along with
> Angular 4 on the web server.
>
>
>
> I would rather do everything in Visual studio where you can hit debug and
> run the entire application and then deploy without hassle than trying to
> figure out why something isn’t working after the development is done.
>
>
>
> .02c
>
>
>
> Davy
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Craig van Nieuwkerk <crai...@gmail.com>
> *Sent: *21 November 2017 10:13
> *To: *ozDotNet <ozdotnet@ozdotnet.com>
> *Subject: *Re: Creating a browser-based product
>
>
>
> Also, you are best not using Visual Studio but using Visual Studio Code.
>
>
>
> https://www.hanselman.com/blog/dotnetNewAngularAndDotnetNewReact.aspx
>
>
>
> Craig
>
>
>
> On Tue, Nov 21, 2017 at 8:00 PM, Greg Keogh <gfke...@gmail.com> wrote:
>
> It will create all the plumbing and you just click Start with everything
> in place.
>
>
>
> Okay, I'll give it a bash tomorrow - fingers crossed - *GK*
>
>
>
>
>
>
>

RE: Creating a browser-based product

[djones147]

Hi, 

We’ve just created a front end application in angular 4, the front end 
developer did everything in Code. When it came to deploying there was a hell of 
a configuration mess. 
There were node dependencies all over the place, with NPM and Node versions 
being different on the server than on the development machine. 
It took us 5 days of trying to coax node and npm to play along with Angular 4 
on the web server. 

I would rather do everything in Visual studio where you can hit debug and run 
the entire application and then deploy without hassle than trying to figure out 
why something isn’t working after the development is done. 

.02c

Davy

Sent from Mail for Windows 10

From: Craig van Nieuwkerk
Sent: 21 November 2017 10:13
To: ozDotNet
Subject: Re: Creating a browser-based product

Also, you are best not using Visual Studio but using Visual Studio Code.

https://www.hanselman.com/blog/dotnetNewAngularAndDotnetNewReact.aspx

Craig

On Tue, Nov 21, 2017 at 8:00 PM, Greg Keogh <gfke...@gmail.com> wrote:
It will create all the plumbing and you just click Start with everything in 
place.

Okay, I'll give it a bash tomorrow - fingers crossed - GK 

Re: Creating a browser-based product

[Tony Wright]

With all the extra configuration, no way. I've done all sorts of variations
and I'm visual studio all the way now. I'm even back to using Resharper.

Yes you can even use cli but we don't even bother with that. And hot module
replacement is awesome and already set up in the environment.

I've also got asp.net membership integrated,and I can call existing dot net
code in dot net framework. I can even use entity framework canvas in dot
net core 2 if I want to.


On 21 Nov 2017 11:05 PM, "Craig van Nieuwkerk"  wrote:

> The article is a bit old, but still relevant. The dotnet cli was not a
> temporary solution until VS2017 supported the features, for most people who
> are developing greenfields it should be their go to solution. Personally I
> find using VS2017 for Angular or similar is really a legacy way of doing
> things when your back end and front end are tightly coupled, and if you are
> fitting a new front end to an existing product probably makes sense. I
> would use VSCode every day of the week given the choice though.
>
> Craig
>
> On Tue, Nov 21, 2017 at 10:56 PM, Tony Wright  wrote:
>
>> That's old. That's before they provided templates in visual studio. You
>> won't get as great an experience using vs code and good luck integrating
>> your older code base.
>>
>> On 21 Nov 2017 8:13 PM, "Craig van Nieuwkerk"  wrote:
>>
>>> Also, you are best not using Visual Studio but using Visual Studio Code.
>>>
>>> https://www.hanselman.com/blog/dotnetNewAngularAndDotnetNewReact.aspx
>>>
>>> Craig
>>>
>>> On Tue, Nov 21, 2017 at 8:00 PM, Greg Keogh  wrote:
>>>
 It will create all the plumbing and you just click Start with
> everything in place.
>

 Okay, I'll give it a bash tomorrow - fingers crossed - *GK*


>>>
>

Re: Creating a browser-based product

[Craig van Nieuwkerk]

The article is a bit old, but still relevant. The dotnet cli was not a
temporary solution until VS2017 supported the features, for most people who
are developing greenfields it should be their go to solution. Personally I
find using VS2017 for Angular or similar is really a legacy way of doing
things when your back end and front end are tightly coupled, and if you are
fitting a new front end to an existing product probably makes sense. I
would use VSCode every day of the week given the choice though.

Craig

On Tue, Nov 21, 2017 at 10:56 PM, Tony Wright  wrote:

> That's old. That's before they provided templates in visual studio. You
> won't get as great an experience using vs code and good luck integrating
> your older code base.
>
> On 21 Nov 2017 8:13 PM, "Craig van Nieuwkerk"  wrote:
>
>> Also, you are best not using Visual Studio but using Visual Studio Code.
>>
>> https://www.hanselman.com/blog/dotnetNewAngularAndDotnetNewReact.aspx
>>
>> Craig
>>
>> On Tue, Nov 21, 2017 at 8:00 PM, Greg Keogh  wrote:
>>
>>> It will create all the plumbing and you just click Start with everything
 in place.

>>>
>>> Okay, I'll give it a bash tomorrow - fingers crossed - *GK*
>>>
>>>
>>

Re: Creating a browser-based product

[Tony Wright]

That's old. That's before they provided templates in visual studio. You
won't get as great an experience using vs code and good luck integrating
your older code base.

On 21 Nov 2017 8:13 PM, "Craig van Nieuwkerk"  wrote:

> Also, you are best not using Visual Studio but using Visual Studio Code.
>
> https://www.hanselman.com/blog/dotnetNewAngularAndDotnetNewReact.aspx
>
> Craig
>
> On Tue, Nov 21, 2017 at 8:00 PM, Greg Keogh  wrote:
>
>> It will create all the plumbing and you just click Start with everything
>>> in place.
>>>
>>
>> Okay, I'll give it a bash tomorrow - fingers crossed - *GK*
>>
>>
>

RE: Creating a browser-based product

[mike smith]

http://issurvivor.com/2017/11/20/opinionization-in-the-cloud/

On 21 Nov. 2017 22:15, "mike smith" <meski...@gmail.com> wrote:

> Browsers as virtual OSes, or VMs themselves as virtual environments to
> separate the applications or services?
>
> I was reading an article suggesting that fortune 500 companies that bought
> Amazon, MS style cloud services were being lazy, and should be building
> their own.
>
> I'll look up the link
>
> On 21 Nov. 2017 19:11, "Ken Schaefer" <k...@adopenstatic.com> wrote:
>
> We used to have everything as thick-client apps. And then every time we
> had to upgrade an OS, we have to regression test, and sociability test
> 1000+ apps. That’s a huge waste of time.
>
> Then there’s the deployment issues of pushing thousands of apps out to
> thousands/tens of thousands/hundreds of thousands of endpoints.
>
>
>
> When you talk about building a LoB app – well, that works when you have 1,
> or 2 apps. It doesn’t scale.
>
>
>
> Instead, we’re now using a browser as a virtual OS (with hardware,
> networking etc. abstracted away to the real OS), with an application UI and
> some logic delivered as text at run-time, and the non-GUI parts centralised.
>
>
>
> And when we look at all the possible ways of building apps, and the
> choices being made by both developers of apps, and buyers of apps, it seems
> the market’s been pretty unequivocal about the preferred method.
>
>
>
> Why it’s not much better/faster than before, is probably down to
> immaturity. If you want an app that does something that we were able to do
> 20 years ago, then that’s trivial to implement. But what the market wants
> is apps to do things that haven’t been done before.
>
>
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@ozdot
> net.com] *On Behalf Of *Greg Low
> *Sent:* Tuesday, 21 November 2017 5:51 PM
> *To:* ozDotNet <ozdotnet@ozdotnet.com>
> *Subject:* RE: Creating a browser-based product
>
>
>
> But when a business just wants a line of business app, are these good
> answers now? Do they care if it could be used by billions of people? The
> odd one might care. Most won’t.
>
>
>
> Won’t they be more concerned with taking 6 or 8 times longer, and costing
> proportionately more?
>
>
>
> Not every app is at the high-end. Most aren’t.
>
>
>
> And now I watch daily nightmares around deploying web apps too.
>
>
>
> What exactly have we done to ourselves?
>
>
>
> Regards,
>
>
>
> Greg
>
>
>
> Dr Greg Low
>
>
>
> 1300SQLSQL (1300 775 775 <1300%20775%20775>) office | +61 419201410
> <0419%20201%20410> mobile│ +61 3 8676 4913 <(03)%208676%204913> fax
>
> SQL Down Under | Web: www.sqldownunder.com |http://greglow.me
>
>
>
>
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@ozdot
> net.com] *On Behalf Of *Craig van Nieuwkerk
> *Sent:* Tuesday, 21 November 2017 4:46 PM
> *To:* ozDotNet <ozdotnet@ozdotnet.com>
> *Subject:* Re: Creating a browser-based product
>
>
>
> I'm not sure this is much more of an issue now than it was. Back in the
> day we had to decide between Delphi, VB, Powerbuilder, C++ among others
> when building a Windows app. And once we decided that we had to work out
> which third party libraries we wanted to use with them.
>
>
>
> If I take an old 15 year old Delphi app I have it would take me the best
> part of a week to get it compiling again now if I had to build the dev
> machine from scratch.
>
>
>
> On Tue, Nov 21, 2017 at 3:53 PM, Greg Low <g...@greglow.com> wrote:
>
> So then we’re back to why business apps take so very long to build
> nowadays, and why no-one can seem to decide which tools to use. Either way,
> as an industry, our productivity when building apps is poor.
>
>
>
>
>
>
>

RE: Creating a browser-based product

[mike smith]

Browsers as virtual OSes, or VMs themselves as virtual environments to
separate the applications or services?

I was reading an article suggesting that fortune 500 companies that bought
Amazon, MS style cloud services were being lazy, and should be building
their own.

I'll look up the link

On 21 Nov. 2017 19:11, "Ken Schaefer" <k...@adopenstatic.com> wrote:

We used to have everything as thick-client apps. And then every time we had
to upgrade an OS, we have to regression test, and sociability test 1000+
apps. That’s a huge waste of time.

Then there’s the deployment issues of pushing thousands of apps out to
thousands/tens of thousands/hundreds of thousands of endpoints.



When you talk about building a LoB app – well, that works when you have 1,
or 2 apps. It doesn’t scale.



Instead, we’re now using a browser as a virtual OS (with hardware,
networking etc. abstracted away to the real OS), with an application UI and
some logic delivered as text at run-time, and the non-GUI parts centralised.



And when we look at all the possible ways of building apps, and the choices
being made by both developers of apps, and buyers of apps, it seems the
market’s been pretty unequivocal about the preferred method.



Why it’s not much better/faster than before, is probably down to
immaturity. If you want an app that does something that we were able to do
20 years ago, then that’s trivial to implement. But what the market wants
is apps to do things that haven’t been done before.



*From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
*On Behalf Of *Greg Low
*Sent:* Tuesday, 21 November 2017 5:51 PM
*To:* ozDotNet <ozdotnet@ozdotnet.com>
*Subject:* RE: Creating a browser-based product



But when a business just wants a line of business app, are these good
answers now? Do they care if it could be used by billions of people? The
odd one might care. Most won’t.



Won’t they be more concerned with taking 6 or 8 times longer, and costing
proportionately more?



Not every app is at the high-end. Most aren’t.



And now I watch daily nightmares around deploying web apps too.



What exactly have we done to ourselves?



Regards,



Greg



Dr Greg Low



1300SQLSQL (1300 775 775 <1300%20775%20775>) office | +61 419201410
<0419%20201%20410> mobile│ +61 3 8676 4913 <(03)%208676%204913> fax

SQL Down Under | Web: www.sqldownunder.com |http://greglow.me





*From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
*On Behalf Of *Craig van Nieuwkerk
*Sent:* Tuesday, 21 November 2017 4:46 PM
*To:* ozDotNet <ozdotnet@ozdotnet.com>
*Subject:* Re: Creating a browser-based product



I'm not sure this is much more of an issue now than it was. Back in the day
we had to decide between Delphi, VB, Powerbuilder, C++ among others when
building a Windows app. And once we decided that we had to work out which
third party libraries we wanted to use with them.



If I take an old 15 year old Delphi app I have it would take me the best
part of a week to get it compiling again now if I had to build the dev
machine from scratch.



On Tue, Nov 21, 2017 at 3:53 PM, Greg Low <g...@greglow.com> wrote:

So then we’re back to why business apps take so very long to build
nowadays, and why no-one can seem to decide which tools to use. Either way,
as an industry, our productivity when building apps is poor.

Re: Creating a browser-based product

[Craig van Nieuwkerk]

Also, you are best not using Visual Studio but using Visual Studio Code.

https://www.hanselman.com/blog/dotnetNewAngularAndDotnetNewReact.aspx

Craig

On Tue, Nov 21, 2017 at 8:00 PM, Greg Keogh  wrote:

> It will create all the plumbing and you just click Start with everything
>> in place.
>>
>
> Okay, I'll give it a bash tomorrow - fingers crossed - *GK*
>
>

Re: Creating a browser-based product

[Greg Keogh]

>
> It will create all the plumbing and you just click Start with everything
> in place.
>

Okay, I'll give it a bash tomorrow - fingers crossed - *GK*

Re: Creating a browser-based product

[Craig van Nieuwkerk]

> Come the day when I can just create a JS project in the IDE wizard, get
all the standard plumbing in-place and start coding.

You can do this, type

> dotnet new angular

or

> dotnet new react

or

> dotnet new vue

It will create all the plumbing and you just click Start with everything in
place.

Re: Creating a browser-based product

[Greg Keogh]

>
> But surely we could have improved the dev experience even further,
>

Indeed, I don't want to spent hours configuring a special environment just
to build a web app using a specific framework/component combination (which
is what happened last time). The JS development experience I've seen so far
is ludicrously inefficient and difficult. Tony says that the VS2017
experience is improved for Angular, so I'll be checking that out over the
coming week. Come the day when I can just create a JS project in the IDE
wizard, get all the standard plumbing in-place and start coding.

In concession, I should also point out that the Xamarin coding experience
is still woeful. My Android debugging has been utterly broken for 18 months
and I have to use a USB and phone for testing; the UI preview pane fails
very slowly with useless errors and I have to write all screens in raw XAML
and preview them by running the app; a recent upgrade to the libraries has
busted a whole project to death (it dies deep inside the first line of
code); random untraceable errors never seen in testing occur when deployed
to real devices; and so on...

So the 21st century of development isn't like I expected 30 years ago. I
was sure my PC would be like the one in Star Trek where it could create
virtual computers dynamically to solve any problem. And where's my flying
car and holidays on the Moon?

*GK*

Re: Creating a browser-based product

[David Connors]

On Tue., 21 Nov. 2017, 6:29 pm Greg Low, <g...@greglow.com> wrote:

> A better question might be as to why apps like MS Word, Excel, Power BI
> Desktop, etc. even still exist. With their substantial resources, can’t
> Microsoft build better web-based versions of them? Why do users still want
> the thick client versions of those?
>

Legacy inertia. Microsoft will have to change.

Word is still the only game in town for writing large documents but it is
hard to mount an argument that excel is better than Google sheets. And
airtable shits over both of them.

MS needs to buy airtable and park them next to the excel team as a warning.

David.



>
>
>
> *From:* Greg Low [mailto:g...@greglow.com]
> *Sent:* Tuesday, 21 November 2017 7:26 PM
>
>
> *To:* ozDotNet <ozdotnet@ozdotnet.com>
> *Subject:* Re: Creating a browser-based product
>
>
>
> Again all of that is largely about deployment Ken. Yes thick client apps
> were a pain in the neck to test and deploy. But surely we could have
> improved the dev experience even further, while building something trivial
> to deploy. Web apps were largely driven by IT admin folk who were sick of
> trying to test and deploy apps. But for example, if you sat a user in front
> of say Outlook thick client and the Outlook web apps, it’d be a rare person
> who’d choose the web version for the UI. And how many business apps are
> built better than Outlook OWA? It’s not great but it’s better than the web
> based business apps in most companies.
>
>
>
> Regards,
>
>
>
> Greg
>
>
>
> Dr Greg Low
>
> 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913
> fax
>
> SQL Down Under | Web: www.sqldownunder.com
>
>
>
> On Tue, Nov 21, 2017 at 7:11 PM +1100, "Ken Schaefer" <
> k...@adopenstatic.com> wrote:
>
> We used to have everything as thick-client apps. And then every time we
> had to upgrade an OS, we have to regression test, and sociability test
> 1000+ apps. That’s a huge waste of time.
>
> Then there’s the deployment issues of pushing thousands of apps out to
> thousands/tens of thousands/hundreds of thousands of endpoints.
>
>
>
> When you talk about building a LoB app – well, that works when you have 1,
> or 2 apps. It doesn’t scale.
>
>
>
> Instead, we’re now using a browser as a virtual OS (with hardware,
> networking etc. abstracted away to the real OS), with an application UI and
> some logic delivered as text at run-time, and the non-GUI parts centralised.
>
>
>
> And when we look at all the possible ways of building apps, and the
> choices being made by both developers of apps, and buyers of apps, it seems
> the market’s been pretty unequivocal about the preferred method.
>
>
>
> Why it’s not much better/faster than before, is probably down to
> immaturity. If you want an app that does something that we were able to do
> 20 years ago, then that’s trivial to implement. But what the market wants
> is apps to do things that haven’t been done before.
>
>
>
> *From:* ozdotnet-boun...@ozdotnet.com [
> mailto:ozdotnet-boun...@ozdotnet.com <ozdotnet-boun...@ozdotnet.com>] *On
> Behalf Of *Greg Low
> *Sent:* Tuesday, 21 November 2017 5:51 PM
> *To:* ozDotNet <ozdotnet@ozdotnet.com>
> *Subject:* RE: Creating a browser-based product
>
>
>
> But when a business just wants a line of business app, are these good
> answers now? Do they care if it could be used by billions of people? The
> odd one might care. Most won’t.
>
>
>
> Won’t they be more concerned with taking 6 or 8 times longer, and costing
> proportionately more?
>
>
>
> Not every app is at the high-end. Most aren’t.
>
>
>
> And now I watch daily nightmares around deploying web apps too.
>
>
>
> What exactly have we done to ourselves?
>
>
>
> Regards,
>
>
>
> Greg
>
>
>
> Dr Greg Low
>
>
>
> 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913
> fax
>
> SQL Down Under | Web: www.sqldownunder.com |http://greglow.me
>
>
>
>
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:
> ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Craig van Nieuwkerk
> *Sent:* Tuesday, 21 November 2017 4:46 PM
> *To:* ozDotNet <ozdotnet@ozdotnet.com>
> *Subject:* Re: Creating a browser-based product
>
>
>
> I'm not sure this is much more of an issue now than it was. Back in the
> day we had to decide between Delphi, VB, Powerbuilder, C++ among others
> when building a Windows app. And once we decided that we had to work out
> which third party libraries we wanted to use with them.
>
>
>
> If I take an old 15 year old Delphi 

Re: Creating a browser-based product

[David Connors]

On Tue., 21 Nov. 2017, 4:50 pm Greg Low, <g...@greglow.com> wrote:

> But when a business just wants a line of business app, are these good
> answers now? Do they care if it could be used by billions of people? The
> odd one might care. Most won’t.
>

None do. There is a reason why salesforce and service now have become the
successful companies / cults that they have.

> won’t they be more concerned with taking 6 or 8 times longer, and costing
> proportionately more?
>
App development or TCO? What % did Fred Brooks say Dev is vs lifetime?

>  Not every app is at the high-end. Most aren’t.
>
Correct. But there are hybrid paas/SaaS environments for those. People
still making money out of writing departmental apps need to be shit scared
of SFDC and powerapps.

> And now I watch daily nightmares around deploying web apps too.
>
Not to client PC's you don't. You just email a url.

If you see crap server side deployments then that is a reflection of bad
devops.

>  What exactly have we done to ourselves?
>
Focus on end user experience. If I were a cio I'd mandate responsive web
apps with identity as a boundary so I don't have to give a shit any more.
If someone wants to use an android phone or iPad pro or windows PC ... Who
cares?

David

>
> *To:* ozDotNet <ozdotnet@ozdotnet.com>
> *Subject:* Re: Creating a browser-based product
>
>
>
> I'm not sure this is much more of an issue now than it was. Back in the
> day we had to decide between Delphi, VB, Powerbuilder, C++ among others
> when building a Windows app. And once we decided that we had to work out
> which third party libraries we wanted to use with them.
>
>
>
> If I take an old 15 year old Delphi app I have it would take me the best
> part of a week to get it compiling again now if I had to build the dev
> machine from scratch.
>
>
>
> On Tue, Nov 21, 2017 at 3:53 PM, Greg Low <g...@greglow.com> wrote:
>
> So then we’re back to why business apps take so very long to build
> nowadays, and why no-one can seem to decide which tools to use. Either way,
> as an industry, our productivity when building apps is poor.
>
>
>
>
>
> --
David Connors
da...@connors.com | @davidconnors | https://t.me/davidconnors | LinkedIn | +61
417 189 363

RE: Creating a browser-based product

[Greg Low]

A better question might be as to why apps like MS Word, Excel, Power BI
Desktop, etc. even still exist. With their substantial resources, can’t
Microsoft build better web-based versions of them? Why do users still want
the thick client versions of those?





*From:* Greg Low [mailto:g...@greglow.com]
*Sent:* Tuesday, 21 November 2017 7:26 PM
*To:* ozDotNet <ozdotnet@ozdotnet.com>
*Subject:* Re: Creating a browser-based product



Again all of that is largely about deployment Ken. Yes thick client apps
were a pain in the neck to test and deploy. But surely we could have
improved the dev experience even further, while building something trivial
to deploy. Web apps were largely driven by IT admin folk who were sick of
trying to test and deploy apps. But for example, if you sat a user in front
of say Outlook thick client and the Outlook web apps, it’d be a rare person
who’d choose the web version for the UI. And how many business apps are
built better than Outlook OWA? It’s not great but it’s better than the web
based business apps in most companies.



Regards,



Greg



Dr Greg Low

1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax

SQL Down Under | Web: www.sqldownunder.com



On Tue, Nov 21, 2017 at 7:11 PM +1100, "Ken Schaefer" <k...@adopenstatic.com>
wrote:

We used to have everything as thick-client apps. And then every time we had
to upgrade an OS, we have to regression test, and sociability test 1000+
apps. That’s a huge waste of time.

Then there’s the deployment issues of pushing thousands of apps out to
thousands/tens of thousands/hundreds of thousands of endpoints.



When you talk about building a LoB app – well, that works when you have 1,
or 2 apps. It doesn’t scale.



Instead, we’re now using a browser as a virtual OS (with hardware,
networking etc. abstracted away to the real OS), with an application UI and
some logic delivered as text at run-time, and the non-GUI parts centralised.



And when we look at all the possible ways of building apps, and the choices
being made by both developers of apps, and buyers of apps, it seems the
market’s been pretty unequivocal about the preferred method.



Why it’s not much better/faster than before, is probably down to
immaturity. If you want an app that does something that we were able to do
20 years ago, then that’s trivial to implement. But what the market wants
is apps to do things that haven’t been done before.



*From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com
<ozdotnet-boun...@ozdotnet.com>] *On Behalf Of *Greg Low
*Sent:* Tuesday, 21 November 2017 5:51 PM
*To:* ozDotNet <ozdotnet@ozdotnet.com>
*Subject:* RE: Creating a browser-based product



But when a business just wants a line of business app, are these good
answers now? Do they care if it could be used by billions of people? The
odd one might care. Most won’t.



Won’t they be more concerned with taking 6 or 8 times longer, and costing
proportionately more?



Not every app is at the high-end. Most aren’t.



And now I watch daily nightmares around deploying web apps too.



What exactly have we done to ourselves?



Regards,



Greg



Dr Greg Low



1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax

SQL Down Under | Web: www.sqldownunder.com |http://greglow.me





*From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
*On Behalf Of *Craig van Nieuwkerk
*Sent:* Tuesday, 21 November 2017 4:46 PM
*To:* ozDotNet <ozdotnet@ozdotnet.com>
*Subject:* Re: Creating a browser-based product



I'm not sure this is much more of an issue now than it was. Back in the day
we had to decide between Delphi, VB, Powerbuilder, C++ among others when
building a Windows app. And once we decided that we had to work out which
third party libraries we wanted to use with them.



If I take an old 15 year old Delphi app I have it would take me the best
part of a week to get it compiling again now if I had to build the dev
machine from scratch.



On Tue, Nov 21, 2017 at 3:53 PM, Greg Low <g...@greglow.com> wrote:

So then we’re back to why business apps take so very long to build
nowadays, and why no-one can seem to decide which tools to use. Either way,
as an industry, our productivity when building apps is poor.

Re: Creating a browser-based product

[Greg Low]

Again all of that is largely about deployment Ken. Yes thick 
client apps were a pain in the neck to test and deploy. But surely we could 
have improved the dev experience even further, while building something trivial 
to deploy. Web apps were largely driven by IT admin folk who were sick of 
trying to test and deploy apps. But for example, if you sat a user in front of 
say Outlook thick client and the Outlook web apps, it’d be a rare person who’d 
choose the web version for the UI. And how many business apps are built better 
than Outlook OWA? It’s not great but it’s better than the web based business 
apps in most companies.



Regards,
Greg
Dr Greg Low1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 
4913 faxSQL Down Under | Web: www.sqldownunder.com






On Tue, Nov 21, 2017 at 7:11 PM +1100, "Ken Schaefer" <k...@adopenstatic.com> 
wrote:




















We used to have everything as thick-client apps. And then every time we had to 
upgrade an OS, we have to regression test, and sociability test 1000+ apps. 
That’s a huge waste of time.



Then there’s the deployment issues of pushing thousands of apps out to 
thousands/tens of thousands/hundreds of thousands of endpoints.


 


When you talk about building a LoB app – well, that works when you have 1, or 2 
apps. It doesn’t scale.


 


Instead, we’re now using a browser as a virtual OS (with hardware, networking 
etc. abstracted away to the real OS), with an application UI and some logic 
delivered as text at run-time, and the non-GUI
 parts centralised.


 


And when we look at all the possible ways of building apps, and the choices 
being made by both developers of apps, and buyers of apps, it seems the 
market’s been pretty unequivocal about the preferred
 method.


 


Why it’s not much better/faster than before, is probably down to immaturity. If 
you want an app that does something that we were able to do 20 years ago, then 
that’s trivial to implement. But what
 the market wants is apps to do things that haven’t been done before.


 





From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Greg Low

Sent: Tuesday, 21 November 2017 5:51 PM

To: ozDotNet <ozdotnet@ozdotnet.com>

Subject: RE: Creating a browser-based product




 


But when a business just wants a line of business app, are these good answers 
now? Do they care if it could be used by billions of people? The odd one might 
care. Most won’t.


 


Won’t they be more concerned with taking 6 or 8 times longer, and costing 
proportionately more?


 


Not every app is at the high-end. Most aren’t.


 


And now I watch daily nightmares around deploying web apps too.


 


What exactly have we done to ourselves?


 


Regards,


 


Greg


 


Dr Greg Low


 


1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax


SQL Down Under | Web: www.sqldownunder.com |http://greglow.me


 


 


From: 
ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Craig van Nieuwkerk

Sent: Tuesday, 21 November 2017 4:46 PM

To: ozDotNet <ozdotnet@ozdotnet.com>

Subject: Re: Creating a browser-based product


 



I'm not sure this is much more of an issue now than it was. Back in the day we 
had to decide between Delphi, VB, Powerbuilder, C++ among others when building 
a Windows app. And once we decided that we had to work out which third party 
libraries
 we wanted to use with them. 



 




If I take an old 15 year old Delphi app I have it would take me the best part 
of a week to get it compiling again now if I had to build the dev machine from 
scratch.



 



On Tue, Nov 21, 2017 at 3:53 PM, Greg Low <g...@greglow.com> wrote:





So then we’re back to why business apps take so very long to build nowadays, 
and why no-one can seem to decide which tools to use.
 Either way, as an industry, our productivity when building apps is poor.


 


 

RE: Creating a browser-based product

[Ken Schaefer]

We used to have everything as thick-client apps. And then every time we had to 
upgrade an OS, we have to regression test, and sociability test 1000+ apps. 
That’s a huge waste of time.
Then there’s the deployment issues of pushing thousands of apps out to 
thousands/tens of thousands/hundreds of thousands of endpoints.

When you talk about building a LoB app – well, that works when you have 1, or 2 
apps. It doesn’t scale.

Instead, we’re now using a browser as a virtual OS (with hardware, networking 
etc. abstracted away to the real OS), with an application UI and some logic 
delivered as text at run-time, and the non-GUI parts centralised.

And when we look at all the possible ways of building apps, and the choices 
being made by both developers of apps, and buyers of apps, it seems the 
market’s been pretty unequivocal about the preferred method.

Why it’s not much better/faster than before, is probably down to immaturity. If 
you want an app that does something that we were able to do 20 years ago, then 
that’s trivial to implement. But what the market wants is apps to do things 
that haven’t been done before.

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Low
Sent: Tuesday, 21 November 2017 5:51 PM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: RE: Creating a browser-based product

But when a business just wants a line of business app, are these good answers 
now? Do they care if it could be used by billions of people? The odd one might 
care. Most won’t.

Won’t they be more concerned with taking 6 or 8 times longer, and costing 
proportionately more?

Not every app is at the high-end. Most aren’t.

And now I watch daily nightmares around deploying web apps too.

What exactly have we done to ourselves?

Regards,

Greg

Dr Greg Low

1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax
SQL Down Under | Web: www.sqldownunder.com<http://www.sqldownunder.com/> 
|http://greglow.me<http://greglow.me/>


From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>] On 
Behalf Of Craig van Nieuwkerk
Sent: Tuesday, 21 November 2017 4:46 PM
To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
Subject: Re: Creating a browser-based product

I'm not sure this is much more of an issue now than it was. Back in the day we 
had to decide between Delphi, VB, Powerbuilder, C++ among others when building 
a Windows app. And once we decided that we had to work out which third party 
libraries we wanted to use with them.

If I take an old 15 year old Delphi app I have it would take me the best part 
of a week to get it compiling again now if I had to build the dev machine from 
scratch.

On Tue, Nov 21, 2017 at 3:53 PM, Greg Low 
<g...@greglow.com<mailto:g...@greglow.com>> wrote:
So then we’re back to why business apps take so very long to build nowadays, 
and why no-one can seem to decide which tools to use. Either way, as an 
industry, our productivity when building apps is poor.

RE: Creating a browser-based product

[Tony Wright]

It took me ages to build a framework for Angular. Now that I've built it I
can quickly create new apps based on the previous app, but I would hate to
be back at newbie stage tried to build it again. So many moving parts. At
least I can still integrate with existing code. Deployment is relatively
easy in my opinion.

I built my app from scratch, transitioned to javascript services and
webpack, and it is only months ago that visual studio got a decent angular
2 template built in. Even now it doesn't come with a security model built
in. I added forms authentication but that wasn't trivial. My boss asked me
to give him a document worth all the steps and it was 31 large steps.

So it's a struggle, but I have an app that looks awesome. Draggable tiles,
charts, grids, responsiveness, async loading, breadcrumbs, maps, etc

On 21 Nov 2017 5:50 PM, "Greg Low" <g...@greglow.com> wrote:

> But when a business just wants a line of business app, are these good
> answers now? Do they care if it could be used by billions of people? The
> odd one might care. Most won’t.
>
>
>
> Won’t they be more concerned with taking 6 or 8 times longer, and costing
> proportionately more?
>
>
>
> Not every app is at the high-end. Most aren’t.
>
>
>
> And now I watch daily nightmares around deploying web apps too.
>
>
>
> What exactly have we done to ourselves?
>
>
>
> Regards,
>
>
>
> Greg
>
>
>
> Dr Greg Low
>
>
>
> 1300SQLSQL (1300 775 775) office | +61 419201410 <+61%20419%20201%20410>
> mobile│ +61 3 8676 4913 <+61%203%208676%204913> fax
>
> SQL Down Under | Web: www.sqldownunder.com |http://greglow.me
>
>
>
>
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@
> ozdotnet.com] *On Behalf Of *Craig van Nieuwkerk
> *Sent:* Tuesday, 21 November 2017 4:46 PM
> *To:* ozDotNet <ozdotnet@ozdotnet.com>
> *Subject:* Re: Creating a browser-based product
>
>
>
> I'm not sure this is much more of an issue now than it was. Back in the
> day we had to decide between Delphi, VB, Powerbuilder, C++ among others
> when building a Windows app. And once we decided that we had to work out
> which third party libraries we wanted to use with them.
>
>
>
> If I take an old 15 year old Delphi app I have it would take me the best
> part of a week to get it compiling again now if I had to build the dev
> machine from scratch.
>
>
>
> On Tue, Nov 21, 2017 at 3:53 PM, Greg Low <g...@greglow.com> wrote:
>
> So then we’re back to why business apps take so very long to build
> nowadays, and why no-one can seem to decide which tools to use. Either way,
> as an industry, our productivity when building apps is poor.
>
>
>
>
>
>

RE: Creating a browser-based product

[Greg Low]

But when a business just wants a line of business app, are these good
answers now? Do they care if it could be used by billions of people? The
odd one might care. Most won’t.



Won’t they be more concerned with taking 6 or 8 times longer, and costing
proportionately more?



Not every app is at the high-end. Most aren’t.



And now I watch daily nightmares around deploying web apps too.



What exactly have we done to ourselves?



Regards,



Greg



Dr Greg Low



1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax

SQL Down Under | Web: www.sqldownunder.com |http://greglow.me





*From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
*On Behalf Of *Craig van Nieuwkerk
*Sent:* Tuesday, 21 November 2017 4:46 PM
*To:* ozDotNet <ozdotnet@ozdotnet.com>
*Subject:* Re: Creating a browser-based product



I'm not sure this is much more of an issue now than it was. Back in the day
we had to decide between Delphi, VB, Powerbuilder, C++ among others when
building a Windows app. And once we decided that we had to work out which
third party libraries we wanted to use with them.



If I take an old 15 year old Delphi app I have it would take me the best
part of a week to get it compiling again now if I had to build the dev
machine from scratch.



On Tue, Nov 21, 2017 at 3:53 PM, Greg Low <g...@greglow.com> wrote:

So then we’re back to why business apps take so very long to build
nowadays, and why no-one can seem to decide which tools to use. Either way,
as an industry, our productivity when building apps is poor.

Re: Creating a browser-based product

[David Connors]

On Tue, 21 Nov 2017 at 15:30 Greg Keogh  wrote:

> The Gregs are revolting! Indeed ... polyfills, css, bootstrap, IE, etc ...
> why does all this rubbish even need to exist.
>

Because the Internet is made up of an open market of ideas that grows
organically based on what people want.


> I think the classic example was jQuery, which should have never *needed*
> to be invented, it was huge tub of grout filler to plug the holes and
> inconsistencies in browsers.
>

Not really. It arose as an abstraction to do new things in browsers in an
easier way.

[ ... ]

I wish 20 years ago someone had created a fresh thin cross-platform program
> that just ran apps in some standard bytecode format and had nothing to do
> with html or JS (leave that to the traditional browser). Imagine if Java
> applets, Flash and Silverlight had merged into some kind of unified
> framework with a VM, a bytecode and wide language support and designers,
> and all it was designed for was running real world apps and games. That was
> my argument this morning, that browsers should have always just browsed,
> and something else should have taken its place, a "distributed app player"
> of some kind. But oh well ... a man can dream ...
>

Ah yes, the one true way to do all the things in a top-down, planned way.
Sorry, that isn't how the Internet was built.

David.

-- 
David Connors
da...@connors.com | @davidconnors | https://t.me/davidconnors | LinkedIn | +61
417 189 363

Re: Creating a browser-based product

[Craig van Nieuwkerk]

I'm not sure this is much more of an issue now than it was. Back in the day
we had to decide between Delphi, VB, Powerbuilder, C++ among others when
building a Windows app. And once we decided that we had to work out which
third party libraries we wanted to use with them.

If I take an old 15 year old Delphi app I have it would take me the best
part of a week to get it compiling again now if I had to build the dev
machine from scratch.

On Tue, Nov 21, 2017 at 3:53 PM, Greg Low  wrote:

> So then we’re back to why business apps take so very long to build
> nowadays, and why no-one can seem to decide which tools to use. Either way,
> as an industry, our productivity when building apps is poor.
>
>
>
>
>

Re: Creating a browser-based product

[Greg Keogh]

> So then we’re back to why business apps take so very long to build
> nowadays, and why no-one can seem to decide which tools to use. Either way,
> as an industry, our productivity when building apps is poor.
>

The Gregs are revolting! Indeed ... polyfills, css, bootstrap, IE, etc ...
why does all this rubbish even need to exist. I think the classic example
was jQuery, which should have never *needed* to be invented, it was huge
tub of grout filler to plug the holes and inconsistencies in browsers. And
here I am in 2017 and I can't decide which tool to use for an important new
product line.

I wish 20 years ago someone had created a fresh thin cross-platform program
that just ran apps in some standard bytecode format and had nothing to do
with html or JS (leave that to the traditional browser). Imagine if Java
applets, Flash and Silverlight had merged into some kind of unified
framework with a VM, a bytecode and wide language support and designers,
and all it was designed for was running real world apps and games. That was
my argument this morning, that browsers should have always just browsed,
and something else should have taken its place, a "distributed app player"
of some kind. But oh well ... a man can dream ...

*Greg K*

RE: Creating a browser-based product

[Tony Wright]

Yep, agreed. It takes a long time to build a consistent framework, let
alone an app. Perhaps we'll see a form builder that sits over the top of
one of these frameworks, there is already bootstrap studio. But then you're
constrained again by someone else's structure.

On 21 Nov 2017 3:53 PM, "Greg Low" <g...@greglow.com> wrote:

> So then we’re back to why business apps take so very long to build
> nowadays, and why no-one can seem to decide which tools to use. Either way,
> as an industry, our productivity when building apps is poor.
>
>
>
> Regards,
>
>
>
> Greg
>
>
>
> Dr Greg Low
>
>
>
> 1300SQLSQL (1300 775 775) office | +61 419201410 <+61%20419%20201%20410>
> mobile│ +61 3 8676 4913 <+61%203%208676%204913> fax
>
> SQL Down Under | Web: www.sqldownunder.com |http://greglow.me
>
>
>
>
>
>
>
>
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@
> ozdotnet.com] *On Behalf Of *Tony Wright
> *Sent:* Tuesday, 21 November 2017 3:44 PM
> *To:* ozDotNet <ozdotnet@ozdotnet.com>
> *Subject:* Re: Creating a browser-based product
>
>
>
> Yep, these days you abstract away the differences with polyfills. You
> build for different screen sizes using a css framework such as bootstrap.
>
>
>
> On 21 Nov 2017 3:27 PM, "David Connors" <da...@connors.com> wrote:
>
> On Tue, 21 Nov 2017 at 14:17 Greg Low <g...@greglow.com> wrote:
>
> Completely agree (that’s why I said Apples and Oranges) but you are
> describing a deployment issue no, not an app-development issue?
>
>
>
> The question is why the tools don’t abstract enough away to allow for a
> high degree of developer productivity. As an example, I can’t believe how
> much time is wasted trying to get things to look the same on different
> browsers. That’s just dead time that surely could be abstracted away.
>
>
>
> That is much less of an issue these days - esp if you just ignore the
> existence of IE.
>
>
>
> David.
>
> --
>
> David Connors
> da...@connors.com | @davidconnors | https://t.me/davidconnors
> | LinkedIn | +61 417 189 363 <+61%20417%20189%20363>
>
>

RE: Creating a browser-based product

[Greg Low]

So then we’re back to why business apps take so very long to build
nowadays, and why no-one can seem to decide which tools to use. Either way,
as an industry, our productivity when building apps is poor.



Regards,



Greg



Dr Greg Low



1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax

SQL Down Under | Web: www.sqldownunder.com |http://greglow.me









*From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
*On Behalf Of *Tony Wright
*Sent:* Tuesday, 21 November 2017 3:44 PM
*To:* ozDotNet <ozdotnet@ozdotnet.com>
*Subject:* Re: Creating a browser-based product



Yep, these days you abstract away the differences with polyfills. You build
for different screen sizes using a css framework such as bootstrap.



On 21 Nov 2017 3:27 PM, "David Connors" <da...@connors.com> wrote:

On Tue, 21 Nov 2017 at 14:17 Greg Low <g...@greglow.com> wrote:

Completely agree (that’s why I said Apples and Oranges) but you are
describing a deployment issue no, not an app-development issue?



The question is why the tools don’t abstract enough away to allow for a
high degree of developer productivity. As an example, I can’t believe how
much time is wasted trying to get things to look the same on different
browsers. That’s just dead time that surely could be abstracted away.



That is much less of an issue these days - esp if you just ignore the
existence of IE.



David.

-- 

David Connors
da...@connors.com | @davidconnors | https://t.me/davidconnors
| LinkedIn | +61 417 189 363

Re: Creating a browser-based product

[Tony Wright]

Yep, these days you abstract away the differences with polyfills. You build
for different screen sizes using a css framework such as bootstrap.

On 21 Nov 2017 3:27 PM, "David Connors"  wrote:

> On Tue, 21 Nov 2017 at 14:17 Greg Low  wrote:
>
>> Completely agree (that’s why I said Apples and Oranges) but you are
>> describing a deployment issue no, not an app-development issue?
>>
>>
>>
>> The question is why the tools don’t abstract enough away to allow for a
>> high degree of developer productivity. As an example, I can’t believe
>> how much time is wasted trying to get things to look the same on different
>> browsers. That’s just dead time that surely could be abstracted away.
>>
>
> That is much less of an issue these days - esp if you just ignore the
> existence of IE.
>
> David.
>
>> --
> David Connors
> da...@connors.com | @davidconnors | https://t.me/davidconnors | LinkedIn
>  | +61 417 189 363
>

Re: Creating a browser-based product

[David Connors]

On Tue, 21 Nov 2017 at 14:17 Greg Low  wrote:

> Completely agree (that’s why I said Apples and Oranges) but you are
> describing a deployment issue no, not an app-development issue?
>
>
>
> The question is why the tools don’t abstract enough away to allow for a
> high degree of developer productivity. As an example, I can’t believe how
> much time is wasted trying to get things to look the same on different
> browsers. That’s just dead time that surely could be abstracted away.
>

That is much less of an issue these days - esp if you just ignore the
existence of IE.

David.

> --
David Connors
da...@connors.com | @davidconnors | https://t.me/davidconnors | LinkedIn | +61
417 189 363

RE: Creating a browser-based product

[Greg Low]

Completely agree (that’s why I said Apples and Oranges) but you are
describing a deployment issue no, not an app-development issue?



The question is why the tools don’t abstract enough away to allow for a
high degree of developer productivity. As an example, I can’t believe how
much time is wasted trying to get things to look the same on different
browsers. That’s just dead time that surely could be abstracted away.





*From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
*On Behalf Of *David Connors
*Sent:* Tuesday, 21 November 2017 1:51 PM
*To:* ozDotNet <ozdotnet@ozdotnet.com>
*Subject:* Re: Creating a browser-based product



On Tue, 21 Nov 2017 at 12:18 Greg Low <g...@greglow.com> wrote:

On a recent project where after 8 months I looked at the web app that 5
people had created and realized I could have created a WinForm app by
myself in a week, and with s better UI. Agreed it’s an apples and oranges
comparison but that’s just ridiculous for us as an industry to have ended
up at that point where we think that’s acceptable.



Your WinForms app can reach 2/10th of fk all people. The web app can reach
billions.



If you want to write departmental apps quickly there is always PowerApps or
Salesforce.



David.

-- 

David Connors
da...@connors.com | @davidconnors | https://t.me/davidconnors
| LinkedIn | +61 417 189 363

Re: Creating a browser-based product

[David Connors]

On Tue, 21 Nov 2017 at 12:18 Greg Low  wrote:

> On a recent project where after 8 months I looked at the web app that 5
> people had created and realized I could have created a WinForm app by
> myself in a week, and with s better UI. Agreed it’s an apples and oranges
> comparison but that’s just ridiculous for us as an industry to have ended
> up at that point where we think that’s acceptable.
>

Your WinForms app can reach 2/10th of fk all people. The web app can reach
billions.

If you want to write departmental apps quickly there is always PowerApps or
Salesforce.

David.
-- 
David Connors
da...@connors.com | @davidconnors | https://t.me/davidconnors | LinkedIn | +61
417 189 363

Re: Creating a browser-based product

[Greg Low]

On a recent project where after 8 months I looked at the web 
app that 5 people had created and realized I could have created a WinForm app 
by myself in a week, and with s better UI. Agreed it’s an apples and oranges 
comparison but that’s just ridiculous for us as an industry to have ended up at 
that point where we think that’s acceptable.



Regards,
Greg
Dr Greg Low1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 
4913 faxSQL Down Under | Web: www.sqldownunder.com






On Tue, Nov 21, 2017 at 12:39 PM +1100, "Nathan Schultz" <milish...@gmail.com> 
wrote:










My company uses OutSystems for web-development. It isn't cheap - but it's very 
fast to develop, good quality and effective.
On 21 November 2017 at 07:34, Greg Low <g...@greglow.com> wrote:


I look at how far we’ve come in the last twenty-plus years and in terms of 
application development productivity, you’d have to wonder what we’ve all been 
smoking.

 

 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Keogh
Sent: Tuesday, 21 November 2017 9:17 AM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: Re: Creating a browser-based product

 

After the cluster fail that has been Javascript and Silverlight...

I am NOT optimistic that anything will change in a positive way real soon.

 

If you step way back and look at the last 25 years of the web, it's clear that 
the web browser should never have been used to run apps.

 

First we had html in the dumb browser, which was only good for looking at cats 
and porn.

 

Then someone decided to spice the browser experience up by knocking-up a script 
language without any proper research, design, conventions or consideration of 
the future.

 

Then someone finally decided it was wise to pull the styling out of the markup 
to give us css.

 

Then they made valiant attempts to run "real" apps inside the browser with Java 
applets, Flash and Silverlight. They all died for various reasons.

 

Then we went back to using html, css and that stupid scripting language in an 
attempt to write useful apps. The browser, the rendering, the layout and the 
language all don't interoperate properly and there are no standards for 
developers to follow. This results in every bored academic and hobbyist writing 
their own framework.

 

And here we are well into the 21st century with no robust way of creating an 
app in a web browser.

 

GK

Re: Creating a browser-based product

[Nathan Schultz]

My company uses OutSystems for web-development. It isn't cheap - but it's
very fast to develop, good quality and effective.

On 21 November 2017 at 07:34, Greg Low <g...@greglow.com> wrote:

> I look at how far we’ve come in the last twenty-plus years and in terms of
> application development productivity, you’d have to wonder what we’ve all
> been smoking.
>
>
>
>
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@
> ozdotnet.com] *On Behalf Of *Greg Keogh
> *Sent:* Tuesday, 21 November 2017 9:17 AM
> *To:* ozDotNet <ozdotnet@ozdotnet.com>
> *Subject:* Re: Creating a browser-based product
>
>
>
> After the cluster fail that has been Javascript and Silverlight...
>
> I am NOT optimistic that anything will change in a positive way real soon.
>
>
>
> If you step way back and look at the last 25 years of the web, it's clear
> that the web browser should never have been used to run apps.
>
>
>
> First we had html in the dumb browser, which was only good for looking at
> cats and porn.
>
>
>
> Then someone decided to spice the browser experience up by knocking-up a
> script language without any proper research, design, conventions or
> consideration of the future.
>
>
>
> Then someone finally decided it was wise to pull the styling out of the
> markup to give us css.
>
>
>
> Then they made valiant attempts to run "real" apps inside the browser with
> Java applets, Flash and Silverlight. They all died for various reasons.
>
>
>
> Then we went back to using html, css and that stupid scripting language in
> an attempt to write useful apps. The browser, the rendering, the layout and
> the language all don't interoperate properly and there are no standards for
> developers to follow. This results in every bored academic and hobbyist
> writing their own framework.
>
>
>
> And here we are well into the 21st century with no robust way of creating
> an app in a web browser.
>
>
>
> *GK*
>

RE: Creating a browser-based product

[Greg Low]

I look at how far we’ve come in the last twenty-plus years and in terms of
application development productivity, you’d have to wonder what we’ve all
been smoking.





*From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
*On Behalf Of *Greg Keogh
*Sent:* Tuesday, 21 November 2017 9:17 AM
*To:* ozDotNet <ozdotnet@ozdotnet.com>
*Subject:* Re: Creating a browser-based product



After the cluster fail that has been Javascript and Silverlight...

I am NOT optimistic that anything will change in a positive way real soon.



If you step way back and look at the last 25 years of the web, it's clear
that the web browser should never have been used to run apps.



First we had html in the dumb browser, which was only good for looking at
cats and porn.



Then someone decided to spice the browser experience up by knocking-up a
script language without any proper research, design, conventions or
consideration of the future.



Then someone finally decided it was wise to pull the styling out of the
markup to give us css.



Then they made valiant attempts to run "real" apps inside the browser with
Java applets, Flash and Silverlight. They all died for various reasons.



Then we went back to using html, css and that stupid scripting language in
an attempt to write useful apps. The browser, the rendering, the layout and
the language all don't interoperate properly and there are no standards for
developers to follow. This results in every bored academic and hobbyist
writing their own framework.



And here we are well into the 21st century with no robust way of creating
an app in a web browser.



*GK*

Re: Creating a browser-based product

[Craig van Nieuwkerk]

If you use Angular 2+ and Typescript it is very much like doing server side
development in C#.



On Tue, Nov 21, 2017 at 9:34 AM, Greg Keogh  wrote:

> I think what you mean is there isn't a single way of doing things with a
>> prescribed framework you like.
>>
>
> I stand by my claim that JavaScript is a disease, and I persist in the
> faith that time will prove me right. Independent of what I like.
>
> *GK*
>

Re: Creating a browser-based product

[Greg Keogh]

>
> If you step a bit back and look at the last 10 years of the web, it's
> clear that the web browser should be used to run apps.
>
https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html

[image: Inline images 1]


Touché

Re: Creating a browser-based product

[Greg Keogh]

>
> I think what you mean is there isn't a single way of doing things with a
> prescribed framework you like.
>

I stand by my claim that JavaScript is a disease, and I persist in the
faith that time will prove me right. Independent of what I like.

*GK*

Re: Creating a browser-based product

[David Connors]

On Tue, 21 Nov 2017 at 08:17 Greg Keogh  wrote:

> After the cluster fail that has been Javascript and Silverlight...
>> I am NOT optimistic that anything will change in a positive way real soon.
>>
>
> If you step way back and look at the last 25 years of the web, it's clear
> that the web browser should never have been used to run apps.
>

If you step a bit back and look at the last 10 years of the web, it's clear
that the web browser should be used to run apps.

If you look at today, it is hard to see what sort of app you wouldn't build
for the web.

https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html

First we had html in the dumb browser, which was only good for looking at
> cats and porn.
>

[ ... ]

And here we are well into the 21st century with no robust way of creating
> an app in a web browser.
>

I think what you mean is there isn't a single way of doing things with a
prescribed framework you like.

David.
-- 
David Connors
da...@connors.com | @davidconnors | https://t.me/davidconnors | LinkedIn | +61
417 189 363

Re: Creating a browser-based product

[Greg Keogh]

>
> After the cluster fail that has been Javascript and Silverlight...
> I am NOT optimistic that anything will change in a positive way real soon.
>

If you step way back and look at the last 25 years of the web, it's clear
that the web browser should never have been used to run apps.

First we had html in the dumb browser, which was only good for looking at
cats and porn.

Then someone decided to spice the browser experience up by knocking-up a
script language without any proper research, design, conventions or
consideration of the future.

Then someone finally decided it was wise to pull the styling out of the
markup to give us css.

Then they made valiant attempts to run "real" apps inside the browser with
Java applets, Flash and Silverlight. They all died for various reasons.

Then we went back to using html, css and that stupid scripting language in
an attempt to write useful apps. The browser, the rendering, the layout and
the language all don't interoperate properly and there are no standards for
developers to follow. This results in every bored academic and hobbyist
writing their own framework.

And here we are well into the 21st century with no robust way of creating
an app in a web browser.

*GK*

Re: Creating a browser-based product

[Greg Harris]

Hi Greg #1,

After the cluster fail that has been Javascript and Silverlight...
I am NOT optimistic that anything will change in a positive way real soon.

My gut tells me that Web Assembly will be the way of the future.
But ten years ago, that same gut told me, you and a lot of other people
that Silverlight would be the way of the future!
I think that Web Assembly is at about Silverlight 1.0 level about now...

By now, I would have expected a good C# implementation on Web Assembly.
So there may be some other reason why we are not getting it

Recommendation:
If you can, I would hold off a little and do a bit of study into Angular.
If MS or someone else comes out with "a nice" language for Web Assembly -
use it.
Otherwise fall back to Javascript / Angular.
Latest version of Visual Studio has much better support for Angular.
(But I have not really used it so can not advise)

Now I like Mike's idea Pascal for the web?!

The great (bad) thing about Javascript is it will not go away any time
soon! (SAD FACE)

All the best
Greg #2

Greg Harris
harris.gre...@gmail.com
phone: 0407 942 982
45/1 Russell St
Baulkham Hills
NSW 2153



On Tue, Nov 21, 2017 at 8:06 AM, Greg Keogh  wrote:

> Can you afford to wait for http://webassembly.org too get to production
>> ready???
>>
>
> A bit of reading on this does give me some optimism. The idea of a widely
> supported general purpose bytecode that runs in browsers is a great idea.
> But hang on ... haven't we been here before? What is Java bytecode, what is
> IL? Now we'll have another one, but at least is seems to be getting input
> from all the big companies. Then we pray for how long it will take before
> the developer frameworks and language bindings pop up around it. How long
> before I can write, debug and deploy a webassembly app from Visual Studio?
>
> *Greg #2*
>

Re: Creating a browser-based product

[Tony Wright]

Silverlight was sold to us as the write one work in the main browsers
solution that was going to take over. You can rightfully be sceptical of
promises of any technology. It's all tools and its a matter of picking the
best available ones at the time. Yes, web assembly might be great, but I
would hate to go head to head with the architects over whether a half baked
tool was good enough yet for the job.

On 21 Nov 2017 8:06 AM, "Greg Keogh"  wrote:

> Can you afford to wait for http://webassembly.org too get to production
>> ready???
>>
>
> A bit of reading on this does give me some optimism. The idea of a widely
> supported general purpose bytecode that runs in browsers is a great idea.
> But hang on ... haven't we been here before? What is Java bytecode, what is
> IL? Now we'll have another one, but at least is seems to be getting input
> from all the big companies. Then we pray for how long it will take before
> the developer frameworks and language bindings pop up around it. How long
> before I can write, debug and deploy a webassembly app from Visual Studio?
>
> *Greg #2*
>

Re: Creating a browser-based product

[mike smith]

On Tue, Nov 21, 2017 at 8:06 AM, Greg Keogh  wrote:

> Can you afford to wait for http://webassembly.org too get to production
>> ready???
>>
>
> A bit of reading on this does give me some optimism. The idea of a widely
> supported general purpose bytecode that runs in browsers is a great idea.
> But hang on ... haven't we been here before? What is Java bytecode, what is
> IL? Now we'll have another one, but at least is seems to be getting input
> from all the big companies. Then we pray for how long it will take before
> the developer frameworks and language bindings pop up around it. How long
> before I can write, debug and deploy a webassembly app from Visual Studio?
>
> *Greg #2*
>

What was Pascal pcode?  :)

https://en.wikipedia.org/wiki/P-code_machine

70's and 80's ??  For what it is, why does the IL need to keep getting
changed?

-- 
Meski

 http://courteous.ly/aAOZcv

"Going to Starbucks for coffee is like going to prison for sex. Sure,
you'll get it, but it's going to be rough" - Adam Hills

Re: Creating a browser-based product

[Greg Keogh]

>
> Can you afford to wait for http://webassembly.org too get to production
> ready???
>

A bit of reading on this does give me some optimism. The idea of a widely
supported general purpose bytecode that runs in browsers is a great idea.
But hang on ... haven't we been here before? What is Java bytecode, what is
IL? Now we'll have another one, but at least is seems to be getting input
from all the big companies. Then we pray for how long it will take before
the developer frameworks and language bindings pop up around it. How long
before I can write, debug and deploy a webassembly app from Visual Studio?

*Greg #2*

Re: Creating a browser-based product

[harris.greg.m]

Hi Greg,
Can you afford to wait for http://webassembly.org too get to production 
ready???That may make client side programming bearable again???Not sure about 
the time scale though...But I am expecting good things soon...I am not on the 
inside with any special knowledge (Sorry).
Sent from my phone Regards Greg #2 Harris 
 Original message From: kirsten greed <kirsten.gr...@gmail.com> 
Date: 17/11/17  12:13  (GMT+10:00) To: ozDotNet <ozdotnet@ozdotnet.com> 
Subject: Re: Creating a browser-based product 
Hi Greg
Perhaps checkout DevExtremeKirstenhttps://js.devexpress.com/
 
https://www.devexpress.com/Support/Webinars/details.xml?id=devextreme-asp-net-core-2
On Fri, Nov 17, 2017 at 10:13 AM, Craig van Nieuwkerk <crai...@gmail.com> wrote:
If you backend services are well established and you could easily put a WebAPI 
over them, then it makes sense to do a SPA and mainly Javascript front end. 
If it is an enterprisey type app then it is hard to go past Angular, 
Pluralsight is your friend to learn. I would also talk to ssw.com.au, they have 
some good courses that will get you running in the right direction quickly.
Craig
On Fri, Nov 17, 2017 at 9:14 AM, Greg Keogh <gfke...@gmail.com> wrote:
Folks, we have a serious decision to make about the future directions of our 10 
year old Silverlight product that is in wide use in some big companies. I told 
the boss I'd poll this forum for advice, so I'd really appreciate serious 
comments from people in-the-know.
The large companies using the Silverlight product are now locking down 
security, so Internet Explorer is being banned and Edge adopted, which means 
Silverlight is out (some employees are already being forced to use the product 
from home). Our product is available as Xamarin authored tablet and phone apps 
for three platforms, but they won't even allow our apps on their company 
devices.
So for the first time we are forced to produce a "browser based" version of our 
product, which apparently is acceptable to their security policies and audits. 
Here are some issues swirling in my head:The backend services to drive the 
product are established.The UIs of other product versions are explorer 
(master-detail) style, so it would be nice to maintain that feel in the 
browser.We have to display data in Excel-like tables and a variety of charts 
(the richer and more interactive the better).Should we use server-side ASP.NET 
Web Forms or MVC to drive it?Should it be browser-side SPA? (you know I hate JS 
everything, so there is personal resistance there).Could server-side and 
browser-side be combined to produce a better hybrid experience? Are there 
things to help you do that?There are development platforms such as GTK and many 
others I guess that I'm not familiar with. Are they viable?Other issues I'm 
forgetting?
I'm personally familiar with ASP.NET Web Forms and MVC, but not with quality 
JS, layout or styling. Perhaps I could write a black-and-white skeleton of the 
working product and then give it to someone to style and script (I have done 
that once before).
So in summary (I know this is a very broad question) ... if you were in my 
position, how would you proceed to produce a browser based version of a product?
Cheers,
Greg K

Re: Creating a browser-based product

[kirsten greed]

Hi Greg

Perhaps checkout DevExtreme
Kirsten
https://js.devexpress.com/

https://www.devexpress.com/Support/Webinars/details.xml?id=devextreme-asp-net-core-2

On Fri, Nov 17, 2017 at 10:13 AM, Craig van Nieuwkerk 
wrote:

> If you backend services are well established and you could easily put a
> WebAPI over them, then it makes sense to do a SPA and mainly Javascript
> front end.
>
> If it is an enterprisey type app then it is hard to go past Angular,
> Pluralsight is your friend to learn. I would also talk to ssw.com.au,
> they have some good courses that will get you running in the right
> direction quickly.
>
> Craig
>
> On Fri, Nov 17, 2017 at 9:14 AM, Greg Keogh  wrote:
>
>> Folks, we have a serious decision to make about the future directions of
>> our 10 year old Silverlight product that is in wide use in some big
>> companies. I told the boss I'd poll this forum for advice, so I'd really
>> appreciate serious comments from people in-the-know.
>>
>> The large companies using the Silverlight product are now locking down
>> security, so Internet Explorer is being banned and Edge adopted, which
>> means Silverlight is out (some employees are already being forced to use
>> the product from home). Our product is available as Xamarin authored tablet
>> and phone apps for three platforms, but they won't even allow our apps on
>> their company devices.
>>
>> So for the first time we are forced to produce a "browser based" version
>> of our product, which apparently is acceptable to their security policies
>> and audits. Here are some issues swirling in my head:
>>
>>- The backend services to drive the product are established.
>>- The UIs of other product versions are explorer (master-detail)
>>style, so it would be nice to maintain that feel in the browser.
>>- We have to display data in Excel-like tables and a variety of
>>charts (the richer and more interactive the better).
>>- Should we use server-side ASP.NET Web Forms or MVC to drive it?
>>- Should it be browser-side SPA? (you know I hate JS everything, so
>>there is personal resistance there).
>>- Could server-side and browser-side be combined to produce a better
>>hybrid experience? Are there things to help you do that?
>>- There are development platforms such as GTK and many others I guess
>>that I'm not familiar with. Are they viable?
>>- Other issues I'm forgetting?
>>
>>
>> I'm personally familiar with ASP.NET Web Forms and MVC, but not with
>> quality JS, layout or styling. Perhaps I could write a black-and-white
>> skeleton of the working product and then give it to someone to style and
>> script (I have done that once before).
>>
>> So in summary (I know this is a very broad question) ... if you were in
>> my position, how would you proceed to produce a browser based version of a
>> product?
>>
>> Cheers,
>> *Greg K*
>>
>>
>

Re: Creating a browser-based product

[Craig van Nieuwkerk]

If you backend services are well established and you could easily put a
WebAPI over them, then it makes sense to do a SPA and mainly Javascript
front end.

If it is an enterprisey type app then it is hard to go past Angular,
Pluralsight is your friend to learn. I would also talk to ssw.com.au, they
have some good courses that will get you running in the right direction
quickly.

Craig

On Fri, Nov 17, 2017 at 9:14 AM, Greg Keogh  wrote:

> Folks, we have a serious decision to make about the future directions of
> our 10 year old Silverlight product that is in wide use in some big
> companies. I told the boss I'd poll this forum for advice, so I'd really
> appreciate serious comments from people in-the-know.
>
> The large companies using the Silverlight product are now locking down
> security, so Internet Explorer is being banned and Edge adopted, which
> means Silverlight is out (some employees are already being forced to use
> the product from home). Our product is available as Xamarin authored tablet
> and phone apps for three platforms, but they won't even allow our apps on
> their company devices.
>
> So for the first time we are forced to produce a "browser based" version
> of our product, which apparently is acceptable to their security policies
> and audits. Here are some issues swirling in my head:
>
>- The backend services to drive the product are established.
>- The UIs of other product versions are explorer (master-detail)
>style, so it would be nice to maintain that feel in the browser.
>- We have to display data in Excel-like tables and a variety of charts
>(the richer and more interactive the better).
>- Should we use server-side ASP.NET Web Forms or MVC to drive it?
>- Should it be browser-side SPA? (you know I hate JS everything, so
>there is personal resistance there).
>- Could server-side and browser-side be combined to produce a better
>hybrid experience? Are there things to help you do that?
>- There are development platforms such as GTK and many others I guess
>that I'm not familiar with. Are they viable?
>- Other issues I'm forgetting?
>
>
> I'm personally familiar with ASP.NET Web Forms and MVC, but not with
> quality JS, layout or styling. Perhaps I could write a black-and-white
> skeleton of the working product and then give it to someone to style and
> script (I have done that once before).
>
> So in summary (I know this is a very broad question) ... if you were in my
> position, how would you proceed to produce a browser based version of a
> product?
>
> Cheers,
> *Greg K*
>
>

Re: Creating a browser-based product

[Tony Wright]

Also, I highly recommend investing the time in doing some pluralsight
courses on whichever tech you choose. The value I got from doing that was
immense.

On 17 Nov 2017 9:14 AM, "Greg Keogh"  wrote:

> Folks, we have a serious decision to make about the future directions of
> our 10 year old Silverlight product that is in wide use in some big
> companies. I told the boss I'd poll this forum for advice, so I'd really
> appreciate serious comments from people in-the-know.
>
> The large companies using the Silverlight product are now locking down
> security, so Internet Explorer is being banned and Edge adopted, which
> means Silverlight is out (some employees are already being forced to use
> the product from home). Our product is available as Xamarin authored tablet
> and phone apps for three platforms, but they won't even allow our apps on
> their company devices.
>
> So for the first time we are forced to produce a "browser based" version
> of our product, which apparently is acceptable to their security policies
> and audits. Here are some issues swirling in my head:
>
>- The backend services to drive the product are established.
>- The UIs of other product versions are explorer (master-detail)
>style, so it would be nice to maintain that feel in the browser.
>- We have to display data in Excel-like tables and a variety of charts
>(the richer and more interactive the better).
>- Should we use server-side ASP.NET Web Forms or MVC to drive it?
>- Should it be browser-side SPA? (you know I hate JS everything, so
>there is personal resistance there).
>- Could server-side and browser-side be combined to produce a better
>hybrid experience? Are there things to help you do that?
>- There are development platforms such as GTK and many others I guess
>that I'm not familiar with. Are they viable?
>- Other issues I'm forgetting?
>
>
> I'm personally familiar with ASP.NET Web Forms and MVC, but not with
> quality JS, layout or styling. Perhaps I could write a black-and-white
> skeleton of the working product and then give it to someone to style and
> script (I have done that once before).
>
> So in summary (I know this is a very broad question) ... if you were in my
> position, how would you proceed to produce a browser based version of a
> product?
>
> Cheers,
> *Greg K*
>
>

Re: Creating a browser-based product

[Tony Wright]

Hi Greg,

If you want something as swish as what silverlight gives you, I don't know
how you could achieve that easily without learning css and without using a
responsive, progressively loading spa.

I personally do angular (currently at version 5) and it gives me everything
that I need to build an impressive looking cross browser app. To support
older browsers you use polyfills. I also use typescript, not javascript.
Typescript is a better version of javascript.

I chose angular because it provides the whole client side framework out of
the box. The only other candidate that does this that is in wide-ish use is
Aurelia.

Other alternatives are React (use with another tech called Redux) and Vue.

Microsoft now has a built in template for developing either angular or
react with redux. You can get templates for Vue and Aurelia directly from
the javascript services web site.

I also use google material design as the user interface guidelines as it
gives me a clean consistent user interface design framework for people that
aren't that great at ui.

Kind regards,
Tony



On 17 Nov 2017 9:14 AM, "Greg Keogh"  wrote:

> Folks, we have a serious decision to make about the future directions of
> our 10 year old Silverlight product that is in wide use in some big
> companies. I told the boss I'd poll this forum for advice, so I'd really
> appreciate serious comments from people in-the-know.
>
> The large companies using the Silverlight product are now locking down
> security, so Internet Explorer is being banned and Edge adopted, which
> means Silverlight is out (some employees are already being forced to use
> the product from home). Our product is available as Xamarin authored tablet
> and phone apps for three platforms, but they won't even allow our apps on
> their company devices.
>
> So for the first time we are forced to produce a "browser based" version
> of our product, which apparently is acceptable to their security policies
> and audits. Here are some issues swirling in my head:
>
>- The backend services to drive the product are established.
>- The UIs of other product versions are explorer (master-detail)
>style, so it would be nice to maintain that feel in the browser.
>- We have to display data in Excel-like tables and a variety of charts
>(the richer and more interactive the better).
>- Should we use server-side ASP.NET Web Forms or MVC to drive it?
>- Should it be browser-side SPA? (you know I hate JS everything, so
>there is personal resistance there).
>- Could server-side and browser-side be combined to produce a better
>hybrid experience? Are there things to help you do that?
>- There are development platforms such as GTK and many others I guess
>that I'm not familiar with. Are they viable?
>- Other issues I'm forgetting?
>
>
> I'm personally familiar with ASP.NET Web Forms and MVC, but not with
> quality JS, layout or styling. Perhaps I could write a black-and-white
> skeleton of the working product and then give it to someone to style and
> script (I have done that once before).
>
> So in summary (I know this is a very broad question) ... if you were in my
> position, how would you proceed to produce a browser based version of a
> product?
>
> Cheers,
> *Greg K*
>
>

Creating a browser-based product

[Greg Keogh]

Folks, we have a serious decision to make about the future directions of
our 10 year old Silverlight product that is in wide use in some big
companies. I told the boss I'd poll this forum for advice, so I'd really
appreciate serious comments from people in-the-know.

The large companies using the Silverlight product are now locking down
security, so Internet Explorer is being banned and Edge adopted, which
means Silverlight is out (some employees are already being forced to use
the product from home). Our product is available as Xamarin authored tablet
and phone apps for three platforms, but they won't even allow our apps on
their company devices.

So for the first time we are forced to produce a "browser based" version of
our product, which apparently is acceptable to their security policies and
audits. Here are some issues swirling in my head:

   - The backend services to drive the product are established.
   - The UIs of other product versions are explorer (master-detail) style,
   so it would be nice to maintain that feel in the browser.
   - We have to display data in Excel-like tables and a variety of charts
   (the richer and more interactive the better).
   - Should we use server-side ASP.NET Web Forms or MVC to drive it?
   - Should it be browser-side SPA? (you know I hate JS everything, so
   there is personal resistance there).
   - Could server-side and browser-side be combined to produce a better
   hybrid experience? Are there things to help you do that?
   - There are development platforms such as GTK and many others I guess
   that I'm not familiar with. Are they viable?
   - Other issues I'm forgetting?


I'm personally familiar with ASP.NET Web Forms and MVC, but not with
quality JS, layout or styling. Perhaps I could write a black-and-white
skeleton of the working product and then give it to someone to style and
script (I have done that once before).

So in summary (I know this is a very broad question) ... if you were in my
position, how would you proceed to produce a browser based version of a
product?

Cheers,
*Greg K*