RE: Creating a browser-based product
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
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
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" 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 on > behalf of William Luu > *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 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 fam
RE: Creating a browser-based product
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 on behalf of William Luu 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 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
> > 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
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
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
Node.js is only used to manage the dependencies of an angular 2 application. If you can somehow manage to get those dependencies without using node.js, npm or jspm then you can run and develop your application offline. However, doing it manually will take an inexorable amount of time since you have to download files manually which may have other dependencies which will require other files to be downloaded again (yes I've been there). node.js or npm or jspm for that matter automates this process as well as taking all the necessary steps of configuring the files (jspm) so that whenever you use a particular dependency in your application, that particular dependency's other dependency will also be present in your system. https://stackoverflow.com/questions/26398537/do-i-need-node-js-to-use-angularjs Regards Adrian Halid From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Keogh Sent: Wednesday, 29 November 2017 8:40 AM 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
> > 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
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
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. On Wed, Nov 29, 2017 at 11:39 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
> > 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
hahaha that image is great On Wed, Nov 29, 2017 at 6: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
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
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
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
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
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 Subject: Re: Creating a browser-based product https://www.itnews.com.au/news/microsofts-vmware-azure-stack-neither-certified-nor-supported-478352?eid=1&edate=20171124&utm_source=20171124_AM&utm_medium=newsletter&utm_campaign=daily_newsletter But yeah, VMware would say that, I guess. On Wed, Nov 22, 2017 at 5:12 PM, David Connors mailto:da...@connors.com>> wrote: On Wed, 22 Nov 2017 at 12:43 Ken Schaefer 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
https://www.itnews.com.au/news/microsofts-vmware-azure-stack-neither-certified-nor-supported-478352?eid=1&edate=20171124&utm_source=20171124_AM&utm_medium=newsletter&utm_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
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
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
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&feature=youtu.be&t=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
> > 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
I assume you're referring to Steve Sanderson's Blazer project - "Experimental UI framework running .NET in the browser via webassembly"? https://github.com/SteveSanderson/Blazor David On 22 November 2017 at 21:20, David Connors wrote: > WebAssembly? You could port the clr to it so you can run webforms in a > browser. Greg will want to have your babies as a result. > > On Wed., 22 Nov. 2017, 8:48 pm Tony Wright, wrote: > >> After all this time it means that the browser is ripe for disruption, and >> it might not even be a variant of what we've been doing so far... But what >> is it?What would it look like? >> >> On 22 Nov 2017 8:38 PM, "Ken Schaefer" wrote: >> >>> *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@ >>> ozdotnet.com] *On Behalf Of *Greg Harris >>> *Sent:* Wednesday, 22 November 2017 3:44 PM >>> *To:* ozDotNet >>> *Subject:* Re: Creating a browser-based product >>> >>> >>> >>> Plugins like Silverlight and Flash made web apps open to using a lot >>> more of the client machine’s resources to provide an interactive >>> experience. But, the industry has not supported these plugins for some >>> reason I fail to fully understand. >>> >>> Because Adobe Flash was more bugs than actual working code? The cost of >>> supporting Flash made it unappealing to people who pay the bills? >>> >>> If we cannot use Silverlight or Flash and fat clients are too hard / >>> expensive to install, you are back to the dumb terminal browser plus >>> Javascript again. >>> >>> Yes, and no. There’s offline storage, and some execution, that can be >>> offloaded to browsers. >>> >>> Look at compute intensive apps like 3D modelling or video editing, they >>> could never be done properly with today’s browser technology! >>> >>> Nothing is binary. At some point, the benefit of running a thick client >>> native app is greater than the cost of maintaining it. >>> >>> But those use cases seem to be shrinking year-on-year. >>> >>> Or maybe even a win forms app, because it is fast, I have 100% control *and >>> it is not really that hard to install*! >>> >>> The technical cost of your one app isn’t that much. But the total cost >>> of supporting a desktop does not increase linearly with the number of apps. >>> It increases exponentially, and thus doesn’t scale. >>> >>> >>> >> -- > David Connors > da...@connors.com | @davidconnors | https://t.me/davidconnors | LinkedIn > | +61 417 189 363 >
Re: Creating a browser-based product
WebAssembly? You could port the clr to it so you can run webforms in a browser. Greg will want to have your babies as a result. On Wed., 22 Nov. 2017, 8:48 pm Tony Wright, wrote: > After all this time it means that the browser is ripe for disruption, and > it might not even be a variant of what we've been doing so far... But what > is it?What would it look like? > > On 22 Nov 2017 8:38 PM, "Ken Schaefer" wrote: > >> *From:* ozdotnet-boun...@ozdotnet.com [mailto: >> ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Greg Harris >> *Sent:* Wednesday, 22 November 2017 3:44 PM >> *To:* ozDotNet >> *Subject:* Re: Creating a browser-based product >> >> >> >> Plugins like Silverlight and Flash made web apps open to using a lot more >> of the client machine’s resources to provide an interactive experience. >> But, the industry has not supported these plugins for some reason I fail to >> fully understand. >> >> Because Adobe Flash was more bugs than actual working code? The cost of >> supporting Flash made it unappealing to people who pay the bills? >> >> If we cannot use Silverlight or Flash and fat clients are too hard / >> expensive to install, you are back to the dumb terminal browser plus >> Javascript again. >> >> Yes, and no. There’s offline storage, and some execution, that can be >> offloaded to browsers. >> >> Look at compute intensive apps like 3D modelling or video editing, they >> could never be done properly with today’s browser technology! >> >> Nothing is binary. At some point, the benefit of running a thick client >> native app is greater than the cost of maintaining it. >> >> But those use cases seem to be shrinking year-on-year. >> >> Or maybe even a win forms app, because it is fast, I have 100% control *and >> it is not really that hard to install*! >> >> The technical cost of your one app isn’t that much. But the total cost of >> supporting a desktop does not increase linearly with the number of apps. It >> increases exponentially, and thus doesn’t scale. >> >> >> > -- David Connors da...@connors.com | @davidconnors | https://t.me/davidconnors | LinkedIn | +61 417 189 363
RE: Creating a browser-based product
After all this time it means that the browser is ripe for disruption, and it might not even be a variant of what we've been doing so far... But what is it?What would it look like? On 22 Nov 2017 8:38 PM, "Ken Schaefer" wrote: > *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@ > ozdotnet.com] *On Behalf Of *Greg Harris > *Sent:* Wednesday, 22 November 2017 3:44 PM > *To:* ozDotNet > *Subject:* Re: Creating a browser-based product > > > > Plugins like Silverlight and Flash made web apps open to using a lot more > of the client machine’s resources to provide an interactive experience. > But, the industry has not supported these plugins for some reason I fail to > fully understand. > > Because Adobe Flash was more bugs than actual working code? The cost of > supporting Flash made it unappealing to people who pay the bills? > > If we cannot use Silverlight or Flash and fat clients are too hard / > expensive to install, you are back to the dumb terminal browser plus > Javascript again. > > Yes, and no. There’s offline storage, and some execution, that can be > offloaded to browsers. > > Look at compute intensive apps like 3D modelling or video editing, they > could never be done properly with today’s browser technology! > > Nothing is binary. At some point, the benefit of running a thick client > native app is greater than the cost of maintaining it. > > But those use cases seem to be shrinking year-on-year. > > Or maybe even a win forms app, because it is fast, I have 100% control *and > it is not really that hard to install*! > > The technical cost of your one app isn’t that much. But the total cost of > supporting a desktop does not increase linearly with the number of apps. It > increases exponentially, and thus doesn’t scale. > > >
RE: Creating a browser-based product
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Harris Sent: Wednesday, 22 November 2017 3:44 PM To: ozDotNet Subject: Re: Creating a browser-based product Plugins like Silverlight and Flash made web apps open to using a lot more of the client machine’s resources to provide an interactive experience. But, the industry has not supported these plugins for some reason I fail to fully understand. Because Adobe Flash was more bugs than actual working code? The cost of supporting Flash made it unappealing to people who pay the bills? If we cannot use Silverlight or Flash and fat clients are too hard / expensive to install, you are back to the dumb terminal browser plus Javascript again. Yes, and no. There’s offline storage, and some execution, that can be offloaded to browsers. Look at compute intensive apps like 3D modelling or video editing, they could never be done properly with today’s browser technology! Nothing is binary. At some point, the benefit of running a thick client native app is greater than the cost of maintaining it. But those use cases seem to be shrinking year-on-year. Or maybe even a win forms app, because it is fast, I have 100% control and it is not really that hard to install! The technical cost of your one app isn’t that much. But the total cost of supporting a desktop does not increase linearly with the number of apps. It increases exponentially, and thus doesn’t scale.
Re: Creating a browser-based product
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
> > 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
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
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" 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 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" 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 >>> *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, regar
Re: Creating a browser-based product
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 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" 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 >> *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 on >> behalf of Ken Schaefer >> *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 t
RE: Creating a browser-based product
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" 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 > *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 on > behalf of Ken Schaefer > *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 ] *On Behalf Of *Greg Low > *Sent:* Wednesday, 22 November 2017 1:35 PM > *To:* ozDotNet > *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
Inline From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Low Sent: Wednesday, 22 November 2017 2:09 PM To: ozDotNet 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 mobile│ +61 3 8676 4913 fax SQL Down Under | Web: www.sqldownunder.com<http://www.sqldownunder.com> From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> mailto:ozdotnet-boun...@ozdotnet.com>> on behalf of Ken Schaefer mailto: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> [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Low Sent: Wednesday, 22 November 2017 1:35 PM To: ozDotNet mailto: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
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 on behalf of Ken Schaefer 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 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 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 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" 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 y
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 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 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 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" 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 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 lon
RE: Creating a browser-based product
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 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" 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" 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 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 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 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
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 *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 ] *On Behalf Of *Greg Low *Sent:* Tuesday, 21 November 2017 7:26 PM *To:* ozDotNet *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" 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 *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 *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 t
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] On Behalf Of Greg Low Sent: Tuesday, 21 November 2017 7:26 PM To: ozDotNet 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" 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 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 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 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
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, 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 > *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 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
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 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
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
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
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
http://issurvivor.com/2017/11/20/opinionization-in-the-cloud/ On 21 Nov. 2017 22:15, "mike smith" 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" 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 > *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 > *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 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
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" 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 *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 *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 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
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
> > 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
> 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
> > 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
On Tue., 21 Nov. 2017, 6:29 pm Greg Low, 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 > *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 ] *On > Behalf Of *Greg Low > *Sent:* Tuesday, 21 November 2017 5:51 PM > *To:* ozDotNet > *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 > *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 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
On Tue., 21 Nov. 2017, 4:50 pm Greg Low, 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 > *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 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
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 *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" 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 *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 *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 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
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" 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 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 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 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
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 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 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 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
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" 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 > *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 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
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 *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 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
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
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
> 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
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" 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 > *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" 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 <+61%20417%20189%20363> > >
RE: Creating a browser-based product
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 *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" 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
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
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
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 *Subject:* Re: Creating a browser-based product 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
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
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" 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 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 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
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 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 > *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
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 *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
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
> > 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
> > 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
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
> > 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
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
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
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
> > 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
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 Date: 17/11/17 12:13 (GMT+10:00) To: ozDotNet 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 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
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
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
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
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
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*