Member Avatar for Fungus1487

i am a web designer. i have been asked to create a web app for use on a company intranet. the problem is i have a treeview (those that dont know asp a simple menu structure) on my page which allows the user to pick records they wish to view. all the records have sub records and sub-sub-records etc. the company has so much info that the first level is equating to 3600 nodes already. this totals at a massive 2.6mb file size including the page info. As i understand everytime i post back etc the browser has to re-draw the page. i am not doin anything stupid like recalculating the tree etc but there is a huge amount of lag while i wait for the information to be rendered. Now would using a frameset with two frames left/right be of use.

i.e. left = the tree
right = records data

as i understand this would mean that the tree isnt refreshed just my right frame can someone clarify that this is the method i am looking to implenment to increase performance ?

  • 5 Contributors
  • 6 Replies
  • 125 Views
  • 1 Month Discussion Span
  • Latest Post Latest Post by nyashaC

Dani AI

Generated

This thread shows a clear trade-off: a fast, pragmatic fix versus a cleaner, more maintainable design. reports a practical win with frames in a heavy intranet case, while points toward XMLHttpRequest/AJAX and / raise maintainability, accessibility and standards concerns. The best route depends on constraints (time, control of client browsers, accessibility requirements), but for large trees the usual long-term pattern is to avoid shipping the entire tree HTML at once.

A recommended approach that preserves responsiveness without frames:

  1. Load only top-level nodes on first render.
  2. On node expand, request that node’s children via AJAX (JSON).
  3. Render returned child nodes on the client and keep them cached.
  4. Use virtualization (remove or unmount nodes that are scrolled out of view) so DOM node count stays low.

Classic-ASP notes and practical tips: implement a simple endpoint that returns child nodes as JSON and call it from browser JS. Keep responses small, enable gzip on the server, add DB indexes and LIMIT paging for large result sets, and cache repeated queries. Use batch DOM updates (DocumentFragment) and event delegation to avoid per-node listeners.

If an immediate, low-effort fix is required, an isolated iframe can reduce full-page redraws short-term, but framesets are obsolete and introduce accessibility and bookmarking problems. If accessibility matters at all, implement ARIA tree roles and keyboard navigation and test with a screen reader. The safest long-term path is client-driven incremental loading + minimal DOM rendering; frames are a pragmatic stop-gap, not a future-proof architecture.

Recommended Answers

All 6 Replies

Member Avatar for autocrat

Technically, Frames are often considered bad for the internet.... they tend not to be SE Friendly, not particularly good to Screen/Text-Readers either.

That said, if more for a "Web-Application", such as on an Intra-net, then I'm not so sure as to the bad poitns being so important (though accessibility could be an issue!).


I would suggest possibly rethinking things abit.
You need to categorise and segregate into groups to make things faster.
Even if they are all as important as each other, you still need to make them smaller groups, as this will ifact speed up the user looking for things...
instead of showing all records A-Z, try showing A-C, D-F,G-I etc... and let the user go to the relevant group, then get the most likely data.
Much faster

Member Avatar for MidiMagic

Several books I have indicate that frames are scheduled for future deprecation.

Member Avatar for Fungus1487

hey, thanks for your help. After undertaking the task and in the end testing both solutions for performance. In all circumstances of EXCESSIVE numbers of records or data i suggest using frames. the increase in speed was at leat 6 - 8 times faster. Taking 20 odd seconds without using frames for me was not an option. I now have the app down to roughly 3 sec startup time with no lag during use while its counterpart was to say the least abismal. This is pushing the barrel as this is the largest number of records ive ever seen anyone use in the software we create, so knowing that it can handle this task is a load off my mind. thanks for the help

Member Avatar for Fungus1487

oh yes. final note never use ASP.NET treeview or any other type. build your own with javascript. it took longer but load time increased by no word of a lie 20 fold. The server just couldnt handle such a large tree in a decent amount of time.

Member Avatar for Marymead-IT

You (or others with a similar issue) may also wish to consider making use of the XMLHttpRequest object in your JavaScript. This object is the core component of "AJAX" web applications. AJAX basically allows your application to send and receive data to the server, without reloading the whole page. Gmail and Google Docs use this technology to do things like "autosave" without interrupting the user, or needing to download the entire page to update part of the page.

For your situation, the XMLHttpRequest object is becoming a more commonly used tool unlike frames, which may soon become deprecated.

W3Schools has a nice little tut on AJAX:

Hope that's useful for someone :),

Chris Fry
- Marymead IT
http://www.marymead.org.au

Member Avatar for nyashaC

Frames are no good. They continue to be in use because of their simplicity and the unwillingness of webmasters to adopt new solutions(see marymeads post above)
Personally I still use frames but not sitewide anymore i.e my templates do not incude frames but certain individual pages do

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.