But shouldn’t the business logic be separate from the UI logic. They should be able to re-use the same classes as the desktop app and just create some new “Skin”.
For the record I’m not advocating Xojo use any resources to do this, I’m just saying it should be a simple straightforward approach if they used proper organization techniques when making the desktop app.
I certainly can see that argument but why create a product in the first place if you cannot develop something that proves it capabilities? Just pass on the new product and fix bugs on the old product until they are all gone it is as stable as possible? I would guess the reason is it represents a new revenue stream, but they really didn’t go all the way to maximize the new products revenue stream.
I would also argue that Xojo would have learned a TON of information that would improve the product by creating something like that.
[quote=157512:@Brock Nash]But shouldn’t the business logic be separate from the UI logic. They should be able to re-use the same classes as the desktop app and just create some new “Skin”.
For the record I’m not advocating Xojo use any resources to do this, I’m just saying it should be a simple straightforward approach if they used proper organization techniques when making the desktop app.[/quote]
I seem to recall Thom saying that feedback used a lot of hacks, and that was the reason its source was not being released. So while you might expect good programming principles, the tight deadlines they set themselves (and break. Repeatedly.) seem to result in “must get it out of the door” code instead.
For those of you that went to XDC last year, we did develop the XDC schedule app in Xojo Web. It took 8 weeks of nights and weekends to develop, and I can tell you that we did find a lot of bugs during that time. Most of which were fixed in 2014r2.
Another reason is that Feedback isn’t just a front-end product. There’s a whole backend PHP structure for communicating with our other products and the database. Releasing Feedback would not be as simple as zipping it up and providing a download link.
I certainly do not know what I’m talking about from a technical perspective… but that never stops me from putting in my half cent!
It seems to me that the design of the WE should have been such that more was done on the clients side with, How I would envision that is with client control events that decide if the info get sent to the server or just a message to another control on screen to change UI or perform some operation the server code does not need to know about yet…
Think about filling out a form that that the server does not need to know about until a submit button is pushed.
The code for those events could be restricted to a subset of xojo with maybe some 'context methods" specific to client code, all which get translated to JavaScript and sent to the server.
In other words, although our code would all be in Xojo, more of hybrid client server or XojoScript model.
Yes there would have had to be more adjustment in HOW we code it, but it seems to me overall the performance/scalability improvement would have been worth the tradeoff
[quote=157512:@Brock Nash]But shouldn’t the business logic be separate from the UI logic. They should be able to re-use the same classes as the desktop app and just create some new “Skin”.
For the record I’m not advocating Xojo use any resources to do this, I’m just saying it should be a simple straightforward approach if they used proper organization techniques when making the desktop app.[/quote]
Look at your own desktop projects and see how close they are to being ready to be ported to web. Usually unless that is planned for, it is a hard to accomplish. Feedback was designed with a significant amount of MVC principles, but I’m sure it would still be easier said than done. Plus, you can’t simply recreate the UI control-for-control. New web-oriented interfaces need to be thought up and designed.
[quote=157517:@Markus Winter]I seem to recall Thom saying that feedback used a lot of hacks, and that was the reason its source was not being released. So while you might expect good programming principles, the tight deadlines they set themselves (and break. Repeatedly.) seem to result in “must get it out of the door” code instead.
DEATH TO THE RAPID RELEASE MODEL! ;-P[/quote]
To be fair, I was a much younger programmer back then.
[quote=157525:@Karen Atkocius]It seems to me that the design of the WE should have been such that more was done on the clients side with, How I would envision that is with client control events that decide if the info get sent to the server or just a message to another control on screen to change UI or perform some operation the server code does not need to know about yet…
Think about filling out a form that that the server does not need to know about until a submit button is pushed.[/quote]
This was my first design. I created an app that would take a project and build a set of HTML/JS/CSS files designed to be run entirely client-side. Besides requiring your Xojo code to be translated to JavaScript, there was an insurmountable number of problems with this.
Today, the desire for some things to be client-only can only be satisfied by no-code solutions. I wouldn’t expect Xojo code to ever run on the client.
We will build applications using the web framework when it makes sense to do so. We didn’t spend the time to create new forum software because we found an existing solution that we liked. That’s a simple cost/benefit analysis. As for demonstrating what is possible, that’s what we have the Eddie’s example for. We can also point to actual customer applications as well.
We actually were working with a user who was designing an app for conferences and were hoping to use it at XDC. We were getting concerned that this particular app might not be ready in time and I was looking for an excuse to learn the web framework anyway, so Greg and I built the XDC app just in case the app we expected to use wasnt ready.
This was a great exercise for me to learn more about web edition.
Lots of fun and we did find bugs. I learned a lot about that portion. Still no expert but more conversant with things.
You know, I did not buy licenses for all these years to see Xojo engineers lose sleep over creating an app in WE for XDC. I buy Xojo to develop my apps. Not for them to develop their apps.
It is amazing how in this forum that works rather well with Esotalk, we read all and everything, from “they should hire and give us 64 bit yesterday”, to “I never use feedback but it should be online”. I did not purchase Xojo for this forum, although I spend far too much time in it. Actually, I spent much less time in the old forum. Esotalk must be doing something right. I did not buy it for Feedback either.
And, no, I am not only for desktop. I also use Web Edition and was quite vocal to get iOS. What is important is that we get the tools to build better applications. Not that they eat their own dog food. Which they already do, BTW, since the IDE has been in RB then in Xojo for quite a while.
From what I see, Eddies Electronics is a nice demo of what WE can do. Then it is up to each one of use to have enough talent to do better.
Same thing for the iOS Eddies Electronics and all the example projects, as well as Tip Calculator for iOS.
I have ideas and interesst do create some web apps and would like to use Xojo WE, but they haven’t convinced me.
I think that WE has only power and performance for small Apps with less user access at a time. So they have done a lot of work to create WE and very less marketing work to get it on the road. When Xojo or another one creates a middle complex web app with Xojo WE and shows us that this app survives a lot of traffic, then I will believe in Xojo WE.
Xojo apps may be a bit chattier than your typical web site but that’s to be expected. You have the ability to handle hundreds of events for common controls while your business logic sits server side. Is that the best scenario for every application? Of course not.
Your blog probably does not need a web user interface similar to the desktop. Neither does this forum. Several apps do benefit (or require) that interactivity.
In regards to performance and load balancing this is par the course. Node.js is single core aware as well. There are extensions to use fibers or external processes but those are merely sub-processes with something similar to IPC sockets managing the processing.
My point is Xojo web apps are not inherently any less performing than any other stack. It just so happens that its single core aware and the apps are chatty. Using a load balancer will give you a tremendous performance boost. Sure for some thats “a lot of work” but nobody gets the web for free. Running a web site that can potentially get thousands of concurrent connections requires some planning. If you are not willing to do that planning then you should stick to desktop apps in my opinion.
Thanks for everyone’s response to this post, even Xojo Staffs responded to my post, how amazing is that.
Please let me explain my situation, our team is in the stage to choose a web developing tool, my other team member suggest to use “HTML5+CSS3+React.js+Loopback+Node.js+MongoDB”, so many things to learn, it may take me one year only to learn these technology but doing nothing. Thus I suggest to use Xojo, learn only one language one tool that can compile and run everywhere “native”.
Developers know that there is always debate in developing team about which tool is better, we need some reference and evidence to support our choice, when I told my team member that Xojo IDE it self is made by Xojo, this is very convincing, I understand Xojo might have some reason they did not use Xojo WE for feedback and forum system, I am ok with that, but at least, can we have a “Show Case”, or “Hall of fame”, or “Case Study” section, to show case what great web applications have been done by other developers in the real world, this can help development team to make decision to invest their time into this tool, and make sure that “No one gets fired by choosing Xojo”, if all these great web apps are made by Xojo, when we facing some difficulties while developing, that has to be our problem, not because we have choosing the wrong tool.
By the way we have a little Chinese community for Xojo developers, there are very few resource or document in Chinese Language, and of course no book at all, it is very challenging convincing other developers to use a new tool in this situation. We are working hard to grow this community, but we do need some “sales tools”.
I think proving a products value through real world working apps go a long way to growing your business. Especially when your trying to sell a developer on a new concept and new product. It helps remove user doubt and other perceptions user’s have regarding product capabilities. If spending a little bit of time to remove obstacles to sales it should be done. Especially if you can kill two birds with one stone - demo the product and provide an internal solution (feedback). I doubt anyone these days buys apps without a trial version to see if the product is suitable, especially given the price point of WE. In the case of WE where the main intent is to have multiple users working with an app on the web it only makes sense to prove that out. The question has come up quite a bit on the forum. Very few people will invest the time and resources necessary to test this out if the company who develops it won’t either. My time is just as valuable as Xojo’s.
To my knowledge the eddies electronics app is used for demo only so its quite possible when I am in there I will be the only one. I must recruit a hundred of my closest friends to give it a true test at the same time, even then it looks like it is using a single user database. Is this not correct? Is it really just a single user database and web interface? Is this the real intended use for WE?
They can do whatever they want, it’s their business, but based on what I see it’s answered my questions which unfortunately didn’t result in new license (sale). Still a Xojo fan (desktop) but not feeling real confident in WE.
I truly believe Xojo WE can be a great tool for developing web solutions, now a days to develop big data web solution with capability to communicate with other solution though API is so important, and plus a good tool for programmers to make beautiful web interface like Bootstrap or Material Design, it looks like Xojo can do these all but I just can not find a solid prove.
We know Xojo can be used to develop API, this is addressed in user guide, and I find “parse.com” do support RealBasic, this can let us develop a big data solution, and I know we might be able to make Bootstrap theme into Xojo controls, if any one can put these three things together and make a example to prove it works, I will definitely give it a go buy the license right a way and dig into it deeply, invest all my time into it.
If you think that, then you haven’t really done any complex WE development. What I mean is it is a simple example that doesn’t stress the framework at all.