What should be NetSurf's priority?

Development work on the open source NetSurf web browser project will once again be funded by Google as part of the internet giant's Summer of Code scheme. NetSurf has been accepted into this year's GSoC, which pays students to develop open source software during their holiday, under the guidance of a mentor. This year it's hoped budding engineers, who must first successfully apply for a place to work on the browser, will work on various improvements. What do you think the NetSurf team should be focusing development on?

What should be NetSurf's priority? Keyboard navigation 1% Page reader for the blind 2% Improve display of websites 11% Improve the user interface 2% Port to Windows or Mac OS X 6% Work on achieving JavaScript support 63% Dave Holden 17% Discuss this | Archives

Previous: Google to fund another round of NetSurf development
Next: USB memory stick app bugfixed in time for British Summer Time

Discussion

The three key priorities for me are Dave Holden, improving the display of websites, and Javascript. Unfortunately I could only vote for one of these. fylfot on 23/3/09 12:10PM [ Reply | Permalink | Report ]

I fear we may have taken our eye off the ball here. We've been so busy working on improving rendering and laying the groundwork for JavaScript that we appear to have missed the huge importance of Dave Holden to our users. jmb on 23/3/09 12:26PM [ Reply | Permalink | Report ]

Perhaps you could placate Dave by announcing NetSurf 2 as NetSurf Dave Holden Edition! sa110 on 24/3/09 11:39AM [ Reply | Permalink | Report ]

All Hail The Dave! hEgelia on 24/3/09 3:31PM [ Reply | Permalink | Report ]

sa110: excellent idea on naming. But to be clear, I'm not sure it would be about placating Dave Holden. More about recognising the "huge importance of Dave Holden to [NetSurf] users", as jmb wisely recognises. My only personal concern would be that Dave receives all the support he needs as this progress occurs. He must be feeling a bit faint-hearted. fylfot on 24/3/09 11:53PM [ Reply | Permalink | Report ]

I voted for "Improve display of websites" because that's all browsers' priority, surely. However, what I'd actually want to see is better memory handling - it doesn't half leak memory... it's by far the leakiest RISC OS software I use - the only program I regularly quit and restart just to get my 256 MB of RAM back! riscosopen on 29/3/09 11:16PM [ Reply | Permalink | Report ]

