Blog: Xojo Web Framework 2.0?

Targets Web
22

[quote=362514:@Rudolph Thomas]Initially, it was and probably still is marketed as being quicker than other scripting languages because it is compiled to binary but in actual fact, I’m sure PHP is quicker and uses fewer resources due to the way you interact with the browser.

[/quote]

If you used the xojo web client side framework with a PHP backend the client would feel roughly the same. The backend would be able to handle more requests in most scenarios due to its request model. In a load balanced environment Xojo is likely faster.

23

[quote=362525:@Jeff Tullin]If Xojo are announcing something new within days, it’s probably way to late to be assembling a wish list now; or you are discussing Web Framework 3.0?
Hopefully someone raised these as suggestions last year…[/quote]

They are announcing they are working on something new at XDC late April. I suspect we have some time - not that our feedback is necessarily desired.

24

[quote=362526:@Maurizio Rossi]Sorry Lars,
Xojo Web was not meant to be used by Web pros.

This was repeated many times by Xojo’s team developers.
An example of this is my feature request to implement a more advanced CSS editor: the reply was that Xojo web must be simple enogh to be used by users with little or no knowledge about web technologies.
If you need something more you can use WebSDK, implement yoursef CSS styles and so on.

I hope Xojo will listen also more advanced users.[/quote]
I hope we can create container-like control using webSDK.

25

[quote=362526:@Maurizio Rossi]Sorry Lars,
Xojo Web was not meant to be used by Web pros.

This was repeated many times by Xojo’s team developers.
An example of this is my feature request to implement a more advanced CSS editor: the reply was that Xojo web must be simple enogh to be used by users with little or no knowledge about web technologies.
If you need something more you can use WebSDK, implement yoursef CSS styles and so on.

I hope Xojo will listen also more advanced users.[/quote]
This is pretty much nail-on-the-head here. When I was tasked with creating Web Edition, it took me roughly two weeks of prototypes before the concept actually “clicked” in my head. See, as a web developer it was difficult for me to let go of the low-level stuff like html, css, and javascript to produce the high-level product. One of my prototypes was a tool that would take a desktop project and convert it into a client-side web system. Basically the browser window would be the desktop, Windows would still exist, it had a menubar… everything like that. There were technical problems such as compiling the Xojo code into Javascript, but it also wasn’t the right user experience.

But what I’m getting at is if you know how to do things without Xojo, the high-level nature of Xojo tends to get in the way. Thoughts like “I just want this button to smoothly transition to another color when the mouse is down, that would take me two seconds with CSS” get in the way of the bigger picture. Yes, that would be simple in CSS if you already know css and how all your styles work together. The correct solution, however, is to ask for improvements to Xojo’s style system, not to ask for a way to do it yourself.

I realize I’ve wound up replying more to @Lars Lehmann but the concepts are related.

26

I think they should support both worlds: actually desktop devs which just want to design a webapp and more professional web devs, which want to deeply customize their apps.

Because, let’s face it: out of the box are the xojo webapps really boring and ugly. You need to spend much time to the interface with CSS to design modern and good looking Webapps.

27

[quote=362562:@Lars Lehmann]I think they should support both worlds: actually desktop devs which just want to design a webapp and more professional web devs, which want to deeply customize their apps.

Because, let’s face it: out of the box are the xojo webapps really boring and ugly. You need to spend much time to the interface with CSS to design modern and good looking Webapps.[/quote]
When the default designs were implemented, they looked modern. But times change, the designs have not. And changing them would be a problem since styles modify the default, so any changes to the default design is equivalent to breaking code. It’s not a great situation.

But my point stands, what you’re asking for it outside of Xojo’s intended usage.

28

[quote=362562:@Lars Lehmann]I think they should support both worlds: actually desktop devs which just want to design a webapp and more professional web devs, which want to deeply customize their apps.

Because, let’s face it: out of the box are the xojo webapps really boring and ugly. You need to spend much time to the interface with CSS to design modern and good looking Webapps.[/quote]

