3 ms·

I think the effort going into browsers is a double-edged sword. It's nice that we've got so much work going on, pushing new standards, etc. but it's also making

I think the effort going into browsers is a double-edged sword. It's nice that we've got so much work going on, pushing new standards, etc. but it's also making browsers more bloated and making it less viable to bring out new browsers. As more stuff gets done in Javascript, and Javascript gains more APIs, browsers like Lynx, Dillo, Netsurf, and umpteen yet-to-be-written ones are becoming less able to browse the Web. Likewise, the effort required to "upgrade" them would be massive. I think a consolidation of features would alleviate the situation a little: have a small "foundation" of required tech, e.g. a subset of JS (or WebAssembly) with few primitives or APIs, and have the browser pull in polyfills for everything else, including interpreters for fuller, newer JS standards, etc. If a browser is graphical, it could provide a bitmap-blitting primitive, and use polyfills for CSS, fonts, layout, etc. The Chromes and Firefoxes of the world could ignore the polyfills and keep going with their highly-tuned native implementations of these things, but it would prevent "kicking the ladder away" from everyone else.

glebm 9y ago
While I agree with the overall sentiment, browsers like Dillon and Lynx don't even implement HTTP caching correctly (they cache everything regardless of the headers). JavaScript is not their biggest problem, as they can plug in one of the existing engines (in fact one of the links forks does just that).
- zimpenfish 9y ago
  > as they can plug in one of the existing engines As someone who attempted this for Lynx back in the [~late 90s~] early 00s with the Mozilla JS engine of the time, no, they can't. Lynx has no DOM. It parses and renders the HTML to a fixed textual pane without any intermediate format - even `document.write()` is nigh-on impossible to implement because it required keeping a copy of the HTML around, jiggering it with the output, reparsing, and going through the layout again. And that only covers the most trivial uses of `document.write()`. To add Javascript to Lynx would require rewriting the entire internals of Lynx - not going to happen. [Edited to correct the time period]
chii 9y ago
> browsers like Lynx... less able to browse the Web. they are still able to browse the web that they were able to browse back then. You can't expect that the web won't move on. The only lament is that most websites don't cater for text only/low-resource/disabled users. But that's a different story to the OP of having lots capability/libs/standards.

glebm 9y ago

While I agree with the overall sentiment, browsers like Dillon and Lynx don't even implement HTTP caching correctly (they cache everything regardless of the headers). JavaScript is not their biggest problem, as they can plug in one of the existing engines (in fact one of the links forks does just that).

zimpenfish 9y ago
> as they can plug in one of the existing engines As someone who attempted this for Lynx back in the [~late 90s~] early 00s with the Mozilla JS engine of the time, no, they can't. Lynx has no DOM. It parses and renders the HTML to a fixed textual pane without any intermediate format - even `document.write()` is nigh-on impossible to implement because it required keeping a copy of the HTML around, jiggering it with the output, reparsing, and going through the layout again. And that only covers the most trivial uses of `document.write()`. To add Javascript to Lynx would require rewriting the entire internals of Lynx - not going to happen. [Edited to correct the time period]

chii 9y ago

> browsers like Lynx... less able to browse the Web. they are still able to browse the web that they were able to browse back then. You can't expect that the web won't move on. The only lament is that most websites don't cater for text only/low-resource/disabled users. But that's a different story to the OP of having lots capability/libs/standards.