Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Java Programming Python The Internet

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!)."
This discussion has been archived. No new comments can be posted.

Thoughts On the State of Web Development

Comments Filter:
  • getters setter :) (Score:5, Insightful)

    by roman_mir ( 125474 ) on Sunday April 18, 2010 @05:17PM (#31890510) Homepage Journal

    First, getters/setters are generated by your IDE of-course, so you never have to write them by hand, however, more to the point, I have avoided many various parts of the 'Java ecosystem', while still using that language to do all sorts of development and really, you don't have to use getters/setters. I use many Java classes as simple data structures, just like C-Gods intended, no getters or setters there, just public or protected fields.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      Geez, again with the same excuse: "My IDE generates them automatically". Yes it does, but Java IDE's are not the only one's that can do that, duh.

      Deeper problem is that you later have to use those "fully automatically with just a few special clicks" getters and setters like this in your code: point.setX(point.getX()+1); instead of just writing point.X++;
      2.7 times longer line than it ought to be. And with current java IDE-generated non-VM supported getters/setters all of the shorthand abbreviations such as +

      • all of the shorthand abbreviations such as ++ -- += -= *= etc are unusable

        So you're saying we can't implement Brainfuck for Java? OH NOES

      • Geez, again with the same excuse: "My IDE generates them automatically". Yes it does, but Java IDE's are not the only one's that can do that, duh.

        - 'duh' what? Where do you see me arguing against this point?

        Deeper problem is that you later have to use those "fully automatically with just a few special clicks" getters and setters like this in your code: point.setX(point.getX()+1); instead of just writing point.X++;

        - again, what? I said I use classes often without getters / setters, so this is exactly what I can do. Do you understand that getters / setters are a choice and are not mandatory? They are not required by the language. I think you do understand that, you just are not understanding what I wrote in my first comment.

      • by ebuck ( 585470 )
        If you're really sweating the point.setX(point.getX()+1) call pattern, pray tell why don't you create a point.increment() method? Of if you need more flexibility, a point.add(1) method? It seems like you're really trying to program like an idiot to prove you point that idiots program in Java.
        • Re: (Score:3, Insightful)

          by Daishiman ( 698845 )
          The fact that you even NEED an add() or increment() method shows the idiocy of the programming language.
          • I guess I will have to leave the same comment over and over again. What in the language (Java in this case) makes you do any of that?

            This is a dumb point.

            x++ works
            point.x++ works
            point.moveRight(1) works

            choose your poison but don't blame a language of the choice of a programmer

    • The idea with getters and setters is that in the end the value may not actually be a field (it may be computed), and interfaces can't contain fields. Plus the JavaBeans style naming conventions are pretty ubiquitous in the Java world... not sure if everything works right with just plain fields like that (it may).

      • As long as this is my project, everything will work without getters/setters where I choose not to use them.

    • by yabos ( 719499 )
      At my job they like you to use getters/setters for everything, even inside the class when accessing private members. To me this is pointless and a waste of time requiring a method call when you really don't need one. I can understand the reason for encapsulation where you want to protect certain things from outside access but to have to use this.getter() rather than this.variable inside the class really makes me want to puke. IF java wasn't garbage collected and the getter/setter actually did something r
    • First, getters/setters are generated by your IDE of-course

      Programs should be written for people to read, and only incidentally for machines to execute. I, for one, am not willing to read three additional lines of code and declarations for every line of code that actually does something.

      • Once again, (you are not the first coming up with this), you can chose to view or not to view various things in your IDE, like getters/setters don't need to be visible, however, I am saying that my choice is often not to use them in the first place and just to access a public/protected field directly without any getters/setters, it certainly is NOT FORBIDDEN in the language.

    • by thsths ( 31372 )

      > First, getters/setters are generated by your IDE of-course

      No, I think that is exactly what the article is about: your IDE is the wrong level of abstraction. Adding generators does not change that, as long as you still view, save and edit the generated code. Code generation in general is usually a sign of things going wrong, especially if used as scaffolding.

      The right level of abstraction is thinking about data, not state, and not code. Define your date, and please use a more modern approach than SQL, w

  • java centric (Score:3, Informative)

    by thetoadwarrior ( 1268702 ) on Sunday April 18, 2010 @05:23PM (#31890554) Homepage
    This isn't really about web development in general but Java web development and writing getters / setters is the IDE's job.
  • by Banacek ( 994201 ) on Sunday April 18, 2010 @05:27PM (#31890598)
    Using Java for web development is like using a wrecking ball to hammer in a nail. Use something that fits the job better, like Zend Framework, Django or Ruby on Rails. In web development, time to market is everything. Build your application and hopefully you get a large user base. Then when performance is an issue, you should already be working on a rewrite that can incorporate something like Java on the backend.
    • Re: (Score:2, Interesting)

      by Anonymous Coward

      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: (Score:2, Informative)

        by Daengbo ( 523424 )

        TFA (Shock! I read it) says that this is his new preferred method. Separate all the server and client-side logic. Push almost all the logic into the client.

    • by Lennie ( 16154 )

      I think the only reason this even made the frontpage is because the editors like a good discussion.

      The subject pretty much doesn't interrest anyone, right ?

    • by Kenneth Stephen ( 1950 ) on Sunday April 18, 2010 @06:20PM (#31890926) Journal
      ...are doomed to reinvent J2EE. Badly I confess that I haven't tried any of the frameworks mentioned by the parent. But I have had conversations with people who have, and here are some questions that I have for the folks who think that the people who came before them (and invented J2EE) are stupid:
      1. Can your framework handle two-phase transactional commits when it interfaces to other applications?
      2. How well does it support single-sign across apps deployed across different servers but behind a reverse proxy that unifies them under a single domain?
      3. Can you cluster multiple hosting servers for your app to minimize downtime during app upgrades? Does your application sessions failover to the other members of your cluster correctly, if so?
      4. Can you take legacy code and layer your app around it without needing to rewrite the legacy app? Can you do this even if the programming team who wrote the legacy app is no longer around?
      5. When you discover that you are having intermittent glitches (slow responses / server 500 response codes /etc), do you (a) reinstall (b) upgrade to a newer version of your framework / OS / whatever (c) Troll the user forums for your product / framework and hope that someone has seen your problem before. (d) Pull three all-nighters reading the source code to your product / framework? [Hint. The right answer is (e) Put your product into a supported trace mode and get your vendor to support you]

      IMHO, programming language wars are silly. The proof of the pudding is in what you can achieve with the framework of choice. After many years of observing the competitors to J2EE, I have yet to see a professional grade alternative to it.

      • Re: (Score:3, Interesting)

        by inKubus ( 199753 )

        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 i

      • Spring is the only real alternative, but given the state of J2EE it has taken until version 5 that JEE really became usable, you speak mostly of the merits the app servers give you but seriously until JEE 6 JEE in many areas was a mess (EJBs while good in idea were barely usable due to the XML bloat, the entire ORM part was broken so people had to refer to alternatives outside of the JEE realm)
        The first version which I would call outright excellent is JEE6 and this one is the first which beats Spring in the

      • IMHO, programming language wars are silly. The proof of the pudding is in what you can achieve with the framework of choice.

        The flaw in your reasoning is that programming languages can and do affect the expressivity of frameworks that are written in them.

        An example that has recently become very obvious is the presence of first-class functions in the language. If you've seen the newer additions to the .NET class libraries, or what people do with Java-with-closures prototypes, you should know what I mean. If you haven't, then are you really in a position to judge?

      • are doomed to reinvent J2EE.

        Nonsense.

        Can your framework handle two-phase transactional commits when it interfaces to other applications?

        Sure. Most apps don't need that, mind you, but if there's a need then 2PC is fairly trivial to implement *where it's needed*.

        How well does it support single-sign across apps deployed across different servers but behind a reverse proxy that unifies them under a single domain?

        What does that even have to do with anything?

        Can you cluster multiple hosting servers for your app to

      • The professional grade alternative is that you drop the half the superfluous bullshit J2EE seems to support and build and honest-to-God web architecture like God intended: shared-nothing workers on the web server and scale out on the database, use job queues that go to a compute farm if you need that. A decent web framework has transactions built-in so I don't even have to think about the problem, SSO is handled with a cookie and a generic backend that plugs to whatever you want, you don't need special clus

    • Really, try it. You can leverage many existing Java-centric frameworks. Sitemesh, Spring and Hibernate are fast & stable. Grails takes the 'suck' out of using them. Rewrites are easier, since you are already 1/2 way to Java. Find the bottle neck, rewrite it in Java and away you go.
    • Using Java for web development is like using a wrecking ball to hammer in a nail.

      Actually, *that* sounds pretty effing cool, almost Mythbuster-like! I'd like to try that some time. But using Java for web development? *That's* just crazy-talk.

    • by SQLz ( 564901 )
      He didn't use Java, he used Groovy.
    • Jython supports Django I've read, so again you can theoretically get the best of both if that's important. Personally, I dislike the Java ecosystem due to its bulkiness. However, for some particularly high-CPU tasks (complex search), it can fit into a larger REST environment nicely via Restlet or Django.
  • Need a New UI Tool (Score:5, Insightful)

    by Tablizer ( 95088 ) on Sunday April 18, 2010 @05:29PM (#31890610) Journal

    As I've said before on slashdot, the open-source movement should look at creating a new GUI browser that does desktop-like and CRUD GUI's well. Forcing the e-brochure-like HTML-based browsers to act like desktop/CRUD GUI's is like trying to roll Pluto up Mt. Everest: people have kept trying to pull it off with AJAX and whatnot for more than a decade, but it's still kludgy, bloated, buggy, security-challenged, and version-sensitive.

    It's time to throw in the towel and start a new tool and markup language.
       

    • Re: (Score:2, Informative)

      by Animats ( 122034 )

      Forcing the e-brochure-like HTML-based browsers to act like desktop/CRUD GUI's is like trying to roll Pluto up Mt. Everest: people have kept trying to pull it off with AJAX and whatnot for more than a decade, but it's still kludgy, bloated, buggy, security-challenged, and version-sensitive. It's time to throw in the towel and start a new tool and markup language.

      Right. Java applets!

    • The main issue with (X)HTML is that it's not meant to be used for application user interfaces. This shows partly in the types of "widgets" (form elements basically) available and in the severely lacking layout possibilities.

      Building basic user interfaces for various business web apps is probably the most frustrating part of web development, and the frustration coming dealing with building user interfaces using HTML, CSS and Javascript is definitely a major contributing factor.

      • Building basic user interfaces for various business web apps is probably the most frustrating part of web development, and the frustration coming dealing with building user interfaces using HTML, CSS and Javascript is definitely a major contributing factor.

        This was my view on web development for quite a while, until I gave jQuery a try and put aside some time to properly understand CSS. It's honestly not that bad.

        There still is a bit of frustration (in getting everything perfect on all major browsers) but t

    • Welcome to the world of legacy software.

      Essentially HTML is the world's biggest legacy system. The problem with finding a replacement is that everyone in the world uses HTML, thats a consequence of what state the technology was in when the internet took off. Even if you could find a replacement, convincing everyone to switch over is a pretty gargantuan task, esp. when you factor in the chicken and the egg issue, you aren't going to get people to switch to your platform of choice unless there is content,
      • It didn't take that many years to go from 0 users of HTML to where we are today despite the fact that most people didn't understand the potential at the time.

        Or perhaps there could be two protocols available - one to support legacy sites and a new one specifically designed to facilitate web applications.

        It would be great if you could have the most common AJAX-style transactions be available declaratively so that you could use them with little or no client-side scripting

        • "It didn't take that many years to go from 0 users of HTML to where we are today despite the fact that most people didn't understand the potential at the time."

          But HTML came first. Niche oportunity is already lost.

      • by Nikker ( 749551 )
        The only problem with HTML is in the interpretation. With every other language being high or low level if it runs it runs the way the programmer intended. With HTML, one line of HTML can behave differently for each browser that interprets / renders it. Any method of communication falls on 2 people to be useful right now we are not getting that. If you had to write different classes for each of the possible targets you end up with a messy bloated heap. Now with web developers in many cases throwing CSS/
    • Interesting, but why not take it one step further and do a lazily-downloaded environment, so as that applications can be super rich like desktop apps and still have all the advantages of web apps? app components could be downloaded strictly on a need basis and only when new versions are available. The mechanism will make sure components are cached locally in an appropriate manner.

      I dream of the day that I can import components from URLs... (import www.mycompany.com/mycomponent, for example).

      • You mean like Javascript?

        Any interpreted language can easily do it. Just download the file with the code, check it against some hash/public signature and import it.

        You could do a proof of concept in Python in 30 minutes, using nothing but the standard library.

      • You have just described Sun's Java Web Start, and Microsoft's ClickOnce.

        • by Jaime2 ( 824950 )
          Both of those are whole applications, not components. It's more like anything that implements SOAP, or Microsoft's WCF.
          • No, actually, they work just as GP described:

            a lazily-downloaded environment, so as that applications can be super rich like desktop apps and still have all the advantages of web apps? app components could be downloaded strictly on a need basis and only when new versions are available.

            They do indeed download classes (or, in case of ClickOnce, .NET assemblies) from the web as they are needed, and also do version-checking every time this happens, so if class/assembly updates on the server, it will be automatically refreshed on the client next time it is used.

            Now, I don't think either one lets you reference components from varying base URLs - at least ClickOnce requires a single base URL for all components, if I remember correctly.

            • Webstart allows you to specify extension URL's, that are different from the Base URL....(though, admittedly there is an existing bug that prevents resources within these extension URLS from redownloading should they be updated :-( )

      • by nstlgc ( 945418 )
        Sounds like Silverlight to me. Or WebStart. Or ClickOnce. Or ...
    • Re: (Score:3, Informative)

      by phantomfive ( 622387 )
      It's not even just that: as soon as you get out of the three column format, HTML has trouble. The idea of CSS is sound, to separate the presentation from the content, but in practice it fails (if you don't believe me, ask yourself this: when was the last time you used a

      div

      as a line break? That's really not what they're for).

      It's sad, but the problem is HTML has been developed by a committee, and not just a committee but a committee with conflicting goals. Some people want to make desktop-like GUIs, oth

    • Re: (Score:3, Informative)

      by Hurricane78 ( 562437 )

      It’s called QtDesigner & friends. Or XUL. Look it up.
      Basically, it’s an old hat. A very old hat. I did things like that back in 2003.

      I’m back to plain and simple... compiled desktop/server/mobile programs. I still use something like XUL (but in EBML with a tag-mapping attachment), but I mostly generate that “XUL” from SQL DDL, as an itermediate representation, and plain machine code as a final result.
      As an example: A complex application usually takes the time to write a cle

    • It is already happening. Look for the AppWeb project towards the end of the year.

    • It's time to throw in the towel and start a new tool and markup language.

      Or maybe spend long enough on a single version to make something stable. The "new" tool and markup language has been done plenty before. SGML wasn't good enough, so then came HTML, then HTML wasn't good enough, so there was XML. Apparently now XML isn't good enough, so we need SuperMegaMarkUpLanguage. It's funny, but software projects actually require time to mature. There needs to be a phase of "hmm this almost works, except..." instead of "these really minor annoyances are no good, gotta start over."

      Of co

    • by elrous0 ( 869638 ) *
      Yeah, except coders usually make *TERRIBLE* GUI designers. And FOSS coders are often too arrogant to think they need to work with actual designers. It's why so many FOSS projects have absolutely abysmal GUI's (and piss-poor documentation, since coders also think they don't need technical writers). So expecting a bunch of coders to produce a great browser and a markup language that's largely aimed at layout without a strong team of designers behind them (like they have at Mozilla) is likely to produce horrid
  • Sooner or later ANY client small or large, will come up with a 'change' that will require going way down the level to the underlying language, because of the intricate and out of the ordinary way they will ask it.

    moreover, rarely will the two changes requested in similar area by two different clients will be the same. every business has their own style of running things, and what they will ask of you will differ from each other. this is even valid for small ecommerce presences on the web. you cant imagine t

  • They took our jobs! [youtube.com]

    Almost most IT and Web Development jobs have been outsourced to third world nations.

    They took our jobs! Duurkee duuuurr!

  • I've been using this lately, and it beats the crap out of anything else I've seen. It _feels_ like I'm writing a swing app, but it's ajax enabled without writing javascript.
    And since it keeps _all_ the logic (even loops to generate tables or bullets) inside java code, refactoring is trivial. I will never go back to a framework with a separate templating language again (I'm sorry, Django!).
    !
    • I find it ironic how, in the end, the Java camp has came to the same "stateful Web" model for frameworks for which ASP.NET was originally ridiculed (and which is being departed with in ASP.NET MVC).

      I haven't used Wicket, but from what I've read about it, it sure sounds a lot like ASP.NET, except that it's actually done right (and in Java).

    • by kisrael ( 134664 )

      I used Wicket a few years ago. It wasn't god-awful, but between the irritation of keeping the HTML in synch and of trying to make a custom component or even fix Ajax behaviors gone awry, I don't think it pulled its weight in the power/complexity added ratio.

  • by jbwiv ( 266761 ) on Sunday April 18, 2010 @11:07PM (#31892582)
    Rails? Been there. Grails? Done that. Both are decent. Rails is very good, but the abuse of open classes gets old quickly. Grails is ok, but it's really just a thin veneer over a complex mix of Java projects, and God help you if you run into any problems, because you'll be dealing with a stack trace that's 1000s of lines long, and you be troubleshooting these underlying complex java libs. For me, the play framework (http://www.playframework.org) is the best Rails-like approach on a Java platform. It stays very close to rails, so if you know rails learning it is easy. It's very pragmatic and very fast. It doesn't require a compile step to see your changes. It just works. Best of all, the code is clean and easy to troubleshoot. I suggest you check it out.
    • I've been watching "play" for a while now; it seems to be getting pretty good press. Can you go into a little more detail what you like about it? What's your "work flow" like if you want to add, say, a new screen? How [well] does it interact with your DB layer, etc? Would love to hear some real world stories; both good and bad.

    • I've been using Stripes [stripesframework.org] for a while now and what I prefer about the approach there is that it does not mandate how to interact with the data access layer. In an MVC design pattern approach, Stripes focus strictly on the V and the C and leaves the M alone.

  • Web development has expanded into a very large and exciting platform for content and applications, both on the server and client.

    Still, every time I open an article about it, all I see is a developer who's tortured at the thought of generating endless CRUD forms and writing elaborate explanations, why he had no choice, *no choice* at all, but climb high up on the abstraction ladder, so that he can do basic validation in cute one-liners.

    That's great, but that's just a minor fraction of what web development c

  • by Rival ( 14861 ) on Monday April 19, 2010 @01:42AM (#31893304) Homepage Journal

    With the amount of abstraction in software development these days, very few people seem to really know what they're doing anymore. This should concern you -- if it doesn't, you haven't thought about it enough yet.

    We regularly see new exploits that affect systems that have been live for years, oft-times spanning multiple major versions and platforms. In retrospect these flaws are often usually painfully obvious, but because they have been buried in the layers of sediment of "best practices", "boilerplate" code and underlying platforms, they aren't seen. At least, not until a curious or malicious mind starts poking around.

    While this is in part a problem with QA, the deception of abstraction is that it provides a Black Box that is very easy to trust. This affects developers as much as QA.

    Are we really wise to keep building on these layers of abstraction? Toolkits on top of frameworks on top of virtual machines on top of operating systems on top of hardware -- even device manufacturers can't keep their locked-down devices from being rooted in a matter of days, sometimes even before release. While many of the Slashdot crowd laugh because there is a sense of social justice in seeing DRM broken, the same exploits may some day be used against systems we rely on. I don't consider myself a fearmonger, but I wouldn't be surprised to see significant digital infrastructure fail at some point, either due to malicious intent or simply instability, at some point in my lifetime. Poor software quality hurts us all.

    I realize that I sound like an old man yearning for the better days, but I learned to program in assembly on 8088s, and I knew exactly what my programs were doing. I'm not saying I want to go back to that, but the idea that most developers these days don't even understand memory management or garbage collection blows my mind. Asking for a new language because getters and setters are too much of a hassle? Somebody get this kid a lollipop, please.

    I read the article (no, I'm not new here) and the author's main point, emphasis original, is this:

    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.

    Where does he draw the line at "wasting time writing code"? This is exactly the mindset that leads us to buffer overruns, SQL injections, and many other problems which should not make it into production software. He wants his developers to abstract as much as possible, but code reuse all too easily leads to blind acceptance and a failure to understand what is being imported. If he trusts that all those acronyms on the blog post he wrote are bug-free, then I would hate to be one of his customers. Not that there seems to be many categorically better options available.

    In the end, I think we need to abandon the cycle of "software bloat to more powerful hardware to software bloat..." and figure out what we can do with what we have. Good grief -- look at CUDA! We have orders of magnitude more processing power in a single video game console than all the world's computers before World War II, and available memory is simply insane. Take a look at what Farbrausch [wikipedia.org] has done, and you will see what dedicated focus on efficiency can do.

    Stop being lazy, understand what you are doing, understand what you have available, and use it well.

    • Re: (Score:3, Insightful)

      by wurp ( 51446 )

      I haven't read your whole post in depth, but this stood out:

      Where does he draw the line at "wasting time writing code"? This is exactly the mindset that leads us to buffer overruns, SQL injections, and many other problems which should not make it into production software.

      No, rewriting functionality that already exists in stable, tested libraries is the mindset that leads us to buffer overruns, etc.

  • I'm a bit confused.
    It's 2010 and we discuss a java framework as if it represented "the state of web development"?

    You have heard about rails and django, right?

  • I'm much more upset about the lack of innovation in the way that people interact with computers. I know, Rome wasn't built in a day, but it seems like our OS could at least have the graphic appeal of say, Quake 2. Our Desktop is still so flat and limiting, and online collaboration is still so hokey and primitive. All this could be fixed, and largely for free if based on currently available FOSS. Instead we're cloning Windows XP with a prettier menu shade. WTF?

    I'd like a 3d online space where my avatar

    • Re: (Score:3, Funny)

      I'd like a 3d online space where my avatar can stand in the rustling grass of a windy prairie. In this environment, are a variety of nearby locations: A Desk...

      And on that desk, a computer. I virtually sit down in the virtual chair in front of my three-dimensional virtual desk, press the virtual power button, look at the virtual monitor (300 feet wide!) and am confronted with... ad infinitum.

"The only way for a reporter to look at a politician is down." -- H.L. Mencken

Working...