Yeah I get that but I do not think it is practical. I think there is a use case for down and dirty apps that are fast to develop and easy to maintain.

You can build much more sophisticated things with Aloe - or like I did by rolling my own web server.

I accept there are limitations to the web framework. I merely want to see them expand on what they already have like they should have instead of rolling out something new and shiny that could potentially break everything that is already out there.

We will see…

29

[quote=362567:@Phillip Zedalis]I accept there are limitations to the web framework. I merely want to see them expand on what they already have like they should have instead of rolling out something new and shiny that could potentially break everything that is already out there.
[/quote]
Be great if you submitted specific Feedback requests on what you want/need from the new framework? That’s the only official way of getting your voice heard.

30

You clearly have spent a lot of time thinking about this and are passionate about it which is just great. I appreciate the energy you are putting into it. With that said, your blog post and comments on the forum are making a lot of assumptions about our goals, direction and even internal implementation details. As @Bob Keeney pointed out, our system for hearing your requests for features is to create cases in Feedback. That is the most efficient way for us to gather the information and communicate with the users that care about a given case. The forum is great for discussion, even if it’s talking over the merits of a particular feature request, but it’s not the best way to communicate with us about improving the product. That’s what the Feedback app is for.

Rather than put your energy into blog posts and forum threads about feature requests, I think you and (we) would be better served if you instead created Feedback cases. Feel free to discuss those cases on the forum if you’d like, but we NEED the cases to be in Feedback. Those Feedback cases are also a good place to discuss them as it puts all the discussion right there where we can see it. and review it when dealing with that case.

For all that use Feedback, rather than propose solutions, what we need are the problems you are encounter. Instead of “Please add a date picker” say “I need a faster and more accurate way to enter dates”. The former is a solution. The latter is stating the problem and that’s far more valuable to us. The reason is that your problem may be quite narrow and thus your solution might also be narrow. We may have a solution that is broad enough to solve several problems at once but we may not notice that if we are focused on your narrow solution because we don’t know what problem you’re trying to solve.

Again, I very much appreciate the time you’re spending thinking about all of this and the energy you are putting into it. I just want to redirect that into Feedback cases as that will serve us all far more than any other method.

31

Keep in mind several of these already have feedback items.

“Outdated and not very secure embedded web server:”

Feedback #38227 by Seth Ober - Reviewed - February 18th, 2015 - Support HTTP/2 in stand-alone web apps

“Lack of new and updated widgets for modern web usage.”

Feedback #46795 by Victor Manuel Osornio - Reviewed - January 28th, 2017 - Bootstrap and native controls in Xojo Web (includes date picker in description)

“Overly complex and difficult to import javascript widgets from other frameworks or toolsets.”

Feedback #39300 by Brock Nash - Reviewed - May 12th, 2015 - Web Control SDK add a handleURL Method to allow the namespace path to serve up custom files

Feedback #36838 by Brock Nash - Reviewed - November 21st, 2014 - Web Control SDK WebControl Wrapper - Add a way to dirty/rerender the control

Feedback #45444 by Michel Bujardet - Reviewed - October 12th, 2016 - Websdk controls should be seen as WebControl and respond to position and size as a regular control

Feedback #45966 by Tim Parnell - Reviewed - November 23rd, 2016 - High resolution asset constants for WebControlWrapper

“Web styles leave a lot to desire in terms of skinning and maximizing web application aesthetics.”

Feedback #47169 by Ian Jones - Reviewed - February 28th, 2017 - Allow WebStyle properties to be added to a class’s Inspector Behavior

Feedback #43531 by Michel Bujardet - Reviewed - April 19th, 2016 - Webstyles advanced field (asks for more advanced ways to create CSS/styles)

Feedback #41736 by Maurizio Rossi - Reviewed - December 2nd, 2015 - Let the application to assign a CSS style not statically created at design time.

Feedback #14614 by Basil Bourque - Reviewed - November 16th, 2010 - Set default style (“WebStyle”) for each kind of control. Ex: TextField → MyFieldStyle, Label → MyLabelStyle, etc.

