6 ms·

Congrats on the release. This feels like Rails for the javascript age. Moving from: REST => GraphQL, Sprockets => Babel/webpack, VM => Lambda, Caching => Stati

by sytse 7y ago

Congrats on the release. This feels like Rails for the javascript age. Moving from: REST => GraphQL, Sprockets => Babel/webpack, VM => Lambda, Caching => Static site, ERb => React, Active Record => Prisma, Rspec => Jest, routes.rb => Routes.js Edit: The twitter thread from the author is a great summary of Redwood and its benefits https://twitter.com/mojombo/status/1237441122097487873 https://twitter.com/mojombo/status/1237441122097487873

mojombo 7y ago
Yes! That is precisely how we see it. Well said!
thebradbain 7y ago
Super exciting, I've always believed a Rails-like philosophy of convention-over-configuration and the Javascript ideal of perfectly-tailored customization could supplement rather than compete each other. Redwood looks like a big step toward that, and I think it speaks to the overall growth of the Javascript ecosystem as a whole.
- cknoxrun 7y ago
  I feel as if Rails plus a progressive framework such as Vue.js is essentially what you are talking about?
  - thebradbain 7y ago
    Yeah, almost. That's essentially my current preferred stack already. But "almost" is the key word: sometimes there seems to be some overlapping duplication of functionality, if not necessarily code, and the handoff between Rails-world and Vue-land is still a kind of purgatory which can be solved and navigated with experience and knowledge of the ins-ands-outs of both frameworks / webpack / package management / etc., but it'd be _nice_ if all those options were solved in the first place, rather than having to work to cleanly and sustainably get two frameworks to talk to each other nicely.
ljm 7y ago
I agree this is super exciting but those things come with a significant operational overhead that your traditional full stacks don't have. one vm => many lambdas/microservices react => server side rendering and state hydration, throw redux in there too prisma => you can't beat the DB with code. Learn SQL and remove the middleman. Jest => fair enough I guess, but I wouldn't use rspec when Ruby had minitest out of the box Caching/Static site => wut? ... wut? there's much more to caching than HTML. routes.js => probably great on the server, not so much on the browser. And the best for last... graphql => not a replacement for REST. You can do more with less by just making your client do the work or going with backend-for-frontends. If you don't understand your network then graphql is an easy vector for DOS (speaking from experience). Meanwhile I can spin up Laravel, Rails, Spring or Django up and get a solid application running in a fraction of the time while in JS land, client server arch is a seemingly unsolved problem. I sound bitter but I'm more incredulous. I don't actually enjoy writing for the browser any more, there are too many divergent trends.
- deleted 7y ago
  [deleted]
- onion2k 7y ago
  Meanwhile I can spin up Laravel, Rails, Spring or Django up and get a solid application running in a fraction of the time while in JS land, client server arch is a seemingly unsolved problem. This might be a slightly controversial opinion, but I don't think the time it takes to get an application running with a framework is a relevant metric. Being able to get an application up and running fast is only a useful benefit when you're first starting out and trying things. If you're choosing a tech stack and you're going to be working on something for months or years, the fact that you can see something on a screen after an hour or after 3 days is completely insignificant compared to how good it is to work with in the long term. Choosing a technology because you can start working on a new application quickly is the wrong way of thinking about your tech stack.
  - hombre_fatal 7y ago
    I think your post summarizes a major reason why so many people ended up using small frameworks and appreciating glue code after using Rails/Django. My noob a-ha example is `rails generate devise:install` where I first thought, wow, what a time saver. Eventually I learned lessons like, perhaps authentication is too important to be hiding from your source code. In fact, maybe almost everything is.
dmitriid 7y ago
Rails didn't load 286 KB of Javascript to display static text and sidebar though. If you go to https://redwoodjs.com/ https://redwoodjs.com/ right now and disable Javascript on the page, you will get the same amazing fast experience at literally 5-10x less size. The only difference? The sidebar in the tutorial will not display properly. JS enabled: 403KB transferred, 1.0MB resources. Of them: 276 KB JS, 82 KB images, 27 KB custom fonts, 10 KB HTML, 5.5 KB CSS JS disabled: 99 KB transferred, 142 KB resources. Of them: (0 JS, 0 custom fonts), 82 KB images, 10 KB HTML, 5.5 KB CSS
- pistoriusp 7y ago
  Part of our story is to make sure we only bundle what matters... We're not there yet, but we're going to make this first class and intuitive.

