Reputation: 94429
One of the design proposed for a web application I am working on suggests using javascript to generate all html content. Basically to create a page in the application you would use a homemade javascript framework to build the dynamic html on the page. The pages of this webpage are very complex and all of the html markup would be generated via javascript using our custom built framework. The framework would essentially need a method to create each element on the page you wanted to produce.
What are some of the pros and cons of this approach?
Upvotes: 4
Views: 6891
Reputation: 147353
The strategy adopted by serious web sites is to start with basic HTML, then add CSS to tidy the layout, then add script to make the users' life easier by enhancing functionality (and not to add time wasting and annoying animations). That way you always have a fallback if something doesn't work or scripting fails for some reason. I deliberately left out the "add annoying advertisements" since they aren't part of the functional design.
To design the site, you should start by determining what it is that your web site is supposed to do (i.e. the vision). Then set out some goals that achieve that vision. Then chose the most efficient design to deliver on the goals—at this point you should not have yet decided on the implementation technology.
Then choose the most appropriate technology and design based on reliability, maintainability, longevity and supportability. That will lead you to a detailed design and implementation.
If, after all that, the best option is a 100% scripted client, so be it. But the fact that very, very few web sites have chosen that architecture makes me very much doubt that it'll be the winner.
Upvotes: 5
Reputation: 270609
The biggest cons of it are that you must rely on the end user's client browser to correctly render all of your content. An out of date browser or an untested browser is likely to result in broken content or no content. This is distinct from and more severe than the problems those same browsers encounter with HTML & CSS they cannot correctly render. If the markup is supplied to the browser, it may incorrectly render the CSS, but at least the content will be accessible. Using a script to generate all the markup can easily result in no markup being generated.
Then there are the users who run without JavaScript, or with something like NoScript blocking most scripts. They'll not see any of your content either. Thirdly, your content will not be indexed by most search engines.
Relating to developer skill sets, working strictly from a JavaScript framework could tromp on the web development division of labor somewhat, if you have such a division. Unless the framework is able to maintain a good separation between the generation of markup, CSS, & application script, your programmers may find themselves more deeply in the role of designer and content editor than they are accustomed to (if you have a division of labor between those aspects of development).
From the comments below, we learn that this is intended for an intranet application in a controlled browser environment. This moots the end-user testing issues mentioned above to some degree, but there is always a danger of a browser upgrade breaking application code in JavaScript.
I cannot think of any positive outcomes that would outweight the potential negative outcomes (by my own judgement, anyway)
Upvotes: 10