Ask HN: What stack would you use to build a CRUD web app on the JVM today? - <AUTHOR> <comment><USER4> I second Play Framework. Have used it and Scala is a very nice language to learn. If I had invested in so much into the JVM, Play Framework would be it. But, if it's just a simple CRUD app, and if you had a choice, I'd recommend you to give Ruby on Rails a try. Hope this helps!

<comment><USER5> Scala and Play is a great choice. Another good Scala framework is Lift: [http://liftweb.net/](http://liftweb.net/)

If JVM is not a must, consider using Meteor.

<comment><USER6> +1 for Meteor. We've been using Meteor for about 8 months now and are amazed with the productivity and no-boilerplate code. To give some context, we were previously a JVM-only shop. In the past we've used Spring+Hibernate+GWT for one project, Ninja for another project, and a full blown custom stack + Dojo client side in a third project.

If JVM is your only choice because you want to connect to legacy Java API, consider wrapping the Java API with REST interfaces and use them with Meteor.

<comment><USER7> How do you find the GC/profile/coverage/tuning of the server side node process compared to the jvm?

<comment><USER6> TBH, we didn't have to do much performance tuning. The Meteor app we are building is heavy on the database CRUD (like real heavy) so there is not much to tune code-wise other than define good data structures for your db. And really, if you have to do any GC tune up for your node app, you really have to ask yourself if there's something you could do instead in your code first.

I must admit that initially it seemed that node js profiling sucks, but it's just that we are still not used to the internal intricacies of V8. When we did profile a couple of times (we use Webstorm so just used flag in the run config), there were too many things out of the context of our code showing up. I think if you show a snapshot of YourKit to someone who hasn't worked with JVM before they would have a similar reaction.

</comment></comment></comment></comment></comment><comment><USER8> Definitely Clojure with http-kit [1]. Easy to use, minimalist and supports websockets.

However, it depends from your use-case. Could add some detail please?

[1]: [http://www.http-kit.org/](http://www.http-kit.org/)

<comment><USER9> I used to be a big fan of http-kit, but it seems like it's not maintained anymore. I've since moved on to Immutant 2, which seems to offer much more. The primary difference between Immutant 2 over 1 is that it's not monolithic and you can just import what you need. And I believe it's faster too.

Also, yesterday I announced that I am writing a book on developing REST API's in Clojure, if anybody's interested in learning: [http://christopherdbui.com/announcing-practical-rest-apis- in...](http://christopherdbui.com/announcing-practical-rest-apis-in-clojure/)

<comment><USER10> looking up to it!

</comment></comment></comment><comment><USER11> Spring MVC + Hibernate. I'm familiar with those libraries and they provide almost everything I usually need.

For frontend I would choose either JSP or Thymeleaf, both are good, depends on your taste and whether you're writing HTML markup. Another option is a JavaScript-powered SPA website. You have plenty of choices there.

And I highly suggest using Intellij Idea Ultimate + JRebel. Those technologies provide tremendous productivity boost and I can't imagine working without them. Though they are not free (AFAIK you can get JRebel for free).

<comment><USER12> For people whose impression of Spring and Hibernate was formed a decade ago, its really worth another look now. You can completely manage them with annotations in your code and lots of the boilerplate will be generated for you based on naming conventions.

JHipster ([https://jhipster.github.io/](https://jhipster.github.io/)) provides a Yeoman generator to make a basic project template as well as generate entities and screens using an Angular, Spring Boot & Hibernate stack which makes it super easy to get started with all of these components.

An open source alternative to JRebel is [https://github.com/dcevm/dcevm](https://github.com/dcevm/dcevm) \- it works great with Java 8, Intellij, Spring & Hibernate.

<comment><USER13> It doesn't change my impression much if the answer to "lots of boilerplate" is to use another tool to generate it automatically...

<comment><USER12> Actually the example I was thinking of is the finder methods which require only an interface definition conforming to a naming convention. Bytecode is generated at runtime - there is no generated source to manage.

Not much of what Jhipster generates could be considered boilerplate - <USER2> application code is pretty DRY. I've used Rails off and on since 2005 and it is fairly comparable in that respect at this point though Java is more verbose of course.

<comment><USER14> It's difficult to take Spring seriously after trying Jersey. Resource traversal is a powerful concept. Also, recent or not, Spring still comes with way too much complexity and magic. I'd really go for something more Sinatra/Flask-like. Haven't tried Dropwizard, but from what I saw it looks a lot more sane.

<comment><USER15> > _It 's difficult to take Spring seriously after trying Jersey_

I'm using Spring Data REST at work. We have a dozen endpoints. We've had to write code for one of them.

The rest were generated by introspecting our models. Complete with HATEOAS links, sorting, searching, paging and HAL. It made a whole bunch of work simply disappear -- even compared to Rails.

</comment></comment></comment></comment></comment></comment><comment><USER16> Spring Boot backed with Postgres and Maven to wrap it all up. Spring Boot is really years of distilled knowledge of creating web servers in Java. Its opinionated but for good reason; you'll very quickly get everything you need for a RESTful API and there's extensions for almost everything you'd need. Need to work with websockets? Just add a few lines to your POM. Need scheduling? Include an annotation on your main class. It really is a solid framework.

<comment><USER17> If you're favoring Boot, why not just use a newer version of Grails?

<comment><USER18> I don't understand the question, beyond the fact that Spring and Grails both had the same corporate sponsorship at one point in the past.

Spring Boot is a rapid, flexible, and fairly tight (as far as Java frameworks go) foundation for building Java applications. Grails is a Groovy-based wrapper layer around Spring and Hibernate.

So if you want to use Groovy for application development, then Grails is certainly there for you. However, I don't think it's the most competitive option. I think Groovy's great as a scripting language, and I use it for things like automated testing, but I wouldn't enjoy using it for primary application development because it's not a statically-typed language.

Although recent versions of Groovy allow you to designate typesafe "areas" within your code, it is still fundamentally non-typesafe. Because of this, tooling is always going to be weaker than it is for typesafe languages. IntelliJ is probably the best Groovy IDE out there, and it's still frustrating to work with because it can't detect autocomplete options most of the time.

If you're doing development on the JVM in the first place, then odds are you favor static typing. Plain Java, or Scala, or most of the fringe options like Kotlin or Ceylon. If you're in the minority camp who want to use a language with dynamic typing, even THEN there are better options than Groovy for application development. JRuby has a much broader and more active community, and Clojure will give you more "Internet cool points" on HN or Reddit or wherever.

Finally, the last time I looked at Grails, it was FAT. Building an application took forever. I'm sure they've (hopefully) optimized or rebuilt things since then. However, since it's a wrapper around Spring and Hibernate, it's never going be any lighter or faster than Spring and Hibernate.

I don't mean any disrespect to Groovy. I've been using it forever, and it comes in handy with certain use cases. However, it's primary niche is being the dynamic JVM language that most "enterprise" shops have become comfortable with... and so if you're trapped in an "enterprise" shop and are dying to use something other than plain Java, it's the thing you'd most likely be allowed to use.

<comment><USER19> For the most part you don't need to rebuild to test your changes. Live reload works.

</comment></comment></comment></comment><comment><USER20> I would not start with technology stack and build around them. You look at your use cases and build out. Pick your frameworks and databases judiciously and as late as possible.

Read: [https://blog.8thlight.com/uncle- bob/2012/05/15/NODB.html](https://blog.8thlight.com/uncle- bob/2012/05/15/NODB.html)

Read: [http://www.amazon.co.uk/Growing-Object-Oriented-Software- Gui...](http://www.amazon.co.uk/Growing-Object-Oriented-Software-Guided- Signature/dp/0321503627)

[EDIT] Removed the unnecessary/unhelpful opening statement.

<comment><USER21> Just because uncle Bob says something doesn't mean it's true.

Frameworks and stacks provide templates for building CRUD apps. Building CRUD apps (read: database skins) isn't a big technological challenge most of the times anyway. So picking a stack that abstracts most of it for you could be a great help to only focus on the parts you care about.

Not every project requires astronaut architecture and grand design. Half the internet runs perfectly fine without these considerations.

Scaffolding a project through the tooling of a framework (tooling matters!) and having something up in a day instead of philosophical debates about your data is huge. Having something up in production super fast because you didn't stop to think about architecture is perfectly fine for 95% of software projects that are just CRUD.

<comment><USER20> My inclusion of these two reading resources were only meant as examples. The reader is still required to make their own mind up.

I haven't suggested astronaut architecture; the question didn't indicate the size/scale/importance either.

50% of the internet runs perfectly fine without consideration...wow! Have you looked at all the source code yourself to make such a ridiculous conclusion.

Tooling does matter, but I'm suggesting the point of focus to start with is the requirements.

<comment><USER21> As a data point, 20% of the internet runs WordPress [1], think these people spent a lot of time thinking about architecture.

A lot of time the problem being solved _is_ in fact simple enough and easy enough to solve without thinking about architecture, not everything is a hard problem - and there is nothing noble about solving things over and over.

The point I was disagreeing with was "Pick stacks as late as possible". _If_ you have a large project by all means do that, if you're just building a REST API in microservice architecture, or you're building a blog or something that's fairly simple to model - you're perfectly fine picking a framework you like first.

[1] [http://w3techs.com/technologies/overview/content_management/...](http://w3techs.com/technologies/overview/content_management/all/)

<comment><USER20> I'll skip the flame about WordPress developers as I don't know any, or, viewed their work.

If you think building micro service architecture can be done without consideration I'm lost for words.

The question–as I've been rightly reminded–was 'CRUD Web App in JVM'; furthermore, we now know that the domain part of the application is already done, so my comment is moot.

That just leaves CRUD, Web, and JVM.

</comment></comment></comment></comment></comment><comment><USER22> I would pick Clojure. Here is a CRUD web app example in Clojure(Script), backed by a RDBMS: [https://github.com/borkdude/full-stack-clojure-han- okt-2015](https://github.com/borkdude/full-stack-clojure-han-okt-2015)

If you want to learn more, I'd check out [http://www.luminusweb.net/](http://www.luminusweb.net/).

</comment><comment><USER23> Clojure + ClojureScript + Reagent/Om as an abstraction on top of React

</comment><comment><USER24> Backend:

Scala

Spark - [http://sparkjava.com](http://sparkjava.com)

ScalikeJDBC - [http://scalikejdbc.org](http://scalikejdbc.org)

Postgres

Coming from Rubyland (and AR specifically), I despise writing a bunch of dao/repo code, so I've resorted to codegen-ing my daos/repos.

Frontend:

Aurelia - [http://aurelia.io](http://aurelia.io)

<comment><USER25> I also highly recommend Aurelia. It's a fantastic and future proof front-end library.

Out of curiosity, why Spark over Scalatra? ([http://scalatra.org/](http://scalatra.org/))

<comment><USER26> What makes you say it is future proof?

<comment><USER27> I assume he's been to the future, that's the only way one could know.

</comment></comment></comment></comment><comment><USER28> Probably playframework [1] or maybe Spark [2] if it's a really simple app, along with jOOQ for persistence [3]. If I was just writing a REST API, then Dropwizard [4].

The reason I would not choose Spring despite the fact that it is better now than it was 10 years ago is because it still approaches things with the wrong mindset, IMO. The reason JVM technologies are so loathed is because of the stupid, pointless complexity that's so pervasive, where Spring is/was the poster-child. Building generation after generation of newer APIs on top of the old stuff doesn't remove the fact that the old stuff is still there. Hiding complexity with code generation doesn't remove the fact that code still needs to be generated. And the same with annotation driven programming. And JPA/Hibernate/etc.

Simplicity isn't about hiding mountains of legacy complexity under a shiny new API, or annotations, or code gen - it's about having a stack that is understandable and easy to use from top to bottom without requiring magician's toolbag of tricks to hide the complexity. I get the feeling that most JVM developers don't even know what this looks like - Dropwizard is a great example. Other languages/ecosystems tend to not have this legacy baggage, so you can't blame their developers for thinking that the mainstream JVM frameworks are ridiculous. Because they are.

/end-rant

[1] [https://www.playframework.com/](https://www.playframework.com/)

[2] [http://sparkjava.com/](http://sparkjava.com/)

[3] [http://www.jooq.org/](http://www.jooq.org/)

[4] [http://www.dropwizard.io/](http://www.dropwizard.io/)

<comment><USER29> I really like annotations.

And I really enjoy working on JavaEE.

For anyone who still thinks it means loads and loads of boilerplate code but wants to check, read Adam Bien, check out the TomEE examples, the Wildfly examples etc.

<comment><USER30> This is so true! ... I was ready to give up on J2EE (prior to the name change and version 1.5). Java EE 7 is wonderful and more tools are coming. It's no longer an XML configuration nightmare with 10 classes to define all the required interfaces and implementation.

To reduce even more boiler-plate, I've recently started using project Lombok [1]. Code generation provides all the standard methods and allows JPA @Entity objects or JAX-B objects to be completely declarative. Start with @Data and @Value.

[1] [https://projectlombok.org/](https://projectlombok.org/)

<comment><USER28> My argument isn't about using tools that reduce boilerplate through codegen or annotations, it's to use tools where boilerplate doesn't exist. Why do you need JPA? Why do you need EE? Chances are, you don't.

<comment><USER29> Boilerplate and annotations are two wildly different beasts on my understanding :

Boilerplate is things I have to repeat mindlessly every time I want to do something.

Annotations on the other hand usually is one single line of code.

Disclaimer : not a native English speaker although I am fairly sure about this.

Edit: look at hodao from the tomitribe GitHub account. Or DeltaSpike from Apache.

</comment></comment></comment></comment></comment><comment><USER31> Groovy / Grails. It's what we chose to base all of our products on and it has worked out really well for us. If there's any complaint / negative, it might be that the ecosystem is in a bit of a "state of flux" with Pivotal dropping support for Groovy and the language moving to the ASF, etc. One bit of fallout from that, for example, is that the GGIDE isn't available for Eclipse Mars yet (or it wasn't last time I looked).

Still, it works, it's easy to learn, there's a rich assortment of plugins for adding functionality, GSP's are nice, it's easy to make custom taglibs, etc., etc.

<comment><USER32> I would have agreed till Grails 3. It doesn't work in so many different ways and it's never clear why. The reload stuff seems completely broken if you have dependencies that use many Java 8 features.

<comment><USER31> Aah, that may well be a fair point. We haven't upgraded to the 3.x series yet, so everything I said should be taken as referring to 2.x.

<comment><USER32> I had about 6 months experience with Grails 2 and loved it then got forced into updating to 3. Now we're trying to replace it completely.

</comment></comment></comment></comment><comment><USER33> Many of these suggestions here sound really complicated.

At Addepar, we use plain Java. A REST API can be served with Jetty + Jersey. We have zero XML configuration of any kind. JOOQ for DB access. HikariCP for connection pooling.

Use Postgres, if possible.

Start with the data models and keep it simple. Favor composition over inheritance. The inheritance-heavy Java you see in old parts of the standard library and certain "Programming 101"-type courses is really bad, in my experience. Use Java 8. Modern Java can be v clean.

If you're starting a new project, use buck as the build system. At Addepar, we migrated from Gradle to buck, and our builds became less flaky and 2x-5x as fast. The build files are cleaner and more concise.

<comment><USER34> Composition is very comfortable with Kotlin. I think one of the reasons why inheritance is used so much in Java, is that composition always leads to a lot of boilerplate code. Kotlin (and Scala) fixes it.

</comment></comment><comment><USER35> Grails/groovy with postgre. Grails is so ridiculously simple to set up and code with... you can literally parse JSON out of a request and map it to an object with "Object yourObject = request.getJSON". Then you can save it with another line like "yourObject.save()".

<comment><USER36> I agree, building crud in grails is really fast. I'm just sorry grails is not so much adopted.

<comment><USER35> Honestly it blows my mind why more people don't use it. Grails wraps Hibernate/Spring, the two most robust java abstractions that exist. Then, it adds the out of the box ability to do things like parse JSON, re-direct, handle AJAX calls easily, manage session object, ect. ect. In my experience coding web apps there is nothing that even comes close to touching the simplicity of Grails.

<comment><USER29> Obviously I was unlucky : my experience was things didn't work and was next to impossible to reason about. This was 4 years ago and I went with (and burned myself on) Play Framework.

</comment></comment></comment></comment><comment><USER37> SparkJava ([http://sparkjava.com/](http://sparkjava.com/)) + jooq ([http://www.jooq.org/](http://www.jooq.org/))

Minimalist and powerful enough. It's as close as you can get to sinatra + active record in the java world.

And, of course, I would use intercooler.js for the front-end:

[http://intercoolerjs.org/](http://intercoolerjs.org/)

to keep things simple.

<comment><USER38> And to go even lighter I use pippo([https://github.com/decebals/pippo](https://github.com/decebals/pippo)). I like the modular way that allows me to tailor my apps to be <1MB final size. Really helps with lightning fast deployments on my many DigitalOcean smallest 512MB instances.It also works great on raspberry pies - I was using nodejs webapps until pippo because they were lighter on resources(I rather hate js and nodejs and hence the praise for pippo) . I also pair it with jooq for db access when needed.

<comment><USER39> Pippo looks pretty sweet. How does it compare to Spark?

<comment><USER40> I'm trying pippo for the last couple of weeks, its quite lightweight and really fast. I could customize it for whenever the need arises, better than sparkjava. For eg: I couldn't customize the Jetty server params with sparkjava, I could with pippo.

</comment></comment></comment></comment><comment><USER41> [http://www.dropwizard.io/](http://www.dropwizard.io/) combined with reactjs

</comment><comment><USER42> Definitely Spring Boot with spring-data (if it supports your database/nosql system) since you're going to do a CRUD app, it will manage a lot for you. Add it spring-data-rest and you've got your models exposed on REST for free. If you want to secure some REST operations, spring-security got you covered.

Then on the client side you can add some hype using React or what's hot at the moment. Joke aside, on the server side Spring is solid, the whole thing is well engineered and it got you covered on every aspect of this kind of app, and then more.

</comment><comment><USER43> Probably start with `rm` of the current project and start over with something else.

I call it rm-driven development. It'll be a thing in a year.

In all seriousness, I'd probably look at Scala and Play if JVM was absolutely required, but I'd first look into why that requirement is in place and if the requirement can be removed.

</comment><comment><USER44> Does anyone have any opinions on DropWizard as a framework? Is it the minimalist web framework for Java, similar to Flask for Python?

<comment><USER45> I've heard good things about it, but my understanding is it's ideal for creating REST endpoints, so it doesn't have some standards MVC stuff out of the box. Spark is a JVM version of Sinatra which may be closer to what you're looking for.

<comment><USER46> "The dropwizard-views-mustache & dropwizard-views-freemarker modules provides you with simple, fast HTML views using either FreeMarker or Mustache":

[https://dropwizard.github.io/dropwizard/manual/views.html](https://dropwizard.github.io/dropwizard/manual/views.html)

"The dropwizard-forms module provides you with a support for multi-part forms via Jersey":

[https://dropwizard.github.io/dropwizard/manual/forms.html](https://dropwizard.github.io/dropwizard/manual/forms.html)

If you can render HTML in responses and accept multipart/form-data in requests, does Jersey become an adequate MVC framework? If not, what is it missing?

</comment></comment></comment><comment><USER47> Grails hands down. I work on an enterprise team and every time we pull a developer in who has no experience with it they fall in love. It's just so easy to work with. We spend maybe 2% of the time configuring something and 98% solving the business problem.

</comment><comment><USER48> If I _had_ to use JVM today, I'd try JRuby + Ruby ON rails:

[https://github.com/jruby/jruby/wiki/JRubyOnRails](https://github.com/jruby/jruby/wiki/JRubyOnRails)

<comment><USER49> I actually did this. Our main app is a rails app with MRI, which has worked well but comes with a bunch of opts complexity (even with heroku / AWS you're still setting up background workers, caching, queues, etc).

We built an internal webapp using torquebox ([http://torquebox.org/](http://torquebox.org/)). It's kind of a weird project (run your rails app on JBoss of all things), but it's actually worked out _wonderfuly_ for us. I know it's all the rage to build your app out of a bunch of separate services right now (and the next version of torquebox is split out into smaller pieces), but for our small team wrapping all the stuff you need for an app up into one box has been great. Torquebox gives you:

\- In-memory cache

\- Message queue

\- DSL for defining services (can be singletons or not) which torquebox will ensure are running. Your services are plain ruby classes but they can access to your rails environment.

\- Threads! Coming from MRI it's really nice to "background" some things via threads.

\- Mount other rack apps at "/app" and they share the environment (e.g., queue)

It's been running rock solid for a year with basically no ops maintenance. I'd encourage anyone building webapps to read through the torquebox documentation, it's clearly written by a team of people with experience deploying and maintaining "serious" stuff.

</comment></comment><comment><USER50> Clojure on the back end and ClojureScript on the front end.

Some reasons:

1\. It's a proper full-stack solution. You can share code between client and server if you need to.

2\. There is some amazing front end technology (Om, figwheel etc.) that can change the way you think about front end development.

3\. It is hard to match Clojure for productivity / interactive development. You can code almost everything at the REPL without restarting (no restarts or edit/compile cycle time needed)

4\. You can use all the Java libraries very easily (although idiomatic Clojure wrappers exist for almost everything you are likely to need)

5\. The usual Clojure reasons: functional programming, concurrency, immutability, Lisp macro etc.

</comment><comment><USER51> Grails, I really like Groovy as a language. Grails provides a lot out of the box and is good enough performance wize for small to medium sites with no tuning.

<comment><USER52> this is a comment posted yesterday criticizing the management of Groovy - [https://news.ycombinator.com/item?id=10293508](https://news.ycombinator.com/item?id=10293508)

<comment><USER31> Meh... vorg posts on nearly every thread that mentions Groovy and rants about all the perceived wrong-doings in the Groovy community. Some of his points have some merit, but he seems to tend to make mountains out of mole-hills.

<comment><USER53> You didn't comment on any of the specifics mentioned in that linked-to comment, instead you attacked my behavior, just like one replier to that comment.

You mentioned Groovy moving to the ASF in another comment above, but if only two people control the DNS name and physical access to that server in Germany hosting the websites, receiving the Nabble mail archive and Apache website redirects, creating the phantom downloads from Maven and Bintray, etc, then the list of committers and mentors at ASF for Groovy is meaningless. Because Groovy _isn 't_ really protected by the ASF guidelines, its future is uncertain.

As for Grails you also mentioned, Grails 3 also has an uncertain future, what with so few people upgrading from version 2, just like with Python version 3. Grails 3 bundles all of Gradle, and its business case seems less about modernizing Grails 2 than about its founder wanting to muscle in on the Gradle consulting market, just like he did with Spring in Grails 1, until SpringSource bought his company to protect their cashflow. He's trying the same with Gradleware.

<comment><USER31> _instead you attacked my behavior, just like one replier to that comment._

Have you considered that your behavior might be at issue then? Seriously man, you seem to go out of your way to find any and every thread that mentions Groovy in any way, and then launch into your rant about all the evils of the Groovy community.

The thing is, I _said_ that you have some merit in what you say. But the repetitiveness and the vitriolic presentation make you look like somebody who has an axe to grind or something, instead of a dispassionate observer.

 _You mentioned Groovy moving to the ASF in another comment above, but if only two people control the DNS name and physical access to that server in Germany hosting the websites, receiving the Nabble mail archive and Apache website redirects, creating the phantom downloads from Maven and Bintray, etc, then the list of committers and mentors at ASF for Groovy is meaningless._

When existing, long-established projects move to the ASF, they always deal with shit like this. It takes time to sort this stuff out, that's why there's an incubator. And if it doesn't work out, then so be it. At that point, I'd reconsider my position of advocating for Groovy. But I'm not going to rush to judgment and focus on all the negatives, which is what you seem to do.

<comment><USER53> > you seem to go out of your way to find any and every thread that mentions > Groovy in any way, and then launch into your rant

The most significant thing you've really said here is that I generally post comments under my own name, as I suspect you also do, given how active your "mindcrime" user is and the implicit assumption in your above comment that you're seeing the entire picture by looking at who's posting comments. Have you considered that other "entrepreneurs" involved with Groovy keep hundreds of HN logins each to obfuscate their mischief here and engage in illicit surveillance of people whose comments they don't like? This I don't say in my comments, instead I keep what I say seemly and do it in my _own name_. It's _because_ I use my own name that I "seem to go out of my way to find any and every thread ..."

<comment><USER31> _Have you considered that other "entrepreneurs" involved with Groovy keep hundreds of HN logins each to obfuscate their mischief here and engage in illicit surveillance of people whose comments they don't like?_

Honestly? No, the thought never crossed my mind. And now that you mention it, it doesn't sound terribly likely to me. Not "hundreds* of such people anyway. Maybe two or three. Why do I say that? Simply because Groovy just doesn't come up that often to begin with. And a decent percentage of the time, when it does, I'm the one bringing it up, and know where I stand. And while "mindcrime" clearly isn't my birth name, my HN account is clearly linked to my real world identity, so no one can really claim that I'm trying to hide anything here.

One other person here to mentions Groovy / Grails occasionally is @mgkimsal, and I also know him in the Real World, and have no suspicion that he's up to anything nefarious.

That said, people never cease to surprise me and clearly some people post on HN largely for commercial gain. I don't think anyone questions that. I just don't see what you seem to see, in terms of large numbers of users here trying to manipulate the discourse around Groovy in particular.

<comment><USER53> > other "entrepreneurs" involved with Groovy keep hundreds of HN logins each

> post comments under my own name, as I suspect you also do

I would agree probably 2 or 3 people -- I _never_ said "hundreds" of people, and I specifically said you post comments under your own name, _not_ the opposite.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER54> I'm going to go with a unique answer here:

Java + MySQL, using these awesome libraries

\- Bowser (webapp): [https://github.com/mirraj2/bowser](https://github.com/mirraj2/bowser)

\- EZDB (MySQL wrapper): [https://github.com/mirraj2/ezdb](https://github.com/mirraj2/ezdb)

\- Ox (IO and Json): [https://github.com/mirraj2/Ox](https://github.com/mirraj2/Ox)

These bad boys make writing Java wonderful again.

</comment><comment><USER55> If that's only me or me and a few experienced Scala developers I would use more cutting edge stuff - Akka HTTP. If the team is less experienced or have more experience with traditional web apps - I would go with Play framework. It's well supported, not difficult to get into.

<comment><USER56> A nice complement to Akka is Spray.io[1]. Not really meant for CRUD type apps that is the subject of the original question, but very well suited for REST systems.

1 - [http://spray.io/introduction/what-is- spray/](http://spray.io/introduction/what-is-spray/)

<comment><USER55> As redtuesday correctly noticed, Akka HTTP is a successor of Spray.io. Mathias Doenitz, the main author of Spray.io, worked on Akka HTTP as well. They are similar in many places, just powered by different "engines". Akka HTTP is built above new Akka Streams, while Spray.io is powered by plain Akka. But, for example, routing DLS is very similar. Our main API is in Spray, but when I tried Akka HTTP for a new microservice, I actually reused most of things from our customised stuff above Spray.

</comment></comment></comment><comment><USER57> Also agree with the combination of Play + Scala for flexibility and ease of use.

</comment><comment><USER58> Not a popular opinion here, I'm sure. But I would no doubt use a newer CFML platform, either ColdFusion 10+ or Lucee.

</comment><comment><USER59> Another vote for Play + Scala here. What I built my last app on, and plan to keep building on it.

For simple CRUD it may be overkill, but it scales nicely for when you go past CRUD.

<comment><USER60> Slick has a bit of a learning curve, but it's really a thing of beauty once you figure it out. I never make syntax errors in queries any more. Getting the code generation from the DB model going is a must. It makes things go really fast, especially for a large data model.

</comment></comment><comment><USER61> Play Framework (Java or Scala)

</comment><comment><USER62> ReactJS + DropWizard + JDBI (or JOOQ) if you like JAX-RS.

ReactJS + Spark framework (or Vert.x 3 or Ratpack) + JDBI if you don't like JAX-RS.

I don't like JAX-RS, but it is hard to beat DropWizard if you do.

</comment><comment> a-saleh It depends.

If I were to work mostly alone on a smaller project, I would use clojure/clojure-script, because I used it at my work for a year and really liked it.

If I were to work with more people, I would first ask them.

Do they have dislike for dynamic typing? Scala+Play sounds good.

Are they really comfortable with EE java? Spring MVC + Hibernate + JSP ... e.t.c

</comment><comment><USER63> First of all, I have to agree with dommer. You pick the stack depending on the use case.

That being said, in most use cases I've encountered I would've gone with a REST API on the server for CRUD operations and an SPA framework on the UI side. I've found that the use of a classical UI Framework like Play, Grails or JSF make seperation of UI and business logic harder, rather than easier. Especially Grails is a huge vendor lock in and the framework leaks through all layers.

To "scaffold" your REST+SPA application, I've found Spring Datas automagic generation pretty useful, but you're free to use any technology you like.

<comment><USER47> Grails is great for building a REST API. Especially the latest version. It makes it dead simple. I do SPA frameworks on the front and JSON APIs from the back.

<comment><USER63> Grails is great to get things done quickly (scaffolding). But if you want to write vendor independent code, Grails makes your life unnecessarily hard by providing a full stack from Database to UI. Somewhere something leaks into the business logic. This is less the case if you can pick and control exactly what Database and REST technology you use. Of course you can ignore the DB part in Grails and plug your own thing, but then, why should I use Grails in the first place?

<comment><USER47> Fair point. Grails 3 provides "profiles" for this reason. So if you don't need the view layer and everything that goes with it won't be loaded.

</comment></comment></comment></comment><comment><USER64> i recently wrote a small blog engine in vert.x ([http://vertx.io/](http://vertx.io/)). i'm not fluent with reactive programming yet (so i didn't use RxJava), but the callback hell was manageable enough. among the upsides are the seamless integration and handling of websockets. the blog engine is a bit of an outlier though because it's embedded and fully single threaded. there are a lot more advantages if you leave out the embedding, like several more languages (several languages with interpreters available on the JVM).

<comment><USER28> Vert.x is fantastic.

My honest opinion is that JVM folks love complexity though. It's a mix of popularity, job security and good marketing that allow the traditional bloat- powerhouses to remain popular while technologies like Vert.x remain criminally under-utilized (see the rest of this thread for evidence). I don't know how or if this will ever change, but the downside for the JVM ecosystem overall is that people associate the JVM with things like Spring and Hibernate rather than things like Vert.x. And that's a shame.

</comment></comment><comment><USER65> If Scala is an option, try Finatra 2. Much simpler than Akka* and Play, well done, performant and battle tested (as opposed to akka-http).

[https://www.youtube.com/watch?v=7dsX0S0WsEk](https://www.youtube.com/watch?v=7dsX0S0WsEk)

If Scala is not your thing, you should definitely check out Vert.x 3 with vertx-web [https://github.com/vert-x3/vertx-examples/tree/master/web- ex...](https://github.com/vert-x3/vertx-examples/tree/master/web-examples)

<comment><USER34> Unfortunately the documentation is pretty poor. You'll definitely run into troubles with any non trivial app due to the lack of proper documentation (and there is not much third-party documentation around).

</comment></comment><comment><USER66> Web based?

Apache Wicket ([http://wicket.apache.org/](http://wicket.apache.org/)).

Java + HTML. Can't get any simpler than that. Java 1.8.0 makes me not miss Groovy at all.

</comment><comment><USER67> Play Framework

<comment><USER68> I like Play too.

<comment><USER69> So much great code being checked in.

</comment></comment></comment><comment><USER70> In scala-land, I've got experience from Scalatra, http4s and Play framework. We've recently migrated a large Scala project from Scalatra to http4s. I would not recommend using the current 2.x version of Scalatra. The biggest issue I've got with it is it's lack of type-safety. Each REST-endpoint in Scalatra is basically a function from Request to Any. So you can return anything and cross your fingers it works runtime (see e.g. [https://github.com/scalatra/scalatra/issues/534](https://github.com/scalatra/scalatra/issues/534)). I believe many of the core Scalatra-contributors are nowaday much more active in development of the http4s (see [https://github.com/scalatra/scalatra/graphs/contributors](https://github.com/scalatra/scalatra/graphs/contributors) vs [https://github.com/http4s/http4s/graphs/contributors](https://github.com/http4s/http4s/graphs/contributors)).

I really like the design of http4s; services compose really nicely -- each service/server is just a partial function from Request to Response. It utilizes Scalaz Tasks for asynchronous opeartions / streaming. On the other hand, I would not consider http4s very mature yet. We've encountered some issues during refactoring from Scalatra to http4s. Also, they offer support for both Servlet- and Blaze NIO -servers, but I've had the feeling that Servlet-support feels a bit like second-class citizen. Maybe not so thoroughly tested (I'm just spitballing here)? But still.. I like it and based on current experience would not advice against using it. Also, I've had great help from their Gitter-channel. :)

Play framework, is nowadays pretty mature. I've used it in multiple projects, and love that nowadays it's sbt compatible (just declare the dependencies) -- I think in the past you had to download a separate distribution for using it.

I think http4s and Play are both excellent choices. Play feels a bit bloatish and maybe opionated compared to http4s, but on the other you've got everything ready (play-ws, play-json, play-twirl etc.). Once http4s gets a bit more mature, I believe it'll be awesome! :)

P.S. With http4s my current recommendation would be: Argonaut for JSON, and Slick for RDMS-support (Postgres all the way).

</comment><comment><USER71> I'm building something with React + Relay + Sangria and it's working out well so far. There's a sample sangria project showing how to use it on akka-http, and if you write a pure web app like this, you could serve the javascript client from somewhere dumb like S3. Plus with this stack you can plug in react-native apps as well once your server is written.

<comment><USER52> how are you running React on the JVM - Are you using Nashorn or Rhino here?

<comment><USER71> Sangria is scala. React is the client in the browser. That doesn't run on the JVM.

<comment><USER52> can you talk a bit more ? How do you write your views and integrate them with sangria. I'm coming from nodejs .. where everything is JS, so I'm trying to understand how this stack works.

<comment><USER71> Sangria is a scala GraphQL server. Facebook released an initial reference implementation in javascript, but I wanted the type-safety that scala gives. If you're more comfortable with JS you could check that out. See [https://facebook.github.io/relay/](https://facebook.github.io/relay/).

With GraphQL you don't write views per se, but you make data available. The client can pick and choose which of the exposed attributes it needs to render a view. So if you have, say, a user profile page, you might use relay to declare that you need something like:

        user(id: $userId) {
          username
          age
        }

Then relay will hit your graphql server and add this data to your react props.

It's a similar thing with mutations - you expose operations through your server and then relay handles calling it with the necessary data, and propagating back the response into the UI.

I've found this approach to be very powerful and quick to develop in (once I got my head around it). With REST, you have to keep on adding new endpoints or fiddling with your server if you need more attributes from it. E.g. say you also want the user's gender. With traditional REST you'd need to make this change in your client (to request that extra data) and update your server to expose it. Or perhaps you'd add a new endpoint that returned more data about a user. Then you may also need to decide what happens with legacy clients. Should they fail if they receive extra, unexpected data, or do you version your API, etc.?

With GraphQL you can choose to expose all of the different attributes on your user model (with authentication/authorisation, etc as appropriate) in-advance, and then if clients need the gender, they can just request it via relay.

After I tried writing an app using REST and continually feeling like I was walking in mud, this is a real breath of fresh air, and I feel productive again. I definitely recommend checking it out.

<comment><USER52> thanks for that!

I'm assuming your views are written in React.js - how does that get served to your clients ? does the Scala relay server serve it ... or do you have a separate client webapp ?

<comment><USER71> Yeah the views are all just react.js. The JS for the webapp is dumb so can be served by S3 (i.e. no server-side rendering). It's basically REST++ - a pure server that just serves data (sangria/graphQL server) and a decoupled client (which in my case happens to be a react web app for now).

</comment></comment></comment></comment></comment></comment></comment><comment><USER72> Server-generated HTML or browser-generated HTML?

Spring Data REST makes a good HATEOAS JSON REST api for you, somewhat automatically.

Spring Data JPA alleviates the drudge of writing your DAO layer.

Spring 4.2 does websockets and server-sent events nicely.

PostgreSQL 9.5 (out soon). Regular JDBC driver for regular stuff, but try the pgjdbc-ng driver to listen to NOTIFYs.

</comment><comment><USER73> Ninja Framework ([http://www.ninjaframework.org](http://www.ninjaframework.org)) with Ebean ORM ([http://ebean-orm.github.io](http://ebean-orm.github.io)). Ninja's SuperDevMode rocks.

</comment><comment><USER74> It depends on your needs, and what you want to do. If you're a big Pythonista, perhaps Jython is worth a look in. Lisper? Look more towards Clojure. Need to be able to hire developers? Plain Java will help you on that front.

Often, choosing a JVM language does not lock you into that language, as there's good interoperability. Be prepared that the first choice of language for a project might not be the best choice.

In response to the question, Java, Spring, Hibernate, and Postgres have served me well on a variety of projects. However, you need to take it with a grain of salt -- my needs will likely be different to your needs, and my skill set is almost certainly different.

</comment><comment><USER75> I'm actually building one right now using Scala + skinny-micro-framework [1] + Slick and it's going pretty well. Very nicely composable, easy to work with Futures (unlike Scalatra) and very easy to extend to handle new types globally. (Just added an `Option -> response getOrElse 404` and if I need it I can add `actorRef -> Future -> rest-of-pipeline` too.).

http4s and rho also look interesting, but they suffer from the magic operator soup that made dispatch a pain to work with (IMO).

[1]: [https://github.com/skinny-framework/skinny- micro](https://github.com/skinny-framework/skinny-micro)

</comment><comment><USER76> On the server: Spring Boot + Spring MVC + Spring Data + Gradle

On the client: React

<comment><USER28> This is like the software engineering equivalent of someone who only wears Nike clothes.

</comment></comment><comment><USER77> If you don't mind Clojure then you could also try Clojure on Coils: [http://coils.cc/](http://coils.cc/)

</comment><comment><USER78> Why are you tied to using the JVM?

<comment><USER79> Because of Scala, in my case, and because I can run React.js server side in the JVM. And because it's fast.

Edit: Oh I misunderstood your question. (Did you perhaps edit your comment, added "tied to"? Didn't notice that the first time)

</comment></comment><comment><USER45> We use Play for www.faqt.co, and it's been nice, but (like any framework) you start hitting random limitations that takes a lot of work and occasional Scala code to get around. Sometimes I wonder if using something like dropwizard.io for a single page app would of been better.

But if your project is only going to be a crud app with limited traffic volume/life time, I'd personally probably pick an interpreted language and framework.

</comment><comment><USER80> Om / ClojureScript ??? / Clojure (I need to check out the options here - <USER3> is good for CRUD but Liberator scares me a bit) Datomic atop Postgres

</comment><comment><USER81> Being the author, I'm of course biased, but I made Boilerplay ([https://github.com/KyleU/boilerplay](https://github.com/KyleU/boilerplay)) for this very reason. It's a Play/Scala app, uses postgres-async for database access, and provides most of the boilerplate you'd need for non-trivial apps (admin, metrics, reporting, sign-in, etc).

</comment><comment><USER29> One of the things I actually do at my current job.

I use JavaEE, more specifically TomEE.

JavaEE has improved massively since last time I used it and is now quite good.

</comment><comment><USER82> My background, which informs my personal taste here:

\- Most recent 8 years, have used dynamic languages on the server (Node.js, Ruby, PHP, some Python)

\- Have dabbled in C# (ASP.NET MVC and WPF)

\- First 4 years professional experience as a Java web developer (servlets, Struts, Spring, Hibernate, etc)

\- Have needed recently to generate greenfield Java apps for relatively straightforward CRUD web apps / JSON APIs

I personally would have a hard time going back to Spring or JEE. I initially looked at Play, which is very cool in many respects, but comes with a high complexity/magic level that makes me nervous. Probably it's great, my old bones just can't deal with another long walk to mastery like with Rails.

Here's the stack I have been most comfortable with - note that this has been for relatively simple CRUD app development, and may or may not suit your hyper-enterprise-iot-multitenant-whatever use case:

 _Web Framework:_

Spark 2 (requires Java 8)

[http://sparkjava.com/](http://sparkjava.com/)

Kevin likes: Easy to generate single runnable jar, simple route configuration, no heavy abstraction over HTTP (easy to filter, redirect, return status codes, set cookies, etc), support for a variety of modern template engines.

Kevin dislikes: pretty small community around the software

 _Template Engine:_

jade4j

[https://github.com/neuland/jade4j](https://github.com/neuland/jade4j)

Kevin likes: terse syntax I came to enjoy from Node/Ruby, can easily re-use templates on the front end if needed in Backbone. Integrates easily with Spark.

 _Model:_

Morphia (MongoDB)

[http://mongodb.github.io/morphia/](http://mongodb.github.io/morphia/)

Kevin likes: <troll>it's web scale</troll>, no schema maintenance, easy to configure for dev/test/prod, easy to create fat models, doesn't require a ton of annotation for persistent fields.

Kevin dislikes: sparse documentation

 _Dependencies /Build:_

Maven (duh)

[https://maven.apache.org/](https://maven.apache.org/)

Kevin likes: doesn't matter if I like it, all Java packages live there. Lots to use and choose from both for build tasks and in your code. Make note of the Shade plugin, which makes it easy to generate a single runnable "fat jar":

[https://maven.apache.org/plugins/maven-shade- plugin/](https://maven.apache.org/plugins/maven-shade-plugin/)

Kevin dislikes: OMG XML. Super verbose. Pretty slow. Seems to frequently download the Internet. Not fun to extend - consider shelling out to your own scripts:

[http://www.mojohaus.org/exec-maven-plugin/](http://www.mojohaus.org/exec- maven-plugin/)

With the above tools, I found that it's easy to take advantage of the great software packages that do exist for Java, without making my brain hurt too much.

HTH!

<comment><USER46> Why Maven rather than Gradle? Gradle has all the libraries in Maven Central. Gradle also has an extensive set of useful plugins built in [1], and many more available externally [2]. In particular, there's a plugin for making a fat jar [3], and even without a plugin, it's a few lines of code [4]. Or you can also make something more exotic like a capsule [5] or a shell script [6], or my preferred format, a 'distribution zip' file containing loose jars and a shell script [7] - which you can even make executable, because i wanted to troll my boss one day [8]).

And there's no XML, it's pretty concise (Groovy syntax, convention over configuration, sensible defaults), and although its raw speed is no better than Maven's, it is smart enough to only execute tasks which are needed (rather than everything, every time, as Maven does), and can run as a daemon to avoid startup costs [9], so in practice it's far faster than Maven. Still downloads the internet now and then, though.

But extension is an absolute joy - there is simply no comparison to Maven. There's a very satisfying spectrum of ways to define your own tasks, from blocks of code right in the build script, to classes defined in the build script [10], to externally packaged plugins, all of which are easy to do and integrate fully with the existing machinery (task dependencies, handling files, inputs and outputs, and so on).

Then there's the stuff you might not even notice until you get off Maven. Gradle builds are graphs of tasks, not sequences of lifecycle phases, so it's trivial to add more tasks, rearrange, tasks, etc. Concrete example: Maven provides a single test task (surefire); if you want a second (say, for functional tests), you can use a plugin (failsafe); if you want a third (say, for external contract tests), you'll need to write a plugin. In Gradle, you'd just make another instance of the test task. It's a few lines of code.

Sorry if i sound like a fanboy or a shill, but Gradle, while far from perfect, is so much better than Maven in every way that it pains me to see a fellow human being suffering under the latter. Seriously, Maven is obsolete. Just use Gradle. Until something better comes along.

[1] [https://docs.gradle.org/current/userguide/standard_plugins.h...](https://docs.gradle.org/current/userguide/standard_plugins.html)

[2] [https://plugins.gradle.org/](https://plugins.gradle.org/)

[3] [https://github.com/johnrengelman/shadow](https://github.com/johnrengelman/shadow)

[4] at its simplest, something like:

      jar {
        dependsOn configurations.runtime
        from {
            configurations.runtime.collect { zipTree(it) }
        }
      }

[5] [https://github.com/danthegoodman/gradle-capsule- plugin](https://github.com/danthegoodman/gradle-capsule-plugin)

[6] [https://github.com/cinchapi/jarsh](https://github.com/cinchapi/jarsh)

[7] [https://docs.gradle.org/current/userguide/application_plugin...](https://docs.gradle.org/current/userguide/application_plugin.html)

[8] [https://github.com/pivotal/executable-dist- plugin](https://github.com/pivotal/executable-dist-plugin)

[9] [https://gradle.org/why/high-performance- builds/](https://gradle.org/why/high-performance-builds/)

[10] [https://github.com/tomwhoiscontrary/PanettoneSpike/blob/mast...](https://github.com/tomwhoiscontrary/PanettoneSpike/blob/master/build.gradle#L42)

<comment><USER53> > Maven is obsolete. Just use Gradle. Until something better comes along.

Google released Bazel a few months ago, which runs on Linux, tho not Windows, and fully supports JVM-hosted software. It's better than Gradle, so why not move straight from Maven to Bazel? See [http://bazel.io/docs/bazel-user- manual.html](http://bazel.io/docs/bazel-user-manual.html)

<comment><USER46> Definitely worth considering! I've never used Bazel, so can't give a very helpful answer. Two things discourage me.

Firstly, it's still in beta - 0.1.0 is out [1], and there's plenty to do before 1.0. [2].

Secondly, according to the article on Bazel currently floating up on HN [3]:

"Blaze was designed to work for Google's unified codebase and Bazel is no different. The implication of a unified source tree is that all dependencies for a given software component exist within the tree. This is just not true in the open source world where the vast majority of software packages have dependencies on other libraries or tools, which is a good thing. But I don't see how Bazel copes with this, if at all."

How would i use Bazel to build a project which uses dependencies from Maven Central, or my company's internal repository? It seems that Bazel can fetch jars from Maven repositories [4], but i don't think it does transitive dependencies.

Also, the extension story looks a bit weird [4]:

"Skylark is a superset of the core build language and its syntax is a subset of Python. The following constructs have been added to the core build language: if statements, for loops, and function definitions. It is designed to be simple, thread-safe and integrated with the BUILD language. It is not a general-purpose language and most Python features are not included."

Whilst i'm no fan of Groovy, it's nice to be able to write plugins in a general-purpose language. For example, in one of the build scripts i linked to in my comment, i have a custom build step which processes templates by running another Java program (which was downloaded as a JAR from Maven), and in other builds i've written plugins which call directly into Java libraries (again, which were downloaded as JARs from Maven). Could i do that with Skylark?

[1] [https://github.com/bazelbuild/bazel/releases](https://github.com/bazelbuild/bazel/releases)

[2] [http://bazel.io/roadmap.html](http://bazel.io/roadmap.html)

[3] [http://julipedia.meroh.net/2015/04/on-bazel-and-open- source....](http://julipedia.meroh.net/2015/04/on-bazel-and-open-source.html)

[4] [http://bazel.io/docs/build- encyclopedia.html#maven_jar](http://bazel.io/docs/build- encyclopedia.html#maven_jar)

[5] [http://bazel.io/docs/skylark/concepts.html](http://bazel.io/docs/skylark/concepts.html)

<comment><USER53> You could be right about Bazel's unsuitability for open source software.

> The following constructs have been added to the core build language: if > statements, for loops, and function definitions

The whole point of using a declaratively-configured build product rather than procedural scripts is to simplify the logic and be easily extendable. Maven provided the declarative DSL and removed totally the procedural language so you needed an addon like polyglot-maven to do anything "out of the box". Gradle then added the whole procedural language back in to be used with the DSL, but it's hardly used as most build scripts out there are just standard 30-liners. Perhaps Bazel's way of providing just enough procedural features (sequencing, selection, iteration, subroutines), and no more, with the declarative DSL is the best mix.

</comment></comment></comment></comment></comment><comment><USER83> Spring Boot + Spring Data

<comment><USER28> Because you can't go wrong with all things Spring (tm), amiright?

</comment></comment><comment><USER84> That would be Spring Roo, along with roostrap.

[http://bhagyas.github.io/roostrap/](http://bhagyas.github.io/roostrap/)

and [http://projects.spring.io/spring-roo/](http://projects.spring.io/spring- roo/)

<comment><USER85> I second this. while creating a CRUD app for a college project, springroo helped me bootstrap it to the point that i was able to complete the entire app in 6 hours.

</comment></comment><comment><USER15> At my office we've got a whole bunch of Spring Boot projects happening. A workmate of mine began making a screencast series, "Annotated Spring", a la Railscast.

[http://www.annotatedspring.com/](http://www.annotatedspring.com/)

</comment><comment><USER86> If using Java and not Clojure, maybe I'd use enunciate again on top of the standard JavaEE stuff. [http://enunciate.webcohesion.com/](http://enunciate.webcohesion.com/) Deploy with tomcat.

</comment><comment><USER87> I don't see how this question is answerable in any meaningful way in its current form. You're going to get a list of basically every JVM framework there is, and you speak nothing of your front-end requirements.

<comment><USER88> I admit OP's question is a little vague, but as someone who hasn't touched Java in a while, I appreciate it. True, the answers are just as vague as the questions, but to someone who is familiar with Java and not the frameworks for web development it does enumerate the options that can be explored

</comment></comment><comment><USER89> JHipster [http://jhipster.github.io/](http://jhipster.github.io/)

It's a yeoman generator actually, generates a Spring based project with all the CRUD stuff ready for you.

<comment><USER90> I'm the creator of JHipster, thanks for the link :-)

Yes we do generate CRUD entities, from the database (SQL, Cassandra, MongoDB) to the view layer (AngularJS/Bootstrap). All this with security, caching, monitoring, documentation, tests... So this is very different from Play, Dropwizard or even vanilla Spring Boot (on top of which JHipster is built).

I'm not saying it's better or worse, just that it's a totally different beast: depending on your needs, JHipster can be a huge time-saver.

</comment></comment><comment><USER91> I'd say it depends on your data model. If it is fairly simple, Ruby on Rails is quite awesome. I didn,t experiment with Clojure, Scala, etc. but RoR is a quite impressive toolset to do CRUD on simple stuff.

</comment><comment><USER92> JHipster, i.e. Spring Boot and AngularJS: [https://jhipster.github.io/](https://jhipster.github.io/)

</comment><comment><USER93> Scala + Spray + ScalikeJDBC, though I miss Spring's DI sometimes. None of the scala DI pieces felt natural & clean. So stuck with scala implicits

</comment><comment><USER94> spring mvc for the rest controllers with spring data jpa for the repository layer. The frontend in Angular 1, nothing beats that in terms of simplicity and flexibility.

Dont try to do your frontend in java using jsf, wicket, gwt, vaadin, play framework the scala compiled templates or anything they are too complex and unflexible compared to what you can do with angular in the browser in a fraction of the time.

</comment><comment><USER95> Grails is great. I'd avoid Grails 3 for the moment use 2.5.1. It has the power of Spring and HIbernate, but really easy to use and configure.

</comment><comment><USER96> Jhipster has a nice stack ( [https://jhipster.github.io/](https://jhipster.github.io/) )

<comment><USER97> +1

</comment></comment><comment><USER40> [http://pippo.ro](http://pippo.ro) with Spring JDBC. Quite light weight, modular and very fast.

</comment><comment><USER98> jruby / rails

</comment><comment><USER99> Right now I am making something simple based on Spring Web, Freemarker templates, and DynamoDB. It works.

</comment><comment><USER100> Play (scala) even if I am more comfortable using java, I prefer using scala just to use play.

</comment><comment><USER101> Java EE - _the_ standardized Java stack for Enterprise Web-Applications.

</comment><comment><USER102> Jersey + Hibernate for a RESTful service. AngularJS in the frontend

</comment><comment><USER103> Scala + Akka HTTP + database that fits the data type in question

</comment><comment><USER104> Django on Jython

<comment><USER105> The nice thing about Django is the combo of its model layer and forms library handle the most boring bits of CRUD without generating a bunch of code or being tied into a particular templating library. I'd be tempted to go with this answer if the frontend is going to be a basic forms 'n links affair.

Is there anything comparable to django.forms in Java yet? There wasn't the last time I went looking a few years ago.

</comment></comment><comment><USER106> I would look at vertx.io with reactjs.

</comment><comment><USER107> Lucee with CFWheels

</comment><comment><USER108> StrawBerry on Beryl as backend and Torque or Glass as frontend

</comment><comment><USER109> Java spark or vertex + hiberate or sql2o + freemarker

</comment><comment><USER110> rails / jruby

<comment><USER111> How about Padrino / JRuby?

</comment></comment><comment><USER112> Try Takes Framework: www.takes.org

<comment><USER20> Despite its four fundamental principles this framework does not read well and I personally wouldn't recommend it.

Class names with Ft or Bk or Rs or [add two letters] prefixes don't work for adoption and clarity of expression.

</comment></comment><comment><USER113> jruby / rails</comment>


Are you one of the 10% of programmers who can write a binary search? - <AUTHOR> http://reprog.wordpress.com/2010/04/19/are-you-one-of-the-10-percent/ <comment><USER3> To be precise, the post says that only 10% of programmers can write it correctly without testing. I agree that this is an interesting statistic, however the industry has been deprecating implementing an entire algorithm in one go in favour of implementing algorithms incrementally. Were I to write it without testing I would probably write it incrementally and try to perform the testing in my head as I went along. It feels very retrograde to try to write the whole thing out and only then start thinking about off-by-one errors, computer arithmetic issues, and other edge cases.

<comment><USER4> It feels like a totally made up problem:

"Here's a binary search algo description, implement it perfectly without testing".

That's not even close to how developers work, and he amplifies the disconnect with the real world by choosing a problem known for it's boundary and off-by- one risks.

<comment><USER5> While this scenario may not allow developers to work like they normally do, I think the author's point is that a simple binary search isn't _that_ complicated. A decent dev should still be able to a pretty good job despite those artificial constraints.

<comment><USER6> And the author is simply wrong about his point (if that is indeed his point). A binary search _is_ that complicated. It just doesn't look like it until you've considered all the possible edge cases, and chances are that most "decent devs" will miss some and be part of the 90%.

<comment><AUTHOR> Speaking as the author: his point, if any, is more along the lines that if we need a test-as-you-go approach to get something this simple to work, it's no wonder we have problems when we have to implement something that's actually complex.

Also: no amount of test-drivenness can save you from just not grokking the problem (as Peter Norvig's Sudoku solver showed ... er, by counter-example.)

<comment><USER7> I'm missing the back story -- tell me more about Peter Norvig's solver?

<comment><USER8> [http://pindancing.blogspot.com/2009/09/sudoku-in-coders- at-w...](http://pindancing.blogspot.com/2009/09/sudoku-in-coders-at-work.html)

<http://norvig.com/sudoku.html>

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Short answer: Yes, I am, including without testing.

For several years I ran a challenge for exactly this question. I have a test harness and test suite, and would run people's programs through it. Roughly 1 in 30 or 40 of those submitted without testing (self-certified) would pass all the tests. Those who tested before submission passed about 1 time in 3.

The vitriol heaped on me was quite unbelievable, and in one case led to concerns for my physical safety. People who had decided to try the challenge then rounded on me and said it was unfair, unreasonable and unrealistic. I didn't affect the results - the vast, _vast_ majority of people simply could not write a binary search that passed my test suite.

FWIW, my first attempt had exactly one problem, to the best of my knowledge. I decided to derive my code formally from the specification. The mistake concerned computer arithmetic, not the algorithm, and was the one lunk to from the article.

But my background is unusual.

<comment><USER3> > Those who tested before submission passed about 1 time in 3

"Programmers are not to be measured by their ingenuity and their logic but by the completeness of their case analysis." --Alan Perlis

<comment><USER9> I would add - and their completeness in testing the correct implementation of those cases, and the correctness of the implementation.

</comment></comment></comment><comment><USER10> No incremental testing strikes me as a rather valueless constraint. Small experiments are one of the most crucial skills -- if not _the_ crucial skill -- in writing correct code. It's like asking me to swim with one arm tied behind my back to see if I am a good swimmer.

Sure, I can run these 'tests' on scratch paper or even in my head, if you require me to. But real life never requires this. I prefer to prove to myself that each piece of an algorithm is correct--using a combination of reasoning and microtesting--before moving on to the next. Why would I waste attention doing this all in my head? The computer will do many pieces of it for me quickly, accurately, in a way that catches language idiosyncracies, and most importantly frees my attention for considering more abstract errors.

Edit: I had to try anyway, and (as far as I can tell) I _was_ able to do it correctly in about three minutes. But I suspect it has less to do with native programming ability and more to do with having written dozens of variants on binary searches in the past year (I've had reason to want to handle various types of fuzzy matches, filtering and desired multiplicities in return values). FWIW, even after a fairly exhaustive suite of random input tests, I trust this binary search I have just written far less than the many I've recently written using my usual incremental methodology. Were I to include this in an actual release, I would not attempt to prove what I just wrote correct. I would destroy it and do the job properly from scratch.

Which rather underscores my point. I just wrote some code the wrong way, and even in spite of quite a lot of recent domain experience, a pretty good test suite, and a lot of staring at it and thinking about it . . . _I don't trust it because I didn't test the pieces while I was writing it_.

<comment><USER9> Do you want to send me your code for testing in my test suite? You've obviously tested it now, but it would still be interesting.

<comment><USER10> All right. It's in perl. Here's what I have:

      sub binary_search {
        my($ary, $val) = @_;

        print "Looking for $val...\n";

        $val < $ary->[0] and return undef;
        $val > $ary->[-1] and return undef;

        my $min = 0;
        my $max = @$ary - 1;
        my $mid = int(($max + $min)/2);

        while($max - $min > 1) {
          $ary->[$mid] == $val and return $mid;
          $ary->[$mid] >  $val and $max = $mid;
          $ary->[$mid] <  $val and $min = $mid;

          $mid = int(($max + $min)/2);
        }

        $ary->[$min] == $val and return $min;
        $ary->[$max] == $val and return $max;

        return undef;
      }

      my $ary_size = int(rand(10));
      my @ary;
      for(my $i = 0; $i < $ary_size; $i++) {
        push(@ary, int(rand(10));
      }

      @ary = sort @ary;

      print join(",", @ary), "\n";
      my $rv = binary_search(\@ary, int(rand(10)));
      print "Returned $rv\n";

I see already that it has the famous 'large array' bug. Not something I encounter in my work, so I'm not on the lookout for it. I'm curious if you'll find anything else wront with it.

<comment><USER9> Can/do you write in C? Would someone care to translate this?

I'll do it tomorrow at work, but if someone can post and/or email me an equivalent C version it will reduce my time. Not a problem, but just more convenient.

You'll need to give me some way to contact you so I can send you the results.

EDIT: I've just realised the spec I usually give asks for the first occurence of a key to be returned in the case where there are duplicate keys. I'll modify my tests to account for that. It's an especially useful feature in a binary search, but rarely implemented.

<comment><USER10> Having to do it in C is even _more perverse_ than doing it in my head.

;)

<comment><USER10> In all seriousness, if you have to translate it, don't bother. I write in C nearly daily, and I certainly wouldn't trust myself not to lose something in translation.

I'd be interested in what's in your test suite, though. I must sheepishly admit that my 'fairly exhaustive' test consisted of running the above random input until I'd seen all the usual tricky cases go by:

      - an array of length zero
      - an array of length one
      - an array of length two
      - the value is present
      - the value is absent and too small
      - the value is absent and too large
      - the value is absent and in the middle
      - the value is the first entry
      - the value is the last entry
      - the array is all one value
      - there are multiple copies of the value you're looking for

If you've got anything more interesting in that test suite, that'd be good to know. Like I said, I represent the one-bazillionth of programmers that actually have a recurring professional interest in correctly coding binary searches.

<comment><USER11> An array of length Maxint?

<comment><USER12> Good call. As per link in <http://news.ycombinator.com/item?id=1277701> (elsewhere in this page):

 _the binary search program that Bentley proved correct and subsequently tested in Chapter 5 of Programming Pearls contains a bug [...] it fails if the sum of low and high is greater than the maximum positive int_

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> Nope and can't say it ever came up in the 20 years I've been programming for myself and others.

<comment><USER14> I've written one. It was for an embedded system.

A good, well tested binary search is a pain in the ass to write...

1\. Your sorted array MUST use exactly the same ordering as the search is expecting. We built and sorted the array on a PC, and ran the search on the device, so this was not guaranteed.

2\. There can be NO DUPLICATE KEYS.. Duplicate keys will eventually send the search down a blind alley and off into hyperspace. Also devilishly difficult to find if the array has a lot of items, and you don't know what the problem is.

3\. The above 2 problems can sneak in during production with new data.

<comment><USER9> In a well-implemented binary search duplicated keys are not a problem. You can even tune your code to return the first, the last, or a "random" one.

The point about the sort order matching the search order is more serious.

I've written all sorts of fundamental algorithms for embedded systems and I only really started to get good when I wrote the spec, wrote the proof, then derived the code. This was done informally, but a background in Pure Math let me do it without too much effort.

And it was worth it. Code developed that way tended to run first time with no surprises. After a while we increased the number of things we needed to prove about the code, and reliability was solid.

It seems the world of programming divides into several sub-classes, including (but not limited to):

\+ Those who program web sites and databases

\+ Those who program numerical systems and simulations

\+ Those who program embedded devices and fundamental algorithms.

These are broad, and there are no doubt many more, but the skills required in "programming" seem to be dividing and become more differentiated.

<comment><USER14> Yeah, the duplicate key business came in because of other code hanging off the side of the search (a rather hairy algorithm that was searching for the next key with a different letter in a position -- given KLXX, increment the 2nd position until there's a key matching that criteria -- KLXX --> KMAA, or if there are no KM __'s, KN __, KO __, etc....

</comment></comment></comment></comment><comment><USER15> I've written binary search for production code (Delphi RTL generic collections), and gotten it right, but more embarrassingly, I also wrote quick-sort and got it wrong. It was a mishmash of two strategies IIRC - <USER2> straight recursive quick-sort, and a half-inlined version with a loop, and it didn't work at all. Escaped into the wild owing to time crunch and me electing to do squeeze too many things in at the last moment.

<comment><USER16> If your compiler/interpreter supports tail-call-optimization you should get the half-inlined version for free.

</comment></comment><comment><USER17> Nothing like a only x% of you can write this to get programmers frantically posting code fragments.

</comment><comment><USER18> _NO TESTING until after you've decided your program is correct._

Why? What is there to be gained by asking programmers to abide by such an unnatural constraint? I would never "decide my program is correct" without having tested at least bits and pieces of it in the REPL.

<comment><USER19> Because every programmer's gut reaction to binary search is "that's easy!". The no testing rule says "orly? then show me"

<comment><USER18> _every programmer's gut reaction to binary search is "that's easy!"_

Perhaps I'm not a programmer then. Or I'm a strange one I guess.

I tend to approach _every_ programming problem assuming the worst: This will be much harder than it seems. There will be corner-cases. I will miss some of them and do the wrong thing for other ones. I should try to enumerate every weird condition I can think of, and then throw random inputs at things to catch the stuff I missed.

<comment><USER20> Sounds like I'm not a programmer, either. Working on the Programming Team for my school for many years taught me to consider edge-cases.

And personally, there's quite frequently SOMETHING I forget when writing a binary search, and it usually ends in it infinite looping -- so, I often have to go find my stupid mistake.

</comment></comment></comment></comment><comment><USER21> Nearly All Binary Searches and Mergesorts are Broken: [http://googleresearch.blogspot.com/2006/06/extra-extra- read-...](http://googleresearch.blogspot.com/2006/06/extra-extra-read-all- about-it-nearly.html)

</comment><comment><USER22> > One of the reasons I'd like to see a copy of the Second Edition is to see > whether this passage has changed

For the author: it hasn't changed. Still only 10%.

I actually had to write this binary search algorithm in my technical competency interview for my current job. Rather than hours, I had minutes and the extra gotcha was that it was unsorted data so I had to write quicksort first. I remember feeling excited that I was going to be working for a company that had such low level issues but eight months in it's still the only time I've written my own sort or search methods since University :)

</comment><comment><USER23> A friend of mine once did work in C++ for the DoD. There was a logistics application that used Binary Search, which had a bug he was working on -- lots of items were somehow "misplaced" in the system. Eventually, he discovered that there was no guarantee that the list being searched was _sorted_!

As for writing out whole C programs and getting it right without debugging -- I once wrote a bit-banging controller for a model aircraft. We did bit-banging with a Gumstix board, which would let us use GPIO to implement 9 PWM inputs and 9 or 10 PWM outputs in software. I wrote a bit-banging loop that did all of the inputs and outputs and let programmers define control mixing functions and finite state machines.

I was unable to test it, because you can only test something like this by attaching to the hardware. Well, _it worked the first time and it can run the remote control of a model aircraft in flight_. (There was one tweak later, to eliminate some jitter in one of the PWM outputs, but that was just a refinement of function. It _just worked_.)

</comment><comment><USER24> I wrote my version in PHP, wondering if someone could tell me what I did wrong (I didn't test it, I assume there are mistakes).

      <?php
      function bsearch($search, $array, $start, $end){
          //$start cannot be zero.
          //$search not in $array
          if($start>$end){
              return -1;
          }
          //calculate middle
          $middle = $start + ceil(($end-$start)/2);
          //check match
          if($array[$middle]==$search){
              return $middle;
          }
          //is the middle higher than the search, if so, cut top
          else if($array[$middle]>$search){
              return bsearch($search, $array, $start, $middle-1);
          }
          //otherwise cut bottom
          else{
              return bsearch($search, $array, $middle+1, $end);
          }
      }

      ?>

<comment><USER25> Yup, no sigar.

1\. You get a division by zero when $start == $end

2\. When the element $search doesn't exist your program breaks

3\. You always check array for value $middle, so $middle should have the range 0 <= $middle < length($array). But according to the comment $start cannot be zero. If so, then $middle is always larger than zero, and as such, the first element of the array is never considered.

So it's pretty buggy.

<comment><USER24> 1\. i knew there was issue with start==end. what is the solution for that issue? i had originally written $start<=$end

2\. i think this is connected to previous issue, with ending it

3\. I knew the zero thing would be an issue, but... had to write it before caps game started :(

</comment></comment></comment><comment><USER26> Yay, I did it in 20 minutes and even remembered to test for the empty array :-)

It _was_ kind of stressful to have to pass 13 testcases on the very first attempt. I rigged them to just shout "YOU FAIL" at me without telling the specific place. Reread the code for one last time and ran it. After it completed without printing anything, I stared at the screen for like ten seconds, then went and changed one testcase to deliberately fail in case I'd screwed up the printing. Nope - everything went better than expected :-)

But Raganwald is right, this exercise doesn't really tell anything about my programming skill. I mean, I don't work like that at all. My first attempts are _always_ broken. Iterating is faster (or maybe only feels faster) than trying to get the first attempt right.

</comment><comment><USER27> I remember reading the linked post on the Google blog. Ah, here it is: <http://news.ycombinator.com/item?id=1130463> (Wow, that was only 60 days ago?)

Maybe that's why when I did this in C just now, my version ended up almost identical to the Java version. (Mine does the more correct "int middle = low + (high - low) / 2;", and I wasn't even thinking about the possibility of integer overflow the other way.) So yes, but only from benefit of having to have written it numerous times in school and in teaching newbies to use it.

</comment><comment><USER28> I started writing a solution and then stopped partway through because the pressure of getting it right in one shot was incredibly stressful.

If this were given to me for an interview question, I'd be incredibly meticulous and build a series of algorithms for len=0, len=1, len=2, etc., including various permutations of values, until I establish a general solution, which I would then submit for the final answer.

I would hardly ever do that in actual coding, though, because I could rely on hammering it with tests instead.

</comment><comment><USER12> Side-issue: why isn't Golden section better known ?

Luenberger's book [1] convinced me that a line search should be done with golden section, when I was hacking non-linear optimization. Yet I rarely see it mentioned - seems always to come down to binary search ...

[1] [http://www.amazon.com/Linear-Nonlinear-Programming-David- Lue...](http://www.amazon.com/Linear-Nonlinear-Programming-David- Luenberger/dp/0201157942)

<comment><USER9> Binary means division into two. Dividing in unequal parts is still a binary search.

And Golden Section is only indicated under some circumstances. It's big-O the same, but not little-O the same, and it depends in the exact details. It's also hard to get those details right.

<comment><USER12> Thanks, good point on the binary ...

</comment></comment></comment><comment><USER29> This is interesting, a somewhat related post can be found here:

[http://googleresearch.blogspot.com/2006/06/extra-extra- read-...](http://googleresearch.blogspot.com/2006/06/extra-extra-read-all- about-it-nearly.html)

The gist of this is that version of BSearch implemented in the JDK contained a bug due to an overflow error. I recall reading about it some time ago, funny to see it come up again.

</comment><comment><USER30> I'm amazed how many interviewees can't even properly explain binary search, down to saying "linked list" as the base data structure.

<comment><USER3> > "linked list" as the base data structure.

I would enjoy reading a logically correct implementation of a binary search on a linked list. Discussing the performance complexity would be an obvious next question in the interview.

[http://en.wikipedia.org/wiki/Schlemiel_the_Painters_algorith...](http://en.wikipedia.org/wiki/Schlemiel_the_Painters_algorithm)

<comment><USER6> Well, a skip list _is_ just a bunch of linked lists...

<comment><USER31> I would describe it more as a multiply-linked list. The important distinction in a skip list is that you get random access, in a different sense of the term, and so binary search makes sense. Similarly, you could justify a binary (or another non-sequential) search on a traditional linked list by assuming huge evaluation costs.

</comment></comment></comment></comment><comment><USER32> Here's a link to some of his work. A big fat hairy perl file:

[http://cpansearch.perl.org/src/MIRK/Net-Z3950-Simple2ZOOM-1....](http://cpansearch.perl.org/src/MIRK/Net-Z3950-Simple2ZOOM-1.04/lib/Net/Z3950/Simple2ZOOM.pm)

Knowing how to write code that is easy to read is just as important, if not more so, than knowing how to write binary searches.

<comment><USER33> How is that relevant? It's essentially equivalent to an ad hominem. Just because the guy wrote bad code doesn't mean he might not have a good point.

<comment><USER34> It is not an ad hominem because he was not arguing the point was invalid, rather that the guy is foolish to such a statement while not advocating code structure and style. Notice "...is just as important..."

I agree - that file he linked is very difficult to read and would make it much harder for me to find problems.

</comment></comment></comment><comment><USER35> Maybe I was fortunate; I learned how to write a binary search in my lower- level CS courses. I didn't even find it particularly difficult, but then again, the concept was explained quite clearly before I had to code it.

<comment><USER15> The trick with this binary search test isn't knowing or being taught or learning the algorithm, or finding it difficult; it's making sure you find and deal with every corner case, first time, without testing. For example: is an empty array handled properly? An array with duplicates? Is every item, including first and last, found correctly? What about arrays with an even number of elements vs odd, vs power of two? How about an array with over 1 billion elements (the integer overflow problem)? Are values before and after the sorted range indicated properly? If working with duplicates, do you want a found index at the start of the range, or at the end?

You get the picture.

<comment><USER36> So what this is really all about is this- do you mentally step through your code and consider what could go wrong at each step?

<comment><USER15> I would rather think in invariants - knowing what must be true at particular points in the code, at the start of loop bodies, etc. Essentially, doing a proof in one's head.

</comment></comment></comment></comment><comment><USER37> Some people here think this is about coding without testing. No, it's an example of thinking through _before_ testing, about the kind of thinking that's separate from testing. It's not meant as an example of what all programming is about, but a probe of an aspect of programming. So why.

Is it okay to write down a guess, then look at it with edge cases in mind, fix and iterate? I think sketching is okay for this exercise as long as you follow through and finish.

The difference is that sketching doesn't tell you what the bugs are. Whereas testing can tell you specifically. One's an aid to thought and the other's... an alternative, to be neutral about it.

A couple people have described case analysis like simulating tests in your head. I hope they actually use more principled thinking than they're letting on.

Iterative coding breaks into two cases: either the task is subjective/aesthetic, like an interaction or layout problem, or it really is an exact task but you don't have it clear in your mind. Everybody recognizes the value of iterating on a fuzzy problem, put that aside. The question is, if it's an exact problem but you don't understand it well, then will test-writing clarify or obscure things?

Sometimes I iteratively write and run or test a program until I get to a point where I say, "Okay, _now_ do I understand what this is about? Can I explain it thoroughly in full sentences?" Even so I'm sure I've fooled myself with tests.

In real world coding, you aren't given small problems. That doesn't mean small problems are poor examples. Obviously we should break big problems into as small and comprehensible problems as possible. Testing doesn't do that (although it could make incentives).

Not to mention the fact that there's no such thing as a complete test for a program with an infinite set of possible inputs. You can test for what seem to be the kinds of bugs the program could have.

The unstated assumption of many here is that somehow in the process of testing we'll come upon all the right tests for that program, without any sneaky missed cases. Then you will look at the tests and code and somehow extrapolate or judge that you've covered all the bases. But how sure is this if you still aren't sure exactly what the problem is, or if you don't think about bugs and cases very well?

There's a kind of thinking you have to do within and around testing anyway. The write- before- testing challenge tests how well you do that necessary thinking, and how reliably you judge how well you've done. It's an artificial light on a real issue.

Btw, my test file, meant to be easily processed in any language: <http://www.mac-guyver.com/switham/2010/04/Binary_Search></comment>


Ambient Life – Animated Vision Of The Future - <AUTHOR> http://www.datavisualization.ch/showcases/ambient-life

<comment><USER2> Original source: [http://www.theqbf.com/?p=project&id=theambientlife](http://www.theqbf.com/?p=project&id=theambientlife)

I like the aesthetic, but I didn't see anything particularly insightful here. Yes, we're working on P2P networks to augment existing networks, and functionality is constantly moving into the cloud. But having a human doctor monitor your vitals 24/7 remotely? Replacing emergency responders' communication devices with those flimsy video chat things? I'm not convinced.

Also, it really bugged me that the woman had wireless medical sensors in her clothing, but no cell phone or equivalent.

<comment><USER3> I agree, it spent a lot of time on 3d interfaces and bandwidth sharing (yawn) and the health monitoring approach was poorly thought out.

I don't see this grabbing the interest of many futurists.

</comment></comment><comment><USER4> This is nice, but it's a very conservative estimate of the near future. Many of these things already exist to some extent, or seem likely to happen within five years or so.

</comment><comment><USER5> Did they really need to have a f'in plane crash into a building?</comment>


Spanish Flu - <AUTHOR> https://en.wikipedia.org/wiki/Spanish_flu <comment><USER2> With modern medicine it appears that this will have a much less fatality rate. Only limited by the capacity of our hospitals. However, I still wonder why a few people passed away although they were young and healthy.</comment>


Proof that Twitter's Bootstrap doesn't make all sites look the same - <AUTHOR> http://builtwithbootstrap.tumblr.com/post/10690805160/christian-kienle-a-portfolio-site-for-presenting

<comment><USER2> The header on the main bootstrap page covers the content on ff7

<http://twitter.github.com/bootstrap/></comment>


More than 100 years ago, streetcars ran throughout Seattle. Here's how they died - <AUTHOR> http://www.seattletimes.com/seattle-news/transportation/more-than-100-years-ago-streetcars-ran-throughout-seattle-heres-how-they-met-their-demise/ <comment><USER2> We burned our trolleys here in Seattle :c</comment>


Lionel Messi wins nine-year fight to trademark his surname - <AUTHOR> https://www.bbc.com/news/business-54193973 <comment> just-juan-post Even the new life forms on Venus know about football Messi. I don't think there was much confusion to be had.

Poor little cycling company never had a chance.</comment>