by sytse 7y ago

mojombo 7y ago

Yes! That is precisely how we see it. Well said!

thebradbain 7y ago

Super exciting, I've always believed a Rails-like philosophy of convention-over-configuration and the Javascript ideal of perfectly-tailored customization could supplement rather than compete each other. Redwood looks like a big step toward that, and I think it speaks to the overall growth of the Javascript ecosystem as a whole.

cknoxrun 7y ago
I feel as if Rails plus a progressive framework such as Vue.js is essentially what you are talking about?
- thebradbain 7y ago
  Yeah, almost. That's essentially my current preferred stack already. But "almost" is the key word: sometimes there seems to be some overlapping duplication of functionality, if not necessarily code, and the handoff between Rails-world and Vue-land is still a kind of purgatory which can be solved and navigated with experience and knowledge of the ins-ands-outs of both frameworks / webpack / package management / etc., but it'd be _nice_ if all those options were solved in the first place, rather than having to work to cleanly and sustainably get two frameworks to talk to each other nicely.

ljm 7y ago

I agree this is super exciting but those things come with a significant operational overhead that your traditional full stacks don't have. one vm => many lambdas/microservices react => server side rendering and state hydration, throw redux in there too prisma => you can't beat the DB with code. Learn SQL and remove the middleman. Jest => fair enough I guess, but I wouldn't use rspec when Ruby had minitest out of the box Caching/Static site => wut? ... wut? there's much more to caching than HTML. routes.js => probably great on the server, not so much on the browser. And the best for last... graphql => not a replacement for REST. You can do more with less by just making your client do the work or going with backend-for-frontends. If you don't understand your network then graphql is an easy vector for DOS (speaking from experience). Meanwhile I can spin up Laravel, Rails, Spring or Django up and get a solid application running in a fraction of the time while in JS land, client server arch is a seemingly unsolved problem. I sound bitter but I'm more incredulous. I don't actually enjoy writing for the browser any more, there are too many divergent trends.

deleted 7y ago
[deleted]
onion2k 7y ago
Meanwhile I can spin up Laravel, Rails, Spring or Django up and get a solid application running in a fraction of the time while in JS land, client server arch is a seemingly unsolved problem. This might be a slightly controversial opinion, but I don't think the time it takes to get an application running with a framework is a relevant metric. Being able to get an application up and running fast is only a useful benefit when you're first starting out and trying things. If you're choosing a tech stack and you're going to be working on something for months or years, the fact that you can see something on a screen after an hour or after 3 days is completely insignificant compared to how good it is to work with in the long term. Choosing a technology because you can start working on a new application quickly is the wrong way of thinking about your tech stack.
- hombre_fatal 7y ago
  I think your post summarizes a major reason why so many people ended up using small frameworks and appreciating glue code after using Rails/Django. My noob a-ha example is `rails generate devise:install` where I first thought, wow, what a time saver. Eventually I learned lessons like, perhaps authentication is too important to be hiding from your source code. In fact, maybe almost everything is.

dmitriid 7y ago

Rails didn't load 286 KB of Javascript to display static text and sidebar though. If you go to https://redwoodjs.com/ https://redwoodjs.com/ right now and disable Javascript on the page, you will get the same amazing fast experience at literally 5-10x less size. The only difference? The sidebar in the tutorial will not display properly. JS enabled: 403KB transferred, 1.0MB resources. Of them: 276 KB JS, 82 KB images, 27 KB custom fonts, 10 KB HTML, 5.5 KB CSS JS disabled: 99 KB transferred, 142 KB resources. Of them: (0 JS, 0 custom fonts), 82 KB images, 10 KB HTML, 5.5 KB CSS

pistoriusp 7y ago
Part of our story is to make sure we only bundle what matters... We're not there yet, but we're going to make this first class and intuitive.