Hacker News new | past | comments | ask | show | jobs | submit login

This is actually the bane of JS community's existence. JS developed so fast and so wildly that there was never a breather to form and write down best practices or opinions. This is jarring to someone coming from the Rails world where a lot of magic is happening, there are strict opinions (heck, it's in the subtitle of the copy) and strict conventions to adhere too. JS is wild west compared to that.

This is not to say that JS is shit but both JS and Rails have their place. If you want flexibility, you need JS. If you want iteration speed and dev productivity you need Rails.




I don't understand. One is server application development, one is client development. They are two vastly different things.

From this hot take on JS, I'd think people are suggesting that the development experience of all the other available clients are a lot better, but then I became an Android and iOS developer and that's not true either.

Swift isn't bad, but the language isn't the only thing that dictates how hard client development is. I'd rather use React than UIKit abstractions, that's for sure. And CoreData is probably the worst and most outdated abstraction I've used across all platforms. And even if I think iOS development is the ideal way to write software... it only runs on iPhones and iPads.

I mean, of course the Rails side of your application is probably nicer than the client side where you get to stay in your simple request -> response realm that runs on the same machine. If given the option, I bet almost every HNer would rather be the person paid the same to build the API endpoints vs the crapshoot that is client and UI development.

But I see this perpetually confused as Javascript vs <my favorite language I use on the server>. For example, Ruby fares pretty poorly against Node if you forget the client, like Sinatra vs Express/Koa.


I think we're diverging. The mental model of a Rails developers is well formed and if you're a beginner then you can rely on a very strong community for opinions, best practices and conventions to follow. This greatly decreases cognitive load and immensely improves productivity.

When you make a jump to a JS stack (whether client side or server side) you have a lot of options but no best practices or conventions to follow. You have to make a lot of choices which have already been made for you in RoR. Even though SPA frontend dev has settled between React and Vue, you still have to make a lot of decisions. React also bills itself as a view library. You have to make decisions about state management (if needed), routing etc etc. A vast chunk of these decisions are made for you in RoR so that you just work on the app. I think this is what the author was lamenting about.


People REALLY underestimate how much those opinions help when it comes to software development. If you start a project or new feature and your team is going to have lots of opinions on how something should get done. It’s typically easier for people to ingest the idea that something is “best practices” than have to follow whatever someone in the room is saying.

If the platform is too unopinionated you will generally wind up with: 1) A project with many competing ideas (most js projects I see end up like this) Or 2) A team with some people feeling like they are not heard


Ah, I see your point. I definitely was that beginner that was originally compelled by the ease of Rails. I would watch RailsCasts for fun and be amazed at how much you could do with so little. I thought it was the ultimate developer experience back then.

These days I prefer building something up from microframeworks and I like to take the opposite side of the trade-offs you mention in your comment. There are a lot of aspects of Rails I ended up really disliking over time.

But at the same time, I still find myself thinking back to some of the pleasantries that Rails gives you and wishing I had them in my bespoke applications. Even just things like being able to enumerate your routes from the CLI or seeing your SQL queries and query response time in the terminal during development. If it's something you have to implement yourself, you just tend to not do it at all. And there's a lot a framework can do for you with some opinionatedness.

I think the classic example of this realization is when you deep dive on microframeworks, accumulate them in production, and encounter things like performance issues but realize you don't even have the tools to debug them because you didn't build them.


Rails was somewhat unique at its birth with its opinionated-ness. Outside of that world, in "respectable" programming environments with smart people who were good at algorithms and O(n) notation and all that (which was not me) it was rare that I encountered the kind of insanity that I seem to run into daily with PHP and later JS.


Agreed, though I use Django. Two Scoops in a great book for going from someone who knows how to use Django, to knowing how to use Djnago well.


> “...JS developed so fast and so wildly that there was never a breather to form and write down best practices or opinions.”

js and ruby were released in 1995, with rails coming 10 years later. so js development wasn’t fast in the least. after the little ajax blip resulting from outlook web access’s release in 98, js stagnated until node came along and made it interesting again.

prototype/jquery a little before it and later front-end frameworks like backbone, ember and then angular helped cement js as a thing. it only seems fast and wild because the ecosystem really only woke up again in the 2010s.

(i tooled around with js on netscape right after it came out but then lost interest)


JS may be released in 1995 but it was not used much for anything except changing status bar messages, or image rollovers (remember those?) for at least ten years. Sure there also was Microsofts DHTML on IE, which failed to get much traction. Only starting with GMail and AJAX in 2004-2005 JS started to be treated seriously, it still took some years and SPA hype to become "a must". So about ten years max. Also Rails was constantly evolving since inception, alas, a lot of JS is revolving, i.e. solving the same problems over and over again, just with different approaches. The last point would be that people initially taking up Rails were not new to programming and usually switched from PHP or Java. Now Javascript is often the first (alas, often the only) language people learn. So I'd say the culture is quite different.


yes, agreed, ruby is a much friendlier language to start with, but javascript is more accessible since everyone has a browser or three.

while gmail brought a nicer ui/ux, i still credit ms owa for showing the world what js could be when it grew up.


Well of course js development is slow - you can upgrade Rails v1 to differently opinionated Rails v2 on a server overnight. Try upgrading 8 billion people to a browser that supports eg. ES6.


sure, but that wasn’t a problem 10 and 20 years ago when js development was even slower. the language just hasn’t evolved as much as others.


> This is not to say that JS is shit but both JS and Rails have their place. If you want flexibility, you need JS. If you want iteration speed and dev productivity you need Rails.

Not true at all. Rails can be extremely flexible; it's all modular and you can reduce it down to almost nothing if you want. Javascript's only place is to run in the browser; it lost its way once people decided to make a server platform out of it. JS is far too forgiving of mistakes to be running backend code, full stop. ES6 and up are vast improvements but the damage has already been done.

And in any case I have yet to work in an environment where I am not writing at least some ES5...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: