What's a good hip web framework to play with?

[Leros]

I do web work professionally. Almost everything is done with Java servlets. Its standard across the company, we've got all kinds of supporting internal libraries... no problem, its works great. I learned pretty much everything I know about web programming at this job, so Java servlets is all I really know

Every now and then people talk about newer technologies such as Grails and Pyramid. If I were to play around with one of these frameworks, what would you suggest? I'm open to anything, not just the two examples I listed.

A couple people at work have pointed at Pyramid, what do you guys think?

 

[Bulldog13]

I am not a Java programmer, but if I were, I would probably choose

http://www.playframework.org/

I watched the video on it and it looks very similar to ASP.NET MVC.

 

[Markbnj]

Ruby on Rails? Django?

 

[Crusty]

I'm a huge fan of Ruby on Rails, I've been using it for various projects since 2.0 came out.

 

[TechBoyJK]

OpenBD+MachII

Looked into Microsoft's WebMatrix?

 

[GregGreen]

Ruby on Rails? Django?

this.

 

[dwell]

node.js + Express. Throw in a little CoffeScript for good measure.

 

[ringtail]

I'm a huge fan of Ruby on Rails, I've been using it for various projects since 2.0 came out.

Is it true it's performance is real slow?
I've read that.

 

[esun]

Been using web2py for a new project the past month or so. Pretty good so far.

 

[Crusty]

Is it true it's performance is real slow?
I've read that.

In the early days of Rails there were issues with the hosting infrastructure that made hosting Rails apps cumbersome and tedious. Now it's so easy to host, deploy, and scale I would be very surprised if any moderate sized site has issues scaling to support their needs.

 

[dwell]

The problem with Rails is that it makes it easy for people who don't know how to code to make sites. The sites work fine under average use but as soon as you have to deal with scale they collapse. Scalability should never be an afterthought.

 

[Crusty]

The problem with Rails is that it makes it easy for people who don't know how to code to make sites. The sites work fine under average use but as soon as you have to deal with scale they collapse. Scalability should never be an afterthought.

Agreed, but that also applies to other languages and frameworks. The quality of the application is mostly going to depend on the quality of the programmer.

I like Rails because as a non-web programmer by trade I can sit down and write a web app using the same techniques I do in my other coding and know I have a working web application.

The biggest problem I have with the whole scaling discussion is that sites like Google, Facebook, and Twitter are on a completely different scale than 99.999% of the sites people(those that ask questions like this) are writing, and those are the ones people are comparing to when they talk about 'scaling'.

In my opinion, scaling is almost always an afterthought simply because you don't realize you have the next 'Twitter' until you actually do. If you spend all your time trying to write code that will handle that kind of scale you'll never get a working site out. Besides, there is no one size fits all method to scaling, sometimes you just don't know where your bottlenecks are until they happen.

 

[teb468]

I've been working with Grails for like two years now. I highly recommend it. Its easy to pick up if you've used Java and the front end is like JSF, but useful.

 

[esun]

The problem with Rails is that it makes it easy for people who don't know how to code to make sites. The sites work fine under average use but as soon as you have to deal with scale they collapse. Scalability should never be an afterthought.

This is a classic example of "premature optimization is the root of all evil". Correctness is more important than performance 99% of the time, and it's easier to achieve while not worrying as much about performance (not to say you should do dumb things, but you shouldn't let scalability concerns hold you back unless you know you're deploying to a large user base).

 

[dwell]

This is a classic example of "premature optimization is the root of all evil". Correctness is more important than performance 99% of the time, and it's easier to achieve while not worrying as much about performance (not to say you should do dumb things, but you shouldn't let scalability concerns hold you back unless you know you're deploying to a large user base).

There are a number of simple things you can do from the get-go that will put you in a better place to deal with scale later. Including:

- Design your system to be stateless.
- Do not use a RDBMS.
- Design with caching in mind
- Design to scale out not up.

I'm not saying go into every effort with scalability in mind, but if your goal is to attract a lot of users it will save you a ton of pain later.

 

[Dravic]

Django is a good one with the benefit of being written in python.

