Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 7 of 7 total
Thread Ideas for EWB - Web Components / Linux
Wed, Feb 9 2022 9:22 AMPermanent Link

Trinione

*** THESE ARE MY IDEAS AND ARE NOT BASED ON ANY COMMUNICATION WITH TIM/ELEVATE SOFTWARE **

Good day folks,
Just some ideas I'm having about the possible future of EWB (EWB 4).

The year is 2022 and lots has changed since EWB 2/3 hit the market. As fantastic as these products are there are some glaring truths that cannot be ignored, namely - the extremely long period of time to get UI components to market and fixes. There are simply too many glaring omissions to be productive with the reasonable expectations of users in terms of what the UI delivers. The current UI features are simply not good enough anymore and with no realistic timeframe for delivery on anything something else must be offered. This leads me to suggesting - WEB COMPONENTS.

Web Components allow the creation of reusable custom elements and are now a standard in web browsers.

** https://developer.mozilla.org/en-US/docs/Web/Web_Components


There are many significant Web Component UI libraries (some are listed below). I suggest EWB 4 UI system be designed to use Web Components in place of the current built-in framework. This shall remove this aspect of now outdated and painful aspect of EWB and permit time, energy and resources to be channeled into overly long awaited and promised features/deliverables such as Linux for Linux and EWB Web Server Linux.

I hope this thread can spark some energy, conversation, ideas and drive to move EWB forward as the product feels increasingly and disappointingly stuck. EWB 4 should not be a 2030 product. :/

------------------------------------------------------
Some popular Web Component sets
------------------------------------------------------
- Microsoft Fluent UI Web Components
https://docs.microsoft.com/en-us/fluent-ui/web-components/components/overview

- Adobe Spectrum Web Components
https://opensource.adobe.com/spectrum-web-components/getting-started/

- Google Material Web
https://github.com/material-components/material-web

- SAP UI5 Web Components
https://sap.github.io/ui5-webcomponents/playground/components

- Kickstand UI
https://kickstand-ui.com/

- Github Elements
https://github.com/github/github-elements

- Vaadin
https://vaadin.com/docs/latest/ds/components
Wed, Feb 9 2022 5:12 PMPermanent Link

erickengelke

Trinione wrote:

*** THESE ARE MY IDEAS AND ARE NOT BASED ON ANY COMMUNICATION WITH TIM/ELEVATE SOFTWARE **

Ideas, especially out-of-the-box ideas are always good for getting people thinking and re-evaluating their preconceptions.  In your posts and our Emails, you have certainly broadened my world..

I may have a different perspeciive, and I'm sure I'm neither more right or wrong, just different due to my experiences.

As some of you know, I've pushed some of the limits with EWB in my books and component toolkit which has added some external capabilities not native to EWB.  My reason for doing that is because I need functionality it doesn't offer natively.  

I charge for my toolkit to keep myself interested (it kind of funds my woodworking hobby... somewhat....), otherwise I wouldn't bother putting effort into it.  But I would be even happier if there weren't the need for my work and I could just do other things with my time.  I'm not getting rich from it, and that's not the idea behind my efforts either.

That said, I have found EWB client is not terribly hard to interface with other libraries.  It's not as trivial as inserting some boiler-plate JavaScript and CSS you find on the Internet, BUT, I contend that working in pure JavaScript and CSS is a lot harder for me than working in EWB's framework with the advantages of the Pascal typed variables.  Once the library is part of EWB, you can use it 10 times faster than writing HTML5+JS+CSS because those things are unmanageable for large projects.   My finished programs rarely have bugs in them, because the strongly typed language finds more bugs than it lets through.  Working in JS does not give you that benefit.

Ideally, you could develop for EWB in Windows, OS/X or  Linux.  A lot of developers use OS/X so they can test cross-platform, etc, and to use EWB we have to use Parallels.  But I can't see the market being large enough to support Tim's time investment in that even though the Delphi compiler supports it, and if his code is probably mostly pascal.,

But porting the EWB Server to Linux is a real requirement.  Some shops, mine included, use as little Window server as possible for a myriad of reasons.  

I don't know that cheap hosted sites will benefit as much from the Linux support, because they rarely let you run programs.  You are often restricted to PHP/MySQL - at least at the cheap ones I looked at.

My hope is that Tim will focus his time on supporting the parts of the program which only he can do.  Specifically, things like promises, JS async functions, Linux, debugging support, draggable objects,  bug fixes in the library and the IDE, etc.  And then look at selected components for improvement, particularly the TGrid, native support for money (in addition to doubles and integers).  A trivial improvement which would advance the library a lot would be to support hint text in edit boxes.

And if we get enough critical mass, others can help bridge the gaps with components and optional libraries and fonts.  I know I'm hoping my contributions will help attract and retain more developers so that the community grows.

That said, there is a lot to be said about staying native EWB rather than relying extensively on 3rd party components.  Trust me!  The authors change versions at random times, changing the API calls and other things, and then there is the inter-compatibility of products to consider.

My PivotTableJS component (which is super cool BTW), uses JQuery to do the fancy UI stuff.  And EWB's lack of dependancy on other technologies means it doesn't often conflict with these external units the way that can happen if you depend on other externals.    A huge compound project relying on many 3rd party units can be disastrous due to interactions between the various libraries, version differences, etc.  How much risk do you want to take as a developer.  Stock EWB offers very low risk, but that comes with fewer options too.

Erick
EWB Programming Books and Component Library
http://www.erickengelke.com
Wed, Feb 9 2022 5:12 PMPermanent Link

erickengelke

Trinione wrote:

*** THESE ARE MY IDEAS AND ARE NOT BASED ON ANY COMMUNICATION WITH TIM/ELEVATE SOFTWARE **

Ideas, especially out-of-the-box ideas are always good for getting people thinking and re-evaluating their preconceptions.  In your posts and our Emails, you have certainly broadened my world..

I may have a different perspeciive, and I'm sure I'm neither more right or wrong, just different due to my experiences.

As some of you know, I've pushed some of the limits with EWB in my books and component toolkit which has added some external capabilities not native to EWB.  My reason for doing that is because I need functionality it doesn't offer natively.  

I charge for my toolkit to keep myself interested (it kind of funds my woodworking hobby... somewhat....), otherwise I wouldn't bother putting effort into it.  But I would be even happier if there weren't the need for my work and I could just do other things with my time.  I'm not getting rich from it, and that's not the idea behind my efforts either.

That said, I have found EWB client is not terribly hard to interface with other libraries.  It's not as trivial as inserting some boiler-plate JavaScript and CSS you find on the Internet, BUT, I contend that working in pure JavaScript and CSS is a lot harder for me than working in EWB's framework with the advantages of the Pascal typed variables.  Once the library is part of EWB, you can use it 10 times faster than writing HTML5+JS+CSS because those things are unmanageable for large projects.   My finished programs rarely have bugs in them, because the strongly typed language finds more bugs than it lets through.  Working in JS does not give you that benefit.

Ideally, you could develop for EWB in Windows, OS/X or  Linux.  A lot of developers use OS/X so they can test cross-platform, etc, and to use EWB we have to use Parallels.  But I can't see the market being large enough to support Tim's time investment in that even though the Delphi compiler supports it, and if his code is probably mostly pascal.,

But porting the EWB Server to Linux is a real requirement.  Some shops, mine included, use as little Window server as possible for a myriad of reasons.  

I don't know that cheap hosted sites will benefit as much from the Linux support, because they rarely let you run programs.  You are often restricted to PHP/MySQL - at least at the cheap ones I looked at.

My hope is that Tim will focus his time on supporting the parts of the program which only he can do.  Specifically, things like promises, JS async functions, Linux, debugging support, draggable objects,  bug fixes in the library and the IDE, etc.  And then look at selected components for improvement, particularly the TGrid, native support for money (in addition to doubles and integers).  A trivial improvement which would advance the library a lot would be to support hint text in edit boxes.

And if we get enough critical mass, others can help bridge the gaps with components and optional libraries and fonts.  I know I'm hoping my contributions will help attract and retain more developers so that the community grows.

That said, there is a lot to be said about staying native EWB rather than relying extensively on 3rd party components.  Trust me!  The authors change versions at random times, changing the API calls and other things, and then there is the inter-compatibility of products to consider.

My PivotTableJS component (which is super cool BTW), uses JQuery to do the fancy UI stuff.  And EWB's lack of dependancy on other technologies means it doesn't often conflict with these external units the way that can happen if you depend on other externals.    A huge compound project relying on many 3rd party units can be disastrous due to interactions between the various libraries, version differences, etc.  How much risk do you want to take as a developer.  Stock EWB offers very low risk, but that comes with fewer options too.

Erick
EWB Programming Books and Component Library
http://www.erickengelke.com
Wed, Feb 9 2022 7:48 PMPermanent Link

erickengelke

erickengelke wrote:

>My hope is that Tim will focus his time on supporting the parts of the program which only he can do.  
..
> And if we get enough critical mass, others can help bridge the gaps with components and optional
> libraries and fonts.  I know I'm hoping my contributions will help attract and retain more developers so that the >community grows.

One of the things I found challenging and I didn't do terribly well is organizing my components in advance into easy drag n' drop components configured within the IDE.  I took more of a Javascript approach and configure many of them with code.

Tim's components are very well thought out.  He's probably much more comfortable than anyone at extending his environment and the quality of his work is superb.

Unfortunately, the closed operations make it limited to the ideas and time of one developer.   And that can become stagnant because he is being pulled in a lot of directions at once supporting IDE, client and server as well as component libraries and language compiler and linker.

I think you are hoping for EWB 4 functionality, whereas I'm still not fully using EWB 3 in my bigger production sites as I wait for critical bug fixes that prevent migration from EWB 2.x.

Erick
EWB Programming Books and Component Library
http://www.erickengelke.com
Wed, Feb 9 2022 9:59 PMPermanent Link

Richard Harding

Wise Nutrition Coaching

Greetings Trinione

Do you have a website that describes the products that you produce?

What part of the world are you located in?

There is a diverse group of people involved with EDB and EWB and it is fascinating to find out what they do?

Richard
Wed, Feb 9 2022 11:04 PMPermanent Link

Trinione

Richard,
I develop custom apps and the business apps I have online are not public.

Location: Caribbean.




Richard Harding wrote:

Greetings Trinione

Do you have a website that describes the products that you produce?

What part of the world are you located in?

There is a diverse group of people involved with EDB and EWB and it is fascinating to find out what they do?

Richard
Thu, Feb 10 2022 3:37 PMPermanent Link

Richard Harding

Wise Nutrition Coaching

<<Richard,
I develop custom apps and the business apps I have online are not public.

Location: Caribbean.
>>

Trinione

Must be a completely different world - both physically and culturally - to the Hunter Valley of NSW and upstate New York.

Richard
Image