Sorry, English is not my first language...
I recently got acquainted with this platform and was delighted with its speed, and before that I used for a long time and use right now, chrome applications...
And immediately I had a desire to use the platform for inclusion in their applications as a built-in library without visual elements and with a simple and easily portable to all languages (I use mostly VBA and Free Pascal for applications) programming interface, which gives the ability to open pages and access via js scripts to the virtual DOM...
I understand it's not the hardest task (the biggest problem is that I have never worked with C++, but it's not so hard to drop graphics libraries and compile not browser executable, but dynamic library, like nodejs or ancient PhantomJS can do).
It would be nice if someone, maybe even developers, would be interested in this, in my opinion, very necessary and useful for many, task.....
headless browser library
Moderators: trava90, athenian200
Re: headless browser library
UXP works the other way around: instead of using the platform as a library included in the application, you build the application on top of the platform.
It's hard to set it up correctly because of Mozilla's bad decisions that ended up being inherited by the project, but with UXP you get a set of graphical widgets supporting different operating systems out of the box and programmable via javascript, which is what things like Electron do.
It'd be nice to have UXP as an embeddable web browser, but the times you need such a widget are very few and if you need anything more complex than an HTML reader you are better off using UXP as a platform instead of as a widget.
It's hard to set it up correctly because of Mozilla's bad decisions that ended up being inherited by the project, but with UXP you get a set of graphical widgets supporting different operating systems out of the box and programmable via javascript, which is what things like Electron do.
It'd be nice to have UXP as an embeddable web browser, but the times you need such a widget are very few and if you need anything more complex than an HTML reader you are better off using UXP as a platform instead of as a widget.
Re: headless browser library
UXP as a platform is a VERY good option. I genuinely liked UXP, especially after the ambiguities of Chrome's code. And I've been considering it as well. The problem is that it's written in C++. That is, full-fledged binding to other high-level programming languages is either impossible at all, due to peculiarities of extremely complicated C++ syntax, which has no direct analogues in many places, or extremely complicated and extremely above my capabilities...
And a fast, minimalist and compact program for reading HTML, which on Electron with its slowness and a lot of legacy superfluous code, is impossible - it's already amazing, if there will be a simple API to access the internal java script and DOM with possible interception of events.... On the basis of this it is already possible to solve an extremely large range of tasks...
And a fast, minimalist and compact program for reading HTML, which on Electron with its slowness and a lot of legacy superfluous code, is impossible - it's already amazing, if there will be a simple API to access the internal java script and DOM with possible interception of events.... On the basis of this it is already possible to solve an extremely large range of tasks...
Re: headless browser library
You seem to misunderstand. The front-end for UXP applications doesn't have much C++ in it, actually, and the interfaces with the platform are abstracted (through IDL).
UXP applications get their design and implementation primarily through XUL and JS, that is: an XML UI language to build your user interface, and JS to provide the actual functionality behind controls in that user interface. Aside from providing a small app launcher shell that sets up the primary window and initializes the platform, there's really no C++ or its quirks involved.
As already said it's the opposite of thinking of this like embedding a webview lib. You don't start with your design and then "plug UXP in", but rather your build your application using the language and tools the platform provides.
UXP applications get their design and implementation primarily through XUL and JS, that is: an XML UI language to build your user interface, and JS to provide the actual functionality behind controls in that user interface. Aside from providing a small app launcher shell that sets up the primary window and initializes the platform, there's really no C++ or its quirks involved.
As already said it's the opposite of thinking of this like embedding a webview lib. You don't start with your design and then "plug UXP in", but rather your build your application using the language and tools the platform provides.
{{This headspace for lease}}
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: headless browser library
Um... For example, right now I have a task, accessing and analyzing dynamic pages from VBA. And the usual, purely scripting methods using an ordinary browser don't work at all, because of the need to simply distribute code through policies. That is, everything that is used must be in one place and without any dependencies.
As an option, as I write about, open a minimum one-page and extremely compact browser and through it take the necessary data through the API DOM....
I already have several working implementations, but they all don't satisfy me... Either they are outdated and not always interpret the data and scripts correctly (phantomjs crashes), or they are very unstable and very tied to a specific software environment ....
That's why I paid attention to UXP. I didn't find any problems with stability, speed, or the size of the final implementation....
...I may be wrong...
As an option, as I write about, open a minimum one-page and extremely compact browser and through it take the necessary data through the API DOM....
I already have several working implementations, but they all don't satisfy me... Either they are outdated and not always interpret the data and scripts correctly (phantomjs crashes), or they are very unstable and very tied to a specific software environment ....
That's why I paid attention to UXP. I didn't find any problems with stability, speed, or the size of the final implementation....
...I may be wrong...