
Choosing a Web Framework/Language Combo for the Next Decade - freshfey
http://jacquesmattheij.com/choosing-web-framework-language-combo
======
tikhonj
I (naturally) think that the article's summarily dismissing Haskell is
unfortunate. It's probably just the result of poor PR on Haskell's part.

Haskell is not only for surpassingly intelligent people, or even optimized for
them. If anything, it's the opposite: one of its core tenants is that we're
not smart enough to reason about our programs in most languages. Much of the
design work focuses on unloading complexity into the language, tools and
abstractions.

Haskell goes out of its way to prevent common errors and help you design your
program. In a very real sense, it trims the "search space" of possible
programs, helping you zero in on a reasonable solution. To an extent, I use
Haskell because I'm _not_ smart enough to use C.

Haskell _is_ unfamiliar. And people mistake that for some sort of innate
difficulty. But the two are not the same.

I would argue that overcoming unfamiliarity is one of the most important ways
to grow as both a programmer and, more generally, a person. That's why I think
the article focuses too much on choosing a language that's familiar, codifying
it as "just about all the good advice". This mindset is far, far too
exaggerated in most programmers, and its what really slows down progress,
especially for popular programming languages.

The blub paradox is also a bit misrepresented. Being a "blub" programmer is
not a matter of being more or less intelligent—it's a matter of not knowing
what you're missing. "Beating the Averages" is not "we used Lisp because we
were smarter than you"; it's more like "we used Lisp because it offers some
incredibly powerful tools that non-Lisp programmers have never used and so do
not really appreciate". It's a matter of habits and experience, not
intelligence.

My advice? _Do_ try something unfamiliar. Especially if it seems to be higher
in the great partial order of programming language power :).

~~~
mtrimpe
I'm all for trying something unfamiliar, and I could even argue for Haskell
that way, but from a different angle.

I would say that adopting a language for the next 10 years that doesn't have
purely functional data structures at its core is a fool's errand.

Persistent data structures, i.e. efficiently storing every version of your
data structure, is the natural reflection of the new reality in computing
where:

    
    
      * storage is cheap
      * random reads are cheap
      * random writes are expensive
      * serial writes are cheap
    

Whether you adopt this through Haskell, Clojure, scala or even Bloom e.a. is
fairly inconsequential.

What will matter is that persistent data structures will inevitable become
commonplace over the next decade and that techniques for leveraging it (such
as functional reactive programming) will be adopted in one form or another.

@jacquesm: I live in Amsterdam so I can try to explain it to you in person
once; virtually everyone still underestimates the impact this will have and
(or perhaps because) it's very difficult to get that across in writing.

~~~
jacquesm
Living in Romania right now, but I'll ping you when I'm back in NL (I go there
at least once every few weeks), Clojure seems to be the most approachable from
the languages you list.

Besides your listed reasons mutable state is becoming a bigger and bigger
bottle neck as the number of cores goes up and that's why functional
programming is becoming more and more important. It also makes programs _much_
harder to write in a bug-free manner and it makes testing much more difficult
(if not impossible).

It's one of the core reasons why I felt so bad about dropping Erlang from the
list because I feel that it gives me that _plus_ a battle tested environment
to work with.

Still tempted to put it back in. Your reasons add weight to an already very
difficult decision, whether or not to pursue this opportunity as a way to get
more into functional programming or to stay in my 'comfort zone'.

I've been toying around with FP on and off for the last couple of years and it
is one of the most important revivals the computing world has seen to date
(imo of course).

~~~
lmm
This may be my biases speaking but I'd say Scala is a more approachable option
than Clojure (and more popular, and has a first-class web framework in Play).
It keeps more of the traditional OO style and syntax - you _can_ use scalaz
and write scala that looks like Haskell, but you can also write code that
corresponds line-by-line to java, whereas with Clojure you're forced to make a
more immediate leap to the lisp-style syntax, immediately stop using
inheritance, and so on.

~~~
ctdavies
That's a major appeal of Clojure, the Lisp (not Lisp-style) syntax, the
functional paradigm (and the idioms are great). I really don't want to write
code that corresponds line-by-line to Java. If I wanted to do that, I'd just
write Java. However, Java interop with Clojure is straightforward.
Furthermore, Clojure allows one to solve problems with an "orientation" toward
objects, but as one learns to write Clojure well, the language guides one
toward sublime and elegant functional solutions. An important thing about
Clojure, however, is that it is _not_ tied to the JVM; The original and most
well-known implementation is for the JVM, but not only is there also
Clojurescript, there are implementations that compile to CLR bytecode, Python,
Ruby, and Actionscript. And with EDN, the extensible data notation, not only
can you have your front-end and back-end codebases entirely in Clojure, you
can transfer and store your data as Clojure too. I know not everyone has the
same aesthetic tastes as I do, but I do like to think that there is something
beautiful about this.

Finally, I must say that while Scala does indeed have a first-class web
framework in Play, web frameworks are first-class objects in Clojure. Joke.
Sort of. I personally do not want to have a monolithic pre-packaged web
framework to bow down to; the Clojure community is a community of hackers, we
like to make things out of other things, and to take things apart. Clojure and
the work of its community allows me to compose my own web framework as needed
very _very_ quickly–and to drastically change it just as fast. I'm not saying
you should stop doing what you like to do, but if you gave Clojure a
chance...dude: it's addictive.

~~~
lmm
> I really don't want to write code that corresponds line-by-line to Java. If
> I wanted to do that, I'd just write Java.

The code I write now is nothing like Java, but it's a question of how you get
from there to here. When I started Scala I wrote what I'd write in Java. In
the first week I removed the semicolons. In the second week I started to use
function literals. Then I started using match/case. Later I found out about
for/yield with futures. And so on. I learnt the language at my job, and I was
delivering real, user-facing features in it from day 1. I don't think I
could've done the same with Clojure.

(Reasonable people can disagree on syntax; I find that Scala's lets you get
very close to the language of the domain (e.g. see the Spray "routing DSL")
and that's worth the cost it imposes on the macro system)

------
abalone
Dropwizard is where it's at right now for Java frameworks. It's a superproject
that glues together the best pieces out there. Surprised it wasn't on the
wikipedia list.

Which brings up another point: if we're talking about web frameworks for the
next decade we should really be looking at service-oriented architectures /
single-page apps or whatever you want to call that model. It's quite different
from the web frameworks of yesteryear that generated UI on the server.
Dropwizard can do web views but it really positions itself as a REST service
framework.

So, that brings javascript frameworks into the consideration. And the author
has a paragraph where he just dismisses it as a "terrible hack"...??? I think
that is going to seriously hamper the outcome here. It's good that modern web
apps leverage the power of the browser and JS frameworks are the way to do
that.

~~~
hackerboos
>Dropwizard can do web views but it really positions itself as a REST service
framework.

That would eliminate it for me.

Not everyone is coding APIs and fat client web apps. I'd prefer a framework
geared up to do standard web apps as well.

~~~
abalone
That may be what you want right now but the article is about something that
will last 10 years. And what constitutes a "standard web app" is definitely
shifting and will likely solidify over that time. "Fat client" isn't really
the best term for it, because the client code is usually pretty lightweight.
I'd say "modern web app".

I'd be including a consideration of AngularJS, Backbone, Ember etc. + a
service-oriented backend framework like Dropwizard. That's also incidentally
how you'd architect your backend support a native mobile client, which is a
good thing to prepare for even if you think you only need an HTML frontend
right now.

~~~
brianchu
The "cutting-edge" web frameworks that _already exist_ today are the fat
client frameworks you describe (client-side rendering). The web frameworks _of
the future_ will have robust server-side _and_ client-side rendering, in my
opinion. We're already seeing a little bit of this with Airbnb and Rendr for
Backbone, React, and Twitter's web app, but it's not quite there.

------
shaunol
FTA: "I still haven’t forgiven Microsoft for their countless misdeeds so
Asp/C#/F# are all right out. That may be shooting myself in the foot here (cut
off my nose to spite my face), but contributing to this decision is that I
work exclusively with linux (both on desktops, laptops and servers) so the MS
ecosystem has become totally unfamiliar to me and I don’t like running windows
on servers (though, of course there are some workarounds possible here and
Mono is quite good). So, the L in my LAMP is firmly established. And besides,
I don’t have a lawyer on the payroll to make sure that my licenses are all
read, ok’d and acceptable."

