Let's replace your kidney with React
Ahmad Nassri returns to the party for a deep, nuanced discussion around the thoughts he shared in a recent blog post called Solving Solved Problems. We hear about the common issue Ahmad’s seen at software shops of all sizes, learn the anatomy of the total cost of software ownership, and debate what to build and what to buy.
Sign in or Join to comment or subscribe
Loved this! Curious whether the “login as a spec” idea you had is fully realized by Solid https://solidproject.org/ - are there ways you think that falls short from what you had in mind?
Jerod co-hosts The Changelog, crashes JS Party, and takes out the trash (his old code) once in awhile.
I think Solid shows a lot of promise, but its challenge (from my limited understanding, correct me if I’m wrong) is that it needs end-user adoption into its ecosystem before it can be relied upon as a generally useful auth solution for app developers.
So not only do I have to convince you that my application offers enough value that you’re willing to sign up to use it, but I also have to educate you and convince you that you should adopt Solid’s storage pods, etc, etc
That being said, I’d rather do that than use Sign in with Google/Facebook if I had to choose one.
You’ve got it right! There’s a major chicken/egg problem. After building apps on Solid for the last year I’ve come to believe this will end up being solved in two ways - first, driven from the top, by large institutions like the BBC and NatWest adopting this stuff at the institutional level and giving people Pods and second, bottom-up by a new class of applications built by developers who want to stop re-building auth[z] backends and basic data collection user interfaces partnering with community-driven Pod providers. It’s been stunning to me as a web application developer how much more productive I feel using Solid as an application development platform - I haven’t felt this kind of quantum leap forward in productivity since I discovered Firebase, and it’s delightful not to have the downside of being tied to Google.
The one major caveat I’ll offer is that it took me a year of banging my head against the very nascent developer tools to get to this point, but that tide seems to be turning - Inrupt’s new frontend library is much simpler and much more clearly documented than its predecessors and has provided an wonderful base on which to build a React hook library. Inrupt’s recent announcements of next generation Community and Enterprise Solid Servers also feels likely to push this forward as they promise to make it dramatically simpler to set up production-quality Solid servers…
So TLDR - your skepticism is warranted and on point, but it’s a great time to kick the tires on Solid - a better world really feels possible!
Excellent episode and really good food for thought. The part about the build vs buy discussion that I missed was the old issue “the devil is in the details”. When you buy into a solution, you are potentially buying into show stopping bugs or limitations that aren’t apparent at the outset.
If the switching cost is too high you might end up having to fork a project and inherit technical debt that is way beyond the scope of your use case.
Personally I always consider the switching/forking cost as part of the risk analysis. If you need to fork, it is not just about being open source. You need to be able to maintain it.
Trying to keep your tech stack as simple as possible is a big win, and sometimes building will achieve this over buying because you only need a limited feature set.