5 ms·

I really appreciate endeavors like this, but... My experience with many other frameworks is that they really help you get started quickly, and some of them tru

by blunte 5y ago

I really appreciate endeavors like this, but... My experience with many other frameworks is that they really help you get started quickly, and some of them truly cover a vast majority of common use cases. But when you reach a point of need or situation where they don't work the way you want, you must then learn how to work around them or enhance them. That usually means doing a lot of digging and learning, essentially repaying that early time gift you received from all the nice built-ins. This should be a pretty familiar scenario for many of us here, and perhaps some have experienced this with RedwoodJS. If so, how do you feel about the framework now? How was the workaround/change-behavior experience?

maps7 5y ago
The alternative here is that you DoItYourself from the start and never launch or burn company money _before_ you even have a product or users.
- pooya72 5y ago
  I think that's taking the extreme end. Couldn't someone use a larger framework, for example Spring? It's pretty productive with Spring boot, but also large enough that you can expand for your use case. I'm not advocating for Spring per se, as I think .Net core is equivalent.
  - maps7 5y ago
    I was talking in wider terms of not using a framework at all and not specifically about Redwoodjs. I can't speak to whether RedwoodJS will lead you down a path of working around it.
pooya72 5y ago
Yes, and it's difficult to understand the tradeoffs without investing time in a framework. There are a lot of unknown unknowns, both in terms of the market fit and the framework. It's hard to know starting off what "situations" would be difficult for a framework like RedwoodJS.
rgbrgb 5y ago
My experience is that full-stack frameworks like rails (and hopefully redwood) free you from a ton of bike-shedding and customization up front and help you get to a point where you outgrow parts of the framework. An advantage of using something like rails today (or over the past 5 years) is that there was a huge crop of unicorn rails startups that all hit those challenges before and a lot of their solutions are codified in open source tools that can be plugged into the framework. In some cases those startups (like shopify, github) have made huge investments in ruby and rails themselves. I hope in a few years that will be the case for redwood. I like the concept of innovation budgets for startups. You can only innovate on so many vectors because time is typically your most limited resource. Very few startups have a good reason to spend any of that budget on innovations that are not core to their product differentiation. These things include web frameworks, corporate structure, credit card processing, low-level hosting. Just pick a pretty standard solution that fits your use-case and move on. I don't think it's a coincidence that so many of the big startups over that past 10 years were built with big batteries-included frameworks (would be so curious about a larger study of this, I just have cloudy anecdotes). Don't get me wrong, I love bleeding edge web stuff and playing with new frameworks. But if my priority is making a new company succeed I'm going to look for a framework that minimizes time spent picking libraries and gluing them together nicely and maximizes time I have to iterate on the product and tweak user-facing business logic.
10x-dev 5y ago
While this thinking isn't wrong, it is optimizing for the wrong thing. By focusing on future development velocity you are trading off current velocity, which is extremely important to build an MVP, test (and eliminate) potential product paths and generally get from 0 to 1 as fast as possible. There will be a point in the product lifetime when you will outgrow the framework and you will need to rewrite large portions of it and pay off the tech debt. Most projects don't get to that point. Once there, it is also the right time to make those decisions that were classified as premature optimization. Now they are merely tech decisions with one crucial difference: at this point you have much more information about the product, the market, the customers, and your team than you had initially, so now you can take the best decisions about what will really increase your velocity. If speed to market is not essential (such as a side project for fun) then by all means, it's you now, and it's you later, so take the time to enjoy your craft and become proficient at combining the best tools to make your project shine, instead of opting for the cookie cutter frameworks.
- danmur 5y ago
  I think you have to strike a balance sometimes, maybe bank on your eventual success and put a few % more in upfront to ease the path later. Using something you already know well is good, given you'll be more productive in it to start with and better understand how it's going to impact you in the future.
