Please stop duplicating Rails | Hacker News Reader

Please stop duplicating Rails

srirangan.net

28 pointsfactorialboy34 comments

Am I the only one who isn't excited by {any.new.framework} that provides RoR like capabilities in {your.favorite.programming.language}.

If I want to use a MVC framework, there are plenty available including RoR + other alternatives across various platforms.

A new framework doesn't really help.

At least something like Meteor tries to meet the next generation challenges (real-time apps). I'm not saying Meteor is perfect or horrible, I'm just saying they tried to solve the right challenge.

Server side MVC feels like 2005.

There are plenty of frameworks across a whole range of platforms.

You aren't really solving a problem here.

Open articleView on HN

Guide on how to Hacker News:

1. Look at the current popular articles in Hacker News and choose one.

2. Write short blogpost about it which could easily been a comment (but your opinion is much more important and deserves its own golden soapbox)

3. Post said golden soapbox on Hacker News.

4. Steps 1-3 are repeated by someone else posting a rebuttal to your blogpost.

On the other hand, your complaint is a shining example of comments that add value to HN...

I disagree with the author of that blog post.

If you think something should be built, go right ahead. Ignore the naysayers and write what you enjoy writing. Don't listen to people that tell you how you should spend your time.

[I'm somewhat puzzled why this post is on the first page of HN in the first place but that's another topic]

Don't you think it makes more sense to contribute to existing open source projects than rewrite one without offering anything new? DRY?

Don't we have way too many MVC frameworks? Time to consolidate imho.

What looks sexier on your resume though: "Creator of backbone.js" (Not trying to pick on backbone since it's a great project, but you can read the entire source in an hour) or "Contributed to making AR 5% faster for certain queries"

I'd much rather see 10 people put their time towards making one project better, then seeing 10 people start 10 divergent projects with dreams of becoming the next DHH, but I recognize that there are other factors at play.

Contributor to a well known project > Creator of an obscure, unknown project

Sure, but a lot of programmers' dream (not mine) is to be the creator of the next big thing and gain accolades from other programmers. That won't happen if you're strictly contributing to other projects.

not sure which one you're implying sounds sexier, but if i were reading his resume, the AR contribution would definitely strike me as more significant. compare "wrote a fuse-based filesystem for whatever" versus "got several patches into the ext3 tree"

It's debatable. You can have perfectly valid reasons to develop your own framework: - you want to propose something different compared to existing solutions in the field, where your vision is clearly incompatible with what already exists - the coding standards for an existing, similar solution is not acceptable, and unlikely to change

On the other hand, many a "me-too" piece of software crops up simply because it can be easier to reinvent than to contribute (not implying that RailwaysJS is that). But TFA's point is also that server-side-heavy frameworks are a thing of the past, which is a fair argument.

Don't you think it makes more sense to contribute to existing open source projects than rewrite one without offering anything new?

Depends on whose goals you're trying to further. If you're just working for the Man^H^H^H community at large, then yeah it makes the most sense to spend your free time on contributing to existing platforms. After all, any time spent not acting as a unit of production is time wasted.

On the other hand, if you're doing it for your own enjoyment then it makes all the sense in the world to spend your free time working on whatever gives you the most enjoyment. There's nothing wrong with being satisfied with 40 hours a week of being a unit of production, and wanting to spend the rest of the time living for oneself.

I totally agree. Derby (http://derbyjs.com/) and Meteor are the only new frameworks out that excite me. RoR is close to ten years old and has thousands of man hours invested into it. Does anyone think a new project that has some of the same capabilities, but lacks the ecosystem/community is going to gain signifigant traction?

I disagree, what if you like rails conventions but aren't a big fan of Ruby? What if you have a large collection of code in one language and would rather something that integrates better with it or you have a development team that have core competencies in a certain language.

Sure some will say put down the time now and switch to Ruby, some though would much rather be in another language though with the same type of conventions and ideas that Rails brings.

Age old debate. Either create something new (that no one understands or wants), or rebuild something existing but better (and has a market).

One is a lot more fun (the former). One is a lot more lucrative (the latter).

I'd be willing to wager that MeteorJS doesn't find major traction until it starts to adapt to the generation of developers who have previously embraced server side MVC. It's examples and API will eventually start looking a lot more like Rails.

I assume the OP is complaining about the RailwayJS article on the HN frontpage. Meh.

Personally, wish someone would implement Erlang's OTP in node. That would be useful.

http://www.erlang.org/doc/design_principles/users_guide.html

Isn't Akka inspired by OTP? http://akka.io/

edit: /oops Oh you meant in node, hmm.. /sorry

I think it would be easier to take the best stuff in the node ecosystem and port it to Erlang than the other way around.

How do you bring code sharing between the server and client into Erlang? :)

Edit: I should have given a little more value on the post. I left node for Scala because the advertised code sharing wasn't worth having to work around an event architecture that I found hard to debug (as I've mentioned elsewhere) and I too considered Erlang before settling on Scala due to our previous java experience and my co-founder's knowledge of people in the Scala community.

