Thanks. All good stuff. what is "DRY, YAGNI, (chunky, not chatty)".

Albert



>>If the task were creating a totally new app, Electron would probably first thing I'd reccommend to check. But as this is a port on a local LAN, users are probably accustomed to minimal protocol overhead incurred between data store and client machine. Electron apps often include web-typical ORM layers plus protocol "conversions" (is JSON a conversion for Javascript ?), which do typically not matter when accessing via internet, as internet latency is greater than protocol overhead. Even with Javascript JIT code/function call speed running circles around poor old vfp p-code interpreter speeds, complexity of ORM layers plus transfer protocol might make ported app slower than old app if sizeable data is moved between client and remote data store. Such a result would not be allowed in a port - in a new app, fine tuning would be scheduled, whereas a port would be ridiculed and scuttled ;-)
>
>It really depends on what you're after. If you're trying to build a Web like applicaiton for the the desktop then Electron is fine.
>
>But if you're trying to build a super interactive desktop app that reflects the host OS features, then Electron is much more of a hard sell because you have to build all the UI components that behave properly yourself. AFAIK, there are no decent **desktop HTML/JS libraries** out there that provide the things that most desktop applications are expected to have which includes rich menus, drag and drop between windows including OS components, OS integrated text controls (Datetime, autocomplete with OS recent lists, context menus etc). There are lots of Web UI libraries, but most are not really adequate for desktop application IMHO - unless you just don't care about those details. It's kind of like FoxPro's UI at that point. It works but it doesn't fit unless you use a lot of add-on hacks.
>
>I started a couple of projects with Electron and eventually abandoned them because of the difficulty in building a nice looking UI that worked for desktop...
>
>
>
>>Full ACK again. I ALWAYS argue for a pure maintainance architecture rewrite in vfp using same tests as before to create a clean and layered source to start porting from. Replacing layers stepwise over time during a few release circles can be cheaper by a magnitude - including the maintainance effort for the "unneccessary" rewrite/rearchitecture of the to-be-abandoned fox code.
>>
>>Keeps feature creep at bay, commitee meeting time down, needs only small enhancement of dev crew, allows development following a mostly single source tree with branches always close to trunk ;-)
>
>Yes - doing a rewrite is always difficult because of - expectations. Users will expect the same functionality of the old, while also expecting it to be better. Making incremental updates more tricky IMHO. Ultimately the goal should always be to build a more maintainable application which is a large chunk of why re-writes get done. Part of hte problem is usually that while the desire to change is there, the actual implementations often run into road blocks because of expectations of how the new dev environment should behave even if that in some cases is not possible. I find that that's usually the biggest hurdle - overcoming doing the same thing you've always known rather than exploring different ways to accomplish the same thing.
>
>
>>>Switching to any language other than xBase will be a learning curve, but again I think the biggest hurdle to success is clinging to old ways of doing things and expecting things to work the same way. With an open mind to different approaches any new platform can be adapted successfully.
>>
>>Yupp. Still, there are some principles a good coder should have: DRY, YAGNI, (chunky, not chatty), KISS and so on ;-)
>
>
>Right - xBase never precluded doing things the right way, except that many code bases are so old they even preceed these concepts :-) The xBase language was never designed for structured development either and although FoxPro added much of that, the data layer in particular is very susceptible to reckless coding. And that's what I see in most FoxPro applications that end up migrating. For apps like that the biggest issue is that there are actually two learning curves for conversion: Learning a new language/environment/paradigm and learning about better design which is challenging.
>
>
>+++ Rick ---