NetSurf leaks very little. The problem is that RISC OS's memory management doesn't lend itself to situations where an application's heap can become fragmented. The memory is free, unfortunately, it's only available to NetSurf to use again. Several people (including myself) have looked into using sparse dynamic areas to help solve this issue (although it'd appear to be using more memory than it was!), it is unfortunately just too soul destroying. rjek on 30/3/09 2:37PM [ Reply | Permalink | Report ] Fragmenting or leaking is an internal distinction; to the rest of the system, it's a memory leak. Browse/Phoenix had the same problem so it used a shifting heap - which has a performance penalty but you can limit the shifting to odd occasions (such as closing a window). If you simply held all of the image data and raw HTML for each page in its own DA, then that could easily be discarded when no longer referenced. I bet it's images which cause the bulk of the fragmentation. riscosopen on 30/3/09 3:50PM [ Reply | Permalink | Report ] (I meant one DA per browser window, BTW.) riscosopen on 30/3/09 3:51PM [ Reply | Permalink | Report ] Sorry, I don't think any of the NetSurf developers think that OS- and Application-specific hacks like you suggest beat the generic solution of having an OS with a memory allocator from the 20th century, or a C library that hides that hideousness from us. rjek on 30/3/09 4:16PM [ Reply | Permalink | Report ] All very worthy and architecturally beautiful, I'm sure. Back in the real world, cross-platform software has what we call a "porting layer" full of "glue code" which often boils down to exactly what you are brushing aside. It's saddening that you are so quick to dismiss the very platform which gave birth to NetSurf, especially as that still (probably) represents a significant number of your users. Stick to using Firefox on Ubuntu then, should I? riscosopen on 30/3/09 8:46PM [ Reply | Permalink | Report ] We'd rather the problem was fixed in the right place. Which unfortunately will never happen, so the C library is the next best choice. Adding in multiple layers of ugly hack to fix an issue unique to just one system NetSurf runs on seems like the wrong choice, no? If we didn't think very carefully about everything we do, NetSurf would just be another WebsterXL. And nobody wants that. So you're damned right we aim for the worthy and architectually beautiful. (And unfortunately, sliding hack heaps are not something you can easily abstract, which means even the OSes with designs from the last 30 years would have to suffer the performance-degrading foulness.) rjek on 30/3/09 8:58PM [ Reply | Permalink | Report ] Given the extensive list of platforms that NetSurf runs on, I don't think we need a lesson in how to make our software portable. NetSurf is quite unashamed in requiring a functioning POSIX runtime. There are many good reasons for this, not least that all the "glue code" of which you speak may be shared between all applications on the platform, rather than each application reinventing the wheel. On RISC OS, this runtime is UnixLib and it is that which needs improving. As ever, that requires someone with the time and inclination to sit down and perform the necessary work. Using sparse dynamic areas for heap space is not unknown on RISC OS -- the Java port used it, for example. (Incidentally, I've lost count of the number of improvements and fixes to UnixLib that have occurred as a direct result of NetSurf's requirements.) As for dismissing RISC OS, I don't consider a desire to make life simpler for application authors dismissive. There are few enough developers for RISC OS as it is without making life even harder by forcing them to avoid standard language features such as malloc() and free(). Nor would I have just invested a huge amount of time and effort in implementing a remote debug server for the GNU debugger so we finally have meaningful source-level debugging for applications compiled with GCCSDK. As for your choice of browser, that's up to you. Noone's forcing you to use NetSurf. jmb on 31/3/09 2:15PM [ Reply | Permalink | Report ] Wow! When the topic of conversation is "What should be NetSurf's priority?" and I suggest one area where I find NetSurf is weak that could be improved, I should have expected a barrage of defensive flaming. Of course it's my choice of browser, of course it's up to me. But hello! I'm one of _your_ users reporting a problem. NetSurf eats all your memory when used on RISC OS. You guys are aware of the issue but don't want to spend your time on OS-specific stuff to fix this because you don't believe it is a priority or good use of your limited resources. Fair enough. Your point about making life simpler for application authors is a complete red herring. Portable software stacks often abstract library functions such as malloc() and free() through their own veneer - primarily because you cannot rely on standard implementations doing everything you need (like helping you to debug memory leaks and crashes, for example). Anyway, I've raised the issue and you guys quite rightly have more important stuff to work on so enough is enough. riscosopen on 2/4/09 10:28AM [ Reply | Permalink | Report ] > barrage of defensive flaming I didn't read it as that and I doubt that's how it was intended. They explained their point of view, which you had been questioning. I know for a fact that there have been earnest attempts to get UnixLib to use sparse DAs to solve precisely this issue. I'm not sure why it wasn't finished. More pressing demands on people's, time I expect. tlsa on 2/4/09 2:13PM [ Reply | Permalink | Report ] > More pressing demands on people's time I expect Like implementing Dave Holden of course helpful on 2/4/09 5:28PM [ Reply | Permalink | Report ]

Riscosopen, rjek: no doubt these are important considerations from a software-design POV, but speaking as a non-expert user of RISC OS NetSurf over the past 2 or more years, I have not suffered from the memory-leakage (or if so, not from its effects) as described; NetSurf works just fine on my 512MB Iyonix and doesn't appear to interfere with any other programme (as well as NetSurf I normally have Firefox, MessPro, DrawPrint, Geminus, Task Usage, Techwriter, Netfetch, PDF, Alarm, SwiftJPEG, AemulorPro, Printers, BlackHole and HID permanently running, typically supplemented by several out of Rhapsody, KinoAmp, Photodesk, Artworks, DPingScan, Thump and Variations, several of which have multi-MB caches configured). bucksboy on 31/3/09 10:23AM [ Reply | Permalink | Report ]

I've noticed the memory leak, though only before I'd installed extra memory. Was constantly running out of the 32mb. Once on 128mb though, either its stopped or, more likely, is negligible. My personal gripe is some of the text entry handling. I'm glad to see clipboard options being added to the menu, but there are other issues. As I'm typing in this box on the drobe page I instinctively highlight text with the mouse and hit delete, or backspace. Nothing. Couldn't a more sofisticated text editor be intergrated into it, rather like a plug-in for the 'big' browsers? I'm aware this may not be the most elegant solution, but its better than unintuative text entry, surely? Monty on 31/3/09 12:51PM [ Reply | Permalink | Report ]

Consider the following from the GSoC ideas list: "A plotter-based (single & multi line) text input widget." We're aware that text input still has issues. However, there simply aren't enough hours in the day to fix everything straight away. jmb on 31/3/09 2:20PM [ Reply | Permalink | Report ] One of the GSoC ideas (core UI enhancements) includes creating a new text input widget. So it's already planned. Whether it gets done as part of GSoC depends on the applications we get and what work accepted students manage to do. tlsa on 31/3/09 2:28PM [ Reply | Permalink | Report ] It would be truly fantastic if, when this text input widget does get some attention, a certain amount of consideration could be put into IME-type input. It's the perfect way to implement such a feature, and, like many other parts of the Netsurf project, it could perhaps be wrapped up in a generic package for use by other applications. I've spent weeks and months (years if I'm honest!) playing around with ideas for this, and have come up with quite a few useful thoughts, but I just don't have the spare time to implement them. Perhaps a GSoC applicant would! wpb on 7/4/09 9:30AM [ Reply | Permalink | Report ]

Thought someone might be interested that I've found a (non-javascript using) website which runs better on Netsurf on a RiscPC than Firefox 3 on a hefty Core2Duo box. anywherebb.com Admittedly, there are some issues with the layout, but nothing significant. WinXP Firefox scrolls like a fat man waddling to the chippy compared to Riscos Netsurf's 100 yard dash. Must be an odd page design I suppose. Monty on 31/3/09 12:59PM [ Reply | Permalink | Report ]

