Thoughts On the State of Web Development

rmoskal recommends his blog post up at Most Media on finding the right level of abstraction, Grails, and SOFEA. "[Three years ago] I was very excited about Apache Wicket as the way to develop line of business applications with a domain model, CRUD [create-read-update-delete] screens for maintaining the model, and in the most interesting cases, doing something else useful besides. I still like Wicket. It has, as its website says, a small conceptual surface area.' It reminds me of Python in that 'You try something it usually just works.' In many respects, though, Wicket seems to be at the wrong level of abstraction for the for the sorts of line-of-business applications described above. If your team is spending any time at all writing code to produce listing, filtering, and sorting behavior, not to mention creating CRUD screens and the back-end logic for these operations, they are probably working at the wrong level of abstraction. ... Recently I did a small project using Grails and was quite pleased. Grails uses groovy, a dynamic language compatible with Java, and is based on the proven technologies that I know and love well: Spring, Hibernate, SiteMesh, Maven, etc. ... I get all the power of the Java ecosystem without the fustiness and lack of expressivity of the core language (no more getters and setters, ever!)."

Comments

Thoughts from another experienced developer...

[Hurricane78]

If your team is spending any time at all writing code to produce listing, filtering, and sorting behavior, not to mention creating CRUD screens and the back end logic for these operations, they are probably working at the wrong level of abstraction.

Agreed, BUT: I expect more from me, than the average developer. I expect to be at the very top. One of the best in the world. (Yes, that doesn’t mean I am always. ^^)
So none of the present libraries are even remotely acceptable to me. The one does one thing good, and the other one does the other thing good. But basically they are more of a “framework” mess, than a set of simple, separated libraries.
Which is why I did actually spend a lot of time on the above things. To custom-build my own system.
I think generating SQL from a UI design, is the wrong way around. So my system generates a UI from the database definition code. A bit like rails, but with a graph as the basic model of site structure, instead of a flat set with hacks.
Also, I made a separate library of every aspect of my abstraction toolbox.

Recently I did a small project using Grails and was quite pleased. Grails uses groovy a dynamic language compatible with Java and is based on the proven technologies that I know and love well: Spring, Hibernate, SiteMesh, Maven, etc.

Sorry, but I hate things like Grails or TypoScript with passion. The reason for this is, that their design is based on the inner platform anti-pattern. In a nutshell, the recreate the environment they’re implemented in... badly. PHP and Java (in JSP form) already are dynamic scripting languages made for this task. Just use these, save a layer, lose nothing, and gain a massive performance boost for free. And: No. Grails and TypoScript are not easier to use. They are usually only easy, when you don’t want to do anything special. But usually, in my experience, there is no such thing as a project without something special. And on top, you have to learn new things in addition to the language you’re already using. It is silly.

I get all the power of the Java ecosystem without the fustiness and lack of expressivity of the core language (no more getters and setters, ever!

No you don’t get all the power. You get another pointless layer of abstraction. And if you want expressivity, then why start out with Java in the first place.
My rule of thumb is: If you are using a compiler, it must result in machine code. If you are using an interpreter, it must be in machine code. Prefer compilers over interpreters, and always only use one single compiler xor interpreter between your code and the machine. If you have more than that, you’re doing it wrong.

Which is, why my above system is not written in a scripting language, but mostly in Haskell and Python, with some Python scripts for quick code generation from the SQL model plus some annotations. The result is always compiled code. The result is always compilable to a normal GUI, web service or mobile device application.

But I’m in the process of phasing the whole thing out. It lacks in themeability (an issue, if your whole UI is generated automatically), and I want to write an even more generalized system. And this time I want to open-source it.
But you may not like it, as it will most likely not be usable from withing a browser. There are just too many efficiency and security issues with that. Also I nearly stopped doing webdev anyway. Too weak. I need a bigger challenge! :)