RISC OS Open
Safeguarding the past, present and future of RISC OS for everyone
ROOL
Home | News | Downloads | Bugs | Bounties | Forum | Documents | Photos | Contact us
Account
Forums → General →

The Elephant in the Browser

Subscribe to The Elephant in the Browser 106 posts, 28 voices

Posts per page:

Pages: 1 2 3 4 5

 
Mar 5, 2015 9:57am
Avatar Glen Walker (2585) 469 posts

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?)

 
Mar 5, 2015 10:14am
Avatar Malcolm Hussain-Gambles (1596) 811 posts

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.

 
Mar 5, 2015 10:24am
Avatar Glen Walker (2585) 469 posts

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…

 
Mar 5, 2015 11:23am
Avatar Steffen Huber (91) 1847 posts

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.

 
Mar 5, 2015 11:46am
Avatar Rick Murray (539) 12521 posts

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

 
Mar 5, 2015 12:37pm
Avatar Richard Walker (2090) 367 posts

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.

 
Mar 5, 2015 12:40pm
Avatar Steffen Huber (91) 1847 posts

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.

 
Mar 5, 2015 12:45pm
Avatar GavinWraith (26) 1451 posts

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.

 
Mar 5, 2015 12:56pm
Avatar Glen Walker (2585) 469 posts

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…?

 
Mar 5, 2015 1:15pm
Avatar Steffen Huber (91) 1847 posts

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”.

 
Mar 5, 2015 1:57pm
Avatar Dave Higton (1515) 3112 posts

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.

 
Mar 5, 2015 2:16pm
Avatar Stephen Scott (491) 36 posts

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?)

 
Mar 5, 2015 2:25pm
Avatar Dave Higton (1515) 3112 posts

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.

 
Mar 5, 2015 2:50pm
Avatar Glen Walker (2585) 469 posts

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?

 
Mar 5, 2015 4:02pm
Avatar Peter Howkins (211) 215 posts

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

 
Mar 5, 2015 4:39pm
Avatar Tony Noble (1579) 62 posts

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?

 
Mar 5, 2015 4:59pm
Avatar Stephen Scott (491) 36 posts

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

 
Mar 5, 2015 6:46pm
Avatar David Gee (1833) 215 posts

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?

 
Mar 5, 2015 7:17pm
Avatar David Feugey (2125) 2628 posts

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 :)

 
Mar 5, 2015 7:40pm
Avatar David Feugey (2125) 2628 posts

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.

 
Mar 5, 2015 7:45pm
Avatar Steve Pampling (1551) 7459 posts

(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.

 
Mar 5, 2015 8:10pm
Avatar Steffen Huber (91) 1847 posts

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.

 
Mar 5, 2015 8:38pm
Avatar Steve Pampling (1551) 7459 posts

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

Unfortunately a well known network vendor1, of other peoples ideas from a number years ago given a “today” gloss2 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.3
You can tell I’m a fan can’t you (or not). Yes, I just love the GUI on ISE.

1 Cisco
2 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?
3 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)

 
Mar 5, 2015 9:34pm
Avatar Michael Emerton (483) 136 posts

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

 
Mar 5, 2015 10:17pm
Avatar Steve Fryatt (216) 1865 posts

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.

Next page

Pages: 1 2 3 4 5

Reply

To post replies, please first log in.

Forums → General →

Search forums

Social

Follow us on and

ROOL Store

Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.

Donate! Why?

Help ROOL make things happen – please consider donating!

RISC OS IPR

RISC OS is an Open Source operating system owned by RISC OS Developments Ltd and licensed primarily under the Apache 2.0 license.

Description

General discussions.

Voices

  • Glen Walker (2585)
  • Malcolm Hussain-Gambles (1596)
  • Steffen Huber (91)
  • Rick Murray (539)
  • Richard Walker (2090)
  • GavinWraith (26)
  • Dave Higton (1515)
  • Stephen Scott (491)
  • Peter Howkins (211)
  • Tony Noble (1579)
  • David Gee (1833)
  • David Feugey (2125)
  • Steve Pampling (1551)
  • Michael Emerton (483)
  • Steve Fryatt (216)

Options

  • Forums
  • Login
Site design © RISC OS Open Limited 2018 except where indicated
The RISC OS Open Beast theme is based on Beast's default layout

Valid XHTML 1.0  |  Valid CSS

Powered by Beast © 2006 Josh Goebel and Rick Olson
This site runs on Rails

Hosted by Arachsys