I think you have a handle on the problem. It's all about productivity and the ability to generate results quickly. Sounds like you have a few people pushing the "not invented here" doctrine.
What you have with a framework, such as Tapestry, is a lot of institutional knowledge realized as code. This has evolved over time, and encompasses a wide variety of subjects, including performance, localization, JDK bugs, browser quirks and bugs, and hundreds of tiny edge cases related to the toxic soup of technologies used to create a "modern web application". The basic premise of the "not invented here" crowd is shaky ... it's based on the idea that The Architects (and only The Architects) understand the problem well enough to solve it. Two problems there. First, The Architects won't be implementing, they'll just be telling people what to do and the reality is that the soldiers on the ground are going to find lots of undocumented gaps in The Design that will need to be filled leading to a lot of cruft and duplicated work. Second, The Architects do not, can not, will never understand every aspect of every bit of technology. I sure don't. You start to build something and your assumptions fall away and you start experiencing the sharp edges I alluded to earlier. Nobody can be an expert in every stage of the stack ... the goal of Tapestry is to compartmentalize people's skills, so that each person can work in the area of their strength. Designers can create visually interesting and usable interfaces. Java coders can link those to the living machinery of Tapestry. JavaScript hackers can create JavaScript components usable by those less versed in JavaScript, back-end guys can create services linked to by front-end components. Everyone has something to contribute, and nobody has to be the master of all things. On Wed, Nov 5, 2008 at 9:28 AM, devilabit <[EMAIL PROTECTED]> wrote: > > > I apologize in advance if this is a little off topic. > > I recently started work for a new company and they are looking at moving > some of their desktop apps to web apps. I have been tasked with > investigating how we would go about this. The web app in question will need > a rich interface but I would not consider it a Rich Internet Application. > Without going into too much detail this app will be used to search a large > archive and display the results. A user can drill down into these results > and apply filters client side. Additionally it will be necessary to save > searches, tag, rate, comment on results and export to PDF/word etc. The look > and feel will be familiar to something like outlook web access. > > Now this to me sounds like a normal web app with some extra bits of > JavaScript to make it feel like a desktop app. Thats why I started to > consider Tapestry5. We could build our own custom widgets and reuse would > be easy. > > However the architecture that the developers here have in mind is to write > everything client side in javascript and html and use our own custom web > server to serve the application. Communication is JSON over http. The idea > is to write our own custom modules for the web server to handle things like > saving searches, tagging, templates, ajax. This architecture doesnt even > consider the concept of a web application, its built more around the idea of > a an ajax request going to the ajax module as an example. It like a "C" > design a web app. Even the document structure will require us to have a > separate version for each localized html page instead of having one master > version and a properties file. For now they have a couple of simple web > apps using this design. However I feel that for feature rich web > applications with a lot of functionality we will need to write many custom > modules(things that come for free in tapestry like template's, components, > client/server side validation) and it will be a nightmare to develop and > maintain. Eventually after a long difficult struggle we will end up having > written our own web framework written in C with little library support(no > tool support) that is not as good as a mature framework thats taken a web > framework expert 2 and half years to write. Productivity will be low, the > company will have to hire many more people and these will be expensive > because they will have to be C and JavaScript gurus! > > I dont think the people here really understand the concept of a web > application and how much work it takes to develop one. Its difficult to > change peoples ideas when your new and have yet to earn your colleagues > respect so thats why I need your help. My question is how do I sell them the > idea of using a web framework? Any comments, suggestions, arguments, links, > advantages/disadvantages to using web frameworks etc would be very welcome. > > Thanks. > -- > View this message in context: > http://www.nabble.com/Why-would-you-use-a-web-framework--tp20343460p20343460.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
