mojombo

8 ms·

31.
by mojombo 7y ago
While Redwood is currently optimized for deployment on Netlify, it is by no means restricted to that environment. Our intention is for Redwood apps to be deployable to a variety of JAMstack providers in addition to traditional serverful set
32.
by mojombo 7y ago
Thanks for noticing our hard work! We spent a LOT of time making sure the tutorial was rock solid and very clear. We will continue investing time into making the tutorial and our docs even better!
33.
by mojombo 7y ago
Unfortunately, no. Cloudflare workers are heavily restricted in what they can do, both from an outbound request and compute time perspective. If those restrictions are reduced, it’s possible we could make it work someday. It sure would be a
34.
by mojombo 7y ago
Not currently, and we will prefer pre-rendering to SSR if we can make it work well enough. But we are planning to address SEO concerns.
35.
by mojombo 7y ago
Like David said, we currently only help you build a web frontend, but we intend to eventually make it super nice to build a mobile app, desktop client, CLI, etc. All under the redwood umbrella (canopy?).
36.
by mojombo 7y ago
That’s the Schema Definition Language native to GraphQL.
37.
by mojombo 7y ago
Thanks! What would you use instead of GraphQL? Curious what your specific needs are.
38.
by mojombo 7y ago
As a fully integrated framework solution, it may be hard to gradually adopt Redwood, and that's ok. If you already have a setup you like, and it gives you the flexibility that you need, then that's awesome! I want Redwood to be ar
39.
by mojombo 7y ago
Next.js is really great, and has definitely helped push the industry forward. I'm not a fan of the way they handle routing, though, and we need to be able to evolve Redwood without fighting against our dependencies. If I had to guess,
40.
by mojombo 7y ago
We are currently not doing any pre-rendering, but it's on the roadmap to enable pre-rendering on a route-by-route basis. Even so, Redwood is still JAMstack because it's JavaScript, APIs, and Markup; it's just that we're
41.
by mojombo 7y ago
Cool! I'll take a look and see if there are any ideas we can pick up from YOU! I love that so much area is being explored in the JS world right now.
42.
by mojombo 7y ago
Quite tightly at this point, as really nice integration is a primary goal. That said, it’s not impossible that another rendering layer could be used, but it’s not our focus right now.
43.
by mojombo 7y ago
Yes! That is precisely how we see it. Well said!
44.
by mojombo 7y ago
We're looking to be a modern replacement for something like Ruby on Rails, so think full-on web application vs a blog or simple eCommerce site. Another way to think about is: do you have a lot of custom business logic you need to imple
45.
by mojombo 7y ago
I think it's a natural consequence of new possibilities existing in the JS world. Build tools like webpack, transpilers like Babel, type systems like TypeScript; deployment architectures like JAMstack; all these things mean we can do n
46.
by mojombo 7y ago
Thanks for the kind words! Redwood started as an experiment, and we'll see where it goes, but my intuition is that it will fill a need that many React developers currently have (namely: the lack of integrated solutions to all the techn
47.
by mojombo 7y ago
Yes! Our intention is to support TypeScript as a first-class citizen in Redwood apps (while still supporting JavaScript as well). We're currently working to make sure all of the framework code is written in TypeScript.
48.
by mojombo 7y ago
Hi! One of the Redwood authors here. I'm really excited to launch Redwood today and happy to answer any questions you have about the framework and what makes it special!
49.
Redwood: An integrated, full-stack, JavaScript web framework for the JAMstack(redwoodjs.com)
431 points by mojombo 7y ago|167 comments
50.
Joining the Netlify Board to Help Shape the Future of the JAMstack(tom.preston-werner.com)
1 points by mojombo 7y ago|0 comments
51.
by mojombo 8y ago
> It's an interesting counterexample to the typical stereotype that engineers cannot build products with good UX. Thanks! To me it's always been about product and I have a lot of background in design so it was always a priority
52.
by mojombo 8y ago
I don't know that there's anything that feels quite the same at the moment. React has some of the feeling, except that it's enjoyed much faster adoption because of the Facebook backing. Vue seems to be more the underdog. Grap
53.
by mojombo 8y ago
Our growth was always pretty linear. Surprisingly, steadfastly, linear. But we had the luxury of time from being bootstrapped and staying within profitability for years. We just waited for the market to shift as people realized Git was awes
54.
by mojombo 8y ago
Given today's tooling, I would probably have started later, but at the time it took us long enough to get a good Enterprise product put together that having started quite early gave us a reasonable timeline to enter the Enterprise mark
55.
by mojombo 8y ago
> Second, did shipping all source code in plain text to enterprise clients concern you? In the early days we ran the Ruby code through an obfuscator (which came along with its own set of problems), since we offered a downloadable free tr
56.
by mojombo 8y ago
All of the internal GitHub development was done on branches, so things stayed very simple. We developed on feature branches and merged to master. That's it. As long as you communicate well between team members you can avoid merge confl
57.
by mojombo 8y ago
I would probably start with a React frontend and GraphQL backend and then optimize from there. Rails is awesome and I owe a lot to it, but the world has changed a lot in the last decade and the modularization and data binding that React&#x2
58.
by mojombo 8y ago
> One piece of advice I got when porting my SaaS to Enterprise (on-prem) was NOT to create an "enterprise" branch in the source code, but instead just use one big GIANT flag such as an environment variable "ENTERPRISE&quot
59.
by mojombo 8y ago
> Tom: what tools did you use to build the OVF Enterprise image? Early on it was a mostly manual process too inefficient to even discuss (shudder). Then we moved to a Vagrant-based solution to make upgrades from any version to the latest
60.
by mojombo 8y ago
> How would you ship/deploy GitHub Enterprise (or FI) if you made the decision today A few years ago I met the founders of Replicated, who were just starting to build tools to make it much easier to ship an existing SaaS product to

More ›