[DrewADesign]

Ok, so their homepage design unintentionally omits that pertinent information. I’ve wasted a couple of hours installing a FOSS package for a personal project only to find out one of the most heavily presented features was a paid add-in. Even if it’s bad communication design add not intentional, it feels like a salesey bait-and-switch tactic in that situation, and they probably want to know that.

[sudodevnull]

Why is pro pertinent info? You probably don't need it. It's just a set of plugins and tools anyone could write if they needed.

[nchmy]

What is it that you think is the most heavily presented feature that is actually behind a paid addin? Because they're quite vocal about the fact that most people should not ever need the pro license... They actively dissuade people from buying it.

[hasanhaja]

Which feature are you referring to?

[skeeter2020]

not the OP, but a lot of the referenced functionality looks like I might use it. The problem is I'm not going to bother trying this and investing any effort with even the looming possibility I'll need to pay to keep going. I don't think too many people approach this space with a purchase evaluation mindset like say, "I'm going to test out this grid to see if we should buy it". In that case pay-for advanced functionality is part of the approach from the start.

Also, I can't see this approach working. Getting enterprise adoption of a front end framework is almost impossible outside of React, let alone paying for a niche one, and the "contact us" approach is a non-starter.

[hasanhaja]

Fair enough! That's up to you

If the core of the framework fits what you need, you could write those additional plugins yourself, rather than relying on the official "pro" ones. My understanding so far is the plugin architecture is intentionally designed for this usecase, so you aren't beholden to the official maintainers to add/tweak features for your specific usecase.

This makes the investment in the tool a lot safer, because you can always swap out pieces that don't fit your usecase, rather than start from scratch with a new framework.

In an enterprise setting, I don't believe the cost alone will be the factor that drives the decision. It'd be weighing up the value of the framework (e.g., UI framework/programming language agnostic stack, simpler architectures, delivery speed, performance, cost of using the framework on users) against the license cost.

> Getting enterprise adoption of a front end framework is almost impossible outside of React, let alone paying for a niche one, and the "contact us" approach is a non-starter.

Two questions on this:

1. Why do you think it's impossible to get org buy-in? 2. Why do those same orgs pick frameworks like Next.js, whose full benefits can only be realized with sophisticated and paid infrastructure?

[nchmy]

as i've said in many comments and the devs say ad-nauseum, there's very little need for anything in the Pro license. the fully open-source library is sufficient for almost all needs. And it is easily extendable with plugins if you want more functionality than it provides.