Why I did not choose Cwicly for my next big project…

General
27

This strategy was used by the Cwicly team for v1.3 to introduce the Components features.

The biggest issue at that time was ensuring synchronisation between the release channel and the beta channel, otherwise it is harder to switch between them to test out features.

I think a beta channel can work well as long as the iterations are on the shorter side and/or any bug fixes and enhancements from the release channel are kept in sync.

This is an interesting one. I have seen many very good plugins switch to modularisation using multiple separate add-ons and then switch back to a single “Pro” plugin for various reasons.

In theory having separate modular add-ons can be good to keep the file size lower and only include what is needed. On the other hand, it does require additional maintenance, keeping everything in sync and can lead to some duplication for each plugin.

On hosts like SiteGround which has “Inode” restrictions, the number of files can also be more of a significant factor than the size of the files.

I think a reasonable compromise initially may be to make each release go through a short beta stage. This would increase the time to get each release out but would likely catch many bugs / conflicts before they can affect a lot of users.

28

from the looks of it, because it’s toggable in the settings, Tailwind as a major feature is already being thought of as a module. Good example of what I was referring to. Not quite sure what you mean with duplication though.

Can’t really see that argument, because the bottom line is having feature A with it’s codebase being implemented as part of the big package VS standalone. Those 5 extra files don’t appear as such a big problem on hosts like SiteGround.

Plus I was thinking, that additional “major” features could be maintained in a seperate plugin until it reaches stable status and is ripe to be integrated into the main branch. Again, just like they do with the Gutenberg Plugin.

How should this beta stage looks in practice and how does it differ from the status quo?

1 Like
29

He Peter,
Ik zie je post nu pas. Wat mooi dat je dit zo beschrijft.
Cwicly is inderdaad geweldig maar we lopen soms nog wel tegen wat issues aan.
Ik gebruik het nu altijd, al heb ik weinig grote projecten.

Gr. Bob.

1 Like
30

There can be many duplications required, one common example would be license checking code, which would need to be present in each add-on, if it is a separate installable plugin.

I’m not sure what you are basing 5 files on, but I am inferring there could be significantly more overhead than this.

A temporary additional feature plugin may work well, as it would eliminate any synchronisation issues. This may work for a completely standalone feature, obviously wouldn’t necessarily work as well for something that modifies or enhances an existing feature.

Beta releases could have a separate channel and users could opt-in to install them. After an agreed time frame, any feedback or bug reports can be incorporated and then this can be released into the main release channel. In the case where there are no bug reports or feedback reports, the release could be directly moved over to the release channel.

31

Maintaining two separate builds of the same plugin and making sure everything works correctly on both, including dependencies, hierarchy, and iteration is not a trivial thing, especially when you have a small team. It adds overhead and complications that might not be worth it, or simply might hurt the entire release process, including fixing the bugs you might want to be fixed earlier rather than later. Not to mention customer support, and the communication hiccups that may occur. It means doing everything twice, including taking twice the time it would take to release bug fixes. It’s more common on these scenarios to have a reduced quality in overall code, potentially leading to more bugs over time.

The idea seems lovely on the paper, but implementing it might not be as simple as one would think it is.

1 Like
32

Ok I get the point. From the developers perspective it’s not easy to do. But from a clients view, it’s important to have stable and reliable software though. I’m not talking minor bugs, rather breaking changes.

Let’s set aside the Beta/LTS channel idea.

What do you think of the idea to release big new features (like Tailwind) as separate Plugins? And potentially introducing a Cwicly API to piggy back on?

33

Big releases like TW should be perfectly integrated in the whole system. I hardly see how it can be a separate extension. Also I tend to dislike smaller extensions for a main extension. With that it’s easy to have edge cases with one version of the plugin is not compatible with another one. Or they should be 100% independent.

In short having only one plugin is in my eye the assurance that everything should work together nicely. This doesn’t block any “quick patch” on the main branch of the project.

1 Like
34

Hi, maybe two update possebilleties?

Stable and Latest?

Cheers

35

The emphasis is on “should” here. The reality tells another story though: With the introduction of Tailwind, people got aware that it’s possible to set mobile first breakpoints. Me included. I expected to be able to flip the approached as I please, based on the dynamic nature Cwicly brings to the table. Including the help text "Make sure to regenerate your block CSS and Global Class CSS after modifying breakpoints."

