Thoughts On the State of Web Development 253
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!)."
Author should look into Scala (Score:1, Interesting)
Scala gives you most of the same benefits of groovy with the addition to being statically typed. The lift web framework is very nice (albeit poorly documented), especially with its ability to generate pain-free AJAX/Comet for you.
ps I would hardly call this article "the state of web developement." Maybe "the state of Java ecosystem web development", but even that seems a bit of a stretch.
Re:Using Java for web development (Score:2, Interesting)
Or just dump the server side all together, seriously with the maturity of the JavaScript frameworks, there is no reason to build on restrictive server side technologies, just build your UI with HTML/CSS/Javascript and communicate back to RESTful services implemented in whatever language the back end team chooses. This fixes a lot of things that where broken in web development not to mention that it is a far faster development style and is more maintainable to boot.
Re:getters setter :) (Score:1, Interesting)
The problem is that the implementation sucks. How about rather than making everyone call functions to get or set variables, making the access to the variable automatically call the appropriate getter or setter if it exists? You could even add a "controlled" member type (to public, private and protected) to indicate that the variable should only be accessed via getter/setter (read-only variables would then have no public setter, as opposed to being written to directly)
Re:People who do not learn from history.... (Score:3, Interesting)
These kids today who act like there's some art to programming that's instinctual, that they should be comfortable programming when they don't know shit about the language they're using. Guess what, C is the most comfortable language ever invented. Perl is one of the fastest to write.
Of course, perl is designed for text. HTML, while a subset of "text", is a pretty complex markup language. To generate such code using another language is not trivial. Then you're dealing with networking, web servers, the internet, unknowns like browser type and user screen resolution. Then you have various databases on the back end. It's a very complicated problem yet kids think somehow the computer (or someone else) should just solve it.
The problem is that frameworks are generic and your app is specific. Yeah, the basic types are always there, CRUD, forms, lists and datagrids. But the amount of variance between two "lists" can be huge. A styled list that may work great for a list of books might be horrible for a list of people.
There's no way a framework is going to define base types for every possible thing you could have in a list. The frameworks and object-relational mapping engines are just tools to assist you. You still have to classify everything and their interactions. You still have to define a logical flow for every feature. You still have to test everything. That's what a programmer's job is! So, kids, you're never going to have something that will abstract away the programming. As much as you'd just like to point at the computer and magically create an "app" like you paint a picture, it's not possible, has never been and never will be. "Fustiness and lack of expressivity"--shut the fuck up and get off my lawn.
Play framework is the way... (Score:3, Interesting)
Re:getters setter :) (Score:2, Interesting)
You do not think OO enough. The problem is that you think about, "how can I modify an object" instead of "what services that class should provide". You rarely need inc, mult, etc, they are very primitive operations, and indicate a poorly designed interface -- as you noted, too. The class here is a Vector (or Point, which is the same), so instead of inc, mult, you can simply use add(Vector delta), and scale(int lambda) -- which are the natural operations for a Vector. You can also have rotate, mirror, etc.
Re:We're going the wrong direction (Score:1, Interesting)
I'm a software engineer that understands the importance of good documentation and understanding of the code, along with what tests are applicable for each code module.
Generally the older the language the more difficult it was to code in. My dad had to write code in binary - simple commands required pages of code! I first programmed in Basic and then Fortran77 and compared to binary, this was relatively easy, especially when things didn't work first time and you need to check for errors. Error checking has really improved over time and now you can easily set watches and breakpoints to see what is happening.
Now I use C+ or .NET to plug things together and can do what my dad did in one or two lines of code. This is exactly becasue of the level of abstraction that allows me to ignore what's actually happening on a binary level. So as things progress, we loose the knowledge of exactly how things work and use increasingly simple analogies.
We rely on the platform and best practices to be secure, but this is relative to the cost benefits and risks. From my experience managers are less interested in testing and security and more interested in functionality and processing time (how quick it is).
With any programming, the real issue seems to be getting a library of good code, that is tested and open and understood. So any new code can be plugged together, like lego. Why redesign the wheel if you can modify it to whatever you want and create as many instances as you need? Why bother with memory management if the programing enviroment (Java) was designed to automatically release memory allocation when the code stopped running? It is also able to run in a virtual machine that means it can be supported on virtually any OS.
Personally you look at WEB vunerabilities and it seems that you can block flash and java and you are actually quite safe, except from social engineering of course!