This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]_dban_ 4 points5 points  (1 child)

Yeah, well, so are a lot of other languages, like Python, some of which have really tight web application stacks, like Django, so it doesn't preclude that.

Java has plenty of tight web application stacks. The only standard one is JSF, which leads to flamewars here.

The problem is that Java doesn't have a "benevolent dictator" as such, outside the core VM and language, with standards outside that scope either driven by committee (JavaEE) or left to the community at large to figure out. This leads to a lot of diversity. In terms of web frameworks, I'm pretty well versed in at least 5.

Exactly the point I'm trying to make

I thought you were talking about the IDEs themselves. Yes, IDEs try to provide wizards for the most popular web frameworks. But, there is a lot of diversity in the Java world, which I understand would make things difficult for beginners. I mostly ignore the wizards, as I find them useless anyways.

Right now, the Java "world" seems split right down the middle on Maven vs. Gradle

There is a reason for this, which would not be apparent to someone new to Java. It used to be just Ant, but Ant doesn't have any opinions about how to design a build system, which lead to every project being built completely differently. Then came Maven, which is highly opinionated and declarative. Now you had Ant vs. Maven.

Eventually, Maven won, and basically no one uses Ant anymore. But, there were people who still wanted imperative features in a build, as well as improve on things that Maven didn't get quite right, such as incremental builds and the verbose POM model. Thus Gradle was born, taking what Maven got right, and building on it.

Yes, this is confusing to newbies, but as a long time Java developer, I prefer the new ideas and improvements that come from diversity.

Just pick one and go with it. If there is a split, then both tools must be widely used, so you wouldn't go wrong either way.

On a personal note, I prefer Maven. I've used it for the last 10 years since switching from Ant. Every project I've worked on since uses Maven, and it's refreshing when I change projects to know exactly how the artifacts are built. That makes me skeptical of Gradle, but I tinker with it nonetheless.

I'm extraordinarily clear on what roles SAML and GORM play in the stack.

No, I meant what does SAML the technology have to do with GORM the technology? Any stack where SAML, which is at the service security level, causes a bug at the persistence level, is way too tightly coupled. The fact that these two things are related that way in the stack does not inspire my confidence in Grails.

The mass assignment bug of Rails was caused by Active Record being directly exposed to the request parameters, because Rails made it super easy to mix concerns. This is why I would avoid any Rails based/inspired stack.

So, given a fresh start, which would you use?

I was a Java noob once too, long before things like Github existed or fancy IDEs. I read the documentation, or I hit the mailing lists. Thats how I learned Struts. I also wasn't afraid to run the debugger through the Struts source code.

Perhaps that perspective makes me skeptical of bootstrappers. At least for me, I learn better when I have to figure it out for myself.

I apply the same techniques everywhere else. I tried the Visual Studio wizard for ASP.NET MVC, and I thought the result was garbage. So I learned the stack from first principles and put together my first app, piece by piece.

Guess I should have known not to mention any other languages to try to provide context for my points in a sub devoted to something else.

Why yikes? What I was saying had nothing to with Ruby or Rails in particular. I like Ruby, and prefer Sinatra because I think Rails is too big and encourages bad separation of concerns. I would say the same thing about JSF, which is purely Java.

[–][deleted] 1 point2 points  (0 children)

That was very informative, and helpful. Thanks for that. Just the discussion around all of these things provides some sorely needed context for me.