But fundamentally, node.js isn't interesting if it's not in Javascript. Actors seem like a better model than futures tacked on to callbacks, and frankly javascript's quirks (like having to use require.js for modularization rather than a feature built into the language!) IMHO don't make for a compelling case.

I'd use node.js on someone else's project, but I don't know if I'd pick it for my own.

I wonder how hard it would be to make JS compile to Erlang like Elixir. I think the big problem would be some kind of actor model in the browser with everything callback based. Other than that, they're both dynamically typed, functional (Erlang obviously more) languages.

It's possible, but you can also end up with monstrosities like GWT in the end. The best bet is to implement some Actor-like layer like https://github.com/Gozala/actor upon which the "ErlangScript" depends.

Oh wait, JS compile to Erlang? Wouldn't it make sense to do it the other way around?

I think it makes more sense to go JS -> Erlang, because the valuable thing about JS is the language itself (and trying to achieve code sharing), while the valuable thing about Erlang is the vm/concurrency model/OTP.

You are right on all points ebiester, but you missed the one compelling reason to use node anyway: the browser is well on it's way to being the dominant programming model (and for a good reason: application components and data are addressable by other applications via the DOM! this turns out to be necessary to have globe-spanning meta-programs like search, and also useful personal meta-programs like Evernote) and that model can and will extend into the server. JavaScript is a quirky language but can and will get's it's act together. "use strict" for example was a good step in the right direction.

Even more than that, I think that the entire notion of what a server is for is changing rapidly away from "server-side MVC" to a far more rational (not to mention more efficient) dual role of "initially serve a client" and then "handle messages from the client". Server-side manipulation of client state is a horrible, terrible idea in any language, and right now node is suffering from cultural/technical momentum of wanting to do things that way. Once that impulse goes away and alternatives become more popular and well-understood, I think node will get even more popular.

Can you expand a bit on what you meant by "...and that model can and will extend into the server."?

Sure. I think server software should be constructed, simulated and visualized in a browser. Server components can be sourced from around the net, pulled into a shared environment, inspected, tested, and connected, and then when you're ready, pushed onto the server. This approach has the added benefit that when get to client code, a lot of what the client needs to know about the server is available to it, either at build time or even at runtime.

NIH syndrome?

Unless there is something really revolutionary on the framework, most of them are just reinventing the wheel and sadly not from a new approach.

On the upside, if you treat this frameworks as code katas. I could see some value on them.

i don't see much substance in this. let's all stop building something new.whatever suits your needs. or hell, maybe whatever helps you learn.

linux was just made from a guy who wanted to learn os programming.

You missed the point. A lot of these frameworks aren't building anything new.

You could have said the same thing about Linux.

Nope, but I can say the same thing about my redundant Linux distros.

So once something is popular then it is self-justified, but new things that imitate something else are bad. How do you ever cross the chasm with that attitude?

That's your inference. Just because you make outlandish inferences, doesn't mean I get put on the dock and I have to justify them. :-)

Pot, kettle, black.

Linux is derivative, there I said it.

not to mention that meteor is just a pretty wrapper around expressjs and a bunch of other node packages.

it's more or less a prettier npm with 10 million investment.

I think it completely depends on why you are doing it. There's no better way to learn about the internals of frameworks than to create one.

This looks like it's getting HN'ed, google cache is here: http://webcache.googleusercontent.com/search?q=cache:srirang...

Reply on news.ycombinator.com