I always found Dillo interesting. It’s one of the few browsers with their own layout engine.
I really wished there were more options. It always feels a bit odd to have a standard when they’re are so few implementations.
I know the smaller implementations are rarely taken seriously and of course some things cannot work without eg WebRTC.
However having more than one layout engine might also be different in other regards than just typical web applications. I think this becomes clear with electron. And I don’t mean that Dillo should become the next electron (I think if you want to do a web app, let me use my browser), but that I think a lightweight/more minimal way to render basic HTML and CSS provides opportunity, just like the web did back when Microsoft still thought that the Web is overhyped.
Aside from all the reasons that monocultures in software implementing standards are bad. First and foremost because it becomes very hard to tell if a standard is even any good, as the lines between the standard and the major implementation blurs.
There are probably more developers than ever, but when it comes to implementations support for everything from POSIX to C standards (libs/compilers) and even things like CPU architectures (which aren’t standards per se) things look somewhat like monocultures.
As complexity grows doing something novel without also fully copying all the quirks of major implementations becomes really hard.
And I know, having to be compatible with the major player was a topic for DOS, x86, Firefox, etc., but the complexity or in other words, the amount of what’s necessary to be compatible is many times higher.
So things become a one way street. And if the path is a bad one, it becomes really hard to get out of it.
So kudos to everyone not just tagging along. Be it by implementing standards on their own or creating new one. Even if it’s not the next big thing, I think it’s a worthwhile endeavor and something worthwhile of support, because having only one choice in this context is the same as having no choice.
It seems that the failure of FLTK 2 to ever reach final status and get released kiboshed a number of FLTK projects and drove some of them to move to other toolkits. The app FLTK itself was created for, Nuke, moved to Qt years ago.
It’s a damned shame. It looks like a better bet than Gtk since it’s part of GNOME and the developers of that project seem not to care about any other project.
(Source: they invited me to GUADEC, I met the core team, talked with them, and came away metaphorically shaking my head in astonishment.)
Wouldn’t it be easier to just maintain Gtk3? Similar to the Trinity Desktop Environment which uses TQt3.
Well, if MATE and Xfce and whoever else could agree and work together.
But does that seem likely?
This is referring to GNOME, right?
Yes. GUADEC is the annual GNOME developers’ conference.
Because I could imagine shaking my head at FLTK too, given that they are taking so long.
As I tried to say in my preceding comment:
It looks to me, from the outside, like a lot of work went into FLTK 2 and then for some reason it was abandoned. Now the project is finally recovering from that.
For comparison, other projects have survived comparable failures.
There was a 20 year gap between Perl 5 and Perl 7, and AFAIK it took 15 years for Perl 6 to appear under a different name.
There was a decade between PHP 5 and PHP 7 and AFAICS the PHP 6 effort was abandoned completely.
However having more than one layout engine might also be different in other regards than just typical web applications. I think this becomes clear with electron. And I don’t mean that Dillo should become the next electron (I think if you want to do a web app, let me use my browser), but that I think a lightweight/more minimal way to render basic HTML and CSS provides opportunity, just like the web did back when Microsoft still thought that the Web is overhyped.
There was one cool little thing called HTMLayout. I am not sure about the current state of its offspring, Sciter, but back then, it was a pretty cool thing: an HTML/CSS/JS engine specifically dedicated to desktop UI creation. It was long before the Electron, and it wasn’t Chrome (or anything else) based, just written from scratch in C by one man (also then a member of various HTML/CSS/JS workgroups, so his implementations of the standards were a playground for future possibilities).
It was small, fast, and very powerful. At one point, I think it was a pretty popular solution for various developers who need just small yet fashionably powerful UI, like antivirus software (it was a UI/layouting engine for several popular antiviruses then, AFAIK).
OTOH, it was closed-sourced, Windows-only, and paid, though free for hobby usage. Worked with it a lot for some proprietary software and even developed a Ruby wrapper for it (though never published) + MVCB (Model-View-Controller + “Behavior”, akin to modern web components, but in Ruby) microframework . It was pretty cool stuff, though it never had its deserved market share because of monoplatformeness and closed source.
PS: Seems like Sciter is alive and well, though, yet not very well-known.
I always found Dillo interesting. It’s one of the few browsers with their own layout engine.
I really wished there were more options. It always feels a bit odd to have a standard when they’re are so few implementations.
I know the smaller implementations are rarely taken seriously and of course some things cannot work without eg WebRTC.
However having more than one layout engine might also be different in other regards than just typical web applications. I think this becomes clear with electron. And I don’t mean that Dillo should become the next electron (I think if you want to do a web app, let me use my browser), but that I think a lightweight/more minimal way to render basic HTML and CSS provides opportunity, just like the web did back when Microsoft still thought that the Web is overhyped.
Aside from all the reasons that monocultures in software implementing standards are bad. First and foremost because it becomes very hard to tell if a standard is even any good, as the lines between the standard and the major implementation blurs.
There are probably more developers than ever, but when it comes to implementations support for everything from POSIX to C standards (libs/compilers) and even things like CPU architectures (which aren’t standards per se) things look somewhat like monocultures.
As complexity grows doing something novel without also fully copying all the quirks of major implementations becomes really hard.
And I know, having to be compatible with the major player was a topic for DOS, x86, Firefox, etc., but the complexity or in other words, the amount of what’s necessary to be compatible is many times higher.
So things become a one way street. And if the path is a bad one, it becomes really hard to get out of it.
So kudos to everyone not just tagging along. Be it by implementing standards on their own or creating new one. Even if it’s not the next big thing, I think it’s a worthwhile endeavor and something worthwhile of support, because having only one choice in this context is the same as having no choice.
I agree.
Netsurf is another one. I can’t think of many others right now.
I wrote about Dillo when the project was revived earlier this year, and I also wrote about the first new release of FLTK in over a decade.
It seems that the failure of FLTK 2 to ever reach final status and get released kiboshed a number of FLTK projects and drove some of them to move to other toolkits. The app FLTK itself was created for, Nuke, moved to Qt years ago.
It’s a damned shame. It looks like a better bet than Gtk since it’s part of GNOME and the developers of that project seem not to care about any other project.
(Source: they invited me to GUADEC, I met the core team, talked with them, and came away metaphorically shaking my head in astonishment.)
NetSurf avoids the dilemma of choosing a toolkit by supporting multiple ones, including GTK, Win32, Haiku, etc. ;)
They even started some work on an FLTK frontend, although it seems abandoned now.
I did not know that.
Maybe do to its origins on RISC OS?
Wouldn’t it be easier to just maintain Gtk3? Similar to the Trinity Desktop Environment which uses TQt3.
This is referring to GNOME, right? Because I could imagine shaking my head at FLTK too, given that they are taking so long.
Well, if MATE and Xfce and whoever else could agree and work together.
But does that seem likely?
Yes. GUADEC is the annual GNOME developers’ conference.
As I tried to say in my preceding comment:
It looks to me, from the outside, like a lot of work went into FLTK 2 and then for some reason it was abandoned. Now the project is finally recovering from that.
For comparison, other projects have survived comparable failures.
There was a 20 year gap between Perl 5 and Perl 7, and AFAIK it took 15 years for Perl 6 to appear under a different name.
There was a decade between PHP 5 and PHP 7 and AFAICS the PHP 6 effort was abandoned completely.
There was one cool little thing called HTMLayout. I am not sure about the current state of its offspring, Sciter, but back then, it was a pretty cool thing: an HTML/CSS/JS engine specifically dedicated to desktop UI creation. It was long before the Electron, and it wasn’t Chrome (or anything else) based, just written from scratch in C by one man (also then a member of various HTML/CSS/JS workgroups, so his implementations of the standards were a playground for future possibilities).
It was small, fast, and very powerful. At one point, I think it was a pretty popular solution for various developers who need just small yet fashionably powerful UI, like antivirus software (it was a UI/layouting engine for several popular antiviruses then, AFAIK).
OTOH, it was closed-sourced, Windows-only, and paid, though free for hobby usage. Worked with it a lot for some proprietary software and even developed a Ruby wrapper for it (though never published) + MVCB (Model-View-Controller + “Behavior”, akin to modern web components, but in Ruby) microframework . It was pretty cool stuff, though it never had its deserved market share because of monoplatformeness and closed source.
PS: Seems like Sciter is alive and well, though, yet not very well-known.