The are issues in the latest Word and Excel which did exists in the 1995 versions and they are still not solved ;-). Last week I discovered quite a severe bug in one of my apps, which is probably around for 15 years now … a few of my apps have reported bugs which I didn’t yet fix for different reasons: other priorities, no funding, a complete re-write is planned anyways, waiting for new solution (Xojo, plugins, etc.), waiting for new possibilities with an OS update, you name it.
The main issue today is most likely how fast technology is changing. Though it dramatically improved, we are for instance still in 2021 far away from all browsers behaving in the exact same way. Same for Android. All the different flavours Android versions, devices available make it very hard to thoroughly test software for all devices …
Yes of course, it is a world apart. Even when VB classic stoped in 1998 and the new thing (vb.net) came in 2002, VB had bugfixes (runtime and IDE) until 2008.
Also, a couple of apps I made almost 20 years ago, are still running in the latest windows with newest hardware.
Any OS, the same thing, Windows XP last release (SP3) was in 2008, and it got fixes until 2018.
macOS 32-bit? macOS PowerPC? Well, with Xojo most likely if you just compile it with a newer release and the code wasn’t too “special” ;-). Just google for “swift and deprecated” the gras isn’t greener on the other side. But we should probably agree to disagree. But of course I would very much like that the transition would be easier, smoother and everything from Web1 still available, but I’m realistic that we can’t stop change.
yes, this sounds like a good summary. To the bugs:, for me it is less the amount, but the fact that they are not well “known”. Now this is the nature of bugs, but it would be easier knowing what is exactly not working rather than debugging stuff which works differently than described in the documentation (if that already exists).
However, I also believe that Xojo needed the mass tests to find exactly these bugs. It’s a chicken and egg problem somewhere.
In any case, I also hope that further releases will quickly improve the product. The big advantage of the web that we and Xojo shouldn’t forget: unlike desktop applications, where we have to recompile for updated versions and then redistribute these new products to the customers, updates in Web2 are quick and easy to do.
(Too) many point releases are usually a real pain but solely for Web2 they are a feasible way to optimize the product quickly.
What you where not mentioning is that they skipped this functions because of the fact that people shoot in their feets as Geoff said about. This in your mind you should look on it as a professional programmer and you will see that it is for us a problem cause we where using this functionality where it was needed and where it was possible. Newbies can and may have performance issues and other problems with it.
So in my view: if the app is running without problems as Web 1.0 App, leave it Web 1.0. If you will in future redesign your app it will not such a big step to switch to API 2 because you anyhow will redesign most of the stuff. Only my thinking.
You are not the only one. Web 2.0 is incredibly slow. I have read a lot about the Bootstrap framework and it seems to be a common theme that Bootstrap is slow in and of itself (for websites with as many controls on it as would be the case with complex webapps). These issues are just compounded.
While Bootstrap’s dependency files might be quite large if you’re developing a static one-page website, for something like Xojo it’s darn near perfect – especially when combined with appropriate caching. Can it cause slowness under the right conditions? Sure. For rapidly building a uniform UI? It’s great.
Switching to Bootstrap means that Xojo has to do less work on the real meat of the client-side for Web 2.0. They can leverage alot of freely available libraries, especially when compared to other frameworks, and don’t have to fight with their own custom CSS becoming outdated (either by function or appearance) and they can update their shipped version of Bootstrap in the future without having to rewrite the entire client-side CSS+JS.
The truth is, anything you add to a web application or website that must be sent from a remote server can slow down the execution, download, or rendering. I’ve seen some truly horrific things written in PHP and basic HTML/CSS that you wouldn’t believe.
Yes bootstrap compared to other frameworks is more thinking to load, but in this case it is not the problem of xojo. As I wrote in the feedback there is something broken underneath. I think 2.0 was born with Flex layout in mind and then adapted to make old designs compatible. Unfortunately Flex layout is useless in my opinion in a webapp. It is very useful if you want to develop static sites that focus a lot on graphics. In a management software for example it makes no sense that the components are scattered without a logic.@Greg_O_Lone can give us some more explanation, but I think that for now the problem of performance has been ignored to give priority to other things.
Well, I am not entirely in agreement with that. Not all my labels should look alike. In some instances, I want them to be textfield descriptions. I some cases, I want them to be standalone, as for block labels (section header if you want). With Bootstrap, it is one size fits all. Or a really large amount of work. Frankly, while I am getting better at bootstrap and can for the most part handle my requirements now, it is at the cost of immensely more work than is necessary in web 1.0.
I am also one of those who experience this huge performance drop. Containers load in minutes, not seconds, for example. Web 2.0 is as I said before just an MVP, and just barely that. I am sure improvements are on the way, but for now, Web 2.0 remains IMHO a lab project, not a production ready tool.
I’m not arguing what you or any other end-user of Xojo might want, I’m stating the design goals that Bootstrap accomplishes quite well. Bootstrap should be considered, for Xojo Web, what we think of as platform-native for desktop. It gets you a basic starting point that’s useable for everyone, and if you want customization then that’s up to you to build and implement.
the problem of webstyles is small compared to all the methods and events removed from the most used objects which make it impossible to port to web 2.0. Not to mention the old unsolved web 1.0 bugs and the new bugs highlighted in web 2.0
I wouldn’t say impossible. I’ve done a few large conversions, but I build the solutions I need if I run into something I don’t like.
Web 1.0 to Web 2.0 is no different than any other deprecation. You have to draw a line somewhere or you’ll forever be bogged down in fixing old bugs on a framework that constantly needs more and more work to keep running. Web 1.0 is ancient in terms of the modern web and I wouldn’t want to be the one tasked with maintaining it.
I feel like, as developers, we all understand these concepts on some level.
if I have to change too much code for the porting, the porting doesn’t make sense, better rewrite the app! what I do not understand and it bothers me a lot is that it is difficult to report bugs, do a demo project to demonstrate the bug and that these bugs, after years (from 2016) have not been solved even in rel 2019R.3.2, this does not give peace of mind for future developments
Any design that paints the user in a corner, as exemplified with the label issue I pointed out, is a bad one as far as I am concerned. Web 1.0 allowed total control and flexibility. Web 2.0, as far as I know, does not. A label is a label is a label. Same with all other types of control. It is virtually impossible to have variations of styling on same-base-class controls that should look different in specific UI situations. Only superficial adjustments are possible without a lot effort. While one could design different classes in bootstrap which would provide for “a label is not a label is not a label”, I am not aware that it is possible to point controls on one specific variant (or please someone teach me!!). One can only hope that this kind of styling flexibility will be part of future Xojo releases.
But you can subclass the basic WebLabel class and add your own styling logic, which can be reused anywhere in your app for uniform headings, as an example.
I just created a new class in a Web 2.0 project, set its Super to WebLabel, named it “HeaderLabel”, and added the following in the Opening event handler:
