The Elephant in the Browser

I think its time we talked about JavaScript.

This is something that I believe we badly need for RISC OS to progress and I was wondering what everyone thought about it, and if anyone had any bright ideas. The way I see it we have several options:

1. Resurrect Firefox. This could be a big problem because Firefox development has moved on at an alarming rate on other platforms, and from what I gather, it was always a bit problematic on RISC OS
2. Resurrect !Browse with JavaScript – am I correct in assuming that a basic JavaScript engine was part of !Browse but was never properly developed?
3. Resurrect WebsterXL. As a commercial project this would obviously require input from R-Comp but I think if there was a really good browser that had a fully working JavaScript engine I wouldn’t mind paying a bit for it.
4. Add JavaScript to NetSurf. The development plan for NetSurf states that they want to change the layout engine when they release version 4 and that this will bring JavaScript. How much work will it involve to make sure that version 4 with the new layout engine actually works on RISC OS?

As an interesting aside – I found a potentially useful tool that (as I understand it) could be included into one of the browsers to get JavaScript working: Duktape – I wonder what people think of this? Is it possible to use with one of our browsers?

(oh, and in case anyone is concerned I’m still looking at NetSurf when I get the chance, although at the moment this will only be a couple of hours a week at most – initially I’m going to get to grips with the source and hopefully fix a few bugs but ultimately I do want to help with the JavaScript engine…if that is the best way forward?)

There’s only one option realistically that’s option 4.
“Adding” javascript is a world of pain, javascript in general is a world of pain. It’s horrible.

My only concern is that with the move to the new layout engine for NetSurf (no details of what the engine is: clicky ) that there is even less support/more complications for RISC OS – from previous discussion on here it is evident that there are only a few of us working on the RISC OS port of NetSurf now and our time is unfortunately quite limited.

Although I am committed to helping NetSurf develop I do worry that we are putting all of our eggs into one basket. Now it might be that this basket is wonderfully padded, super strong and carried everywhere lovingly on the back seat of a 2CV…but its still a concern…

Duktape will not help you (much). The problem with adding JavaScript support to a browser is not to be able to interpret JavaScript code, but to integrate it in everything the browser can do, namely manipulating the DOM. This is (I think) the reason why JavaScript integration in NetSurf will take a while – you have to enable many parts of the browser to integrate with your scripting engine.

These technical challenges are also the reason why options 2 (the JavaScript-enabled brother of Browse was called Phoenix btw) and 3 won’t work. Of course there are also other reasons like not having any meaningful support for modern HTML and CSS.

Short-term, I think we have to acceppt that there just is no solution. Investing in a RISC OS future of NetSurf is certainly a good idea, because it is a browser well-suited to RISC OS and by far the best we have.

Long-term, the only solution is to port one of the two modern browser engines – Firefox or WebKit. WebKit is the base for many browsers including mobile phone ones, so I could imagine that it is easier to port than Firefox.

Don’t forget that porting Firefox and/or WebKit will also benefit many other ports because of the sheer amount of dependencies that would have to be ported, too. Long-term, I think RISC OS can only stay (or become!) a credible platform if powered by a mixture of native and ported applications – the ported applications constitute the “base load”, the software everybody has got used to expect on any platform. The native applications are then the icing on the cake.

Just a random thought – any remote tiny possibility of reawakening Fresco or Oregano? Those (26 bit era?) browsers both offered some form of javascript.

I think Steffen has it spot-on. Path of least resistance going forward is to try and keep the RISC OS port of NetSurf alive. The older RISC OS browsers are too far behind.

It may be interesting to look at what would be needed to create a WebKit-based browser. Even if that didn’t come off, there would be some useful learning in bringing over various subsystems. I always got the impression that this was the theory behind Peter’s ‘Unix Porting Project’: it had a goal of bringing Firefox, but there were all sorts of other bits on the way.

Both Fresco and Oregano (1 and 2) suffer from the same problem as Browse and WebsterXL: no meaningful support for modern web standards like HTML4+ and CSS. JavaScript support was very weak (Oregano 2 was best, but still a long way from being good and useful).

The Web still moves fast. I think it is a catch-up-race we cannot sustain. Porting (and keeping the port up to date!) takes less resources than home-grown implementations.

It would be interesting to hear from the NetSurf developers about their “catch-up-experience” and their thoughts on manpower requirements of porting vs. implementation.

Which Javascript? Yes, I know that there is supposed to be a standard, ECMA . I seem to remember that Fresco, Oregano, Phoenix and Webster were all trumpeted to have Javascript but not only were their interpretations partial and different, they were also impossible actually to discover. I can understand that their developers were put in a difficult position by requests for information.

I heard tell of an embarrassing incident at a BETT show in London when a demonstrator clicked on the wrong link and found that his audience of teachers were staring at pornography. The problem was that Javascript on the offending page had taken over the window controls – something possible with his browser (Internet Explorer?) – so the only recourse that the demonstrator could find in the urgency of the moment was pulling the plug. I suspect/hope that RISC OS may be a difficult platform for this kind of behaviour to be implemented on.

Maybe the way we can have our cake and eat it is to encourage NetSurf to use a port the Gecko engine (as used by Firefox) for version 4?

I’m not sure how much of a headache using C++ would be though…?

Obviously I cannot speak for the NetSurf developers, but I cannot imagine that putting Gecko (or WebKit) into the heart of their browser could possibly be in their interest.

NetSurf is advertised as a fast and resource-saving browser that is easily portable also to non-linuxy platforms. If you implant Gecko, you lose all three main selling points and end up with an “also-based-on-Gecko” browser. Development would be more “how to integrate Gecko and put some shiny UI around it” and less “read those interesting web standards and think about how to implement ’em cleverly”.

By coincidence, I’ve just been in a developer lunch at work, the topic of which was HTML5. It’s clear that various additions along the web browsing route (jQuery for example) have made browsers more useful as control panels. Control panels are what we often want, but implicit in a control panel application is status monitoring – which requires information to be pushed from the server, not merely pulled from the client. Websockets, which are in HTML5, will make this better again by allowing proper server pushes, rather than repeated client pulls in case something has changed.

The Netsurf developers are doing sterling work, but there just aren’t enough of them to keep up with how the web is moving.

Keeping Netsurf alive is the best way forward. However, RISC OS needs more people developing for it. ARM programmers are out there, but they’ll (probably?) have to backpedal their skills to suit the OS, you need the critical mass to get things done quickly.

I can see why the Netsurf team have gone for Duktape – many of the JS engines are pretty unwieldy. If RISC OS PI is to get a foothold in applications concerning Internet Of Things, then having a small JS engine like Duktape may provide a niche for us?

Do a Google for Javascript: The Good Parts by Douglas Crockford – Javascript is not so mean and nasty these days (did I just say that?)

It puzzles me that some people still say that Javascript is nasty. I have long seen the usefulness of it.

If Acorn had invented it, I’m sure all RISC OS fans would be trumpeting it to high heaven.

I like JavaScript but I can see how people would take issue with it when every engine/browser treats it slightly differently to the point where a well designed website just doesn’t do what its supposed to do. One of my favourite applications that I ever built was a replacement for Windows based CHM files that used HTML and jQuery to render the help content into a stripped back embedded version of the K-Meleon browser. It worked and looked wonderful and then when I came to deploy the same HTML help files elsewhere they just looked awful because the other browser that was being used had a different layout engine and screwed things up.

The Netsurf developers are doing sterling work, but there just aren’t enough of them to keep up with how the web is moving.

You are right of course, perhaps we need to attract more developers? Hopefully I can devote some of my time and maybe one day I’ll be a NetSurf developer too! :—)

Obviously I cannot speak for the NetSurf developers, but I cannot imagine that putting Gecko (or WebKit) into the heart of their browser could possibly be in their interest.

True it does seem to go against some of the philosophy but faced with the alternative of developing a unique engine which will take years of effort or using one that is already mature maybe some compromises can be made? Also I’m fairly certain Gecko has already been ported to various operating systems (Amiga, BeOS) so it might be that it could work well with NetSurf. The ideal, would be an in-house strictly standards compliant fast/small implementation – but do we have the resources to do it?

http://ietf.org.uk/browser.html

every engine/browser treats it slightly differently to the point where a well designed website just doesn’t do what its supposed to do.