Sadly this is, just not yet, the case. So we are left with taking the red or the blue pill. All in for Tailwind/mobile first (probably starting all over) or staying with the prior way of working with Cwicly and missing out a bunch of opportunities.
And in both cases breaking changes are introduced to at least one block, the most important one: the Nav Block and it’s decendants. It’s impossible to style it correctly with Tailwind classes and the former Cwicly way is broken, because presets don’t work.
I filed a bug already:

This is super frustrating to me and I just wanted to express my thoughts on a more safe approach to handle updates or new big features. While I see and have an utterly positive picture of Cwicly, this particular way of handling updates and QA raises questions.

36

I feel you. It should be really frustrating. Tailwind integration is a HUGE change indeed. Hopefully, everything will get sorted asap.

1 Like
37

I couldn’t say it better, I share exactly the same thoughts about TW or updates like that. and there was not appropriate warning about it.

1 Like
38

I still think complicating things won’t make fixing others faster.

It’s just going to take more time, because now you have extra plugins to compile, and extra tasks to do. Then you have to handle compatibility, and user support, and infra.

I understand your concern and that your goal is to raise awareness about issues you think are important. You probably feel that Cwicly is not prioritizing your concerns. But I don’t think this is the best approach.

We’ll have to be patient.

2 Likes
39

I am patient, but I was thinking constructively about ways how the Cwicly team may deal with new features that can introduce bugs in the future. And it seems I’m not alone here.

So I’m curious to hear some constructive ideas from an Elementor Dev Community Manager like you, @zeinnicholas. You probably have some experience and insights in this matter. How to deal with breaking changes?

40

Hey @oppi,

please understand that I’m not here to unconditionally refute or invalidate your opinions or points of view, I’m just trying to share my personal ones. I’m here representing myself, and my own points of view only. If for any reason you felt oppressed or offended I apologize.

Even when I’m extremely familiarized with the term “Separation of concerns”, as a Graphic Designer with experience in software development I do understand that usually things are not as simple as they might look. There are many pieces of a big puzzle that need to all fall in place at the right time, in the right way, and most of the time taking the long route is the best option when you take into account the big picture.

Moreover, working on specific new features never means setting aside the maintenance or improvement of existing ones. It just means they get priority on release based on a myriad of reasons that only make sense when you know the whole project. Sometimes working on these features means opening opportunities to not only fix existing bugs, but also improve the infrastructure to prevent them from returning, or to allow improving them further, and adding new features in the future. In other words, just because there is work being done on something, it doesn’t mean other things get abandoned. Not to mention sometimes fixing a bug means more than simply changing a couple of lines of code, but actually requiring refactoring that may affect a lot of other components, and therefore needing more time to make it right.

The idea of making everything optional is really something we all look for, because it’s easy for us. But to do that it means adding a lot of complexity that in the long run may actually hurt us instead of benefitting us. It’s also very true that most of the time there are simply too many things that are out of the dev’s control, and require more time to be handled (like dependency bugs, or conflicts with other software). While it would be great to have this separation, it means adding complexity to something that is working well already, which translates to more time to develop, maintain, and support. Time that could be spent on actually working on fixing the things that are broken, and/or adding new features.

To summarize, thinking about what @Xonbu.com asked:

Adding more complexity to the whole project might actually cause more damage and delays than having a single point of truth to deal with.

But this is just my opinion. :wink:

41

No offense taken! :relieved:

You more or less repeated the case against separating concerns, and I truly understand your POV.

I was really hoping to get some insights from you on how to deal with breaking changes.

42

@oppi I’m not sure I have any insights to share other than the usual suspects:

  1. Always check the changelog
  2. Backup
  3. Test on a staging environment before updating on production

As for improving reliability (which is necessary, no doubt about it), all I can say is that I understand why some things are being handled before others, and I believe that the Cwicly team knows what they are doing (they have proven themselves over and over).

Maybe a public beta would help prevent releasing some bugs, but it really depends on engagement. Usually it helps just a little, and on some rare occasions it does help find some bugs that are difficult to test and may only appear on live websites in specific cases. Unfortunately, most of the time crucial feedback is really not there, and you end up having to test on your own (in this case the Cwicly team), which is something they already do.

I for example would love to beta-test, but I simply don’t have time to do that. Usually what happens is that people focus on everything else (including requesting features not in scope) but the critical points, and the problem is only identified after the GA is released.