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.
Choosing a Web Framework/Language Combo for the Next Decade
161–170 of 228 posts
Re: Choosing a Web Framework/Language Combo for the Next Decade
#162Goodness, 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?
In the long run this should save me time.
Re: Choosing a Web Framework/Language Combo for the Next Decade
#163FWIW, 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 i…
The thing is that it doesn't matter if it is EOLed or rumored to be. These things always have a chicken-egg problem because even the rumor will demoralize people to use it in new projects which will make commits fewer which will make users fewer which will make the project die anyways, and that's because a) Google has a history of abandoning projects b) people like to be optimistic (unrealistic) when they chose a framework so they think it will be good for X years.
Re: Choosing a Web Framework/Language Combo for the Next Decade
#164Earlier quoted context omitted.
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 copyi…
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).
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)!
Re: Choosing a Web Framework/Language Combo for the Next Decade
#165FWIW, 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 i…
The move to superdevmode is the nail in the coffin for GWT for me. It has been my go-to framework for the past 5 years. I really love doing everything in Java (I don't like Javascript, don't particularly enjoy writing HTML, and find the compile time checks of the UI invaluable); some of the core components are clunky to work with, but you can easily write some component libraries that sit on top of GWT and generate e…
> ideally will generate much of the Javascript
Just to play devil's advocate, but with any compiled-to-JS language, you're right back to where GWT is with superdevmode: stuck in the browser's debugger.
My hope is that with enough "compiled-to-JS" languages (Coffeescript, etc.) becoming popular that browser vendors will build a standard debugging wire protocol, much like the JVM's, which would allow IDE-based debugging of sourcemapped JS code.
This project is taking that on for Eclipse, which is a huge challenge and I'm very impressed that they're even attempting it:
Given you use IntelliJ, which typically has a much faster turn around on supporting bleeding-edge browser/etc. integration, I would actually except them to get it first.
Re: Choosing a Web Framework/Language Combo for the Next Decade
#166A 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 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.
Re: Choosing a Web Framework/Language Combo for the Next Decade
#167Spring is included in the end shortlist, but I thought you excluded it due to licensing? What do you mean about Laravel's "bus factor"?
Good catch. Laravel seems to be pushed forward by a single individual. Elsewhere in this thread that is disputed.
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.
Re: Choosing a Web Framework/Language Combo for the Next Decade
#168I 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.
Re: Choosing a Web Framework/Language Combo for the Next Decade
#169I (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…
I think Haskell underestimates people's intelligence when it comes to things like mind-simulating state change in simple subroutines, and overestimates it when it comes to understanding lazy evaluation and monads. Humans had built useful structures long before they've been capable of rigorous abstract thought. How? By trial and error. Most people find it easier to learn how to catch a ball by practicing rather than b…
> Haskell discounts the very useful choice of reasoning about your code after it runs
Huh, I have never thought about it like that. Thanks.
Re: Choosing a Web Framework/Language Combo for the Next Decade
#170Earlier quoted context omitted.
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. Nevertheles…
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.
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.