>>Whether solutions are componentized and maintainable or not has absolutely nothing to do with web bases vs desktop apps. SAP grew huge on this concept before the web became hot.

>Big apps are big apps and any way you slice it building them is hard. You can build an enterprise system as a single developer in many years worth of time. But it took years to get there and maintain that. Why should it be any different on the Web platform if you were to build that now? It isn't.

Agreed, but you were arguing that componization was a Web specific feature, where I pointed out, it isn't.

>My point is that if you start with Web in the first place the difference in building it in terms of resources is not necessarily more expensive than a desktop app. Sure if you learn the Web as a platform as you go - yeah - that'll cost you. But if you are as familiar with the platform as you are with VFP let's say the productivity is no worse.

>This is the fallacy that I see in the belief by many that VFP is/was this miracle tool that did things better than what newer tools do. Granted it was very good at its focused feature set - especially for the time. But technology has gone a different way and to be honest once you accept that the VFP way is not the only or the best way you realize that there's a reason that technology has marched on in the direction it has. Other technologies look hard and confusing but what technology doesn't when you start from ground zero? There's a lot to learn yes, but what you need to know is typically not very difficult to pick up. After think about what all the kids fresh out of school are doing. If they can do it without a wealth of 25+ years of knowledge surely it can't be that difficult?

I do not think many developers will regard VFP as a miracle tool today, me not even a decade and a half ago when I first met Navision. Today the tools that I would use are more SAAS oriented. Tools that VFP should have evolvded into. Unfortunately, MS decided otherwise.

Writing regular business apps IMO, are much better done through those tools where the complexity of the web is taken for you, so that you can focus on solving business problems, rather than dealing with the ever changing technology and its problems in web technologies. Sure it might not be as sexy, but that is not the focus unless you're trying to sell to the public rather than the corporate world.

>Applications are distributed today, spread out over the network with smaller components interacting, rather than building one monolithic application that does everything. There's additional complexity there no doubt, but it also provides a lot more flexibility in where you can run and access these applications compared to desktop apps.

Not sure why you focus on desktop apps again. For example, our product has one desktop app, another one will be developed and delivered before the end of the year, a web app, text message service, HL7 services, medical hardware interfaces, and smaller apps that run on a network to interface with medical hardware. Creating components have nothing to do with either desktop or web technology.

>As you have pointed out there are things that are difficult to do - like interacting with old hardware that's not network aware (today you can find most components that ARE network controllable and many hardware related tasks can be actuallly be handled by servers that drive hardware on other machines (print server, networked scanners etc.).

>To give some perspective, I recently was involved in a high volume printing project where the front end app has ~hundred workers on the floor printing to a variety of custom print devices all controlled from a central print server. They essentially take print orders, modify them, then assign them out very rapidly. This is a high turnaround work flow where workers are rapidly churning through products to print generating hundreds to thousands of requests on the backend a minute.

< SNIP >

>The other thing about this app is that it's continuously updated. The app changes nearly every other day. You can't do that easily with desktop apps running on a hundred workstations. With the Web app we update the server and everybody is up to date. You don't end up a shipping a big pile of new features and fixes at once, rather you continuously roll out fixes and updates on a consistent basis. And if stuff breaks? You roll back source control and redeploy.

Eh... we are doing that all the time with our desktop app. We can update the desktop app while users are using the system, since they are using a launcher. The next time they restart the app, they will get the new version. Since the database is SQL server, changes to the data model can be made while users are working,
I must say that while this is very easy to do is that we usually schedule updates, rather than doing it in the middle of the day. But it can, and we are doing that if we need to fix a bug that is a shopstopper to the client.

As for smaller updates. Again this has absolutely nothing to do with Web apps vs Desktop apps. We are releasing builds for release about once a month, with smaller builds in between. There is a lifecycle involved where a team of developers work on the product, testers that have to validate the work, writing release notes and support that has to install it at clients. Things are different when you have a vertical market application where regular updates are part of the maintenance contract, as opposed to a single instance app as you describe above.

As interesting your product sounds, I haven't read anything in your description that made this project such that it had to be written for the Web. In fact is was working with VFP but was not performing well anymore (for whatever reason). So where is the advantage, over that the Web stack was in your toolbox?


>Again, I realize this is one example and maybe not representative of every situation, but I think it recognizes that you can most definitely tackle many problems that you might think are not possible the same way you solve those problems on desktop or local network apps.

I realise that things improve in web development land, but for joe average it is still encredibly difficult IMO, to create fully functional apps, something that you're story seems to confirm. All credits to you to complete the project sucessfully, but I'm less optimistic for the lesser gods.


Walter,