I really think the author is missing out here - for the sake of just sticking
with what they know and not wanting to do any actual research, it's impossible
to come up with an actual objective choice. So misinformed, I get that .NET/C#
development is not everybody's cup of tea but I think it's crazy to title an
article "Choosing a Web Framework/Language Combo for the Next Decade" without
even evaluating an extremely popular option due to simple disinterest. The
lawyer comment is just irrational fear (and I get is probably meant to be a
bit of a gibe towards Microsoft's licensing schemes), unless you're writing
something completely from scratch, you need to be aware of the licenses of ANY
library/framework you depend on, even if they're free.

------
jhuckestein
FWIW, I'd remove GWT from consideration. I heard that it's shortlisted for
end-of-life at Google because it's a hassle to work with.

Anecdotally, I agree with that. I once built a product on GWT because it
impressed me so much on paper. Static typing, compiling permutations of your
app and loading only what's needed, optimization of stylesheets, rendering
only on the client etc. It seemed perfect. IIRC the two main issues at the
time, a few years ago, were a) terribly slow tooling for any decent sized app
and b) the usual interface-hell of Java. This may not be a problem if you're
used to it, but for me it was an issue.

~~~
jacquesm
Wow. That's going to piss off quite a few people if google EOL's GWT and they
know about it today but are not communicating it to the outside world.

Google has a habit of pushing tech out for people to build on and then pulling
the rug right out from under them.

A citation would really help here but 'I heard' makes me realize that will
probably not be forthcoming.

~~~
stephen
I know the Google GWT manager, and unless he's playing his cards very close to
his chest, GWT is not EOL'd inside of Google.

Google did "re-open source" GWT a few years ago, and unfortunately it
coincided their (AFAIK unrelated) closing of their Atlanta office (where most
of the old GWT team worked).

So, it gave the impression of washing their hands of it, but in reality they
a) staffed their GWT team back up to 4-5 people, and b) the open source model
is much healthier for the project anyway.

(Previously the master GWT SCM has literally Google's internal Perforce/etc.
repository, so any patches from external contributors had to be fostered by a
Googler that cared about your issue, which made it really hard/impossible to
have an external community of committers.)

~~~
jacquesm
I think it will be a long long time before the tech community will forget
about wave, that makes rumours like these so credible.

------
cabalamat
> Python has always been a mixed bag for me. What I wrote in it worked, when I
> wrote it. Then, a little while later it stops working, either because some
> module that it depends on gets deprecated or changed in an incompatible way,
> starts to exhibit weird behavior or even disappears.

This is no longer a problem in Python because of virtualenv and pip, which
together allow you to tie down the version numbers of all the dependencies an
application uses.

------
phpnode
I'm also a bit frustrated with the Yii situation, although I do understand why
they're doing it. Yii 2.0 is a total rewrite, and it is technically very
impressive. However they have had the disadvantage of not being able to ship
until it reaches feature parity with 1.1 which has been a huge undertaking.

The lead developer, Qiang, is literally the second most active developer on
github[0], so it's not like they're not trying - the guy is currently on a
370+ day streak - it has taken a huge amount of effort for them to get to this
stage.

I would personally build on the beta at this point because I have a lot of
faith in the core team and they've had a lot of time to iron out any major
problems, at this stage any changes are likely to be quite minor or fixes, so
the real release will probably ship before your new project does.

Kohana seems dead and CakePHP has historically been rather slow and ungainly.

The lack of library support for Lua is a bit annoying, but it's getting better
and can possibly be mitigated by using Lua's FFI to talk to C. If the eco-
system was a bit more mature OpenResty[1] would be pretty compelling.

