Thanks for the clarification. I agree that testing everything when you only fixed a padding issue is something that is undesirable and as @Raphael stated something that shouldn’t be needed.
But it seems like your bug only showed up AFTER your published a new version of the app. If a weweb update could break a production app that is something of nightmares that would ensure me getting a lot less sleep in the future. Having the ability to roll back a published version to a previous one could have resolved your issue. And that would help with going the self hosted route as you can backup your versions yourself.
I do think WeWeb needs to adress the support structure their offering. If we want to be able to build mission critical applications using the platform some form of formal support structure needs to be in place. We have projects that we gladly pay $1000 a month for support we never use. Because I know what it would costs if we ever did have an issue and the clients needed to wait 24hours before we get a response from our supplier.
So dear WeWeb,
can we perhaps get a few agency partners together to discuss how we’re able to adress these issues and make WeWeb even more capable in large enterprise environments. Perhaps a few writeups or demo’s on how we can manage issues like this. A feature we’re we can rollback a published version on the live environment for the people using the hosted version. I think there are a few small things that can make life easier so more room is created to do the things that are harder but also interesting.
In the situation that @bradley_gibson described - the current process to recover a backup might even be too slow? Or I suppose at least disruptive to the current development.
So prior to providing (very helpful) writeups and demo’s of whatever is currently in place, please consider if the current backup facility is at the maturity level that it should be.
For what it’s worth, I have been advised to consider a ‘reverse proxy’ that can switch instantly between (two versions of) websites. But this assumes that multiple versions of your website are simultaneously available (not sure if that’s the case with Weweb’s current setup).
I’m a developer, working on a large project using weWeb. I chose the platform because of its ease of use, clarity and everything else the tool offers.
Development, documentation and testing help a lot in future updates. The problem you had there was certainly trusting updates too much and not testing all possible scenarios. With code versioning, everything can be returned to its previous state.
Now I have a criticism of weWeb: don’t waste time trying to bring AI into the tool and focus on improving components, UX/UI, security, etc. Don’t try to compete with other tools that use AI to build everything. Honestly, as a developer, I don’t see how it’s possible to build an app the way we want using only AI, asking it to do it and that’s it. I use AI to save time creating debugging code, but outside of weWeb, I don’t use weWeb’s AI and I’ll never use an AI to create an application that I need to have full control of the code to scale.
These tools that promise to deliver everything to people are a Trojan horse, so don’t waste your time trying to compete with these tools, strengthen the WeWeb editor and congratulations on your work, I love WeWeb.
ANY change WeWeb makes to a “core” native component - should be versioned and should NOT automatically update on publish. WeWeb can alert a User that XYZ component has bee updated improved and GIVE THE USER THE OPTION to update the component.
One main value prop of a “nocode editor” is that you can go in - make a quick change - and republish. And ONLY QA / test the what you changed. This goes out the window if WeWeb is changing code on a core component that automatically updates on a publish on a user that has used that component.
I was speaking to a founder who has a very large WeWeb project - and he said “I DREAD every publish”. That is sad. And unnecessary.
I think Mark brings up a very good point. And to be honest it’s a feature that we have seen on other platforms before. It gives control back to the developer. Combining that with the ability to restore a previous version (and I do mean restore and not republish as that is not the old version) should eleviate most issues.
I’m glad we have a standard that large mission critical WeWeb application are self hosted. And if your using github you have even better control and insight into changes and what is being deployed. So i think a lot of tooling is already in place, we might not be using them as efficiently as we might want to.