Strike vs. Lightning Base components - How to stay fast and maintainable?

Base Components.

Those are built in Java (said René Winkelmeyer) and have better performance.

That being said, I would remove any 3rd party component as soon as viable base alternatives are available. lightning:progressIndicator and strike:modal are good examples for the progress of the platform: Indicator and Modal were merged/abstracted into lightning:overlayLibrary which can better interact with different lightning layers than any custom component could do with ease/minimal complexity (without itself relying on the same base component).

Also, as a Salesforce Rule of thumb, don't go Third Party without due cause.

Personally, I'm dependent enough on SFDC releases and would not want to wait for 3rd party updates or issues.

This is what George Kenessey, the CEO of Apphiphony answered on the Github version of this question highlighting that:

• Strike was created to fullfil the needs of Appiphony customers
• Appiphony is not at all cordinating their Strike efforts with Salesforce.com
• They will evaluate how to best cope with Strike and Base components being very similar

...Please keep in mind that Strike components are an open source project that came out of our own needs for a set of Lightning components. To-date we have put in over 5,000 plus hours into making them. We thought it would be great to share them with other developers as a way to give back. Yes, we are funded by Salesforce but I want to make it clear to all that we are in no way coordinating our roadmap for Strike components with the Salesforce Lightning team. We base our roadmap on the challenges we are facing in our current projects and often have to decide if we need a solution immediately or if should wait for a future Salesforce release when a component may become available.

We have not made decisions yet as to what changes we will make due to all the awesome new components being released in Winter 18. Over the next few releases we will evaluate how to best approach the scenario of a new Base component being released by Salesforce that is the equivalent of a Strike component. I suspect that there will be times when we require a component to have some functionality that a Salesforce Base component does not support and in those cases we will be able to make the decision to add it to an existing Strike component or build our own version of the component. We see a world where there is a benefit to multiple choices existing side-by-side. Data Grid is a good example, there are a multitude of open source grid/table projects because the use cases for them vary so much. I imagine Salesforce would struggle supporting them all with the new Datatable component. In situations like this the Strike Data Grid may have a role to still play.

At the end of the day every one has a different situation they are facing and I hope that sharing some of our thinking helps in some way.

We try to replace any custom components (either strike or internally developed) with base components whenever there is feature parity. Using Salesforce components should reduce the maintenance overhead for the team down the road.

That being said, just because Salesforce releases a new base component does not mean it has feature parity. lightning:overlayLibrary is a great example. They don't yet support some basic things like specifying size with an attribute. Also, they have made a fundamental shift in how developers define the modals moving from markup to dynamically generated components. For these reasons, lightning:overlayLibrary does not yet have feature parity for us with c:strike_modal.

I would love Salesforce to add more flexibility to their base components but given the pace at which we have gotten these existing base components it does not seem likely soon. This was a pretty basic example, but I hope that it gives a little insight into one possible thought process for choosing components.