Thrust: Chromium-based cross-platform, cross-language application framework(github.com)
github.com
Thrust: Chromium-based cross-platform, cross-language application framework
https://github.com/breach/thrust/
13 comments
Correct, there have also been other similar implementations along the same vain, but they all attempt to inject one technology into another. Thrust takes a different approach, it is itself the chromium content library, with some added libraries, and an rpc interface. This allows it to be used without forcing another library implementor to `inject` their code into it.
This would be absolutely phenomenal if you could have the entire pip ecosystem and write cross platform desktop apps in python.
pip or npm yes!
As well as
go get -u {urltopackage}
go install
Doesn't go get already do go install?
Yes. In some cases ive experienced both. Sometimes it installed sometimes it did not.
As a proof of concept I knocked up JankyBrowser in about 3 hours. Nagivation? Check. Tabs? Check (how long did other browser take to get those!). All in a little over 6K of JS.
https://gist.github.com/morganrallen/f07f59802884bcdcad4a
https://gist.github.com/morganrallen/f07f59802884bcdcad4a
Cookies are handled by Chromium, I suppose?
Or are they completely ignored?
Or are they completely ignored?
My god. I'm just awestruck, I just ran it and it worked beautifully.
The same thing in Java Swing took me 3 weeks 4 years ago.
The same thing in Java Swing took me 3 weeks 4 years ago.
Thanks! Not too bad for a couple hours on a sick day.
...wow! This is a really compelling
I know it's really fashionable to hate on javascript, but there's really something to be said for being able to code a web browser with tools you can learn on Khan Academy.
I know it's really fashionable to hate on javascript, but there's really something to be said for being able to code a web browser with tools you can learn on Khan Academy.
"var webview = document.createElement("webview");"
Turns out, it's pretty easy to code a web browser in ANYTHING if one of the primitives you can instantiate is A WEB BROWSER...
Turns out, it's pretty easy to code a web browser in ANYTHING if one of the primitives you can instantiate is A WEB BROWSER...
al2o3cr, actually no. There are a load of difficult implementations needed to achieve even the most basic webbrowser, even when building on top of the already great chromium content lib. For instance, Thrust's predecessor ExoBrowser failed where Thrust is succeeding, thankfully we have progressed to a state of composability where we can take the work of others before and compose it into something useable for the world. The 500 something commits to Thrust were no simple feat, and their are many more to come.
This is really awesome. Reminds me of http://www.tidesdk.org
Honestly, I'm super prepared for the world where HTML/CSS is used for all the GUIs (while HTML/CSS are not perfect, I think they've done a pretty good job being flexible enough style to millions of user-facing GUI applications, also known as web sites, for so long). I don't think many people agree, but the day I don't have to try and choose between TK, GTK, QT, and some other smaller framework is gonna be a good day.
Not quite the same (since this runs on chromium, and I'm not sure that TideSDK does also -- at least it's been around too long that it feels like they couldn't possibly have).
Honestly, I'm super prepared for the world where HTML/CSS is used for all the GUIs (while HTML/CSS are not perfect, I think they've done a pretty good job being flexible enough style to millions of user-facing GUI applications, also known as web sites, for so long). I don't think many people agree, but the day I don't have to try and choose between TK, GTK, QT, and some other smaller framework is gonna be a good day.
Not quite the same (since this runs on chromium, and I'm not sure that TideSDK does also -- at least it's been around too long that it feels like they couldn't possibly have).
This is not a popular view, but I think as developers we should focus on one platform and serve it well, instead of making nearly tolerable apps for every platforms.
I'm supplying a node-webkit app to thousand of clients and I feel you.
We thought "Hey, it runs on everything!" would be nice for our future roadmap...but didn't we say the same about Java?
We thought "Hey, it runs on everything!" would be nice for our future roadmap...but didn't we say the same about Java?
Some days I agree with you -- optimization/platform-specific code definitely has it's place (we would be nowhere without it, all the web stuff stands on shoulders of giants on other giants), and targeted building.
But other days I'm struggling to use objective-c.
But other days I'm struggling to use objective-c.
As a web developer this is a very cool project. It's a very simple sandbox to develop a custom application or even customize my browsing experience. Being built on the current stable release of Chrome makes it even better.
I get this error when building it. Any thoughts?
$ go get -u github.com/miketheprogrammer/go-thrust
package github.com/miketheprogrammer/go-thrust
imports github.com/miketheprogrammer/go-thrust
imports github.com/miketheprogrammer/go-thrust: no buildable Go source files in /Users/user/.gocode/src/github.com/miketheprogrammer/go-thrustApologies to all, we are restructuring the application to work better with go get.
You can try with the -d flag to avoid building files. this should download the application to the proper gopath.
then you can use the instructions from the go-thrust repo homepage.
There appear to be different instructions you can try at https://github.com/miketheprogrammer/go-thrust/
Got the same on Win7.
Node that there is also the same-called project: http://thrust.github.io/
Seems nice, especially with variant bindings instead of only one.
One more question, how to update the whole application after distributed, including HTML/CSS/JS files and the framework binaries? Do I still have to make one updater(which is not really an easy task if you want a fancy UI), or is Chromium's update framework included already?
This is great! Installed it via PIP and it just worked. I would love to see this combined with https://github.com/enthought/jigna / https://www.youtube.com/watch?v=KHSXq5jfv_4 .
Awesome project. Breach is also very cool. What are the plans for the future of Breach?
It will get rebuilt on top of Thrust.
Can someone tell me use-case wise how this differs from PhantomJS and CEF?
Unlike PhantomJS, this is not a headless browser (though can be!), its a browser that can be designed in HTML/CSS/JS. This is to say, the navigation buttons are controlled by you, your own download manager, etc. Time and imagination are your limits.
You could write a browser in assembler. Only time and imagination are your limits.
I think this is the first time I've seen the phrase, "requires Python 3." It's certainly the first time I've seen it on something that I want badly enough to mess with it.
I was happy they had "requires Python 3" because cefpython keeps going back and forth on Python 3 support.
To be fair the Python bindings are pretty simple, you could easily implement it in Python 2. You do need evented I/O however so you could write either gevent or twisted bindings.
Yes exactly. I started coding in Python 2 days ago so I went with what I found (asyncio) but it could be easily recoded in Python2!
Sounds great. Just one question about the Windows screenshot - why are the fonts so jagged?
Screenshot from a remote server running on AWS. I guess the settings are screwed up on that machine!
Not sure if it's the same issue, but I ran into problems with node-webkit and jagged font-icon animations due to them not being able to package direct3d dlls with the project. Simply popping them in on my own solved it.
So my question is what's your rationale for using Thrust vs. Node-webkit?
Node-Webkit is hacky at best. Atom-Shell is a major improvement on Node-Webkit, however not quite there. Native modules need to be compiled for a completely different target.
Thrust takes it a step further, improving on the past. Thrust uses the same backing library as Atom-Shell (brightray) to expose the Chromium Content Library.
Thrust is cross-platform cross-language. Use a similar familiar api from any language you want, or roll your own. No need to use javascript on the backend if you dont want to.
For example, Go-Thrust can compile, this is a particular advantage for distributing applications.
Thrust takes it a step further, improving on the past. Thrust uses the same backing library as Atom-Shell (brightray) to expose the Chromium Content Library.
Thrust is cross-platform cross-language. Use a similar familiar api from any language you want, or roll your own. No need to use javascript on the backend if you dont want to.
For example, Go-Thrust can compile, this is a particular advantage for distributing applications.
Now to add some more context, Thrust's predecessor (ExoBrowser) still used embedded NodeJS, this made it incredibly difficult to package native modules with applications. The Thrust team learned from the mistakes of the past and decided to try to simplify the stack as much as possible to allow true composability.
does this mean that I can import other python modules directly in to the thrust app?
Essentially yes, you can import python modules into go-python and expose their API's via WebSockets to Javascript.
Could one write a fast text editor using Thrust? Can one use C++ instead of Python/JS/Go?
One could use c++ instead of Python/JS/Go, I would however recommend still using the JSONRpc bridge to communicate. I would not recommend using c/c++ at all, as Atom.io has proven more modern garbage collected languages have become so incredibly fast that c/c++ are primarily distractions unless you are a master of the incredibly huge ecosystem and can sling code together fast without having leaks, pointer issues, and a host of other security issues.
At a minimum, I would recommend using Go or NodeJS with a C binding for any extremely low level operations you would like to achieve, that would make everything much more suitable, you would also benefit of the ecosystem of modules.
At a minimum, I would recommend using Go or NodeJS with a C binding for any extremely low level operations you would like to achieve, that would make everything much more suitable, you would also benefit of the ecosystem of modules.
Agreed, though I'm sure Atom doesn't steal more users from Sublime Text (C++ & Python for the plugins) due to its so-so performance.
It can be binded in C++ yes
Distribution through npm directly. X-language also.
Make sense?
Make sense?
Additionaly it's much easier to use native modules! No recompile needed
I'm curious about this. How are native modules compiled if I want to deploy from my architecture X to windows, os x and linux?
Well it's handled by Node directly right?
node-webkit and atom-shell embeds NodeJS along the chromium content module forcing its user to use not only NodeJS but a particular build of it.
On the contrary, Thrust embeds the Chromium content module and exposes an API on the standard IO, which makes it bindable in any language and works perfectly well as a dependency with vanilla nodeJS / Go / Python
Makes the distribution of cross-platform GUI apps through the pip/npm possible.