My question actually relates to Java frameworks for Web development, but I didn’t want to put such a contentious topic in the headline.
Some friends and I are building a Facebook app (like Will Ferrell in “The Other Guys”). Most of the work is likely going to be in JavaScript but we do need to generate some pages from a MySQL database management system. We’ve settled on Java as the server-side page script language, mostly because we want something that people will still understand 10 years from now.
That leaves us with the question of how to program in Java. Much of the code that I’ve reviewed using frameworks and towers of abstraction has been extremely inefficient and hard to debug/change. Generally the organizations who invested in those Java-based systems would have been better off with VB.NET or PHP. The cool kids tell me that the Play frame is what is hip right now. But watching http://vimeo.com/58969923 I can already see some horrifying SQL practices from the auto-generated SQL, e.g., using a string data type as a primary key instead of an integer and a lack of not-null constraints to the point where it was possible to put a row into the database with no information at all, other than the primary key. The video also shows coding in Coffee instead of JavaScript, which seems like a bad idea for maintainability. Is there any guarantee that Coffee will be popular a few years from now? Generally the amount of machinery to generate a “hello, world” page seems excessive, though perhaps the Play framework makes more sense for complex applications?
What do folks who are using Java on the server like? And do these frameworks at the end of the day actually save time compared to old-school Java Server Pages?
Thanks in advance for any advice.
We use Dropwizard and Guice for Java web projects at my company, and mostly build up SQL queries by hand. Most of our Java web services serve up JSON to client-side apps that transform that JSON into HTML markup. There’s some overhead to spinning up a new resource / service that would be avoided with something like Play, but we’ve decided it’s worth it to have more immediately readable code. After all, most of this code is going to be executed a lot more frequently than it is written. It’s more “old-school” probably, but it avoids the layers of XML-Hell that things like Spring and Struts require.
A small handful of Java web projects actually return HTML, usually from rendering Freemarker, but we avoid that whenever possible.
I don’t know anything about Java frameworks, but it seems clear that in a few years CoffeeScript’s best features will have been rolled back into JavaScript ES6/7, and everyone will forget CoffeeScript existed. It doesn’t even offer a stable API today — I tried running one year old CoffeeScript with the latest release and got a bunch of syntax errors.
I’d highly recommend the Play! framework.
I am not so convinced of Java’s future longevity, if I had to use it I would build a REST API layer using something like CXF, and have the JavaScript do most of the rest with a framework like Angular.js or Ember,js. You’d be much better off using Node.js or Flask, and using a DB that supports stored procedures, migrating the whole business logic in-DB.
Java frameworks have a reputation for inefficiency and largeness.
People who are interested in smaller more comprehensible frameworks tend toward Ruby or Python or more recently server-side JavaScript (node) and Go.
The first two suffer somewhat in the efficiency department, but they’re established and their smaller frameworks (Sinatra, Flask, …) are very popular and small enough that they are unlikely to age out badly. Frameworks in the latter two are somewhat immature (Go) and/or still changing rapidly (js).
If you’ve settled on Java, some people do have good things to say about Guice. It’s newish and I wouldn’t trust it to be around in five years, much less ten, but your options are few.
On the plus side, I think the days of worrying about varchar PKs are over. And you can always add constraints to the schema yourself, if your framework doesn’t give you the option. Most do, though — I’d consider the lack more of a measure of pre-1.0 status than ignorance.
You’re already committed to Javascript. Why not node.js? 😛
Since you are writing a Facebook clone you will need the app to both read and write data from the server. Look at Ember.js for the client side with a backend REST API server (serving JSON). Our latest app is doing this, and we have the API written in Ruby and Rails. I don’t know what Java frameworks are good for writing a REST API in. I do know I am very glad to have left JSF in the past. Same with JSP. But these two would be poor choices to start with for API development, unless they have added a lot of features since I last used them.
We’re also using Postgresql for the database, switching away from MySQL. The main driver was the ability to use hierarchical common table expressions. As such we’re hand coding most of the SQL, but the Rails generated SQL is pretty clean. Now having used both Postgresql and MySQL I wouldn’t hesitate to use Postgresql, even in projects where we don’t need the CTE. We are also using UUIDs for the ids to simplify the creation of objects on the server. It’s not as efficient as integers, but the advantages make up for that.
I agree that skipping Coffee script is the right approach. I see no benefits in the long term to using it, only added pain.
I think Ruby will still be understood in ten years, if you’re open to switching backend frameworks. Not knowing the Java frameworks for writing API servers I can’t say if a Ruby On Rails approach is better, but past experience switching from JSF to ROR tells me it would be.
Larry: Thanks for the input. One correction, though. We are not writing a Facebook clone (remember that I did that in the 1990s with photo.net). We are writing a Facebook APP that, from a user’s point of view, will plug into Facebook.
I think that many lightweight frameworks omit consistency constraints at the database level because frameworks want to support many backing data stores (and want to be reasonably easy to extend to new data stores), and the consistency constraints tend to be hard or impossible to generalize across data stores. Maybe you can write an abstraction layer for your ORM that can generate constraints that work on both MySQL and Oracle databases, but then someone will come along and want to use your framework with MongoDB or Apache Cassandra. Regardless, if you love `ADD CONSTRAINT`, and I agree that you should, there’s nothing to stop you from opening a connection to your database and adding the constraints yourself.
Why do you think that non-integer primary keys are so abhorrent? Integer based primary keys can be troublesome in a few ways for even moderately successful apps. First, it’s surprisingly easy to pick an integer size for your primary key that you end up overflowing.
Second, even if you you don’t overflow your primary key in the database, if you ever expose it in JavaScript (say you use AJAX to update an element by id), and your integer id is bigger than 2^53, then you’ll have very confusing bugs until you realize that JavaScript is rounding your integer to the nearest representable double (its only numeric type). Then you will have to convert your integer ids to strings at the application layer before exposing them to JavaScript anyway.
Finally, if you ever grow to the size where you need to shard a database to scale its write capacity, then you may be faced with the challenge of concurrently generating unique ids on several different machines. There are many ways to solve this problem, but I think it’s a little easier if your application isn’t expecting ids to be consecutive integers.
I don’t think it matters a whole lot what lightweight framework you pick. They are all great at some things, and weak at others. No matter what you pick, you will end up spending 90% of your development effort on things the framework is weak at supporting, and you will end up hating the framework for those shortcomings. At the same time, since you spend very little time and effort on the things the framework makes easy, you will won’t appreciate how helpful those features are.
Eventually you will decide it would have been easier if you had written your own framework. If you ever do write your own framework, it will either be insecure and short on features, or you will be shocked by how much effort you need to sink into CSRF protection, preventing SQL injection, implementing password hashing, an asset and resource preparation pipeline, caching, a form generation framework, an email generation and sending framework, XSS protection… You can’t win. Pick the framework with the nicest website, and get on to the real work.
Jon: I’m not against a character string as a primary key in general, but if you watch the video it looks as though the software creates a database sequence (putting out integers) and then stuffs the values from that sequence into a column with a string type. Apparently it works in MySQL, but it doesn’t seem very tasteful. Maybe I misinterpreted the SQL example in the video because I’m really an Oracle programmer.
I am puzzled that people are mentioning Guice, which is not a web application framework. Guice is a useful tool, and I do recommend using it lightly (stick to its simplest features) for large Java projects, but all it does is dependency injection.
BTW Guice is extremely unlikely to go away or bitrot in the next 5 years; in fact that is a conservative lower bound on its longevity. It is used heavily internally at Google, and Google’s Java leadership believes in it with a near-religious fervor. Even if you were to wave your magical mind-control wand and convince those leaders to renounce it, the millions of lines of Guice-ified legacy code within Google would probably take 5 years at a minimum to rewrite.
As for web frameworks, I hate them all. Jon S has the right idea.
1. Write your Javascript with jQuery
2. Get your data into your pages with AJAX
3. Get your data out of the database, validate credentials, and handle communication with Java HttpServlets and JDBC. The main purpose of modern web frameworks is to corrupt your database because the people using them are afraid to learn SQL. They think set theory is an exotic and dangerous New Math craziness. Since you’re not afraid of set theory, just write your own SQL; it’s a simple human writable language, not a scary esoteric abstraction.
4. Consider picking Postgres over MySQL, for your own sanity.
For a comparison of frameworks see Matt Raible’s presentations: http://raibledesigns.com
He has a very good comparison of the pros and cons.
Roll it yourself. A basic framework isn’t hard, and can be kept very trim, unlike a language, database, ORM, etc. I’ve had nothing but trouble with java frameworks.
Since your focus appears to be on maintainability I suggest you go for vanilla Java EE (Wildfly is probably your best option there). While most “cool” frameworks come and go, Java EE has way too much money invested by companies like Oracle, IBM and RedHat to disappear
Go for Dropwizard on the server for exposing a bunch of REST services. If you want to also serve HTML, it integrates (out of the box) with Freemarker, but the other option is to serve static HTML directly and use something like Angular, Knockout, or whatever else you want on the client.
Dropwizard is dead simple, the code is readable, it’s pretty standard JAX-RS but without any of the fanfare of having to wire up all kinds of Servlet goo. It has a built-in high performance webserver (Jetty), integrates nicely with Maven (you don’t have to worry about dependency/JAR madness) and is fast.
Every time I see a new language that attempts to ditch the braces and semicolons to make it look ‘less like C’, it’s accompanied by a lot of hype and fanfare and then shortly thereafter starts to lose popularity when the next challenger comes along. Languages that adhere to the C-derived syntax occupy 8 of the top 10 spots in the TIOBE index which measures the popularity of programming languages. Once in a while a challenger that deviates from C syntax will pop up into the top 10, and then fade away just as quickly. TIOBE is not a perfect measure, I realize, but it’s better than anything else I’ve seen and it closely matches with my own experience. The only exception to this has been VB that continues to occupy a spot in the top 10 due to the the sheer marketing strength of Microsoft.
If your goal is to avoid programming in something that won’t be around in ten years, please ignore what the cool kids are doing. They’ll be on to something else next year, and then on to something else the year after that.
The web has plenty of languages and frameworks already. The computer industry just has too many egos that get fulfillment by introducing new languages and frameworks instead of trying to master existing technology because it offends one’s sense of how things ‘should’ work.