0\.
[https://gist.github.com/paulmillr/2657075](https://gist.github.com/paulmillr/2657075)
1\. [http://openresty.org/](http://openresty.org/)

~~~
girvo
Kohana has died as far as I'm concerned. Such a shame, but it was a great
replacement for CodeIgniter back in the day. CakePHP tried to hard to be Rails
and messed it up, and I've never forgiven it, and it was horribly slow in my
benchmarking.

Out of PHP frameworks, I would rule out anything that doesn't use Composer. If
you can't use the best bit of tooling PHP has gained lately (other than HHVM)
and are stuck copying libraries in by hand, well if you want it to survive
then you've made the wrong decision IMO.

Personally, I would pick either Symfony or Laravel, the latter for development
speed, the former for robustness and power (and explicitness, I'm working on a
400k line web app in Laravel which has had too many shit developers hacking on
it over the last 12 months, and we get bitten by magic weekly because a long
since fired or quit dev worked _against_ the framework rather than with it).

~~~
noir_lord
400kloc on Laravel, holy shit snacks what the hell does it do?

I just cloc'd my projects root and including laravel and some dependencies
(/vendor) that's 295,000loc).

~~~
girvo
Far, far too much. :'(

It's a corporate real estate web app, client facing and internal all in the
one big app, so they can run their business (taking on a MASSIVE incumbent in
the industry) all from the one bit of software. Has nearly 100kloc in an
Angular front end, too. Huge bastard that I inherited two months ago, and have
finally got it to a state where we can hand it over to the clients internal
team. Easily the most challenging project I've tackled thus far in my career,
but I managed to do it (with the help of two other awesome developers)!

------
david927
To me, the most interesting thing about this post is that there is no clear
answer. We're mired in, frankly, a lot of junk. There's no winner because
nothing is really very good.

~~~
grayrest
If you arbitrarily reject everything unfamiliar then filter the remainder for
stability you wind up with unremarkable stuff that will get the job done.
There are better ways to write web apps but you're not going to find them
following the process outlined in the post.

~~~
jacquesm
Boring unremarkable stuff that gets the job done sounds great to me. Sexy,
new, hot, flashy are exactly what I'm trying to avoid getting sucked in to
(though, believe me I can feel the draw).

The life-cycle of the software underpinning what I build is as important or
even more important than whether or not it is 'the best way' to do something
today. Because that best way is the bleeding edge and the day after tomorrow
(or even tomorrow) that will be something else.

I don't have the manpower nor the interest and time to keep rebuilding the
stuff I put out there.

~~~
goldfeld
I was really drawn to the title of your post because that's just what I have
done--well, over the last few months--and I went with Clojure. I want to
absolutely focus now and I can see the momentum is gonna take me for at least
the next 10 years. I never rode the Rails train and after becoming a
functional programming believer I'm kinda glad I didn't in retrospect, but I
had always been envious of people who did make that decision to become _good_
at a stack. I agree with you that the error exploding in Clojure is not nice,
but to me it makes up for it in being on top of both Java and JavaScript
(having been a JS dev previously, but being entirely tired of the convulsion
of frameworks and build tools and module systems.)

It's a lisp that, as opposed to Lisp and Scheme, is not fragmented and seems
to have mostly a healthy, united community. I see amazingly smart people, and
so many of them, pushing Clojure forward (Rich Hickey, Stuart Sierra, David
Nolen, Chas Emerick to name a few) and yet it's more approachable than
Haskell. And I think these people will eventually find good, standardized
solutions for things like the awfully ugly stacktraces.

Clojure doesn't really have a 'framework', and I like it that it's really
composable in that sense. But things like Ring and Compojure are lightweight
no-brainers, much like Rails is a heavyweight no-brainer for Ruby. What I want
to say is, unlike JavaScript, after having picked Clojure as the language, the
choice of everything else is mostly always a no-brainer (e.g. leiningen,
core.async, enlive/hiccup, maybe Om soon.) And that really pleases my choice-
avert brain.

~~~
jacquesm
Another well reasoned upvote for clojure then. Tempting to put it back in,
I've already played with it quite a bit, wrote some toy programs in it.

Thank you!

~~~
goldfeld
Most welcome! I wrote that wall of text more in wanting to get my reasons out
of my head, like you did, than in trying to wrestle you over to my side of the
field. But if you want to be really tempted now, reconsider, like someone else
commented here, the importance of concurrency and persistent data structures
for web development going forward. Even for a one-man team (such as I plan to
be, and actually one of my side-projects in Clojure has to do with language
learning and SRS, would love to keep up with what you end up doing.) It means
you can handle traffic spikes and trace errors as a one-man operation much
more easily than if you had stateful bugs and failures to deal with.

------
gexla
Might as well go with the one which sparked the wave which inspired most of
these.

Rails is pretty much the premier MVC framework. If you are going to go MVC, go
with Rails. If we are looking for an alternative to Rails, then we are
probably looking for an alternative to MVC, and none of these mentioned
choices fit the bill.

I wonder when the day will come that we finally get sick of recreating all the
libraries that typically go into an MVC framework. That day, Rails will still
be going strong and we will probably give up and just go with Rails.

Of all the choices mentioned, not many have been around as long as Rails. For
every day that Rails survives, the stronger it becomes. The more likely it
will continue while the alternatives shrivel.

One day MVC may become obsolete, but some people might still want to use an
MVC framework for whatever reason. That day, Rails will be there waiting for
you.

Years ago, I watched the video on how to build a blog in 10(?) minutes. Today,
I can still somewhat follow that video. With many of the MVC frameworks in
this list, you couldn't do that. ZF1 is not ZF2 for example. The framework was
completely changed. They might as well call ZF2 by a different name. If it
were called anything more interesting than "Zend Framework" then maybe it
would have a different name.

Go is interesting, but the MVC web framework ecosystem has to be created, just
like we did for Node. I don't even know if that will happen anytime, or ever.
Maybe people are getting sick of doing that. And then you need to wait X years
to see if something actually has any lasting power.

Screw it, just go with Rails.

Or Django. ;)

~~~
BSousa
For all the mentions of MVC in your post, you should probably realize that
Rails isn't really MVC. Some of the new JS frameworks are actually MVC, but
Rails it is not. (Rails is more Model2:
[http://en.wikipedia.org/wiki/Model2](http://en.wikipedia.org/wiki/Model2)
than true MVC).

~~~
gexla
Right, but it's a close enough match to meet his requirements.

ETA: A blue collar match as opposed to an academic match. ;)

------
arethuza
Interesting views on Python - I decided to start using it for personal
projects after trying Go for a bit. Initially I _hated_ the significant
whitespace, and indeed many other things, but I stuck with it and I find it
all rather elegant - I certainly haven't noticed any huge problems with
dependencies but I've probably stuck with pretty mainstream ones (e.g.
Requests).

I now rather like significant whitespace and often find myself considering
that my ideal language would probably be half way between Python and Lisp.

~~~
pmontra
I had enough syntax errors appearing after a copy and paste that ended up with
difficult to spot unaligned code that I decided to use Python only for little
scripts and when I'm forced to use it and nothing else would do. The problem
with Python is that editors don't have hints to autoalign the code for us.
Same problem with templating languages like HAML and Slim which, oh the irony,
were born for Rails. Nevertheless many people like Python and it's growing
strong (maybe stronger as system/desktop language than for the web) so those
problems of mine are not as big as I feel they are. But how do you survive to
them or make them not happen? I'm sincerely interested.

~~~
arethuza
I must admit that I only really took to Python once I got IDE support
(initially in Visual Studio with PVTS and for the last while with PyCharm).

I'm _very_ happy with PyCharm.

~~~
nls
Exactly, use PyCharm for auto-identing and this is no longer an issue. For
shells, you can use bpython or IPython to the same effect.

------
yawn
I create a new personal web project around 3 times a year, and go through this
exercise each time. I am still not happy with the choices out there. The last
couple of times I have settled on Python/Flask.

The dismissal of Python and not Ruby over arguments of slowness of execution
and dependency issues seems backwards to me.

The main reason I choose Python is because I can jump into a codebase that is
years old and immediately understand what the code is doing. Brevity and
readability trump just about everything else for me. I also like the pluggable
nature of the Flask ecosystem.

------
bsaul
I've been in a quest for my favorite web server technology as well for the
last 2 years, so this definitely rings a bell. I pretty much agree with
evertyhing the author said, except for one :

Dismissing python due to maintenance difficulties and not Ruby seems weird.
Both are highly dynamic languages with not much help from static analysis, and
this is for me the reason why maintenance may be hard.

The fact that whitespace was an issue to OP probably means he never used
PyCharm. I haven't had any single syntax issue since I started using this IDE.

~~~
thatthatis
I had the same knee jerk and even a bit further: ruby seems to embrace the "go
fast and break things" philosophy much more than python.

~~~
jacquesm
That is quite possibly true but I've never even written a line in ruby so I'm
unfamiliar with this. Thanks for the warning!

------
smoyer
Being a Java/JVM expert, I wanted to add a couple of thoughts to your process.
I'm not insinuating that you should change anything you've done!

\- Dropping JBoss Seam as a framework was a good choice because the important
parts of Seam have been added to the JavaEE system, which provides an end-to-
end set of technology specifications. If you choose to run a Java Application
Server (such as JBoss EAP, Glassfish or Wildfly), then the server will support
the full set of specifications, but you don't have to use them. Since
JavaServer Faces (JSF) is one of those specification, I'm not really surprised
you hadn't heard of it ... it's essentially JSP with lifecycle control and
data-binding.

\- GWT is indeed a Java technology, but it produces client-side code. For big
projects, I generally use GWT with Bootstrap to generate the client. It
compiles into Javascript producing several versions optimized for different
browser groups. Using Martin Fowler's Passive View pattern, it's easy to write
fast tests for your client-side business logic, and since it's typesafe, you
get compiler errors before the compilation to Javascript instead of the run-
time errors you often see when writing in Javascript (or Coffeescript). Since
I generally write the back-end for a generic JavaEE server, I also tend to use
REST calls from GWT to an Application Server for client-server communication.

