We have an internal web app for the folks downstairs which was written about 10 years ago. Part of the app is done with a frameset. It's actually a pretty decent implementation of such and has worked really well for them over the years.
I'm trying to modernize this app, both structurally and visually. On the backend, I've done some crazy stuff, such as putting functions in their own libraries and eliminating all the inline, css, js, and SQL. On the front-end, I'm doing some cleanup in the way the page renders making sure different parts of the app use the same function libraries include common css and js libraries.
The problem comes from changing that one page which uses a frameset to organize the content and structure to using divs and css to show/hide different regions. The feedback on the overhaul overall has been very positive, but, they *really* liked the ability to resize the regions on that screen. I'm trying to get some feedback on use cases to see if I can tweak the layout such that they won't miss the old functionality, else I may be looking at using a potentially criminal amount of javascript to poorly replicate the functionality afforded by a simple tag.
So the question is, just do a frameset and screw the future, replicate poorly with javascript and screw maintainability (and the future), or tell them to suck it just, just because!?
(Score: 1, Insightful) by Anonymous Coward on Tuesday December 09 2014, @01:52AM
If it was good enough for your father, it's good enough for you.
(Score: 3, Insightful) by c0lo on Tuesday December 09 2014, @02:09AM
Umm... what [xkcd.com]!?!
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by el_oscuro on Tuesday December 09 2014, @03:31AM
I was involved in designing a website at about the turn of the century which basically worked just like ISPF - or CICS. Just fill out the form, click SUBMIT or press ENTER and get your results. It worked so well, that it is now used enterprise wide and gets millions of hits a day. It also uses frames and looks rather old. The interface hasn't been updated in 10 years. I was involved in a project to modernize it using CSS/DIV tags, and that shit is a pain in the ass! I have never seen such a clusterfuck "language". Even javascript looks good by comparsion. What the fuck is wrong with frames anyway? It seems a lot simpler way of laying out a webpage than that CSS shit.
SoylentNews is Bacon! [nueskes.com]
(Score: 0) by Anonymous Coward on Tuesday December 09 2014, @11:54AM
Was the back end COBOL, SAS or REXX?
(Score: 2) by WillR on Tuesday December 09 2014, @06:49PM
(Score: 0) by Anonymous Coward on Tuesday December 09 2014, @11:58AM
Ahhhhhhhhhhhhhhgrl
10 FIVE YEARS with NO thoughts of CICS and you had to bring it up.
20
30
40 DIE!
50
60 CESF
70
80 or something
90
100 *whimper*
(Score: 5, Insightful) by Anonymous Coward on Tuesday December 09 2014, @01:57AM
Dont tell them to suck it. They probably will be dealing with it long after you are gone.
Find out why they are resizing. Is it because they are swapping things back and forth and having to relook things up? Ask them if you can sit and watch them use it. Sit with them but do not say anything. Just take notes. Then do it again but ask questions like 'why did you resize that window right then'. It will be fresh in their mind and they will tell you. You can go thru your notes and tighten it up. Then you can mock a few things up and let them try it. Rinse/repeat... It may be something as simple as buying them a bigger screen.
My mother went thru one of these 'just because' things. She went from a form that took about 20 mins to fill out to it taking her 2 hours for the exact same information. Plus they went to one of those 'you screw it up well too bad... start over' type forms. I begged her to take it to back to her boss and get 'his buddy' to fix it. He is now long gone but she now deals with that crappy form every single day. They had to hire 2 extra people to get thru the work in time (they already had 4). That is something to keep in mind to. Find ways to make the work take less time. Especially if it is something they do every day (pre look things up for them, anticipate results, etc).
(Score: 2) by Nerdfest on Tuesday December 09 2014, @02:27AM
Excellent comment. I always say that as a developer you are there to make people's jobs easier. Instead of letting the users give you a solution to implement, work with them to solve their actual problem. While they may have some good suggestions, it's quite likely that a good developer can look at their actual problem and come up with a better way. You do need to work *with* them, so insulting their ideas is probably not a good start though.
(Score: 2, Insightful) by Moru on Tuesday December 09 2014, @07:54AM
Yes, until you have understood this part you are not a developer. Forget about the newest craze in the web world, your job is to make their job easier and faster, not jump on the latest trend because it's cool.
(Score: 0) by Anonymous Coward on Tuesday December 09 2014, @02:20AM
Not sure which one is more offensive.
Anyway, sounds like you are building for a phone not a workstation.
A great UI lesson.
(Score: 2) by c0lo on Tuesday December 09 2014, @02:33AM
Genuine curiosity: why do you consider Javascript offensive?
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0) by Anonymous Coward on Tuesday December 09 2014, @02:59AM
(Different AC here)
It's capable of making things go downhill spectacularly if used improperly? I believe it's generally accepted that if it isn't required for a solution to work nicely it's best avoided.
(Score: 2) by c0lo on Tuesday December 09 2014, @03:31AM
I can't agree. I'll put C++ under the same microscope you used and I'll quote something I agree with (not as an appeal to authority, just pure laziness to invent other phrases when they are already available):
(How much of "generally accepted" is "C++: best avoid it"?)
(citation source [wikiquote.org])
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0) by Anonymous Coward on Tuesday December 09 2014, @04:05AM
How about this for an example 'generally accepted'... If you want to adapt a webpage for different browser sizes you can either...
A - Check the windows height/width with javascript constantly and adjust the content when new values are detected.
or
B - Use media queries and adjust the CSS.
In practice there can be times when a combination of both is needed, but you try to avoid using JS if possible. In this example using A exclusively can make projects hard to maintain, can degrade performance for the end user (rarely noticeably, but it can add up) and can just be a plain ugly workaround.
Beyond that if you really really want to know why some people dislike javascript (or are down-right hostile about it, which I find a bit stupid too) I suggest you ask google.
(Score: 2) by c0lo on Tuesday December 09 2014, @04:55AM
:) You are making easy for yourself by your pick of the example, aren't you? Fair enough.
How about another example? Say... why should not a Web GUI answer to a drag-drop operation:
Why would it be wrong to directly ask certain people which like to congregate on SN?
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0) by Anonymous Coward on Tuesday December 09 2014, @06:47AM
Certainly am. I never said you shouldn't ever use Javascript, just that it's not always the best solution to every problem that could be solved with it. Hence my fairly obvious real-world example to make the point.
You just gave a valid example of when AJAX would be a nice solution to the problem *golfclaps*.
It's not, but for someone who doesn't get the "beef with javascript" you seem pretty combative on the matter. The idea of you arguing with google instead amused me :-)
(Score: 1) by gumpish on Tuesday December 09 2014, @03:02AM
https://www.usenix.org/system/files/1403_02-08_mickens.pdf [usenix.org]
Skip to page 7 if you insist.
(Score: 2) by c0lo on Tuesday December 09 2014, @03:15AM
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 3, Insightful) by tibman on Tuesday December 09 2014, @07:53AM
Seven pages of complaining and his suggestion is to not use the internet at all? I doubt anyone is going to take that advice.
SN won't survive on lurkers alone. Write comments.
(Score: 0) by Anonymous Coward on Tuesday December 09 2014, @03:48AM
Slow, bloated, horrendous syntax, poor cross-browser compatibility, etc.
(Score: 2) by c0lo on Tuesday December 09 2014, @04:01AM
Ok, grumbles accepted.
However, show me another language (good for a modern Web GUI) which doesn't show any of the 4 (I'll let the "etc." aside, make your job easier, just don't tell me we absolutely need to stay within the realm of pure HTML: I don't see why a smartphone demand the entire data/business/presentation logic be supported by an over-beefed up server and do nothing with its "God given CPU, memory and storage" - why you'd call it a "smart" phone?).
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by Arik on Tuesday December 09 2014, @10:05AM
The problem is when you respond to an http or https request with a pile of code instead of an html document, and expect the client to blindly execute said code in the browser. THAT is the fundamentally insane aspect to real world ecmascript use that I object to.
If laughter is the best medicine, who are the best doctors?
(Score: 3, Insightful) by Arik on Tuesday December 09 2014, @08:21AM
It was only to be allowed as a supplementary layer on a web-page - an optional extra to be used to compliment an actual web page by adding a little bling. Sane view is still possible when used like this - a parser that discards the ecmascript junk will still work fine with the underlying web page. But 'designers' can't be bothered to do this right, so more and more 'web pages' are not web pages at all, just hunks of obfuscated ecmascript or 'AJAX' junk.
The difference is not trivial. A web page is a document which includes semantic information to facilitate the work of a web browser, whose job is to render web pages as appropriate for the output device it is attached to. A document is inherently safe to handle - the words and thoughts may be dangerous, but the document itself cannot be.
An ecmascript monstrosity is not a document. It is in effect a program that is handed out *in place of* an actual web page, it is not a document and it is not inherently safe, not at all.
When one downloads a strange binary, at least one is not deceived as to what one is doing. It's clearly a security issue, and that's why people have scanners and consider the risks carefully before executing. But an ecmascript substitute for a webpage does deceive the viewer, who often does not realize they are downloading and executing a program, not merely viewing a document. And to add to that insanity, this setup allows the remote server to modify the program they send you on the fly, at will, at any time. So even if you spent hours reviewing it yesterday and found it to be safe *that review guarantees nothing once you reload the page!*
Ecmascript can be considered in abstract isolation and found to be a decent tool for many jobs, surely. But it should not be looked at in isolation, it should be looked at within the context in which it is relied on. A context where it is a tool primarily used to pervert and destroy the open web, in favor of a model where the advertisers own your computer.
If laughter is the best medicine, who are the best doctors?
(Score: 4, Interesting) by novak on Tuesday December 09 2014, @08:45AM
I'll weigh in, I suppose, because I find javascript offensive.
1. Javascript is not in the same league as systemd, not by an order of magnitude. I still think it's bad.
2. Javascript is essentially running unverified code on your machine. Now, in an ideal world this is actually a feature, not a bug, allowing you to run any web program you want on your machine.
In the real world, it means that you have an incredibly complex javascript parser soaking up hundreds of megs of ram so you can view documents. Many of the code snippets are not even from the website you visited, but rather from whatever adds are on the sidebar. So any time you click on a link, to read an article, code from whoever rented addspace is being executed in a manner which is tantamount to a remote code execution vulnerability. It shouldn't be. If things were done better all of our browsers would be running in a secure sandbox, or maybe browsers would just be slow-moving, stable creatures that were well-debugged and hardly ever have any security bugs. In fact, browsers are some of the largest programs, they move at breakneck pace, and they constantly have bugs, including critical security ones. Yeah, that happens when you have a monster codebase moving as fast as you can drag it.
Javascript engines, as I understand, are fairly fast, getting up to 1/2 native C performance in theory. In actuality you probably have enough tabs open and code running that the javascript you are running is not fast at all.
Javascript enjoys its widespread use for a couple of reasons. First, it runs right in your browser, and it did that a long time ago so it is well supported among browsers. Second, increasingly, browsers, not OSs are the target platform of new applications. People want to write their applications as websites, and unless you somehow count flash, javascript is about the only way to do that. I'm not a big fan of using websites as programs, partly because I don't have fast internet, partly because I a bit of a curmudgeon, and also because I like things that are implemented simply.
The problem here is that we're taking javascript, which was originally intended for pretty minor client-side scripting, to add a bit of bling to websites, and demanding that it be our vehicle for writing full-blown programs. It is neither designed nor suited for this.
But for any form of dynamic content on the internet, I don't have a single constructive remark to make, because, really, javascript is the thing that does that. I like old static sites better, usually, because HTML is just much more suited to them, and because they are simple. When you need to go beyond that... You're on my lawn again, you darn kids!
novak
(Score: 3, Interesting) by Arik on Tuesday December 09 2014, @10:01AM
Really? Seriously? Wow.
I would definitely disagree. The worst systemd can hope to do is force me to learn BSD.
The web is much larger and harder to replace than any kernel.
"2. Javascript is essentially running unverified code on your machine. "
EXACTLY.
And this is utter insanity if you care about reliability or security in any way shape or form.
"Now, in an ideal world this is actually a feature, not a bug, allowing you to run any web program you want on your machine."
Same ideal world where there are no passwords, and no one would ever use that fact to log in to your account for anything but a totally legit reason, right?
In the real world the only safe way to interact with any machine whose integrity security and correctness you cannot personally vouch for (which means for most of us most of the time *any remote machine* full stop) is to accept only documents, not executables, from them.
Most people can understand not to run a strange program they downloaded from the internet. But that *doesnt matter* as long as their web browser fails to enforce the distinction. And any web browser that enables javascript fails to do that.
If laughter is the best medicine, who are the best doctors?
(Score: 2) by novak on Wednesday December 10 2014, @02:35AM
Hm, I don't disagree with you as to how evil javascript is. But you can disable it while browsing the web, or better yet use a browser like netsurf or lynx that doesn't even support javascript. The point of systemd is that you can't disable it.
When I do make webpages, which is fairly rarely, I make them static pages, and never include any javascript. I would not ask someone to navigate to a place where I am executing code on their machine. Another thing that helps me get away from dealing with javascript is that I use very few online services. Actually none, unless you count webmail, which I host myself. So the only pages that I go to that include javascript are places that I go to read articles or other interesting info. I can just block javascript, and if the site is non-functional, then it probably wasn't worth reading. I realize that not everyone has this luxury, but not using online services does keep control in the user's hands, so I think it's a good goal to shoot for, at least.
People have called my pages "old looking," and a couple of them have offered to help me redesign. I laugh at that, because I understand how the web works, and "old looking" means functional, not stupidly scripted, animated, and probably huge. I don't test webpages in IE or Chrome, but I do test in lynx. Maybe I only have that luxury because I don't do it for a living, but I'm not really sorry. The web is a mess, browsers are a mess, and it shows no sign of getting better.
Here's a good website, for reference.
http://motherfuckingwebsite.com/ [motherfuckingwebsite.com]
novak
(Score: 3, Insightful) by Arik on Wednesday December 10 2014, @08:47AM
And I do and have always done these things. And I notice that more and more of the web is being shut off to me. This is the most infuriating thing about it - I see webpages turned into webapps with no fallback.
And not just pages I dont care about, unfortunately. Government and bank pages that you effectively *must* access do this. I have one site that I must have access to that worked for 4 years without js without complaint. Then one day it started refusing to let me log in without it. No change in content, no change in function, but one day it was accessible and the next it was not.
THAT is what I find alarming.
If laughter is the best medicine, who are the best doctors?
(Score: 3, Interesting) by novak on Wednesday December 10 2014, @09:52AM
That's one of the reasons I try so hard not to depend on any online services, the other being data security (not that my data is really worth anything, just that it's mine). I guess I don't have any government or bank pages that I require access to.
You make a valid point, though, that the alternative to javascript is simply being unable to use a large part of the web. That is very similar to systemd's plan to force users to conform or be relegated to obsolescence.
I recall seeing a link a year or two back, I can't even find it now- called "this page is what's wrong with the internet," or something to that effect. It was about a web page the author had picked, more or less at random, from a less-than-stellar news website, it's in my mind that it was yahoo news, but that may be wrong. The web page contained a single, small paragraph of text, merely a summary, and weighed in at over 1Mb. That's mostly tracking scripts and unneeded images linking to other pages crowding for attention. That's what the internet is these days, a paragraph of potentially useful text in a sea of useless scripts and ads.
novak
(Score: 2, Informative) by FrogBlast on Tuesday December 09 2014, @03:21AM
AJAX your content in and out of your various DIVs, then style with "resize: both;"
(Score: 2) by SuperCharlie on Tuesday December 09 2014, @03:56AM
My first thoughts too, but it dosent help the scaling thing if they want to drag around frames to resize things.. thus the javascript hell he was referring to. The real solution to that is to make the content look right without having to scale it.. which is change for users to scream about.. So its redesign or leave it. Coin toss.
(Score: 0) by Anonymous Coward on Tuesday December 09 2014, @05:09PM
what do you mean? move things to other places not only resize them? for complicated layouts perhaps flexbox can help instead of using float.
and you don't need ajax to be able to use resize css.
mechanicjay: make sure your website is fully usable with javascript off! otherwise you will just replace one bad thing with another.
Btw, how about making a real program for your users instead of putting things in webpages? :-O
(Score: 4, Insightful) by AudioGuy on Tuesday December 09 2014, @10:01AM
But are still here. I think they were created in 1995 or 1996, and deprecated about 1999 or so, it is now 2014, almost 2015. So they have now been deprecated several times as long as when they were not. :-)
The one single thing I can see that you can do with a frameset that cannot be done with an iframe (not deprecated) is allow the user to resize areas.
If your pages flow in a reasonable way and there is still a need for that, why not use a guaranted reliable and compatible frame to do this?
Just don't mark your page html 5, and it should work for a very long time - browsers are SUPPOSED to support older versions of html, that is why we have that versioning. HTML is supposed to be 'view forever'.
I suspect you are not the only one with this problem and if browsers really DO stop supporting frames, there will be a major outcry to add that particular feature (user resizing) into iframes.
Javascript is a poor, slow, and unreliable substitute.
Frames were deprecated because of people using them for things they really were not appropriate for. It sounds like you have a reasonable use case. They break the back button, but that is primarily a problem for new users, not something likely to cause grief in an internal network - plus the internet is no longer as full of 'newbies' as it was before 2000.
It is hard to make an intelligent comment about a page that cannot be seen. People might have better feedback if they could actually -see- the usage. (Doesn't have to be the real page)
(Score: 0) by Anonymous Coward on Tuesday December 09 2014, @02:41PM
The one single thing ... that you can do with a frameset ... is allow the user to resize areas
Why doesn't a modern web browser let the user resize div's?
I say the solution is to upgrade the users web browsers to something that can. You can resize this form field with just a mouse. and no javascript involved (I don't even have javascript on), why not let the user change any area?
(Score: 0) by Anonymous Coward on Tuesday December 09 2014, @04:48PM
Reading this Ask Soylent today I learned that modern web browsers now do let the user resize things. sweet!
Finally a real reason to upgrade from Firefox3.6.x, now if I could only make the newer ff versions have a decent userinterface instead of the way mozilla completely damaged it.
(Score: 1) by NowhereMan on Tuesday December 09 2014, @06:51PM
Try out Pale Moon, It's a fork of Firefox but doesn't use the new Chrome like interface, you can put the tabs above or below the address bar, you can turn the old style menu on or use the single button menu. I've been using it for some time as are many others here and it is my browser of choice.
http://www.palemoon.org/ [palemoon.org]
(Score: 2, Insightful) by lizardloop on Tuesday December 09 2014, @10:29AM
I would let them have frames. I really don't see the problem with them. What is the problem that frames are causing that means you need to get rid of them?
I could understand if it was some IE6 dependent piece of ActiveX you were getting rid of. But frames are still well supported by all browsers and will be so for a long time.
(Score: 2) by tempest on Tuesday December 09 2014, @02:13PM
I'd second this. Whatever you do it's going to be a pain in the ass, likely less functional, and probably just make users unhappy. I got caught up in the HTML4 BS of the "document structure separated from presentation", but that doesn't neccesarily make things easier. You look at some code these days and it's divs/spans nested 20 layers deep instead of using a simple table.
This doesn't mean the app couldn't use refactoring though. Perhaps reducing the number of frames, or eliminating framesets embedded in framesets. Just because frames were abused 99% of the time, doesn't mean they didn't have their place in 1% of cases. If the back end is cleaned up correctly, you should be ready to move away from framesets when support really becomes a problem (maybe 20 years down the road).
(Score: 1, Redundant) by PizzaRollPlinkett on Tuesday December 09 2014, @11:58AM
The question never actually tells what a "frameset" is and gives no context to figure it out. Do you mean you're stuck with some old framework like Java Server Faces no one uses and is a technological dead end?
(E-mail me if you want a pizza roll!)
(Score: 0) by Anonymous Coward on Tuesday December 09 2014, @03:59PM
I'd guess the question never states what a frameset is because any input of anyone who doesn't know it is likely not helpful anyway.
If you don't know what a frameset is in the context of the web, you obviously don't know much of that subject. So how could you give advice about it?
(Score: 2, Insightful) by Anonymous Coward on Tuesday December 09 2014, @12:08PM
If it is not broken, don't fix it.
If the frame interface does everything you want, leave it alone. Any reimplementation to use other technologies risks
Only if there are problems with the frame implementation (say, it hinders you from implementing some feature the users desire) it is reasonable to change it. And if you change it, make sure your users will like the change. Don't give them a Slashdot beta experience.
(Score: 0) by Anonymous Coward on Tuesday December 09 2014, @04:25PM
as mentioned in a reply above it is easy to set a css that lets users resize the regions on that screen with,
resize:both; <--- to allow resizing
overflow:auto; <--- to show scrollbars if needed
Here is a guide from 2012 about that:
http://www.developerdrive.com/2012/06/allowing-users-to-resize-web-page-elements-with-css3/ [developerdrive.com]
But why should I as a user be bound to what the website maker thinks should be resizeable or not? So my question is where do I change something (in Firefox or PaleMoon) to let me the user actually resize anything? Would it be some user-stylesheet with a line * {resize:both !important; overflow:auto;} in it ?
or perhaps I better set it to anything that is not an inline, how would I do that?
(Score: 1) by Yog-Yogguth on Wednesday December 10 2014, @03:09AM
Yes a user-supplied stylesheet should do it; just add the appropriate css there.
If that isn't fancy enough or the css is lacking you can have a look at Greasemonkey scripts over at http://www.greasespot.net/ [greasespot.net] and http://wiki.greasespot.net/User_Script_Hosting [greasespot.net] or go all the way by using wget [wikipedia.org] to use the page as input to an entirely independent script that modifies it as you wish before sending it to a browser (or anywhere else). All the Greasemonkey extension really does is to do it all within a browser.
I never really got into it so I can only point you in the general direction.
Bite harder Ouroboros, bite! tails.boum.org/ linux USB CD secure desktop IRC *crypt tor (not endorsements (XKeyScore))
(Score: 1) by hogger on Tuesday December 09 2014, @09:49PM
You could use divs in place of the framesets, add overflow-y=scroll to get the vertical scrollbar, and create a short javascript function to resize the divs realtime.
Calling the js function when the user wants to adjust the frames/divs would just depend on what you use for your selector. You could use an image map of a single pixel.gif and get the clicked area, then your js function could figure out where the user clicked. I tried that just now, it works ok.
Or, you could use one of the fancy new html5 sliders - input type="range". That would work great for left-to-right resizing. Up-to-down resizing might get a little tricky because input type=range vertical sliders aren't well supported across all browsers. I created a little fiddle that basically does it though. It works in chrome and FF, not so much in IE9. Apparently the newer IEs have a little bit better rotation transforms.
Here's a mockup of it kinda working with an html5 slider:
http://jsfiddle.net/nshaver/Lsz8ya1n/3/ [jsfiddle.net]
There are lots of ways you could get your slider, but the resizing of the divs is fairly simple with straight javascript.
(Score: 3, Interesting) by mechanicjay on Wednesday December 10 2014, @04:28PM
Thanks for all the comments on this. I was seriously contemplating abandoning the css and divs and returning to a frameset.
I've gone back and asked for the specific use cases where they found themselves resizing stuff and its in two scenarios
As it turns out, when I'm done with a responsive overlay with bootstrap, the first case will be moot, since we can define at what screen sizes the divs will reorder/stack/expand, etc. Also, I've made the display of data little more compact, making the problem even less prevalent. The hiding thing is super simple with a hide/show button for the sensitive stuff
My VMS box beat up your Windows box.
(Score: 2) by urza9814 on Wednesday December 10 2014, @07:52PM
Just ask yourself one question first: Why?
The other stuff you've done sounds good so far. Move the CSS, move the JS, keeping things separated generally makes it easier to maintain, because you don't have to go chasing code all over the place.
Removing frames though...what's your reasoning for that? Some best practices guide said so? Who gives a damn? That's only to prevent the 90% of people who use them wrong. They're still part of the standard, and they're in there for a reason. Sometimes they are actually the best solution.
I've specifically searched for technical arguments against using frames a number of times, but I've only ever found one: that it makes it harder for search engines to index your site. But that became obsolete many years ago as search engines became more advanced. And this sounds like an internal site anyway, so you probably aren't trying to get it highly ranked by Google.
So what makes you think sticking with a frameset is going to screw the future? It's not a deprecated feature, and I doubt it ever will be because there is plenty of functionality which frames provide that simply cannot be implemented any other way (ie, including data from an external website. Cross-site scripting protection will prevent you from doing that almost any other way).
If you were purely using them for layout reasons as a lot of people once did, then I'd say you should definitely replace them. Layout should be done in CSS. But you're using them to get specific functionality too. That's perfectly acceptable. Replacing that with some crappy Javascript kludge is not.
The only case in which I'd say you should replace the frameset with something in CSS or JS is if you want it to expand only to a small number of predefined sizes. Then you can toss in a couple buttons to snap to one of those sizes. But that's still more effort than necessary and would result in a reduction in functionality and a fair bit of code bloat.