It's meant to be a 'rails-like' experience in Go without too much magic and conventions.
Basically, speeding up development of fullstack apps in Go using templ, datastar, sqlc with an MVC architecture and some basic generators to quickly setup models, views and controllers.
not sure i think this is a good way to fund their work BUT exploring models to make open-source sustainable for the developers does seem like a good thing, no?
I have no problem with anyone charging what they would like, but I do think it should be mentioned on the homepage. It feels intentionally left off which makes me think the developers themselves aren't 100% comfortable with the model.
Yes, it feels scammy. Like you, I've no problem paying for software if it seems worth it. I've payed a few times for Highcharts (different companies) and I did gladly and without hesitation, it also feels that they're being honest about their business model.
Not a scam. It just feels the same as a scam feels.
One time I had a couch delivered. Two guys show up to set it up. One guy says he needs a tool from the truck and walks off, and the other guy starts talking to our dog, and tells us how he used to train pit bulls, and starts doing some weird hand motions and yelling commands to our dog like he’s casting a spell or something.
I think the guy was probably just not all there mentally, like too much former drug use or something. But it was one of those surreal moments where red flags were going off in my head. I went to find the other guy just to make sure he wasn’t robbing us out the back. Because that’s what it felt like: misdirection, social engineering, a performance.
In hindsight, I don’t think there was anything suspicious going on. But the alarm bells in my head were still completely real.
When we see this “everything is an plugin” but “plugin details are internal-only” and “plugin detail is coming” and “1.0 is released” and “but we will have 40 more release candidates before 1.0 final” and “you could support us with pro” and “you dont need pro” and “we don’t recommend pro” and “you can build anything in pro yourself anyway” and “you shouldn’t use this pro feature anyway and should use CSS instead”, and then when people ask a question about any of this inconsistency, we get juvenile responses like “don’t use it then”, “don’t buy it then”, “fork it then”, “my time isn’t free”, and so on. Even though there is no scam, it’s surreal. Like, “is this really happening?” It sets off the same red flags in people’s minds, even when there is no scam.
Datastar seems very cool as a tool, and the developers seem very technically competent. The problems they face don’t seem to be technical problems.
I don't think that's a fair read of their intentions given how they talk about it everywhere [1]. Pro isn't there to paywall great features, but there to support the development of complex and annoying ones. The example of `data-on-signal-patch` that moved from pro to core speaks to how they're thinking about the project.
I think most people are not comfortable with making money or talking about money. Also people who are bad at making money might be bad at marketing/handling this.
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.
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.
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.
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?
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.
i went looking for pricing info and it's the last item in the last menu on the website... it's not exactly up front. i was looking for a "pricing" top-level menu item first, which is pretty standard nowadays.
As ive said in many other comments - YOU DO NOT NEED PRO. The devs are very adamant about this - even aggressively so. 99% of apps will work just fine with the free library. Pro is for some bells and whistles, or just to support people who have invested many thousands of hours into making a genuinely innovative framework, and given it away
OK, then this approach will needlessly discourage adoption AND consume way more resources than it brings in. Under this structure the team needs to deliver the highest level of quality to the smallest paying audience without community support. Further, enterprise is very hesitant to pay for this as a product but are way more receptive to paying for support. Everyone would be much better served without a tiered free/pay product and paid support options.
>> or just to support people who have invested many thousands of hours into making a genuinely innovative framework, and given it away
I've never seen a corporation do this even with projects that don't try and encourage like here.
If an enterprise won't want to pay for the product, what makes you think they're more likely pay for support?
If you're implying they'll only pay when they've seen the value of the product, then the non-pro part of the framework is incredibly feature-rich and can easily do that.
Yeah support model for a lit of projects like this doesn't work. Even companies like the one behind NATS struggle. It's almost contingent on you building a bad product that needs support.
you're stretching the definition of deception here my guy-what do you want them to do? plaster a big sign on the landing page stating that this framework ALSO contains pro features that you have to pay for?
I've commented above that this seems like a bad approach, but it sure feels like a lack of awareness vs. an intentional dark pattern. The internet makes it so easy to assume the worst but I think this is a case where we should start with the most charitable interpretation.
I'm confused. Datastar is a free open source framework that you can choose to use or not.
It's weird to call them out as indecent and deceitful for not actively marketing features that they really don't think you need. Even when you think you need it, they've actively encouraged people to analyze their problems to identify if it's a real need or a gap in hypermedia fundamentals knowledge.
Also, the top nav has a Pro page that has what you're looking for.
I do think this is the most sustainable approach for monetizing open source projects, as long as the developer is fair about it. That is, truly make features that only large and/or enterprise users would have a use for, and only charge for those, instead of arbitrarily deciding to put core features of the software behind a paywall.
In the case of a web framework, that choice is a bit difficult. But if the software is fully functional for the large majority of users, then charging for niche features, or those that are actively discouraged, sounds like a fair approach to me.
I'm skeptical about this business model because it can become worse than proprietary software dependency over time. You get lured in by thinking it's open source and free, and might end up paying as much as the developer wants for essential features a few years later.
Like I said, it's crucial for the developer to be fair about it. Running a sustainable business built on open source is entrepreneurship on hard mode. Some companies do a better job at this than others, and, unfortunately, open source has been abused as a marketing strategy on many occasions.
No matter how you look at it, though, any business model that enables users to use open source software is a much better option for users than any proprietary software. There's no comparison. Given the choice, I'd much rather use OSS that is eventually rugpulled or enshittified than proprietary software, which carries those same risks, while also restricting my freedoms from the get-go, and having additional risks I might not be aware of at all (exploiting my data, security issues, etc.).
They're not even running a business on this - its literally registered as a 501c3 nonprofit. Its a labour of love that theyve shared with the world, and they actively tell people that the pro features are unnecessary for most projects. If you want those features or just want to support the project, the cost is quite fair, and just goes to things like traveling to do conference talks etc... They are not getting rich off of this.
Also, they intend for v1, which will be released soon-ish to be essentially the final version of Datastar. There wont be a need for much further development. So there's minimal risk of "rugpull" or even abandonment.
That's admirable. They just gained another sponsor. :)
I do think that they should be paid for this work, and be able to sustain themselves from it. So I wouldn't be against it being a business, or the project having a subscription model. The idea of open source being gratis, and products in general being "free", has done enough harm to the world.
100% so many projects have died because they didn't have a longterm plan to keep the lights on other than hoping for donations and or offering support that no one needed (the better the project the less likely you need support).
If they are charging for features, those features are a business, even if its a nonprofit business. There is also precedent for the IRS to consider it unrelated business income and to make them pay taxes on it, but that seems to be a huge grey area in US tax law.
See for eaxmple the Mozilla IRS dispute as an example. Mozilla resolved this by putting their money making endeavors into a for profit org, which is in turn owned by the nonprofit, but the for profit org pays tax on their income.
https://www.irs.gov/charities-non-profits/unrelated-business...
See also
Yeah it's a weird one people complain about open source projects having extra features you can pay for. But, then they also complain when you make open source GPL.
I'm sure it would be the same group complaining if it was GPL too.
Except the pro option is not "a few years later" it's available in pre-v1 and is a one-time lifetime purchase, not a subscription.
And the framework and docs are so small and simple, that you can read the entire site in an hour or two, in which time you would have noticed the pro features and pricing many times.
At the risk of repeating myself, I was talking in general terms about the business model and the uncertainty about the licensing it creates concerning possible future features.
I wasn't aware that they are a non-profit organization and agree that my remark doesn't necessarily apply to them since they're not a business. If the pro subscription helps them to maintain the open source project without making any profits, then that seems alright to me.
Looking at https://data-star.dev/reference/datastar_pro#pro-features the features that stood out for me as things I would want to to use (and that don't feel particularly "pro" to me) are the animation features, data-replace-url, data-on-resize, data-scroll-into-view, the @clipboard() mechanism and, most importantly, the debugging tool.
My problem with this business model is that it has a chilling effect on open source contributions to the project, because it incentivizes the core maintainers to not accept community contributions that overlap with the paid features.
Datastar is currently in the Release Candidate phase of v1, which they seem to be certain will be the final form of Datastar. So, they're really not looking for "community contributions" to the core of datastar, other than for feedback to polish it off.
Moreover, ALL of the features are "plugins" - there's nothing stopping anyone from building and sharing their own. It is actually encouraged. In fact, in their next release they'll be releasing and documenting some sort of public API for plugins. Not sure exactly how it will differ from the current form though, since you can already make your own plugins.
They also intend to have some sort of free, open-source "marketplace" for community-built web components, based on their upcoming Rocket web component and Stellar css framework. You would just need to have the Datastar pro license to be able to use any of them.
I can see how this final part might be criticized, but it does seem quite fair to me. Sustainable open source is a big problem - in recent months ive had some important fully-open source dependencies disappear - even ones that were backed by well-funded companies. Moreover, Datastar is registered as a 501c3, and they really don't intend to "make money" from all of this. Its just to pay the bills, travel to conferences etc...
They're very reasonable people and open to all discussion in their discord. Im sure that whatever concerns you still have could be explained quickly if you went there.
In fact, i just posted there about this thread and how its overflowing with nonsensical complaints about how there's no link to or mention of Pro on the homepage - they said sure, we'll add a link.
Also, btw, some of these - specifically data-replace-url - are strongly discouraged by the devs, to avoid footguns. I dont have experience with it, but people have spoken lots in their discord about how things like Hotwire Turbo are too magical and end up causing a lot of issues. Datastar strong recommends just using hypermedia as it was designed (HATEOAS https://htmx.org/essays/hateoas/) and doing full page reloads when you change a page. And for more ephemeral in-page changes, you can use the sse fragments morphing etc
Building web applications & APIs for scale with 10 years of experience.
I predominately specialize in creating scalable systems for start-ups and scale-ups. I can help with systems design, creating an mvp, upskill your team assist you in going from 0 to 1.
Recent experiences as largely between in the AI/ML space:
- integrate full-text search across all popular CMS
- backend for large outreach platform
- systems architecture and data pipeline for AI vision product in the pharmacy space
- move client's infrastructure to AWS
In general, I agree because it's easier to test and monitor back end code. However, if the complexity also comes along with heavy CPU load, I like to push that out to the client.
For the record, I love Rust. It’s an amazing language and my example was not meant to discourage the use of Rust. But, it is verbose and generally takes longer time to write and understand compared to Go. For most projects, Go simply fits the bill for speed of development, ease of use, onboarding new people and performance.
> But, it is verbose and generally takes longer time to write and understand compared to Go.
I respectfully disagree, and I don't think I'm alone in that. I would be willing to bet that the majority of people who have used both languages professionally would agree with me.
Reading or writing N lines of Go is easier and faster than reading or writing N lines of Rust, true. But you have to repeat yourself so much in Go that doing the same thing takes a lot more lines of code than it does in Rust, so reading and understanding a whole program that does something useful is much harder. And that's just reading. Writing is even harder because Go has very few guardrails for protecting against important classes of bugs, so you spend way more time debugging issues that are just not a thing in Rust.
> For most projects, Go simply fits the bill for speed of development, ease of use, onboarding new people and performance.
I disagree about speed of development for the reasons I said above. Ease of use is subjective; I find Rust much easier to use than Go (no exhaustive match on tagged unions in 2024? Really?) As for performance, Rust is hard to beat. So you're left with onboarding new people. Sure, Go is easier to learn than Rust. But it doesn't really make sense to optimize a language for the first 100 hours spent learning it when for most people it's a tool they will use for years.
I agree with you. Go saves a lot of time by having an amazing standard library and tooling... but the tedious writing out of the loops man! I don't even mind `if err != nil` - that's just proper error handling, but writing out loops and maps by hand like a cave man... I can't go back to that.
It's not just Rust that has those, it's every modern language except for Go (because Go is the only one run by "simplicity" ideologues who reflexively refuse to consider adding modern features).
I can’t claim to have been paid to write rust, but I’ve written code professionally for many years now and most of them in Go. I have also written my fair share of rust code for web applications.
The repetition in Go, in my experience, mostly happens at the beginning and then you only have to deal with ‘if err != equal nil’, which to be fair is probably a good thing. Is it really more verbose and repetitive than error handling in rust?
I would love to have the type system rust has in go. It really allows you to be expressive and put in guard rails in a way you can’t using go. But I don’t think most applications need that.
My experience tells me something different than yours, maybe I’m wrong. But I can’t reconcile your arguments with my experience writing rust web applications. Even if I still miss writing my queries using sqlx and my views with asakama.
> Is it really more verbose and repetitive than error handling in rust?
Of course.
if err != nil {
return nil, err
}
is 34 characters in Go, counting a tab as one character. The Rust equivalent,
?
is one character.
But Go verbosity and repetition isn't limited to error handling. Another example is e.g. the lack of any metaprogramming capabilities (e.g. macros) which forces you to either copy and paste code or write a code generator in many cases (or use runtime reflection).
> I would love to have the type system rust has in go.
Unfortunately you will never get it, because Rob Pike's ideology is "if it didn't exist in C, it's too complicated and difficult for Go programmers to understand".
This isn't a joke or exaggeration -- programmers being too stupid to understand modern features has actually been cited as one of the main design constraints of Go.
> But I don’t think most applications need that.
Of course nothing needs it, just like nothing needs function calls (it was possible to write large applications in assembly language). But most applications (including all the ones I've ever written) benefit from it. Rust's type system is there to make it easier to write programs, not to make your life harder.
> My experience tells me something different than yours, maybe I’m wrong.
I wrote Rust professionally for 5 years and Go so far for about 6 months (and even that was not spent full-time on Go). So I don't claim to be an expert. But I am constantly running into things that Go makes difficult or impossible that would be a breeze in Rust.
The author here, thanks for posting this. I can see a lot of people not agreeing with Go, that’s fine, I still love writing it everyday. Taking choices away from you in terms of language features enables you to focus on the problem you’re solving. That makes it a great choice to me.
> Taking choices away from you in terms of language features enables you to focus on the problem you’re solving.
As someone that worked with Kotlin for a couple of years, I can agree with this. I actually enjoyed the language but there were so many, I'd say, obscure things or multiple ways you could do the same thing that I'd feel lost sometimes. As someone once said - Kotlin is easy to write, but somewhat hard to read. In the end I just wanted to solve problems and ship my product and I felt the language was getting in my way a lot of the times.
Anyway, in the end I guess it's about personal feeling and conformity with the language of choice.
This is a false dichotomy though. Not wanting to end up as a kitchen-sink language like C++ doesn't mean that you have to swing completely to the other extreme and refuse to add any modern feature (except possibly after years of fighting), even the ones that exist in every other modern language and have proven to have no real downsides and be hugely useful (like sum types).
There is no false dichotomy in my comment. I'm quite happy using Go. It was easy to pick up, the executables work fast and flawlessly and as a language it delivers the required results in what I do so far. Time will tell, but its simplicity does work great for me, and I've tried quite a lot of languages in the past 2 decades.
Yeah, personal feelings towards a language are a big factor.
I once did a short gig with a start-up that used Kotlin and the CTO was very enthusiastic about Kotlin. He showed all the things you could do in the languages like adding behavior to an integer that would be applied throughout the program. He was excited and I was a little horrified haha. But huge companies have been built using Kotlin so who am I to judge?
I'm in the same boat as you, I want to solve problems and build products.
It's very arrogant to imply that people who prefer other languages don't want to "solve problems and build products".
That's what everyone wants to do. They just think Go is not the best tool for doing it.
Again, you seem to think everyone else is some kind of academic egghead who enjoys other languages because they let them solve intellectual puzzles. That's not true, they prefer other languages because those other languages are better than Go for practical reasons.
Mate, come on. I've implied none of that. Just said that the simplicity of Go tends to shift my focus, at least, to the problem and product, not as much the implementation.
You like Rust and hate Go, that is very clear. But maybe before you call me arrogant and put words in my mouth, read back my comments. I haven't trashed other languages or told people that what they like is shit. Simply that I like Go, and that I don't agree with your arguments.
It's entirely understandable that you have a different opinion from me; I just don't like the implication that "caring about solving problems" makes one appreciate Go, since that is what nearly all professionals care about.
Btw, my opinion isn't just "liking Rust" -- Rust has plenty of problems. My opinion is that Go is uniquely bad among modern programming languages. Most of the major flaws in Go are fixed in every other modern mainstream language, of which Rust is merely one example.
But I'm not saying that. I'm not saying that professionals don't care about solving problems. I'm saying that by removing features from a language you tend to shift your focus more to solving a problem vs _how_ to solve a problem (in language space).
When you have lots of options you always have lots of opinions, just human nature. When working with low-level problems I get how having lots of options is good since you need to be precise. But, most people work on web-related problems. These have most likely been solved in one way or another before. I don't want to discuss in PRs if you should use x/y/z language feature, I don't think that's relevant for a lot of technical solutions.
No, because I'm not the only person writing code. If someone else chooses to use this feature, I will eventually have to interact with it and/or maintain it.
It’s a combination of learning new languages and concepts, expanding my skill set and so on. I have written typescript professionally for a number of years now, and its type system doesn’t even come close to Rust.
I use Go professionally and would most likely choose that if I had to do any new “serious” web dev project. But the Rust eco system has come a long way. Plus, the borrow checker aren’t really that tedious once you get use to it. At that point you get a lot of benefits!
It is, yeah! Been such a joy using it, great docs as well. Haven't done much with a DB yet (other than following along the awesome Zero 2 Prod book) but my general impression of SQLx was quite good!
It's meant to be a 'rails-like' experience in Go without too much magic and conventions.
Basically, speeding up development of fullstack apps in Go using templ, datastar, sqlc with an MVC architecture and some basic generators to quickly setup models, views and controllers.
reply