Deprecating The Return Action - Why? | Guys. This is unfair. We need to talk

Ask us anything
1

Dear Weweb Team, thank you for the new updates and congratulations on the growth @Joyce @flo @Raphael @Marc

I am writing this post to really come into a conversation that almost always happens every single time Weweb has a major update. I will alwys root for Weweb, even if I decide to leave.

This community and the weweb team knows I love this product very much and it is why major updates cause me to get nervous. But I am not just speaking for myself I am speaking for those of us who came to use weweb many years ago.

The people who make decisions about the editor seem to make them without fully grasping the idea that real world projects grow to the point where it is IMPRACTICAL to go around making massive logic changes. Nigh Impossible. It is on the back of this that a decision such as deprecating a major action just makes one genuinely upset. Why would anyone deprecate the return action without notice? Why??

IF a product has been working a certain way for YEARS (I have been using Weweb since 2021 or something), it is just wrong to mark things deprecated without any heads up. To specifically speak on this return action issue. I have well over 300 instances of “return” action scattered across my project, can ANYONE explain how one can reasonbly update that to use the new Create Variables action?? Like one would have to go through my app with almost 33 pages, with UI elements and actions running into THOUSANDS combined, to then begin replacing every instance of “return” action that I used with create variable??

Honestly, I REALLY think we must have honest conversations about how too important Weweb is for updates to be opinionated (“this is how this is gonna work now from now on”) THAT cannot possibly work in a tool that is used by thousands of people to build real businesses. It is wrong. Honestly. Just wrong. And to do it without even telling us ahead of time. I mean…

Cos each update these days for me brings apprehension, cos now I am wondering “Oh gosh what is broken this time”. IT is UNFAIR. It is basically punishing those of us who came early and bought into the vision of this platform at the expense of new users. Are old users less valuable??

Today I have woken to find tons of workflow action items scattered throughout the project marked as deprecated and I am wondering “Wait. What??”

This has happened many times with UI elements (there a 10s of posts of users complaining about sudden deprecation of UI elements on this forum), and we have swallowed it eventually. But with workflow actions it’s literally business logic. IT is just wrong!!

To close I will make an example to show just how DIFFICULT workflow action changes are. In 2023/2024 Weweb made an update where IF/Else action default actions were no longer just harmless placeholders, if logic reached them they would error. Now this was NOT how it was before, before they would simply allow logic to pass on, so many users (me included) had workflows built that didn’t put anything on the false side, since it was harmless. Overnight with one update, Weweb made it no longer harmless and several workflows broke. This is April 2026 guys, I just FINALLY fixed the last of such bugs. It took me 2 FULL YEARS to finish. Cos that single update basically meant I had to inspect EVERY SINGLE IF/Else statement in my app to be sure I adjusted to the change. Come on guys!! We gotta have honest conversations here. Serious ones cos honestly I am truly grateful for your work and your vision but I am exasperated.

Running a business is hard, I can’t continue fussing over the underlying stack each quarter. Please think about old customers with old projects.

2

I think you are looking at it wrong. When a component or a workflow like this is marked deprecated, it only means it will not continue to be developed. It will not stop working.

Look at it this ways: Keep all your workflows as they are. But when you rebuild or rework any workflow containing this action at any time later, you can build it using the current actions weweb support.

Same with components: when a new and updated component with breaking changes is released, the old one will be marked deprecated. Not because it will be removed, but because the new version has a breaking change.

Now, if they did not deprecate, but change it, you would end up with what you described about IF/Else action change in 23/24 - and that we don’t want.

3

Hello @AgentD ,

Thank you for your post! I completely understand that seeing a “Deprecated” tag can be alarming. Please rest assured that this will not break your existing workflows.

We are committed to ensuring this action continues to work exactly as it does today. Like @thomlov said, deprecation simply means we won’t be adding new features to it or recommending it to new users.

We removed the action from the main list to reduce confusion, especially since the introduction of the “Create Workflow Variable” action. You will now only see “Workflow Result” action available for functions (global workflows).

We’ve learned from past updates and are working hard to ensure we don’t break existing apps. If anything does go wrong, please contact support and we’ll fix it immediately.

Thank you for your trust. Please keep sharing your feedback and any frustrations you face so we can keep improving.

4

Thanks for the clarification @flo . It helps to know that “deprecated” in this case does not mean existing workflows will break or need immediate migration. You took a huge weight off my shoulder. Thank you.

That said, I think the broader concern still stands, and it is less about this one action and more about migration cost in large real-world apps. Weweb does not have project wide observability for actions and I know that will be a hard thing to build, but I do think it is something to build. A page-by-page audit ceases to be reasonably possible once an app grows past a certain point if I am being honest with you.

In mature WeWeb projects, workflow logic is often spread across hundreds of locations. So even when a feature is only deprecated and not removed, the appearance of deprecation creates operational concern because historically even subtle behavior changes can require project-wide audits that take a very long time to fully resolve.

What would help a lot for teams running serious production apps is:

  1. a clearly documented deprecation policy with notice periods,

  2. explicit guarantees around runtime support for deprecated actions,

  3. project-wide tools to find deprecated items and ideally help migrate them safely.

That would go a long way toward making major updates feel less risky for long-time users managing large applications. Thank you and have a great day.

5

I think number 3 is actually a great idea. I’ll be honest I’m very critical of weweb and things they do, but I’ll give them this one they done a massive redesign of weweb and had some confusion with communication but in general things worked pretty well for such a large change.