>+++ Rick ---
>
>>Rick,
>>
>>>>We're going more than 20 years back. Surely I would have expected to make some progress on cross platform development in 2015. And really, the reason it failed has little to do with the technology, but rather the money. The other platforms didn't sell at the time.
>>
>>>Possibly, but even before that became an issue think about how crappy the Mac version of VFP really was. Likewise think about Java and the crappy experience you get on every platform it runs on. The UI looks 'wrong' on all of them.
>>
>>The thing that you keep overlooking, that it has not have to be that way. There really isn't a technical reason for it other than that there hasn't been put enough resources into it. The main reason for that is that its apparently is very difficult to sell something cross platform. But that is a commercial reason, not a technical one.
>>
>>>>BTW, there is not much in terms of custom windows management in VFP. Windows in VFP are real windows. it is just that the controls are not windows as in other development environments. YMMV, but I never had any significant problems in terms of dealing with VFP controls, nor my clients have ever noticed the difference. I know there are difference in the way that certain controls behave, but they are pretty minor. I doubt whether any user would notice. And BTW wouldn't this apply to all the other applications with owner drawn controls?
>>
>>>Well, it's noticable to me and noticable enough for my customers/clients to have gotten quite a few complaints over the years in the past. There are common things like the way lists behave (hotkeys are wrong, navigation behavior is wrong), the way many controls look (borders and padding and shortcut menus), and then there are a number of nasty UI quirks related to QuickType (yeah there's a workaround for that but it's inefficient and a major PITA). I'm sure I'm forgetting a few others. These are all things that do matter if you care about building a nice UI, which after all is why you'd build a desktop app anymore in the first place.
>>
>>I've been in this business for about 25 years and have been building VFP applications since then, but I've never heard anything substantial that I could related back to the custom drawn controls of VFP. Can you give me an example of what compaints you got ?
>>
>>>Otherwise who builds a desktop application anymore for business apps? If you go out looking for vertical apps in specific markets you'll find that almost all of those things are now Web based solutions either offered as a service or deployable Web applicatinos that can run on in-house servers. Other than some very specialized services or certain hardware dependent features, very little is done on the desktop anymore.
>>
>>Really??? You must be living in an entirely different world than I do. Are you running office 365? or just the plain desktop version. Is you scanner application web based? Navision, web based? How about SPS for statistiscal analysis? Cash register applications, accounting software? The latest video games? There are lots of business apps that are desktop based because the web does not fit for a wide variaty of reasons.
>>
>>In our business where our apps need to have direct connectivity to connected (e.g. medical) hardware, web solutions are pretty rare. Those out there are pretty crappy in functionality (we've replaced a few ones). Web apps still cannot match desktop apps when it comes to automation and connectivity. Office automation through a web app, connecting to network scanners, audio, video, image capture, DICOM connectivity. I haven't looked in a while but those thing are very hard or impossible to do through a web browser.
>>
>>>>An this is the point, weI, and our clients do not give a hoot about the "exact users feel" of the application because a control looks or behaves a bit different, as long as the functionality is there. Now it seems we are stuck because we demand the same look and feel as native apps on each given platform. That will just take time to develop over time.
>>
>>>>>This dream of building an app once and have it run everywhere is just a pipe dream, at least if you want to build something that doesn't look like a cookie cutter enterprise app. There are tools for that like Servoy that do a decent job of that, but for custom development that's not an option. The same goes for Mobile. You don't want a one size fits all for mobile as mobile devices have different styles and behaviors and functionality.
>>>>
>>>>I share your observation, but not your conclusion. It should not have been this way. Servoy indeed is an example that proves that it does not have to be that way.
>>>
>>>Well we differ in what we consider a custom solution and what qualifies as 'cookie cutter' I guess.
>>
>>Again, functionality goes over pretty UI experience. Many of our clients are working through ancient AS400 software, outdated and klunky EMRs, even top medical centers. Why do you think that is? We are selling for to solve a specific business problem in a niche market, not to make money on a slick good looking application (Though ours does not look that bad, using commandbars and office themes) that people buy for its 'user experience'.
>>
>>>>Its just that the platform itself is expensive to deploy. I hope SAAS solutions will pickup and we get away from writing in solutions where you need to master a full set of different techniques and languages on each and every layer/tier. I've been at the servoy headquartes in Amersfoort to talk about moving our product to the servoy platform and was impressed with what they accomplished in 10 years in terms of this goal. Unfortunately, our app has 20 years of VFP development and is so huge that it would take years to port over to servoy. That is not something we can afford at the moment, but If I had to write it from scratch, I would certainly take Servoy, Lianja, Windev or even Navision for that matter to write application bottom up.
>>>
>>>>I'm sure you agree that it is next to impossible for a single soul to develop, troubleshoot and maintain a single web based app that needs to have enterprise functionality. What went wrong?? Because we were doing exactly that until those applications had to run through the web.
>>
>>>Again not sure what you mean. It's totally possible. It's possible for a one man shop to build an enterprise level application and either build it for a customer or a vertical and sell it and manage it - it's totally possible. I have many customers who do just that and I do it with a number of medium sized apps myself.
>>
>>Our experience is different. We are selling a web based component to our EMR, but it was hard, really hard to get that done.
>>We either do not have the right programmers, or our requirements on what we want are too high.
>>
>>>There are so many more opportunities today for developers to make their stuff available over the Web than 20 years ago. Building services, building SaaS applications, making for sale content or procducts available. All of that wasn't possible 20 years ago.
>>
>>I agree, that is the case, but that is no thanks to the webbrowser HTML/CSS/Javascript platform. Its something that we have to work with (or with LAMP), because there were not so many alternatives. But really, if you really think about it, It should be possible to write a web app without having the knowledge of 7+ technlologies to get something installed. It should have been as simple as building a desktop app, Write in a single language, compile, deploy and run without having to deal with all the other stuff. That is why I like SAAS solutions, because they have exactly this goal.
>>
>>
>>>Do you have to know a lot of stuff? Sure - it's not trivial. Yet there are millions of developers out there today - more than for anything else - building Web and Cloud applications on the Web stack today and a good chunk of them manage to be able to do all that is required to make that happen. It's not because they're smarter than you or me - it's that they grew up understanding that there are many technologies that you can pick and choose from to build the best of breed application instead of monolithic beasts that become impossible to maintain due to complexity. These days most 'enterprise' apps are build as componentized services that are parceled out into manageable chunks that are much easier to build and maintain.
>>
>
>
>>
>>>>Its not primitive in functionality, but primitive in its RAD capabilities, crude and 3GL like. Why isn't there a universal GUI builder? it lacks any OO design and for the vast majority is build in text editers without a decent EDI. I recognize that this is not going to change in the near future, but what you see happening is that there are tools hiding the complexity of HTML and JavaScript, but still its next to impossible to get away from those languages as when you want anything more complex. Its like coding in assembly while you're looking for something like C++, C# or even VFP. yes, you have ultimate control, but at what expense?
>>
>>>LOL! Seriously? Clearly you're not looking hard enough.
>>
>>??? for what ?
>>
>>>And if you think VFP had a good IDE, I don't know what to tell you... VFP's IDE might have been decent when it was current but today it's a long way behind other tools. VFP intellisense has always been a half-baked joke. For Web dev look at WebStorm and Visual Studio (and Eclipse) provide very rich IDEs for Web development, with excellent Intellisense, design tooling and much more. For scaffolding tools like Yeoman provide many great startup templates and generators for popular fraemworks.
>>
>>Who is saying that VFPs' IDE is good? The tools you mention are not universal tools for writing HLTM, CSS, Javascript solutions, only be used by a fraction of developers with lifetimes that are absolutely unsure. How many technologies have we seen come and go? How many tools? Its one absolute chaos on what to use. You might recommend one set of tools today, next your it might be entirely different.
>>
>>>Yeah there are no good UI editors and that's mainly because that's been rejected as a feature by developers - mainly because nobody was able to actually build a decent HTML editor because HTML is not like classic desktop apps with a pixel based canvas. Building rich designers for flow layouts that work with many things is very difficult - not just for HTML but also for things like WPF and Flash before it. The main reason it worked for desktop apps is because there was fixed size positional layout. But that paradigm no longer works, if you want to build applications that can run on multiple devices. I suppose it should be possible
>>>to build decent WYSIWYG editors, but this has become a derided feature so I doubt anybody will build one.
>>
>>Which is a shame and exactly my point.
>>
>>>Does that matter? Not sure. I used to think I can't build anything without visual layout, but today I build UIs with CSS frameworks and am perfectly fine using markup text and live previewing the content in the browser and I find that more efficient (especially if you use keyboard templates in WebStorm or Visual Studio).
>>
>>>>In the end, I believe a new platform will be developed that will hide all the complexities and incompatibilities of CSS, HTML, JavaScript, IIS, JQuery etc, because it is just a nightmare to develop, support and maintain something beyond a simple website with limited database functionality.
>>
>>>It's a nightmare because you've convinced yourself it is. Somehow it's the most popular development choice, and the choice of the new generation of young developers coming in as well as the choice for much of the high end set of developers. Yet you label it a nightmare. Perspective...
>>
>>Its a nightmare because of the experience we had with it.
>>
>>>I agree that there's a lot of room for improvement in Web development, but if HTML/CSS/JS was going to be replaced it would have happened already. Instead we're seeing it getting ever more popular, JavaScript in particular with JavaScript and Node having long become the most popular and most used development language. It'll be VERY difficult to unset this platform.
>>
>>I could not disagree more with this, as technology has proven over and over, it is not the best technology that wins, its the one that gets most popular for whatever reason. Why did OS2 not make it while technically much better than Windows 95? Why did Betamax lose from VHS? As for a simple app developer we should not have to deal with 7+ different technologies/tools to get it to work. It just does not make any sense to me.
>>
>>>As I mentioned we're on the cusp of a wave of new technologies for JavaScript and I think in terms of language features we'll see much more variety in you'll be able to use JavaScript via transpilers. But in the end I think we won't see the JavaScript/HTML/CSS stack go away anytime soon. It's been the tool of choice for many good reasons even if there are still a lot of warts.
>>
>>I do not mind it to be there, but hide it from the poor developer, just like a C# or VFP developer does not need to know how it compiles to machine code.
>>
>>Walter,