I think Javascript is a must, the last 10 websites I have helped develop (already existsed before), ALL use AJAX. It's very important that as 3 of them are webware, you really only see one HTML page whose content is altered via getViaHTTP() function to grab HTML templates (Pages in their own right) and display them in a 'MainContent' Div. These simply show the front page in Netsurf (and very well rendered too :@D ) but clicking on the buttons (which won't roll over) does nothing. :@( Also a note as a Chrome user, what about the <Input> tag boxes which you can resize ;@)I have found that feature most useful (like on the drobe response box) when I feel I want to see more of what I have written! :@D Good job though! em2ac on 31/3/09 1:32PM [ Reply | Permalink | Report ]

Why not have, you know, links to change the content on the page, rather than HTML injected into the DOM via JavaScript? This has the advantage that it doesn't screw up history navigation, too. rjek on 31/3/09 2:17PM [ Reply | Permalink | Report ]

This is fine for websites (and I personally prefer that method) But for web applications such as those I have developed for, "They" wanted it to act as an application, so that it looked less like a website and more like a program which anyone could access without software being installed on their PC/Mac/Linux/Whatever box :@) I already had to show them why IE6 only was a bad idea, I couldn't push them further :@D I also personally prefer the :hover CSS declaration to Javascript rollover too, but using JQuery, I have them fading from one state to the other (Vista user request!) em2ac on 31/3/09 2:25PM [ Reply | Permalink | Report ]

I suggest educating the people you work for. A stick with rusty nails in it might be handy for this task. rjek on 31/3/09 2:39PM [ Reply | Permalink | Report ] I can appreciate your clients wanting the website to be more like a web application. But using jQuery for fading out hover's - that's beyond belief. I second rjek's suggestion! sascott on 8/4/09 9:38AM [ Reply | Permalink | Report ] It's just using a JavaScript library to add visual effects which (in that site's author's opinion) make the site more visually attractive and compelling. It's the year 2009 and, frankly, we should be demanding more from cross-platform standards like HTML/CSS/JS, not less. The limited ability to animate pages thanks in part to the lack of widespread SVG scripting or canvas support is a pretty sorry state of affairs all things considered. Some people want dynamic, animated features. Apart from anything else, if done well animation can help the user understand the correlation between action and response. If the site author hadn't done that in JQuery, there's a high chance that it would've ended up as a Flash or Silverlight navigation bar and then everyone would have lost - except Adobe and Microsoft, I suppose. There was a time when JS was just some ugly backwater bolt-on hack, but once the DOM interface became standardised things got a lot cleaner. The language itself is actually pretty good (provided you're capable of understanding the concept of prototypical inheritance rather than classical inheritance) and modern implementations have reasonably good performance characteristics for the core language too. Some of the interactions with the document can be sluggish but that's often due to impossible-to-implement-efficiently features in the HTML and CSS specifications and little or nothing to do with JavaScript per se. Well designed web sites using AJAX principles can work more smoothly with lower server load and a better client UI than static alternatives. You can actually end up with lower CPU and RAM requirements in the client depending on the nature of the task at hand. Although the total architecture as a whole is rather baroque and at times grotesque - HTML just wasn't really designed with any of this in mind - it works surprisingly well and libraries such as Prototype, JQuery, Dojo and YUI take the heavy lifting of dealing with browser bugs and feature variations away from the site author and into the JS library layer. Authors should always endeavour to make their use of JavaScript unobtrusive and have it degrade gracefully, but sometimes there just aren't enough hours in the day to struggle with the significant limitations of bog standard HTML controls for a non-JS version of a page, when a few minutes with your JavaScript toolkit of choice will give a superior interface in a fraction of the development time. History has also shown that people can shout about what people should do with web technologies as much as they want, but for every accomplished, diligent and careful site author there are a hundred hackers doing things the "wrong way" and there are no signs that this is going to change. That's been the reality of the web for years as the NetSurf developers, like any web browser developers, will be painfully aware! There are many things which NetSurf could implement, all of which might make areas of the browser a little better. But the one glaring omission is JavaScript and, although this may have been omitted for very good reasons, it's clear that the range of sites which NetSurf can access without it is only going to get smaller as time goes by. If the browser intends to be a viable option for general web use in future, JavaScript must be integrated. adh1003 on 29/4/09 6:36PM [ Reply | Permalink | Report ] And no, I can't believe that I've just been arguing pro-JavaScript either. My, how times change adh1003 on 29/4/09 6:40PM [ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Search the archives

Today's featured article

From the BBC Micro, little Acorns grew : The Guardian reports

 Discuss this. Published: 8 Mar 2001

Random article

Waving the RISC OS banner
Share web banners with fellow RISC OS sites
 11 comments, latest by on 20/12/01 10:54AM. Published: 31 Oct 2001

Useful links