I'm already doing these things. There are lots of problems that cannot be solved by just your approaches.
1) Dependency management and the proper ordering of loading individual javascript files. In big projects, you really do want to split up your code in different files, but javascript is awful here. 2) The scoping rules are awful in Javascript, and the whole "var that = this;" to get around them adds unneeded complexity. 3) Dealing with development and deployed javascript with the same markup adds even more complexity. It is desirable the minify and merge all the javascript, but this is bad for development. It is just compounded when you are dealing with app servers and so on. It's so much more bloated of a process than it should be. 4) There are all kinds of basic boilerplate and libraries that even jquery doesn't provide that must be programmed oneself. 5) Rendering big snippets of HTML after a page is rendered that duplicate the parts of the html already rendered by the server creates a huge maintenance problem. Sometimes it is impossible to have the server render the html in snippets because you need to investigate data before you decide to render... but if you pre-render, it cannot do this. 6) Keeping the contract between your object graph in your java code and on your client code is a massive pain. 7) Testing every page whenever you add javascript code that could potentially affect the whole site can cause errors that you have no idea about until it's too late. This forces you to manually test every stupid thing on your website. 8) The automated testing of javascript is hard and not nearly at the level of ease or reliability as testing your java code. 9) As if CSS and html weren't enough, you are now dealing with html<- >javascipt dependency through ideas and even markup, as well as css<- >javascript dependencies. The list really goes on and on. For simple stuff... sure... it's not a big problem. But doing anything complex and it is a royal pain in the ***. On Apr 8, 9:33 pm, Mark Volkmann <[email protected]> wrote: > My recommendations are: > 1) read "JavaScript the Good Parts" and possibly "JavaScript Patterns" > 2) follow their advice > 3) use JSLint to improve your JavaScript code > 4) use a good JavaScript library like JQuery, including it's Ajax capabilities > 5) learn and use FireBug > > It really isn't that bad if you do those things. > > > > > > > > > > On Fri, Apr 8, 2011 at 7:44 PM, Ken Egervari <[email protected]> wrote: > > This might not be the best place to post this, but I value the people > > that frequent this forum and I do work in the Java/Spring/Hibernate > > space. > > > My apps that I'm working on are getting to be more and more javascript > > focused. This has brought on all kinds of pain and complexity from my > > point of view... but it's become necessary to be competitive and offer > > user experiences that are more modern and what people expect. > > > I was wondering how you guys managed this complexity? What tools, > > frameworks, libraries, etc. do you think work the best with a Java/ > > Spring way of doing things. > > > It seems that even beyond browser problems and the limitations of the > > language, maintaining the server/client contracts with ajax requests > > is a pain to test and refactor as the system evolves. The lack of > > dependency management in javascript is a pain, and RequireJS doesn't > > work 100% - sometimes it doesn't load the files and you have to > > refresh the page to fix it. > > > There are all sorts of other problems. It's like javascript hell > > sometimes. > > > I am starting to wonder if the pain is even worth the cost. I actually > > can't stand that development has gone this way. Programming just isn't > > fun anymore. There's so many tools and technologies. You think that > > with some things getting more rational and easier, other things end up > > blowing everything up. I mean, this whole polygot approach is driving > > me nuts. I can accomplish the same thing in a Swing application, but > > just because it needs to be "on the web", it makes the same > > application so much harder to deal with. > > > Thoughts? > > > -- > > You received this message because you are subscribed to the Google Groups > > "The Java Posse" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/javaposse?hl=en. > > -- > R. Mark Volkmann > Object Computing, Inc. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
