Matt RaibleMatt Raible is a Web Developer and Java Champion. Connect with him on LinkedIn.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

Do we even need web frameworks?

On the Struts mailing list, Ted Husted writes:

IMHO, if we had today's JavaScript/CSS/HTML environment available to us in 1998, then JSP, ASP, JSF, PHP, and all the rest of it, would not exist. We did all these things to make up for the shortcomings of the client-side environment, and, since then, the key shortcomings have been addressed.

I believe Ted has a good point. However, today's Ajax development toolkits don't help those applications that require Section 508 compliance. Of course, if your toolkit embraces 508 compliance, I'd love to hear about it.

Posted in Java at Aug 09 2007, 08:49:33 AM MDT 8 Comments
Comments:

My frustration with some frameworks is that although they are suppose to save you time, a lot of them end up tying your hands and slowing you down. I personally like a framework that is lightweight, expendable, and structured more like a library where I can pick and choose which components I'd like to use. Regarding JavaScript frameworks, moo tools meets all of these requirements. It is about 30k, really powerful, makes complex tasks easy with less code needing to be written. Java seems to lack the keep-it-simple mentality, trying to make everything into an "Enterprise Level" solution. The only thing this means to me is that you need "Enterprise Level" funding and a team of people to get a product using these methods to market.

Posted by Tony on August 09, 2007 at 10:53 AM MDT #

You mean using JavaScript for all business processing? :O What about security? scalability? I think the guy is kidding. Do not exaggerate about the Ajax toolkits: They are nice, they were born from a real need (read pain) but it is just a piece of puzzle no less no more even if it seems so sexy these days.

Posted by Ashkan on August 09, 2007 at 11:04 AM MDT #

I've been using GWT for a few months now and it dawned on me that the purpose of web frameworks is to provide MVC capabilities on the server to compensate for their absence on the client. With GWT, however, you get MVC on the client and the need for a web framework disappears in the arena of web applications. MVC was invented in Smalltalk for client code. Using a Javascript rich client (e.g., GWT), MVC once again lives on the client so the web framework is unnecessary. Caveat: these remarks pertain to web applications. For a multipage web site as opposed to a web application, I think web frameworks still have a place.

Posted by Larry on August 09, 2007 at 11:31 AM MDT #

I almost totally agree :-). We've been writing apps using DWR (and dojo/ext/prototype or scriptaculous) along with Spring MVC for quite some time now, and it's been long since we've used Spring MVC validators. We have been using for quite some time now only plain Spring MVC Controllers and almost nothing else from Spring MVC.

Posted by Marius Hanganu on August 09, 2007 at 01:05 PM MDT #

Only if writing javascript code wasn't that painful

by the way the math questions to post here are too hard, I just entered:

2 + 22 = 26

:)

Posted by musachy on August 09, 2007 at 03:10 PM MDT #

A better title might have been: "Do we even need server pages?"

At work, we still use a server-side framework to handle input validation, business logic, data access, and text formatting. It's a simple pipeline based on a chain of command. We use JSON-RPC to call a server-side method that calls the appropriate command. The method can then return whatever data is needed. To look at the server-side code, you wouldn't know that a web application was involved.

For the view, we just don't use server pages or text templates. Personally, I find it much easier to code dynamic HTML in JS than with Java tags or ASP.NET controls.

Next, we're thinking of rewriting the chain of command for server-side JavaScript, so that we can do our part of the application in JS, end to end. I'm also wondering what would happen if we added OSGi to the mix on the server-side.

As for Section 508, I believe YUI is putting a lot of focus on accessibility. Of course, if we were all coding in AJAX in 2002 the way we are in 2007, there would be more browser support for AJAX and 508 by now.

-Ted.

Posted by Ted Husted on August 09, 2007 at 07:30 PM MDT #

Ted Husted said:
For the view, we just don't use server pages or text templates. Personally, I find it much easier to code dynamic HTML in JS than with Java tags or ASP.NET controls.
I strongly suggest you to take a look at Tapestry (4 or 5, specially the lattter) and Facelets page template formats. It's HTML, not taglibs. And taglibs suck because they're not HTML. :)

Posted by Thiago HP on August 10, 2007 at 06:51 AM MDT #

Hmm - IBM is deeply involved in Dojo and Section 508 compliance (accessibility in general) is a big deal at IBM.

Posted by Dan Cox on August 10, 2007 at 02:16 PM MDT #

Post a Comment:
  • HTML Syntax: Allowed