Lorin 5y ago
I'd love to know some specific examples of where you've hit walls, I'm building a major web lib/framework.
- danmur 5y ago
  I'm a nobody but I'll tell you a small experience I had with Pyramid (/ Pylons) - it didn't do too much for you in terms of admin UIs and things like Django etc but one thing it did really well is make a lot of its decisions easy to override. It uses the much-maligned Zope Component Architecture, but in practice it meant most parts of it could be switched out when you needed different functionality. (random mixing of past and present tense because it's still around and presumably still good but I don't use it)

by blunte 5y ago

maps7 5y ago

The alternative here is that you DoItYourself from the start and never launch or burn company money _before_ you even have a product or users.

pooya72 5y ago
I think that's taking the extreme end. Couldn't someone use a larger framework, for example Spring? It's pretty productive with Spring boot, but also large enough that you can expand for your use case. I'm not advocating for Spring per se, as I think .Net core is equivalent.
- maps7 5y ago
  I was talking in wider terms of not using a framework at all and not specifically about Redwoodjs. I can't speak to whether RedwoodJS will lead you down a path of working around it.

pooya72 5y ago

Yes, and it's difficult to understand the tradeoffs without investing time in a framework. There are a lot of unknown unknowns, both in terms of the market fit and the framework. It's hard to know starting off what "situations" would be difficult for a framework like RedwoodJS.

rgbrgb 5y ago

My experience is that full-stack frameworks like rails (and hopefully redwood) free you from a ton of bike-shedding and customization up front and help you get to a point where you outgrow parts of the framework. An advantage of using something like rails today (or over the past 5 years) is that there was a huge crop of unicorn rails startups that all hit those challenges before and a lot of their solutions are codified in open source tools that can be plugged into the framework. In some cases those startups (like shopify, github) have made huge investments in ruby and rails themselves. I hope in a few years that will be the case for redwood. I like the concept of innovation budgets for startups. You can only innovate on so many vectors because time is typically your most limited resource. Very few startups have a good reason to spend any of that budget on innovations that are not core to their product differentiation. These things include web frameworks, corporate structure, credit card processing, low-level hosting. Just pick a pretty standard solution that fits your use-case and move on. I don't think it's a coincidence that so many of the big startups over that past 10 years were built with big batteries-included frameworks (would be so curious about a larger study of this, I just have cloudy anecdotes). Don't get me wrong, I love bleeding edge web stuff and playing with new frameworks. But if my priority is making a new company succeed I'm going to look for a framework that minimizes time spent picking libraries and gluing them together nicely and maximizes time I have to iterate on the product and tweak user-facing business logic.

10x-dev 5y ago

While this thinking isn't wrong, it is optimizing for the wrong thing. By focusing on future development velocity you are trading off current velocity, which is extremely important to build an MVP, test (and eliminate) potential product paths and generally get from 0 to 1 as fast as possible. There will be a point in the product lifetime when you will outgrow the framework and you will need to rewrite large portions of it and pay off the tech debt. Most projects don't get to that point. Once there, it is also the right time to make those decisions that were classified as premature optimization. Now they are merely tech decisions with one crucial difference: at this point you have much more information about the product, the market, the customers, and your team than you had initially, so now you can take the best decisions about what will really increase your velocity. If speed to market is not essential (such as a side project for fun) then by all means, it's you now, and it's you later, so take the time to enjoy your craft and become proficient at combining the best tools to make your project shine, instead of opting for the cookie cutter frameworks.

danmur 5y ago
I think you have to strike a balance sometimes, maybe bank on your eventual success and put a few % more in upfront to ease the path later. Using something you already know well is good, given you'll be more productive in it to start with and better understand how it's going to impact you in the future.

Lorin 5y ago

I'd love to know some specific examples of where you've hit walls, I'm building a major web lib/framework.

danmur 5y ago
I'm a nobody but I'll tell you a small experience I had with Pyramid (/ Pylons) - it didn't do too much for you in terms of admin UIs and things like Django etc but one thing it did really well is make a lot of its decisions easy to override. It uses the much-maligned Zope Component Architecture, but in practice it meant most parts of it could be switched out when you needed different functionality. (random mixing of past and present tense because it's still around and presumably still good but I don't use it)