Developer forum

Hi Hans,

I have been struggling with, more or less, the same questions as you do now, so I will share my thought on this (not sure if your question was intended for the developer newtwork or DW team). 

I believe that both Rapido and Swift have Pros and Cons. For me, Rapido's blocks was a pretty good choice for customizations. I know that there are mixed feelings about it across the DW developer community and also there are a couple of performance issues as well. But just considering customization, Blocks were a good choice, and I am missing it in Swift.

The major benefit I see with Swift is the move to Bootstrap. This way the developers are more familiar with the framework and could find a lot of help online if needed.

Components and Visual Editor are also very good things that happened since Rapido. They are not the only ones, they are probably the most visible ones. Much of the Swift Pros comes from the changes in the core DW. Which is good regardless of the starter pack you are using. 

Customizations, in general, could be related to Data structure (ItemTypes) or Templates. The Data structure was always a pain to customize, regardless pf the starter pack. In my opinion this is probably the next area DW has to focus on. Templates in Swift are a bit more explicit and easy to access with the exception of the Cart templates where you have a lot of Includes and Includes in Includes. This results in a lot of template customizations just to change something in the last include.

My internal plan is to build an internal solution starting from Swift and customizing it to our needs. Every team has it's own needs and Swift cannot cover all of them.

Swift is a good place to start from if you sell your projects starting with a fit/gap analysis. If your selling process starts form customer need and not from what can be delivered with the starter pack, you will end up anyway with a custom solution and Swift (or any other pack) will just serve as a reference on how you are supposed to handle some scenarios.

Depending on how your team is built, you may found sometimes that customizng a functionality entirely (with a custom ItemType and a custom Template may be easier that replicating Swift logic just for the sake of upgrading.

Bottom line, Swift is better than Rapido, just as Rapido was better than the previous starter pack. But Swift (or any other starter pack) will not be able to answer every needs and you will end up customizing anyway.

Adrian
 

Hi Adrian

Ok, thank you very much for your torough explantion of your own experiences. Will take it into our consideration for deciding what to do next.

/Hans

Hi Hans,

A disclaimer first. I've been cooperating on Swift so I'm bias, but I'll add to some of what Adrian said.

I agree with all of the Pros and Cons from Adrian. I myself have mixed feelings about Rapido Blocks, but Swift is by far a much better option, specially considering what we'de done (which I'll also explain).

The world has changed too, so you're likely competing with other No-Code / Low-Code tools. For that reason alone, Swift is built with that in mind from scratch; not to mention modern Bootstrap (meaning HTML framework), and modern JS approach, with SEO and Accessibility in mind (Rapido not so much - once you get a customer wanting to do good SEO or accessibility in Rapido, you'll run for the hill). And Performance on Swift is much much better as well.

Swift is much more granular, and not necessarily meant for developers, but rather tech-savvy users (Content editors). It's granularity is actually very freeing. We've moved much more work from Developers to other people in our company because of this too.

Constraints are not a bad thing. It just means we can deliver something much quicker (i.e. 10 min clicking around VS 2 days building). The price gap may come as a shock to a customer, but that's not because you guys would be slow or are bad doing custom work, it's just because a "checkbox" is much quicker than doing new code (not to mention QA, responsive behavior, accessibility when applicable, estimates, back and forth comunication,...)

We still do custom development... a lot of it. And we do it in 2 shapes:

• New Item Types, templates, assemblies,...
• Extend existing Item Types and templates

The first bullet needs no introduction. But comes at a cost, which is that you don't inherit any of the new features (if you create a copy of an item type when you need to add something); and depending on the bug fix, you may not inherit too.

The community may have mixed feelings from the 2nd bullet. We do it... a lot and all the time. But we also have a set of rules to do it; the way we leave hints in our code and the way we work with Git (Squash and Merge our Pull Requests). We are actually capable to getting the latest version from Swift and then re-apply (cherry-pick) all of our changes, so we get the best of both worlds. (Yes, there are some tricky parts and risk, but it works).
We've been doing this for over a year and successfully updated projects that started in Swift v1.4.0 all the way up to where we are now (1.19.0)

Hope this helps you too.

Best Regards,

Nuno Aguiar