Feedback #15949 by Christian Schmitz - Reviewed - February 15th, 2011 - Allow creation of webstyle objects in code (the comments here from Brock address my concer: "WebStyles need to be fundamentally be reworked.

Will consider for some of my other ideas such as building API’s and dealing with varied screen sizes.

32

That’s a great compilation of relevant cases- thanks!

33

Thanks!

[quote=362597:@Geoff Perlman]

I appreciate the energy you are putting into it. With that said, your blog post and comments on the forum are making a lot of assumptions about our goals, direction and even internal implementation details. [/quote]

I think I was fair in my assessment of Xojo Web and possible future outcomes. As you all do not share details I am operating solely on my ideas and concerns about the future. The only thing that give me an indication there might be a new framework is the session description on the XDC website:

“Web Framework 2.0 | Greg O’Lone, Xojo Inc.
Come learn about the new web framework and see how it looks! We’ll also talk about design considerations and how we’ve been building the new infrastructure that powers it.”

I merely desired to add my feedback while it is likely still early in the development cycle. I also posted some enhancements that would benefit me and my customers.

Understood. In the future I will verify that my ideas do exist in Feedback before blogging about them.

34

well, regarding date picker: https://xojo.com/issue/13801

and modern web frameworks like foundation or bootstrap https://xojo.com/issue/46795

P.S. I see some others have had same thoughts…

35

[quote=362609:@Phillip Zedalis]
Understood. In the future I will verify that my ideas do exist in Feedback before blogging about them.[/quote]

And feel free to add your thoughts on those cases even if you are not the original author. More information not only helps us but more users on a case gives us more people to contact if we have questions.

36

Stuff like this and jQuery were very intentionally left out for two reasons:

  1. Going back to the high level concept I spoke of earlier, this shouldn’t matter to the developer.
  2. Controlling our own destiny. Using a third party library opens the tool up to forced timelines, like what has happened with iOS and 64-bit, for example. Maybe a browser update introduces a bug that is fixed in a newer version, but that newer version would require other changes that may break the built-in or custom controls. Or a user wants an update to support some third party non-WE control, but that could pose similar compatibility problems. My creating and maintaining a custom library, Xojo remains in control.
37

Bottom line: there are pluses and minuses to each approach. When we first looked at LLVM for example, while we liked the idea, it was too immature at the time for it to make sense for us. Eventually however, it matured and it reached the point where NOT using it no longer made any sense.

38

I’ve lived under that approach for the past 30 years. I have found there are some severe trade-offs you have to make. You can find yourself in a backwater that is really hard to get out of. Our mantra was always “control”. I’m slowly changing that to “collaborate”. I’m not saying that Xojo is wrong for trying to retain control, it can be great if you have sufficient resources.

39

And if you look at the direction we have been taking with the compiler (LLVM) and the new framework APIs (many of which no longer rely on libraries we include but instead call into the OS), we increasingly see our role as providing the glue that makes the power that is out there accessible to Xojo users.

40

The potential down side of that is that one can become more dependent on specific OS versions/behaviors as well as potentially introducing more and subtle cross platform differences without realizing it… which could undermine Xojo main strength… being X-platform with relatively little effort.

Tough balancing act!

  • karen
41

[quote=362650:@Karen Atkocius]The potential down side of that is that one can become more dependent on specific OS versions/behaviors as well as potentially introducing more and subtle cross platform differences without realizing it… which could undermine Xojo main strength… being X-platform with relatively little effort.

Tough balancing act!

[/quote]
We only do it when we can be confident the behaviors are basically the same or if they are different it’s in some way that’s not relevant. For example some controls don’t behave exactly the same but it’s close enough not to matter. Fortunately, many of the OS calls are for libraries providing standards not controlled by the platform vendors so they are not likely to vary radically in the future.

However, if they did, we would then switch that functionality back to some library we provide. So relying on the OS is not a point of no return. It makes a lot of sense until it doesn’t and then there’s almost always other solutions.