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

Love it. Sometimes I feel like we nerds get caught in the weeds and forget to solve real world problems. We have enough JS frameworks by now... Funny thing is most of them are the same given a few differences.

For JS specifically, it's starting to look like there is no "right" clientside model, at least yet. Web apps behave so differently and have different requirements that no one framework will fix it, sort of like rails, or game engines that solve a large class of problems pretty well.

For side projects or "helper apps" (I make a lot of them), I still use rails 238 and prototype because I'm productive with it. Think of all the things you could accomplish if you didn't spend all that time fiddling with 0.0.1 version software.

I would somewhat agree with this. I recently wrote a completely client-side app using a variety of different micro-frameworks. I used Parse's JS API for my backend. At the end of the day, I felt that a traditional CRUD system on a LAMP stack would have probably been easier to implement and would have fit the client's requirements just as well

Thanks for sharing. I feel like a lot of the time we forget what problem we are solving. The client rarely asks for new technology or a specific stack as much as they ask for web presence, some system integration, or an app to fill a specific need.

I'm in exactly the same situation - will try to finish it anyway though, but in general I regret that I didn't go with Flask and instead went with a client-side + REST framework.

Even if you're doing a client side app, some views are easier to implement in the server-side "full-page reload" style, and you want to have the option to do that.

Also, its very funny how sometimes I think I don't need the four CRUD operations for some object ("oh no, this one works differently") but in the end always notice I do need them...

While there's nothing wrong with Rails 2.3.8, there's also a lot you're missing out on. Maybe you don't start your next project with bleeding edge software, but it's definitely worth exploring to see what is out there.

Web apps behave so differently and have different requirements that no one framework will fix it

If that's the case, why stick with one framework? Why not explore as many as you can and then pick the best one for each new project?

I'm not "missing out" on anything. 99% of the time, I don't need the new features. Rails 2.3.8 and prototype do everything I need it to.

The best framework for each new project is one that has the features I need, and I'm productive with.

Unless I REALLY need the performance improvements, or the modular design of Rails 3.0 why even waste the time?

Exploring as many frameworks as I can is the exact problem I want to avoid. Generally I read enough and do research on the side because its fun, and I know what's out there and what I'm missing out on. If I need to create a simple web app to do simple things, and I'm not scaling to a billion users, and I simply need software to help me automate or model something, Rails 2.3.8 works.

When you quoted me on different web app behavior, I simply meant the client side. Rich client-side JS driven apps need different things because the data behaves differently (especially if you are doing realtime stuff, versus not, etc). When it comes to the server, Rails 3 isn't providing anything I need for my tools. Now, are we porting to Rails 3 for our flagship product? Yes. And we are doing it because we want the performance enhancement and maintaining the gems we use might be difficult in the future.

Anything else though? Much more productive to type 'rails my_app' with my current environment and build something that works.

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