Surely that’s the point of jQuery – not only does it give you shortcuts for common groups of DOM operations, but it also has browser quirks and workarounds built-in?

Most amusing Peter :-) You have it in a nutshell!

It would probably involve a great deal of work, but one way to get better apps for RISC OS would be to port a modern GUI toolkit—I’m thinking here of the cross-platform Qt toolkit: it’s very well-documented, and has been ported to a number of different OSs in the past—including some less common ones (Haiku). It also supports WebKit and there are Qt-based WebKit browsers (e.g. QupZilla).

On the down side, it’s C++ based and the results are not likely to run on a Risc PC—but is it still wise to make the Risc PC the baseline? Perhaps the Pi ought to be the baseline now?

It would probably involve a great deal of work, but one way to get better apps for RISC OS would be to port a modern GUI toolkit

Portability is one way to get new applications. As a web browser is one way to get access to Internet services. Android apps proved that you can work online with applications… and that the users don’t need a web browser for this. Thanks to the mobile world, Internet is today more API than Web.

Problem; for a non-web-centric OS, you need more applications. Applications for the desktop, of course, but also applications connected to web services. There is here a real challenge: to get a Xojo like environment to make GUI applications in hours and not days, and to integrate web services in the applications.

The point is that since there are only a few people to make new applications, you must find some ways to make them in less time.

Now for the web browser, the problem is not JavaScript, but the DOM, and only the DOM (please note that NetSurf has already a complete JavaScript engine). One solution could be to interact with web applications with a JavaScript engine not linked to a web browser. A node.js+weboob solution :)

Nota: for the web browser issue, I bet more on VM. Use Firefox under a mini Linux container :)

Long time ago, some people were working on closed to native speed emulation of an ARM computer under RISC OS. With Cortex-A15 and Cortex-A7 machines, you could also use hardware virtualization.

You can also simply use a Linux Pi as a slave. But we would need here good X and VNC support.

(Peter) http://ietf.org.uk/browser.html

Cost: As hinted by earlier posts the days of a commercial browser are gone. Too many instances of widely available freebies to be able to persuade people they need to pay anything at all.

Four of me? Not done a recent count, I keep quiet to avoid the therapists anyway.

(David) port a modern GUI toolkit—I’m thinking here of the cross-platform Qt toolkit:

Good idea, I’ve lost count of the number of items where the show stopper for a port of something was the lack of Qt or similar.

On the down side, it’s C++ based and the results are not likely to run on a Risc PC

In modern terms nothing much runs on the Risc PC, it might move but it isn’t moving quickly enough to count as running.
Oh, my mail installation of Pluto does an admirable job with a stupidly large set of mail files but the beagleboard nearby will expire and compress the same mail set in seconds rather than a number of minutes.
The RO5.20 IOMD is an experiment on my part rather than an attempt to keep the RPC as a main machine.

is it still wise to make the Risc PC the baseline? Perhaps the Pi ought to be the baseline now?

Work on the Pi2 as a baseline – forces the issue of making the code ARMv7 safe so everything currently available should be happy running the code.

http://ietf.org.uk/browser.html

While really amusing (especially if you know Chocky’s original version), it also illustrates nicely how fast the web moves: nowadays, nobody really needs Flash, Java or RealAudio in a browser.

it also illustrates nicely how fast the web moves: nowadays, nobody really needs Flash

Unfortunately a well known network vendor¹, of other peoples ideas from a number years ago given a “today” gloss² and a load of marketing spin, produces GUI interfaces for products using Flash, Flash and Flash with bit of other code to glue things together.³
You can tell I’m a fan can’t you (or not). Yes, I just love the GUI on ISE.

¹ Cisco
² Cisco call their switch cluster VSS, Nortel labelled it differently when they created it over 10 years ago. I wonder what Cisco will call SMLT?
³ This raises no eyebrows among devotees as said devotees declare GUI interfaces to be crap (familiarity with their renditions and the devotees refusal to look at other vendors soon explains this)

I think Netsurf’s RISC OS Caveat needs to be updated!

I think Netsurf’s RISC OS Caveat needs to be updated!

How so? Everything I’ve just read on that page is still pretty accurate.