Python is the new Perl, its now on most Linux distros by default. You would be learning both a web framework, and scripting/automation/parsing language. Python is a more widely used as a stand alone language then Ruby not on rails.

If a web framework is all you need, then its just a matter of preference for which one fits your style and needs better.

 

[AlexSerov]

... Almost everything is done with Java servlets ... people talk about newer technologies ... I'm open to anything, not just the two examples I listed.

What do you think about HybridJava?

 

[Cogman]

What do you think about HybridJava?

Looks like shitty half attempt to implement RoR.

Doesn't even hold a candle to PlayFramework.

 

[Markbnj]

There are a number of simple things you can do from the get-go that will put you in a better place to deal with scale later. Including:

- Design your system to be stateless.
- Do not use a RDBMS.
- Design with caching in mind
- Design to scale out not up.

I'm not saying go into every effort with scalability in mind, but if your goal is to attract a lot of users it will save you a ton of pain later.

So, never use a relational database? There are a lot of things that stores like Mongo do well, especially with respect to unstructured data that you want to search across in a broad way, but a lot of business data is highly structured. Why shouldn't stuff like customer records, payment transactions, profile settings, etc., be in a relational db?

 

[Cogman]

So, never use a relational database? There are a lot of things that stores like Mongo do well, especially with respect to unstructured data that you want to search across in a broad way, but a lot of business data is highly structured. Why shouldn't stuff like customer records, payment transactions, profile settings, etc., be in a relational db?

Yeah, the "Never use a Relational DB" thing is pretty perplexing to me. Relational SQL databases have been the cornerstone of large operations for a LONG time. Generally, the database isn't the thing that gets in the way of scalability.

Either way, things like this make me pretty wary of suggesting that everyone should use a No SQL DB.

http://blog.engineering.kiip.me/post/20988881092/a-year-with-mongodb

 

[dwell]

The problem with RDBMS with regards to scaling is you either have to scale vertically (throw bigger hardware at it) or start sharding. As soon as you shard you throw out most of the things that make RDBMS great (joins, normalization, referential integrity, etc.).

 

[Dravic]

Ruby on Rails? Django?

These would be my first stops

zope too

 

[Markbnj]

The problem with RDBMS with regards to scaling is you either have to scale vertically (throw bigger hardware at it) or start sharding. As soon as you shard you throw out most of the things that make RDBMS great (joins, normalization, referential integrity, etc.).

I think the solution has to fit the type of data and what you need to do with it. Relational DBs excel at storing, updating, and retrieving structured data, with referential and transactional integrity. When you try to make them store and search unstructured data they start to crumble. For CRUD and searches on indexed columns you can throw a ton of volume at a properly configured setup.

Alternatives like Mongo arose from the need to store and search on unstructured data, and they excel at that. If I was building Newegg's website and dealing with 100,000 products that don't conform to any schema, Mongo would be my first choice. But I would use it to store and search on products. Stuff like accounts and sales would be in a relational DB.

 

[Cogman]

The problem with RDBMS with regards to scaling is you either have to scale vertically (throw bigger hardware at it) or start sharding. As soon as you shard you throw out most of the things that make RDBMS great (joins, normalization, referential integrity, etc.).

The thing is, you need a pretty big traffic flow with lots of data before this starts to really become an issue. Long before you hit that point, your likely going to start seeing issues like "This ruby function is too slow, we need to implement it in C".

If your DB is small enough, you can use replication to scale horizontally.


I would contend that things like MongoDB have similar issues. For example, their global write lock is crazy. On a write heavy website there is no way that will scale.

 

[dwell]

The thing is, you need a pretty big traffic flow with lots of data before this starts to really become an issue. Long before you hit that point, your likely going to start seeing issues like "This ruby function is too slow, we need to implement it in C".

If your DB is small enough, you can use replication to scale horizontally.

I would contend that things like MongoDB have similar issues. For example, their global write lock is crazy. On a write heavy website there is no way that will scale.

Locks in general are bad. I don't know enough about MongoDB to recommend or not recommend it. We evaluated it a while back but it didn't suite our needs for several reasons. We're using Cassandra because it does what we need which is heavy writes, tunable consistency, and distributed out of the box.

Database I/O is almost always a bottleneck over code execution.