\- If you're looking for an ORM, none of the Java frameworks will include one
directly, but it should be pluggable. When people talk about Java web
frameworks, they're often constrained to just the "View" tier. Spring provides
a much more full-featured stack (with DI and JPA) and is more analogous to
JavaEE as a whole. I think you should consider those two as the full-stack
contenders in Java. You can add GWT onto either if you need a client-side Java
technology (I'm sure you'd NEVER use Java Applets for the client side right?).

\- I happen to like Scala and appreciate how purely it seems to add a syntax
to Lambda calculus. Martin Odersky's "Principles of Functional Programming in
Scala" on Coursera was a great class, but I'm hoping the Scala IDE advances
quickly. I'll admit I've never written production software in Scala (or using
WAVE) but I also admire one project that's using it successfully
([https://github.com/takezoe/gitbucket](https://github.com/takezoe/gitbucket)).

~~~
jacquesm
Super comment, thanks a ton, I will update the post at some point after this
thread has cooled down a bit and I will definitely use your input.

~~~
smoyer
You're welcome ... I'm happy to see someone looking at this question from a
pragmatic stand-point. The continuity of libraries and frameworks and the
"usefulness" of a language are _IMPORTANT_ but usually these trade-offs are
discounted versus "coolness" by those comparing the frameworks. If you're
focusing on getting something accomplished, chasing every new and improved
library, framework and architectural pattern only does one thing - it keeps
you from ever delving deeply enough into one technology stack to truly become
an expert. Pragmatism and zealotry don't mix.

I should have also stated in my comment above that I almost gave up on
Enterprise Java back in the J2EE 1.4 days (2005-2007 if I recall correctly).
When you have to create multiple Java files for every EJB (mostly Entity and
Stateless Session beans) and edit XML deployment descriptors (many times one
deployment descriptor for each supported application server), Java programming
feels as tedious as many people describe.

The contrast with JavaEE 6/7 is amazing - the technologies that are
encompassed in each of the specifications tend to follow the same pattern.
Write a POJO and add annotations. For instance, if you need a business method
that consumes messages from a message queue and processes them, that's one
(short) Java file with some annotations. For a more complicated example, if
you have a database table and want to expose the records via a RESTful
interface, here's what you'd have to write six (small) files as follows:

\- One entity bean with fields annotated for the ORM as well as accessors and
mutators.

\- One stateless session bean with your business methods - in this case
providing CRUD operations against the entity bean (using a PersistenceContext
from JPA)

\- One JAX-RS annotated class to provide the RESTful API's methods (again an
annotated POJO).

\- One Application class (with very few lines of code - it activates JAX-RS).

\- One persistence.xml file to define a datasource.

\- One (empty) beans.xml file to activate CDI.

If you stick with the JavaEE annotations and configuration files, there are
some real benefits to this structure:

\- The ORM's entities and configuration are database agnostic ... the same WAR
file could be deployed against your MySQL servers, Oracle (for those who have
money to burn) or PostgreSQL.

\- The application will run on any JavaEE compliant application server. Deploy
the file to Glassfish, Wildfly, JBoss EAP or even WebLogic (for those who have
money to burn).

\- The ORM will cache entities (and can be configured to use a second-level
cache when it's prudent). When you start caching database rows, you have to be
careful and there may be tuning involved.

\- The Application Server will create pools of each of the objects that will
be used so that it's not creating and destroying objects over and over again.
This is a huge performance gain for servers with a lot of request-scoped web
transactions that use stateless session beans for business logic.

There are also ways to create enterprise Java applications that are a little
more light-weight (though today's Application Servers have lost a lot of their
girth). If you simply use a servlet container you can still use JSF which has
a better templating engine that JSP. You can add CDI by including the library
and a little bit of bootstrap code. Application servers like Apache TommEE
start with Tomcat and add libraries as needed.

It also occurs to me that the "experimental phase" you're embarking on could
be leveraged to be both crowd-sourced and open-source. Since you're starting
from scratch with each of these technologies, wouldn't it be interesting to
have a complete newbie and an expert produce the same application using each
of the surviving frameworks?

If you publish a light-weight specification for your test project and open a
Github project with each framework's implementation in a sub-directory, I'd be
really curious to see what efficiencies and problems were experienced with
each implementation. It would also give you a way of comparing your
implementations to others.

------
vidarh
I'm very curious how the Google searches were done. I get 2.5 million results
for "ruby sinatra" on Google vs. 5160 in the article. The numbers I get for
"ruby rails" are similarly much higher. So clearly he must be searching for
something else. Even "ruby sinatra framework" gets 388,000 for me.

------
adrianhoward
Choosing a framework/language for the next ten years sounds like a fools
errand to me. Both because what "best" is changes much, much more rapidly than
that - and because I'd pick different frameworks depending on the team and
project.

Starting at the framework end doesn't help me much. Instead I go with the
people I have for the project and the things I want to do/validate - and start
looking for what gets me progress as quickly as possible.

~~~
mercer
Indeed. Picking a framework/language for the next ten years at this particular
time feels a bit like picking the best horse and cart just as the automobile
is getting popular.

It's an exaggeration, of course, but the fact that we're undergoing some big
changes in web development (more on the client-side with server-side api)
makes me thing this might not be the best moment to think of picking something
for the next ten years.

------
fenguin
"JavaScript web frameworks seem to have a half-life of about 6 months..."

Express [1] has been the dominant framework for Node.js since 2009-2010. What
frameworks are you talking about?

[1]
[https://github.com/visionmedia/express](https://github.com/visionmedia/express)

~~~
camus2
I wouldnt consider Express as a framework.

It's just a router and a few middleware. Hapi or Actionhero are frameworks
though rest ones.Express is definetly not a framework,it doesnt do anything
much.

Writing Spring like, Symfony like frameworks is hard in nodejs. Libs are
bad,often tightly coupled,and frankly nobody's maintaining nothing on the long
run.

~~~
sehr
> Express is definetly not a framework,it doesnt do anything much.

Consider that your definition of a framework may be different from others.

~~~
SEMW
jaquesm's requirements, per the linked article, are that " _Sessions,
authentication, routing, internationalization, MVC, caching, mobile,
templating, ORM and so on should preferably all be part of the deal, so
batteries included please_ ". GP's comment was presumably made with that
context in mind. Arguing for Express on the grounds that the word 'framework'
doesn't imply those those things doesn't invalidate his requirements -
definitions aside, Express clearly doesn't satisfy them.

------
higherpurpose
Google could give a huge boost in confidence in Go, _tomorrow_ (or rather
within 2 years) - just make Go the official main language to use for writing
Android apps and start deprecating Java.

Once it does that, I don't think there will be any doubt in anyone's mind that
Go has less chance of survival than say Java. In fact, Java will immediately
_lose_ confidence once Android drops Java (in a reasonable 3-5 year
timeframe).

~~~
jacquesm
Are you suggesting that the Go language would be retargeted to the VM?

Or that Android apps would be compiled into binaries executed without a VM?

Either way, fascinating idea, and it would be a good way to settle the
Google/Oracle dispute once and for all. If they choose the second path
(security will be a huge concern) they might even pick up a nice speed boost
too.

~~~
zmmmmm
I've secretly hoped Google would be going down this path for a long time but
sadly no evidence of it.

> Or that Android apps would be compiled into binaries executed without a VM?

What I imagine in my Android-Go-fantasy is something like NaCl - your code
compiles to native code, but a subset of provably safe native code ... so sort
of a best of both worlds.

------
porker
The other consideration needs to be "How did this mature framework evolve?".

Symfony dumped all symfony1 users up s __* creek when Symfony2 came out; Zend
framework 2 is an entirely different beast to ZF1...

Are these mature frameworks any more stable than the new ones, or are they new
frameworks, phoenix-like in assuming the name of the old one?

~~~
timdev2
As far as those two frameworks, it's mostly about retaining brand recognition.

On the other hand, major version releases are when you make such dramatic
departures from what's come before. At least in ZF, they got a lot a lot of
things more-right.

I moved a (pretty complex, line-of-business transactional-type) project from
ZF1 -> ZF2, and I'm happy I did. Some things changed a lot (dispatch, routing,
forms), while other things were very easy to translate (caching, logging,
etc).

In that case, most of the business logic was built around Doctrine2,
encapsulated nicely into service classes, and therefore fairly framework-
agnostic.

~~~
porker
With the OP looking for a framework where he doesn't have to rewrite the code
every few years (or more frequently, hello Drupal), major version upgrades
matter.

I'm glad that transitioning your project from ZF1 to ZF2 was worth the effort
and relatively easy. I have a number of clients still on symfony 1.4 because
although unsupported and a 'dead' system, without a straightforward migration
path to Symfony2 it doesn't make economic sense for them to do so - not when
the whole web system (CMS, order management, the rest) is written using
symfony 1.4 and Doctrine 1.2. Until it stops working, as it's going to be a
new build either way.

I think that kind of framework dead-ending is fairly irresponsible; certainly
some of my clients thought I was irresponsible to have chosen Symfony when
their 1-2 year old systems needed to be rewritten...

------
awestroke
TL;DR: using exclusively prejudices and unsupported blanket statements to
choose a language/framework combo

------
Joeboy
My colleagues and I went through more or less this exercise in 2005 and ended
up with Python/Django. I know everybody tends to become a crusader for their
development stack, but I think this was a fantastic decision, either by luck
or judgement.

To be honest I still don't see any compelling reason to switch to anything
else in 2014, but if I was looking I'd be strongly favouring Go as the
language, as it seems like the preeminent forward-looking, popular-ish, well-
supported language. Rust and Erlang would also get a look in.

~~~
mtbcoder
I agree and we also went through a similar process at work (although a few
years later than you), couldn't be happier with Python and Django.

Although looking forward, I have a strong feeling that HHVM/Hack will become
one of the darling platforms given the amount of resources Facebook has and
the poor state of performance many PHP frameworks are currently in.

------
JonoBB
If you are still considering PHP frameworks, then your choices are really
Symfony or Laravel (maybe Zend at a stretch).

Yes, Laravel does have a high "bus factor", but for me personally its the
number one choice in terms of ecosystem, features, support and community,

~~~
radio4fan
Laravel isn't going away, even if Taylor gets hit by a bus.

There's a huge and active Laravel community, it's just that Taylor is the
benevolent dictator.

If Taylor _was_ hit by a bus, there would be plenty of others who would be
willing and capable to take up the baton.

Seems to me pretty remarkable to rule out Laravel on this basis, yet keep
CakePHP, ignoring all its other flaws.

~~~
jacquesm
Excellent input, thank you!

~~~
citricsquid
fwiw
[http://www.google.com/trends/explore#q=Laravel%2C%20symfony%...](http://www.google.com/trends/explore#q=Laravel%2C%20symfony%2C%20cakephp%2C%20kohana)

~~~
kiksy
Updated to include Symfony2:

[http://www.google.com/trends/explore#q=Laravel%2C%20symfony%...](http://www.google.com/trends/explore#q=Laravel%2C%20symfony%2C%20cakephp%2C%20kohana%2C%20symfony2&cmpt=q)

------
pron
I think another question is how much you want done on the server (HTML
rendering?) and how much on the client. It seems like we're definitely moving
towards having the client handle all the UI. I understand this may not be
appealing, especially as client side frameworks have even a shorter lifespan
than server-side frameworks, but that seems to be the direction. If that's
acceptable, for the backend I'd choose Java and Dropwizard (or Jersey+Jetty
instead of Dropwizard). Spring Boot also seems nice. I discuss the state of
modern Java web development in a non-comprehensive recent blog post[1]. For a
more complete discussion of JVM web frameworks, you can take a look at this[2]
and this[3].

[1]: [http://blog.paralleluniverse.co/2014/05/15/modern-java-
pt3/](http://blog.paralleluniverse.co/2014/05/15/modern-java-pt3/)

[2]: [http://zeroturnaround.com/rebellabs/the-curious-coders-
java-...](http://zeroturnaround.com/rebellabs/the-curious-coders-java-web-
frameworks-comparison-spring-mvc-grails-vaadin-gwt-wicket-play-struts-and-
jsf/)

[3]:
[https://www.youtube.com/watch?v=ygW8fJVlDxQ](https://www.youtube.com/watch?v=ygW8fJVlDxQ)

------
wiradikusuma
Hi jacquesm, if you're reading this..

I recommend that you take a second look at Scala. Considering that you "have a
working knowledge of Java (but really don’t like it)", I think Scala is a good
choice.

The usual cliche-but-true reasons:

A. It runs on the JVM, arguably the most performant VM.

B. It has mature, huge (Java) ecosystems. High quality IDEs, rich (3rd party)
libraries, a plethora of build tools (for better or worse) and profilers.

But for me personally, the things I like about it:

1\. I can use different languages (as long as it runs on the JVM, obviously)
for different needs. Probably not wise to mix a dozen languages
([http://en.wikipedia.org/wiki/List_of_JVM_languages](http://en.wikipedia.org/wiki/List_of_JVM_languages))
in a project, but at least I have a choice.

2\. Since I'm a Java developer during the day, I can reuse my skills (can use
same framework, same debugging approach, same build system).

3\. I can start coding with Java/imperative style. When I started learning
Scala, I literally coded like in Java, minus the semi-colons. Over the time, I
enhance my coding style because I keep thinking, "There's gotta be a better
way of doing this." At least this lowers my barrier to learn Scala.

EDIT: IntelliJ allows you to copy Java code and paste it as Scala.

Obviously you can replace "Scala" with "any JVM language other than Java", but
I have my specific reasons in choosing Scala (over, say, Clojure).

------
netcan
Since the exercise is framed this way (for the next decade), It might by
interesting to try it from the perspective of 2004. IE, if you made a decision
this way in 2004, how wrong/right would it have been now that the decade is
over?

~~~
collyw
We would all be writing Java applets, no?

~~~
rubinelli
Java applets were already dead by then. The new hotness was JSF + Hibernate,
and ASP.Net WebForms on the Microsoft side.

------
espeed
A few years back I went through a the same process.

My criteria differed somewhat, but the gist was the same -- maximize your
investment, position yourself well, and as Wayne Gretzky would say, "Skate to
where the puck is going."

I'm in a rush to be somewhere, but here's a quick rundown of my key criteria
for a 10-year language:

    
    
      1. Concurrency Model (we're in a multicore world)
      2. Data Processing (data is driving everything)
      3. Platform (cloud platforms are the new OS)
    

Python, Clojure, and Go are my top three.

Python for its practicality, massive library in general and also in the data
processing/data science space.

Clojure because of its concurrency model, first-class Java interop and thus
massive library, plus its simple elegance and limitless potential appeals to
the painter in me.

Go for its concurrency model on top of being a well-designed systems language
that's backed by Google. I think Go is going to be _the_ language to emerge as
the dominant player in the next 10 years.

All three languages work on App Engine, and Google's Cloud offering is another
one of those "skate to where the puck is going" things. It's already the most
technically advanced cloud, and you can see signs that it's about to catch a
Google-fueled hockey stick and blow past AWS at an exponential pace.

Honorable Mention: Scala.

Scala is in use by big companies like Twitter and LinkedIn, and it's the code
behind some of the key open-source systems like Spark, Finagle, and Kafka. And
Spark's the data-processing skate-puck destination: Cloudera is adopting it,
and the days running up to the Hadoop eclipse keep growing shorter so I
suspect Scala and I will keep crossing paths as these tools continue to make
the rounds.

------
falcolas
This is incendiary advice, but if you've dropped Python due to breaking
changes as you update it, you may also want to consider dropping Rails. I say
this because the perception is that the Rails development goal is to stay with
the bleeding edge of web development first, and support backwards
compatibility second.

------
acesubido
Coming from years of .NET, a year spent with Grails and now 4 months into
'Ruby-land'. If there was a way to vote, I'd vote Rails/Ruby just Rails/Ruby
isn't cool anymore, everyone moved onto NodeJS/Scala or wherever. I'm only
going by experience, and I haven't been deeply involved yet.

It's a good thing. By the looks of it, the community might be jaded in some
way, which means no more running around trying to be the coolest /fastest kid
in the block, mostly everyone just wants to get stuff done. The amount of
useful gems and well-maintained libraries (years of being maintained, not just
a few months) is amazing.

The language matured enough, and the ecosystem along with it. The ecosystem
still has some flaws and voids here and there, but that's what makes it
exciting in being part of it.

~~~
rubinelli
What made you move away from Grails? I understand the community is an order of
magnitude smaller, but I've been experimenting with it recently, and it looks
very solid.

------
davidw
> TCL is not really web suitable (though it’s been done)

I don't use Tcl (not TCL!) anymore myself, but it'd be more honest to say that
it's not that popular these days or not a language you happen to like. This is
built with Tcl just fine:

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

With that out of the way, I think that was a good read, and a reasonable
process. It's fair to be a bit subjective about some things, because... we're
humans, and that's the way we are.

Personally, I use Rails as my go-to framework because while it's not super
fast, it's very, very full of useful things to get up and running quickly, and
keep iterating once things are built.

~~~
zimpenfish
AOL ran on AOLServer[1][2] (TCL + embedded C bits) for many years, I believe,
quite happily.

[1] [http://www.aolserver.com](http://www.aolserver.com) [2]
[http://philip.greenspun.com/wtr/aolserver/introduction-1.htm...](http://philip.greenspun.com/wtr/aolserver/introduction-1.html)

~~~
davidw
Yes, I was going to mention that too - it's a bit ironic saying that Tcl (
_not_ TCL!) is not ok for the web when it was used for some of the first
serious dynamic content web systems.

~~~
jacquesm
I thought I wrote 'modern web'. I'll update if I got that wrong, and I'll
update the spelling too.

Edit: good catch David, I used modern web in one instance and 'web' in two
others. Changed that to be consistent. TcL now properly spelled. Have a well
deserved upvote :)

~~~
davidw
> TcL now properly spelled

The l is a small l. Kind of like Fortran vs FORTRAN or Cobol vs COBOL or Perl
vs PERL. Tcl people prefer Tcl.

I actually think Tcl would be fine for the modern web (it had an event loop
before it was cool to have an event loop), but you could easily eliminate it
for many of the reasons you eliminate other things - not too many people
working on it, not as many ready-made components as something like Rails, and
so on.

~~~
jacquesm
Two typos in three letters, that's got to be some kind of a record. Holding
out for 3. Changed and deployed, thanks once more. And Tcl wasn't going to get
back in on other grounds so at least it won't require me to re-write a major
chunk of the post.

------
dham
I did this a year or so ago. Arrived at Rails. Close contender was Laravel.
Rails won because of:

1\. A awesome ORM 2\. I could use Ruby for iOS applications(Rubymotion). 3\.
JRuby 4\. Great for writing scripts and little one off things I needed to do.
5\. Capistrano (although you can use this with any language) 6\. Opal(although
this really hasn't taken off yet). 7\. People are actively trying to speed the
language up. MRI, JRuby, Rubinius.

So I invested in Rails because of the other things I could do with Ruby in
addition to web.

------
izietto
Lua over Nginx (aka. Openresty) tempts me, Lapis [1] is really exciting

[1] [http://leafo.net/lapis](http://leafo.net/lapis)

~~~
herm
I'm interested lapis as well, I think this might finally be what I have been
looking for...

------
johncip
I can't follow Jacques' reasoning when it comes to any of this. His first
choice would have been a PHP framework (in 2014!), yet he goes on to criticize
a bunch of languages which have sane == operators seemingly on the basis of
his gut reaction to their very existence, while asserting things like "Python
is like driving on the autobahn without guard rails" and "Lua is the sweet
spot between Ruby and Python." That might be true if Python had shipped with
exactly two data structures, and Ruby with zero, and neither of them had
integers.

This is all before the frameworks are even discussed, which are included and
dismissed for reasons just as arbitrary. Smaller frameworks like Sinatra are
discarded because they can't handle the complex logic that flash cards demand,
Django's out because of the whole auto safety thing, and we all know that
ExpressJS didn't show up at Jaques' birthday party that one time. Play's out
because Scala is unfamiliar, despite that not being a specific quality of
Scala and just something that's true in general of programming languages one
hasn't bothered to learn.

So the final list contains some more PHP horror shows and a few Java and Go
frameworks to make things look democratic. Thankfully, Rails makes an
appearance, but it feels like this is just because it was lucky enough not to
get hit by a dart.

Let it be a lesson -- we all procrastinate, but when you get to the point
where you're writing blog posts about dozens of languages and tools, none of
which you have direct experience with, the best thing is just to pick
something, do what you'd meant to do in the first place (although you will
note that writing the flash card app was itself a way to procrastinate on
learning Romainian), and discuss the pros and cons of the tools you chose once
you actually know what they are.

------
losvedir
I was a little surprised to see Gorilla get kicked out. My understanding is
that among Go developers, stdlib net/http + the Gorilla toolkit was the de
facto standard approach.

People are experimenting with new frameworks, e.g., beego, revel, martini,
etc, but I don't think _any_ of them are stable enough to meet your stringent
criteria in that regard.

It seems to me (as an outsider looking in) that the Go community is relatively
"anti-framework", instead preferring _libraries_ , like Gorilla, for special
oomph in routing or sessions or what have you.

I also think it's worth determining what you think the next decade's high
level architecture will be: JSON api backends with fancy JS frontends, or more
along the lines of standard Rails, Yii, etc? That will drastically change the
type of web framework to choose.

------
mgkimsal
"grails not written in java" \- was a bit disappointing to read this - it
mostly is (the spring base) and you can write pretty much all in java if you
want, although groovy lets you be a bit more concise for a (usually) small
speed penalty.

------
jbergens
It was a great article! Very nice to read about how someone else thinks when
making descisions. Regarding your choice I think you should look a little bit
more at javascript frameworks like Mithril and React, they can be used on the
server or on the client which holds many doors open for you. Mithril might
fall for your demands on previous usage and minimum age but it seems to get
web programming very close to other programming and is small enough that you
should be able to do maintenance of if yourself if you have to a few years
down the line.
[http://lhorie.github.io/mithril/](http://lhorie.github.io/mithril/)

------
tkubacki
I would consider Dartlang - "Dart is a new platform for scalable web app
engineering." is the title string on Dart's home page. Dart is designed for
web apps. One downside is it's still not as mature as alternatives.

------
nemasu
I love Kohana (for a PHP framework) ... too bad it's no longer being
developed.

~~~
jacquesm
Thank you for saving me some time. I missed that and thought Kohana was still
being supported, but I just checked and found this:
[http://forum.kohanaframework.org/discussion/12509/final-
rele...](http://forum.kohanaframework.org/discussion/12509/final-releases-of-
kohana-beginning-of-ohanzee/p1)

So you are absolutely right. Will drop it from the list to try and will update
the article.

~~~
nemasu
No problem, looking forward to the verdict. :)

------
quaffapint
I'm pretty sure that PHP Fat-Free number is wrong, but regardless after my
search for a framework that's the one I've been backing for the past many
months on a project.

It's actively developed (just follow the dev branch, which is quite stable)
and the devs/community have been quite helpful. I wanted something much
lighter than Laravel, but still have all the handy features, and that fit the
bill. Based on your requirement of sheer usage numbers though, I don't know if
it meets that (yet).

------
steder
I don't see the point in attempting to choose a language/framework for the
next decade. I would think that different languages and frameworks will be a
natural fit for specific applications and perhaps the reason the author is
struggling to make a decision is that he's attempting to make it based solely
on the abstract rather than a concrete application.

I'm not the only one who'd like people to choose frameworks and languages on
something other than gut feel and googlefight results, right?

~~~
jacquesm
I have a very concrete application in mind but want something that is
versatile enough that I can go and do another application without having to go
through the whole selection process again (and learn a bunch of new stuff on
top of that).

Of course specialization is optimal but as soon as you have to make multiple
things and your resources are limited then a general purpose tool is the
better choice.

Compare it with hammers. If I _only_ need to do metalworking I'd buy a bench
hammer. But if I need to do metalworking and woodwork then a clawhammer is
probably a better choice.

As for the selection process, this was just the preliminaries, it's far from
over and the next step will be a lot more work.

------
biokoda
Saying you are on your own figuring things out with Erlang is false. The
community on the erlang mailing list and IRC channel is extremely helpful,
especially for people starting out.

Finding Erlang programmers is admittedly more difficult, but finding someone
willing to learn Erlang is not too big of a problem. It's also not a big deal
to learn Erlang, because the language is simple.

As someone writing Erlang code for years, the good parts of using Erlang far
outweigh the bad parts.

~~~
Joeboy
> Finding Erlang programmers is admittedly more difficult

Presumably if you are an Erlang programmer, that is a plus point.

------
arthursilva
Python all the way.

And the part about Python code breaking due to external modules must be a
joke, right?! How hard is to specify a fixed version in the requirements.txt

------
epaga
This is an exciting read, kind of like Game of Thrones for web frameworks.

Re: why there were so many "PLAY!" results in Google, that would likely depend
on the query you use. Something like "play framework" would probably match for
any page where someone said "I will play with this framework".

...which is another reason why "Go" was such a bad idea for a language name,
BTW.

~~~
pmontra
I agree.

go: about 2,550,000,000 results. go language: about 3,630,000,000 results.
golang: about 1,950,000 results.

I wish the poster published the Google query strings he used because I get
very different results. Examples: gorest: 984,000 results vs 6580 in the post.
ruby on rails: 11,900,000 vs 258,000.

~~~
jacquesm
The google results should be easily reproducible, I simply used the exact same
query string for every framework, "{framework name} framework", going on the
assumption here that relatively speaking this will give an idea of how much
information there is out there on a given framework. Probably it would have
been better to use google trends for this using suitable criteria.

------
lazyjones
Rather than sloppily relying on hearsay, popularity and Googling, the
suitability of web frameworks could be tested in competitions like
[https://www.plat-forms.org](https://www.plat-forms.org) ... I wish more
people would participate there, the results are somewhat surprising (and of
course take into account the skill of the developers).

~~~
DennisP
Maybe people don't get involved because it's hard to figure out the results. I
see a graph labeled "team A, B, C..." and no key to which team is which. What
am I missing?

~~~
lazyjones
The website is bad indeed, it seems to be an understaffed academic project,
but the concept is worth imitating IMO.

------
olavgg
Grails is written in Java.

And while Grails today is a great servlet framework, Grails 3.0 will allow new
application profiles, like netty, hadoop and batch.

~~~
vorg
So it says in the over 1 year old rant on Grails 3.0
[http://grails.io/post/48599814766/more-on-where-next-for-
gra...](http://grails.io/post/48599814766/more-on-where-next-for-grails) but
it's very slow coming. Same with other Groovy ecosystem software like Groovy
which hasn't made a dent in it's new MOP, Antlr grammar, or Java 8 lambda
retrofit. And Gradle which still ships with Groovy 1.x.

------
syjer
What are the problems of spring license? It's a clear apache 2.0 license which
is quite used in the java world. (edit: ok, noticed that the wikipedia page
was wrong, I've corrected it)

Additionally, even though I'm not a fan of the following frameworks, but any
java web dev know about jsf (due to being pushed as the "standard enterprise
web framework") and vaadin.

~~~
ihaveqvestion
I was surprised too that he hadn't heard of JavaServer Faces, given that it's
the One Official Web Framework of Java. I'm not sure I'd recommend it
necessarily, but it's hugely popular and well-supported, so it knocks at least
a couple of his criteria right out of the park.

~~~
jacquesm
Spring license mistake noticed (on the WP page it reads 'springsource', not
apache 2.0!), as for JavaServer Faces, it may be extremely popular I just
never ran into it in actual use and I see quite a few companies every year.

Is it somehow associated with a branch of industry that I don't have exposure
to? Do you have some examples from the 100 top websites written using
JavaServer Faces?

That would help me to place it better.

~~~
syjer
From what I know, JSF is used mostly for small to medium intranet application
in the context of big enterprises.

I'm quite biased here, but the big seal of approval as the official java
enterprise web framework makes it often imposed by the upper layer of the
enterprise than a willing choice by the developers.

Additionally, if the enterprise is licensing a lot of oracle products, it's
not surprising if they have a ADF (adf is a jsf implementation and component
library) license with jdeveloper, which is trumpeted as the successor of
oracle forms.

------
lmm
I don't know what "MVC" means to this guy, but Wicket's approach is much, much
better than any other framework I've used; you build your web pages out of
objects, your component hierarchies out of object hierarchies, with actual
encapsulation, reusability and composability. If that's not MVC then I don't
want to be MVC.

~~~
jacquesm
Hi, I'm 'that guy'.

[http://en.wikipedia.org/wiki/Comparison_of_web_application_f...](http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks)
has a big fat 'no, modular event driven' in the 'supports MVC' column.

~~~
lmm
Well, I guess the question then becomes: what does MVC mean to that Wikipedia
editor? And what is it you want to be able to do that you're trying to figure
out by reading that column?

Once again, Wicket's approach is head and shoulders above every other web
framework I've ever used. It's good enough to make me not mind using Java (I
dearly wish I could find a framework with the same level of encapsulation in
other languages). I urge you to examine it more closely rather than dismissing
it based on this one line.

~~~
jacquesm
Ok, point taken, I'll add Wicket back in. This thread is a goldmine of good
information so far, I spent a full 2 days researching all this and it would
have been absolutely impossible to evaluate all framework/language combos by
writing a test app so I had to take some shortcuts. Apparently that caused a
good framework to be thrown under the bus for all the wrong reasons so I'll
revive it and we'll see how it does in the real world. Thank you!

~~~
pron
Haven't used Wicket, but this is what a good web framework comparison had to
say about it[1]:

 _With its clear MVC model, clean HTML and a wicked component module, you can
create new applications with reusable components quick and easy. Wicket does
use a model inheritance for it’s components, which isn’t great due to a bit
steeper learning curve.

The existence of markup files for every component gives you a clear separation
of concerns between the controller deciding what to display and the view that
specifies how to display. This not only reduces development time but also
gives your web designers the confidence to modify the HTML code without
worrying about crashing and destroying everything._

[1]: [http://zeroturnaround.com/rebellabs/the-curious-coders-
java-...](http://zeroturnaround.com/rebellabs/the-curious-coders-java-web-
frameworks-comparison-spring-mvc-grails-vaadin-gwt-wicket-play-struts-and-
jsf/)

------
davedx
Spring is included in the end shortlist, but I thought you excluded it due to
licensing?

What do you mean about Laravel's "bus factor"?

~~~
jacquesm
Good catch. Laravel seems to be pushed forward by a single individual.
Elsewhere in this thread that is disputed.

~~~
davedx
Aha, understood... yeah, I think Laravel is very similar to Rails in that
respect. Would you not use Rails because DHH is at the wheel? They both have
big active contributor communities.

------
ohwp
When I read the introduction I immediately thought about Apache + MySQL + PHP
+ Symfony.

ORM, templating engine, community, it's all there.

~~~
adamors
I concur, but I would swap both the database and the web server to Postgres
and Nginx respectively. Symfony and the community around it is just awesome
though.

------
marknutter
Goodness, just pick a framework and start building. There's no way you're
going to make the right choice so just choose whichever language you're most
comfortable coding in and start building. Creating 12 prototypes to narrow
down 12 frameworks? Does this strike anyone else as an insane waste of time?

~~~
jacquesm
In the long run this should _save_ me time.

~~~
marknutter
Well, that's the classic argument for yak shaving. Most if not all of the
frameworks you analyzed will be more than adequate for the app you're going to
build. What it should come down to is what you're comfortable with. Focus on
the product you want to build, not the tools you are using to build the
product.

~~~
jacquesm
I think I got the Yak shaving part covered with the first sentence of the post
:)

I'm well aware of the ups and downs of exposing myself to choice like this but
I _really_ want to get myself exposed to some real world practice with some of
the top contenders here to make a more objective choice and I also feel that
'what you're comfortable with' is getting too close to unsupported that I
should widen my view.

Fortunately this is not a commercial undertaking, nor am I on a tight deadline
so I can afford the luxury of thinking this over. If it were for a customer
and it would be required tomorrow morning then the story would be wholly
different.

~~~
marknutter
Well, I suppose the silver lining is that you're publishing your journey :)

------
websitescenes
Every comment I have read so far is pushing a personal agenda and ignores the
authors criteria. If we are to go by the authors desired requirements then the
obvious winner is Rails. Rails is constantly being developed and maintains
timeless standards while embracing new technologies.

------
speg
Since the author is already familiar with PHP, why not try Hack? You'll get to
keep all of your PHP stuff, with increased performance on the HHVM.

Sure, there is no real hack framework yet.. but you could help build one.
Plus, all your PHP frameworks will work fine in the meantime.

~~~
krapp
A Hack framework might be a good summer project.

------
arisAlexis
[http://arisalexis.com/2014/04/27/odyssey-2014-a-journey-
into...](http://arisalexis.com/2014/04/27/odyssey-2014-a-journey-into-
languagesframeworks-and-databases/)

keep tuned I will write a similar back end post soon.

------
CmonDev
"I still haven’t forgiven Microsoft for their countless misdeeds so Asp/C#/F#
are all right out."

So Xamarin is Microsoft now? Better tell them, because they don't know it yet.
Clojure is a .NET language as well by the way.

~~~
locusm
Keep in mind that Microsoft now require you to login with their latest IDE.
The moment this will bite you in the ass depends on what license you use
(retail, partner etc). If your a partner you get a rolling 30 day trial that's
tied to your MS Partner account and if you've ever used the MS Partner website
you know what a complete piece of shit that is. From the Partner account you
assign development rights to a developer which then flicks a switch in your
MSDN account, allowing your developer to login to Visual Studio. Problem is
these stars dont always align and your left hanging on the phone to support
for hours (this has happened to 2 of our 3 devs now, took 24+ hrs to sort) The
only solution is to switch back to VS2012.

Xamarin also require that you log in to their IDE, so far so good with them
though.

~~~
Encosia
You can install Visual Studio 2013 with a product key instead if you prefer
(that's how I have it installed on my machines currently).

~~~
locusm
I believe thats retail only.

~~~
Encosia
My product keys have come from MSDN.

~~~
locusm
Your not using the Partner license, your likely on Bizspark or a bog standard
MSDN subscription. Partners pay the most, then get treated like an a __hole.

~~~
Encosia
If buying MSDN works out to be cheaper than the Partner program, why not buy
MSDN licenses instead?

~~~
locusm
MS Partner licensing gives you broader usage, through to production servers,
Office etc. Pretty sure MSDN is dev or training only. Plus why pay twice, shit
should just work without all the BS.

------
visarga
It's simple: pick the language that has the most intense energy/vibe around
it. You will benefit from being at the front line of innovation and have the
help of an enthusiastic community to back you up.

It's Javascript and Node.

------
dev360
Sorry if I'm harsh, but I think this is a terrible way to choose a programming
language. It is suggesting a one size fits all approach, and I'm kind of
disappointed to see a lot of languages thrown out without objective scrutiny.

Also, it could be foolhardy to pick just one for the next 10 years. When all
you have is a hammer everything looks like a nail.

It might help to try to think of the specific constraints that you envision
running into. How can your technology choice help address those concerns and
simplify your stack or speed of development, or ability to hire talent? You
should easily come up with over a dozen items that you will want to be able to
address with your choice of technology.

------
cabbeer
What about Meteor ([https://www.meteor.com/](https://www.meteor.com/))? surely
being funded should help longevity

------
lukeholder
My guess will be he will eventually arrive at Ruby on Rails or Laravel.

------
Rygu
Not sure what kind of applications he expects to build, but picking a "Web"
Framework for the next decade should probably also include a Javascript
framework that allows more app-y websites. Clients are already falling for
those.

------
hellbreakslose
Judging by how fast technology is evolving nowadays I can't even imagine what
is going to happen in 10 years from now... We might not even have the Web... I
don't think nowadays you can choose something for the next decade. Maybe for
the next 2 years Maximum!

~~~
jacquesm
I think the web will be around in some form just about forever. I'm more
bullish on the web being around 100 years from now in some recognizable form
than I am on quite a few nation states or species of mammal.

