101–110 of 490 posts
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.
I had similar feelings with Rails. Just memorize this billion convention and you are good to go. Also didn't help that running Rails on Windows was (maybe still is) considered a bad idea.
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…
The issue I have with the JS world is that the most used libraries and frameworks are just "good enough for a small project" and no more than that. * Javascript has such a minimal standard library, you will need to get one or three third-party libraries to augment its core. * React is an excellent view library and nothing more. You will need to get one or three third-party system to turn it into a fully fledged web f…
I'm very bullish on SvelteKit — hits all the points you mention above and outputs a minimal, performant full-stack app. https://kit.svelte.dev/ Still in beta and changing a lot but really really lovely to use.
Heck, to scratch my own itch I'm even making a Rails-like SaaS boilerplate to go on top of SvelteKit to give me all models, user auth, admin dashboards, payments, etc that you need in almost every app these days: https://sveltesaas.com
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…
The issue I have with the JS world is that the most used libraries and frameworks are just "good enough for a small project" and no more than that. * Javascript has such a minimal standard library, you will need to get one or three third-party libraries to augment its core. * React is an excellent view library and nothing more. You will need to get one or three third-party system to turn it into a fully fledged web f…
Am I the only one who simply looks at the business requirements when considering an SPA? Ive built music players, games, real-time chat apps, etc that would be very difficult or impossible with a server side rendering app.
Yeah whenever these SPA-slamming posts come up, I just try to imagine carpenters posting about why they switched to hammers from screwdrivers. They're just different tools that excel at solving different problems.
The more "standard" the product you're building, the better off you'll be choosing a framework that is highly structured.
Earlier quoted context omitted.
> Javascript has such a minimal standard library, you will need to get one or three third-party libraries to augment its core Maybe 5-10 years ago, there is no need anymore > React is an excellent view library and nothing more. You will need to get one or three third-party system to turn it into a fully fledged web framework. Depends on your needs. Small app? React on its own is enough. Larger app? Add a router. That…
I'll pick just one point to address: > The JS tooling ecosystem is amazing and getting things setup nowadays just takes one command. Which command would that be? Sure it's one command if you use one of a billion template projects, but just picking one of those is a chore and I'd never call that situation "amazing".
Like, create-react-app is great, but if you have to eject, you've got no parachute
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…
The issue I have with the JS world is that the most used libraries and frameworks are just "good enough for a small project" and no more than that. * Javascript has such a minimal standard library, you will need to get one or three third-party libraries to augment its core. * React is an excellent view library and nothing more. You will need to get one or three third-party system to turn it into a fully fledged web f…
How so? I found NextJS to be one of the most pleasant and well documented frameworks to work with. Sure, you'll have to read most of the docs to find out how to do something the NextJS way, but so far, I've come to agree with every design choice they've made.
The only gripes I have with it are debugging serverless functions that work in development, but then break in the vercel/aws blackbox.
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.
As the commenters pointed out, Express.js doesn't try to solve the same problems as Rails. Trying to use one for the other's use case doesn't make any sense.
Earlier quoted context omitted.
I think the main Thing here is that Rails is the de facto standard, the 'golden hammer' of Ruby based apps, and there is no space - or developers - for alternatives. 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 dominance of Rails for its use case within the field of Ruby is is only one half of the equation. The other half is that Ruby has mostly collapsed into Rails, there's not much Ruby happening outside of Rails. This could never happen with a js framework of similarly scope, because all the other js use cases won't go away. One example of such a thing that won't go away is doing client-side stuff in the scope of a R…
Rails has a clear one way to do things because there are no/few other options because everything else has withered away.
To put this another way: to have a convention in JS, just pick a convention, and now at least you have a convention, even if everyone else has their own.
Would you advise a JS dev(with no prior experience with Rails) who wants to launch multiples MVPs to switch to Rails?
Thanks