5 ms·

This seems like this is mostly based on their choice of technology > Building the web app in Rails took me 2 days – the same thing in Node would have taken 2 w

This seems like this is mostly based on their choice of technology > Building the web app in Rails took me 2 days – the same thing in Node would have taken 2 weeks This is ridiculous, you are comparing a language framework with a runtime. Anyway, my problem with rails and other template based server side rendered frameworks is that the output looks decidedly un-modern and extending it to add the interactivity you can get from modern JS frameworks is hard. I have worked with code bases that were django or rails that bolted on react and other javascript frameworks and the result was not pretty. For my personal projects today what I do is the following, I use nextjs to build the frontend and I use nestjs with prisma for the api (a lot of the plumbing you were talking about is autogenerated here). I probably can't get up and running in 2 days but I can do it in under a week and adding new features is painless.

bdcravens 5y ago
When I hear someone say "Node", I implicitly understand that they mean an application with the libraries that go with. The same way I assess React with the libraries that go with. Perhaps the difference isn't "framework vs library", but rather, "explicit framework vs implicit framework"
tomc1985 5y ago
You'd be surprised what you can get out of nothing more than Rails + Turbolinks. As long as your site idea follows a "pages" analogy it is pretty much instantaneous. Anything more than that and you're trying to make an SPA > the output looks decidedly un-modern You could say that about anything. The output styles to how you style it. Also since when is modernness more important than content?
- friedman23 5y ago
  >Also since when is modernness more important than content? Design is just as important as content. Design in terms of how nice the site looks and design in terms of ux and usability. If people ignore your site because it looks cheap then the content is pointless. Most users really expect SPAs, they don't expect having to reload the entire site to see new content. Then you get into usability and many react component libraries really work well with you there. Accessibility for the visually impaired is baked into the library and the popular libraries follow modern UI conventions.
  - ch4s3 5y ago
    Things like Turbolinks, HotWire, LiveView, and similar html over the wire tools don't reload the whole page. LiveView(Elixir/Phoenix) and HotWire (Ruby/Rails) can update something as small as a single html tag attribute and if you want to, a lot of people sprinkle on something like Alpine for purely cosmetic changes in the UI. It's really quite amazing what you can do now with these HTML focused frameworks.
    - friedman23 5y ago
      It might be better than I think, I just personally don't want to go back to writing html in custom templating languages. I don't have fond memories of that experience.
      - tomc1985 5y ago
        Funny you say that, I have the same feelings about putting arbitrary HTML in my JS with React. Seems like we've all collectively forgotten about separation of concerns? Give me templated HTML any day of the week please :)
        friedman23 5y ago
        > separation of concerns I learned it and started developing this way taking separation of concerns as dogma and now I look back and wonder why we ever did it that way.
        sodapopcan 5y ago
        The thing is that this was never "separation of concerns", it was always "separation of languages". There were cross cutting concerns across each language (CSS doing layout, styling, animations; JS doing business logic, animations, layout, styling; etc). Mixing your JS/Other Language/CSS/HTML into components is a separation of concerns that really matters: separation of business/application concerns. Having everything you need that works together to solve a problem in place is very powerful (not to mention convenient).
- deleted 5y ago
  [deleted]
subpixel 5y ago
I'm curious what interactivity you require. Reddit is not 'real time' app, and this seems like a feature, not a bug. Slack is way beyond where Campfire started out, but can you boil the difference down to interactivity? In my experience, speed matters the most. Not just of development, but in user-experience. Rails is pretty damn good at this, especially recently. I still can't believe how fast a big Rails site like dev.to loads.
- omnimus 5y ago
  Also wasn't Slack in beginning written in PHP? The most not-realtime web stack there is. Maybe you don't have to go all in and can keep the boring application logic parts in Ruby/PHP/Python and offload the realtime performance stuff to more performant system (that can be even be in Ruby/PHP/Python because all of them offer some sort of async addon nowdays). It's strange in world where everybody is talking about microservices to be so afraid to use multiple connect tools that make specific parts easy. Like "Go all microservices but all of them in Node or Go".
  - deleted 5y ago
    [deleted]

bdcravens 5y ago

When I hear someone say "Node", I implicitly understand that they mean an application with the libraries that go with. The same way I assess React with the libraries that go with. Perhaps the difference isn't "framework vs library", but rather, "explicit framework vs implicit framework"

tomc1985 5y ago

You'd be surprised what you can get out of nothing more than Rails + Turbolinks. As long as your site idea follows a "pages" analogy it is pretty much instantaneous. Anything more than that and you're trying to make an SPA > the output looks decidedly un-modern You could say that about anything. The output styles to how you style it. Also since when is modernness more important than content?

friedman23 5y ago
>Also since when is modernness more important than content? Design is just as important as content. Design in terms of how nice the site looks and design in terms of ux and usability. If people ignore your site because it looks cheap then the content is pointless. Most users really expect SPAs, they don't expect having to reload the entire site to see new content. Then you get into usability and many react component libraries really work well with you there. Accessibility for the visually impaired is baked into the library and the popular libraries follow modern UI conventions.
- ch4s3 5y ago
  Things like Turbolinks, HotWire, LiveView, and similar html over the wire tools don't reload the whole page. LiveView(Elixir/Phoenix) and HotWire (Ruby/Rails) can update something as small as a single html tag attribute and if you want to, a lot of people sprinkle on something like Alpine for purely cosmetic changes in the UI. It's really quite amazing what you can do now with these HTML focused frameworks.
  - friedman23 5y ago
    It might be better than I think, I just personally don't want to go back to writing html in custom templating languages. I don't have fond memories of that experience.
    - tomc1985 5y ago
      Funny you say that, I have the same feelings about putting arbitrary HTML in my JS with React. Seems like we've all collectively forgotten about separation of concerns? Give me templated HTML any day of the week please :)
      - friedman23 5y ago
        > separation of concerns I learned it and started developing this way taking separation of concerns as dogma and now I look back and wonder why we ever did it that way.
        sodapopcan 5y ago
        The thing is that this was never "separation of concerns", it was always "separation of languages". There were cross cutting concerns across each language (CSS doing layout, styling, animations; JS doing business logic, animations, layout, styling; etc). Mixing your JS/Other Language/CSS/HTML into components is a separation of concerns that really matters: separation of business/application concerns. Having everything you need that works together to solve a problem in place is very powerful (not to mention convenient).
deleted 5y ago
[deleted]

subpixel 5y ago

I'm curious what interactivity you require. Reddit is not 'real time' app, and this seems like a feature, not a bug. Slack is way beyond where Campfire started out, but can you boil the difference down to interactivity? In my experience, speed matters the most. Not just of development, but in user-experience. Rails is pretty damn good at this, especially recently. I still can't believe how fast a big Rails site like dev.to loads.

omnimus 5y ago
Also wasn't Slack in beginning written in PHP? The most not-realtime web stack there is. Maybe you don't have to go all in and can keep the boring application logic parts in Ruby/PHP/Python and offload the realtime performance stuff to more performant system (that can be even be in Ruby/PHP/Python because all of them offer some sort of async addon nowdays). It's strange in world where everybody is talking about microservices to be so afraid to use multiple connect tools that make specific parts easy. Like "Go all microservices but all of them in Node or Go".
- deleted 5y ago
  [deleted]