UI development

[maxterner]

Hi,
I am going to create one project but little bit confused, As i am new in UI dev.
and wanna to know which one method would be good?
1. First create html and implement js on the html content.
2. Create all html content using js like input,div,span,lable, textarea etc.
Please help me to find the correct process to develop UI.

[rnd me]

both are fine. if you need something to show up in browsers without javascript, use and html base. if you don't need that, it might be easier to do it all in js; those patterns are often more reusable than "upgrading" html.

[maxterner]

But if i develop using js(second method) so code length increases, And project size will be more than normal html project(first method).
So would it affect the Load time of website.

[rnd me]

But if i develop using js(second method) so code length increases, And project size will be more than normal html project(first method).
So would it affect the Load time of website.

if you generate the interface with js, you shouldn't need to ever re-load the page. that means that even if it takes a bit longer the first time, each additional "page" is instant. so it seems faster.


js should not take any longer than html to transfer. even if it's twice the size, it will transfer in about the same amount of time. unless you're talking hundreds of thousands of elements, it's all quick.

Use a templating system or at least a dom library to generate your html. DON'T use document.createElement("span") 50,000,000 time in a row; that is bloated and wasteful...

if you do it right, you can actually save a lot of bandwidth using js instead of html; it all depends on how you code it.

[Kor]

I am not very sure about the real aim of the project, but wouldn't be easier to use a server-side language, as PHP, and AJAX instead of pure JavaScript generator codes?

[maxterner]

Thanks rnd and Kor, i would like to make a point that i created one web application using Js and jQuery and its seems like a desktop application, But it made me more time consumer. Pure Javascript code is more time consuming so i used both Js and jQuery.
During this Apps development i got confliction in code. and now i came to know that first create html and implement the js, jQuery on that.
Pls suggest if i am wrong.

[handcraftedweb]

if you generate the interface with js, you shouldn't need to ever re-load the page. that means that even if it takes a bit longer the first time, each additional "page" is instant. so it seems faster.

In order to avoid loading an additional page, isn't it required that the URL not change (other than the addition/modification of a hash fragment)?

If so there are some issues that might discourage one from using this approach (the hash-bang problem).

[rnd me]

In order to avoid loading an additional page, isn't it required that the URL not change (other than the addition/modification of a hash fragment)?

no, you can now change the path without reloading.

If so there are some issues that might discourage one from using this approach (the hash-bang problem).

that's a problem for sites, not apps.
if you publish documents, use existing standards.

apps like notepad, mspaint, word, and photoshop don't have a url bar and people seem to use them just fine...

[handcraftedweb]

no, you can now change the path without reloading.

Do you have any pointers (links) on how to do this? I didn't know it was possible, but sure would like to do it.

that's a problem for sites, not apps.
if you publish documents, use existing standards.

apps like notepad, mspaint, word, and photoshop don't have a url bar and people seem to use them just fine...

True, and good point. But people should understand that without links that change the URL, search engines cannot index their content.

[rnd me]

Do you have any pointers (links) on how to do this? I didn't know it was possible, but sure would like to do it.

https://developer.mozilla.org/en/DOM...rowser_history
legacy: http://benalman.com/projects/jquery-bbq-plugin/

True, and good point. But people should understand that without links that change the URL, search engines cannot index their content.

hashes are not broken. if an app needs js, it needs js. just like an app might require osx lion or .net v2, certain apps, by their nature, will have higher requirements than others.

doesn't seem to be a problem for google maps, gmail, twitter, or many other highly-used web apps. if you need app code or data resources consumed by search engines, you can use a sitemap to link to the urls that are not presented by your public-facing app. if your apps is the only public page, you have a problem. but if you have a fancy single-page news reader, you can publish all your stories to static html files, link to them in an index (html or http://www.sitemaps.org/), and they will be found just fine. the general public need not wade through your files because a javascript re-direct at the top of the resource file throws them into your reader app looking at the very story they clicked in google...


for example, right now i am building a large public media site. it has to be SEO, accessible, and all that. So, i built a regular static site that works without js; embeds for media, links to full images, etc.
But, if a user has js, landing on any page will "boot up" the app mode of the site, and the content gets sucked in through a json api instead of browsing html urls. this lets me paint much faster than the cms can render pages, save on mobile bandwidth, and allows rich media features like slideshows, audio playlists, modal interaction, etc.

[handcraftedweb]

This is all very interesting stuff. You've pointed to some solutions to problems I've been trying figure out. Thanks.

https://developer.mozilla.org/en/DOM...rowser_history
legacy: http://benalman.com/projects/jquery-bbq-plugin/




hashes are not broken. if an app needs js, it needs js. just like an app might require osx lion or .net v2, certain apps, by their nature, will have higher requirements than others.

doesn't seem to be a problem for google maps, gmail, twitter, or many other highly-used web apps. if you need app code or data resources consumed by search engines, you can use a sitemap to link to the urls that are not presented by your public-facing app. if your apps is the only public page, you have a problem. but if you have a fancy single-page news reader, you can publish all your stories to static html files, link to them in an index (html or http://www.sitemaps.org/), and they will be found just fine. the general public need not wade through your files because a javascript re-direct at the top of the resource file throws them into your reader app looking at the very story they clicked in google...


for example, right now i am building a large public media site. it has to be SEO, accessible, and all that. So, i built a regular static site that works without js; embeds for media, links to full images, etc.
But, if a user has js, landing on any page will "boot up" the app mode of the site, and the content gets sucked in through a json api instead of browsing html urls. this lets me paint much faster than the cms can render pages, save on mobile bandwidth, and allows rich media features like slideshows, audio playlists, modal interaction, etc.