21–30 of 490 posts
Earlier quoted context omitted.
I can't help but think it is a reflection of the JS ecosystem that I assumed you had misspelled Next.js
I guess Nest.js is actually right: https://nestjs.com/ A TypeScript framework like Rails is a framework for Ruby.
Not quite. "NestJS" is actually right. :)
I think the author is trying to compare what it takes to create an MVP web-app with all modern features versus creating it in the JS ecosystem. Also, Rails is well known to have Convention over Configuration. That helps to set up and maintain a project since everybody has to follow the same pattern. The cons is that you lose flexibility from the architecture perspective. But in Rails, you have ways to overcome that e…
I look at it the other way around, to someone coming from Ruby/Rails, there are far too many choices to make and it can seem very overwhelming. But on the flip side you get very granular control over your projects structure. Like when the author mentioned the framework options: > Next.js, Remix, Gatsby, Vite, Create React App, Koa or Express? - NextJS, Gatsby - Best for building "websites" that are optimized for SEO…
"Next.js", not to be confused with NestJS...
I think the author went too deep into details here, as this crowd is full of people who are going to be able to rip pieces of this article to shreds. But doing so both misses the larger point and in the process proves it - Rails gave them a set of answers that are good enough so they don't need to delve deeper and can just focus on their app. Rails is not the only choice that does so. And people with broader skill se…
No doubt here! I know there's a lot of nitpicking, but that's just my experience so far. I wanted to make it clear by removing all "we" or "you" words from the post to make sure I'm not saying my opinion is the definitively right one :)
> Rails is not the only choice that does so.
Absolutely, the only two reasons I went with Rails is because Ruby looks beautiful to me and I was following the news in Rails world for years.
I used to write Rails professionally for many years This comparison isn't a good one. Rails is an all-encompasing framework. If you compare Rails to something like Nest.js, there's not much you're missing. Nest is one of the best application frameworks I've used in any language, and it comes with all this stuff you say JS doesn't have. --- EDIT: To clarify (because it is confusingly named), NestJS is a framework mode…
I should've been more clearer. This post isn't comparing Rails to any framework out there. What I was trying to say is that Rails got a lot of things right and it's making me productive, because I don't have to make the same decisions over and over again when making a JS app. Rails made those decisions for me and the only thing left for me is to build my app. I myself like Next.js and Remix a lot, but they still leav…
I used to write Rails professionally for many years This comparison isn't a good one. Rails is an all-encompasing framework. If you compare Rails to something like Nest.js, there's not much you're missing. Nest is one of the best application frameworks I've used in any language, and it comes with all this stuff you say JS doesn't have. --- EDIT: To clarify (because it is confusingly named), NestJS is a framework mode…
The JS ecosystem as we know it today started years after Rails (Rails was 2004, Node's oldest version on their releases page is from 2011), and only really took off after NodeJS came to prominence with frameworks like BackboneJS, Angular, then React and the rest in the early 2010's, and it went along with Github and the emergence of everyone and their dog building libraries and frameworks.
The attitude was different; instead of big opinionated but inflexible frameworks, people wanted to pick and choose. This was exacerbated by React that emphasized NOT being a framework but just a rendering layer.
Pick ANY one-size-fits-all framework in the JS space and you will see "bad" decisions that people don't like.
The closest thing to a full JS framework at the moment is probably Angular, which feels bloated and overly complicated (annotations, component / folder structure / file naming) or Express (stringly typed? I haven't looked at it in forever).
I think the author went too deep into details here, as this crowd is full of people who are going to be able to rip pieces of this article to shreds. But doing so both misses the larger point and in the process proves it - Rails gave them a set of answers that are good enough so they don't need to delve deeper and can just focus on their app. Rails is not the only choice that does so. And people with broader skill se…
I’ve yet to see anything in Node that feels like a stable 1:1 replacement. Next.js is excellent, but you still need to sort out a lot of pieces on your own.
We need libraries that are less opinionated and more tightly focused, working through standard APIs that are open and composable. As an example, htmx works w/ any back end fine because it's "just HTML". That's great because you can use htmx with any HTML-producing backend without a big conceptual shift on either the front end or back end.
But the downside of that approach is that it is more fiddly and doesn't handle a lot of stuff out of the box (e.g. CSRF protection) that someone who wants it to "just work" expects.
This is where the other side of the barbell comes in: a nice and complete collection of htmx + whatever config is needed for a particular back-end, and all the other stuff that a typical developer might need to just get things running would be really nice. As someone from the java world, maybe just a pom.xml file w/ an init script that sets up the base project, or something like that.
I know I'd like the latter for my java projects!
I mostly work in Rails, but when I have to hop into a node project, it feels like I'm stepping back into PHP in terms of sheer madness. Barely any convention, lots of repetition and configuration - all things Rails specifically set out to solve.
PHP hasn't been madness for a long time. One could argue Laravel (a RoR inspired framework) has become better than RoR.
PHP should have made a much bigger push early on; mark the weird and unsafe functions as deprecated and point to e.g. prepared statement alternatives. They should have built a package / dependency manager much earlier on. And they should have made a lot more efforts to get a developer community up and running.