Smalltalk Internet Browser
Locked
12
12
 
Administrator
|
Being connected to the internet is going to be a necessity for any piece of software in the immediate future. So every Smalltalk development environment or application should have that capability as default. To push that envelop, every image should have a Smalltalk native Internet Browser. By developing that Internet Browser, we are demonstrating the power of Smalltalk. There is no reason why Smalltalk cannot be as intimate to the World Wide Web as Javascript. We can have the IDE in Smalltalk, Internet Browser in Smalltalk and a WWW language in Smalltalk. As is uniquely Smalltalk, every bit of code is visible, modifiable and debuggable. This supped up environment will grow and grow to be a full OS.
How can we gather the relevant Smalltalk code and necessary plugins to make an Internet Browser? I remember Croquet had internet browser and video player. What is missing? All the best, Aik-Siong Koh |
Re: Smalltalk Internet Browser
|
|
2017-04-29 4:11 GMT+02:00 askoh <[hidden email]>: Being connected to the internet is going to be a necessity for any piece of html5, javascript, etc... Good luck! What is the size of teams for building Firefox, Safari or Edge? For example, just the core: https://github.com/mozilla/gecko-dev Not sure that the million $ that Tim is asking regularly would bring us any close to those references. You'll have to implement a bunch of technologies... At least, the good point is that it would make sure that we have a truly open smalltalk ;)
|
Re: Smalltalk Internet Browser
|
|
Hi. I remember Esteban integrated Chrome into Pharo. Would be interesting to know details. 2017-04-29 8:58 GMT+02:00 Nicolas Cellier <[hidden email]>:
|
|
|
And for simple HTML pages this might be interesting
https://github.com/HPI-SWA-Teaching/Scamper (8 contributors, 380 commits) On 4/29/17, Denis Kudriashov <[hidden email]> wrote: > Hi. > > I remember Esteban integrated Chrome into Pharo. Would be interesting to > know details. > > 2017-04-29 8:58 GMT+02:00 Nicolas Cellier < > [hidden email]>: > >> >> >> 2017-04-29 4:11 GMT+02:00 askoh <[hidden email]>: >> >>> Being connected to the internet is going to be a necessity for any piece >>> of >>> software in the immediate future. So every Smalltalk development >>> environment >>> or application should have that capability as default. To push that >>> envelop, >>> every image should have a Smalltalk native Internet Browser. By >>> developing >>> that Internet Browser, we are demonstrating the power of Smalltalk. >>> There >>> is >>> no reason why Smalltalk cannot be as intimate to the World Wide Web as >>> Javascript. We can have the IDE in Smalltalk, Internet Browser in >>> Smalltalk >>> and a WWW language in Smalltalk. As is uniquely Smalltalk, every bit of >>> code >>> is visible, modifiable and debuggable. This supped up environment will >>> grow >>> and grow to be a full OS. >>> >>> How can we gather the relevant Smalltalk code and necessary plugins to >>> make >>> an Internet Browser? I remember Croquet had internet browser and video >>> player. What is missing? >>> >>> All the best, >>> Aik-Siong Koh >>> >>> >>> >> html5, javascript, etc... Good luck! >> What is the size of teams for building Firefox, Safari or Edge? >> Just browse https://github.com/mozilla for curiosity >> For example, just the core: https://github.com/mozilla/gecko-dev >> Not sure that the million $ that Tim is asking regularly would bring us >> any close to those references. >> You'll have to implement a bunch of technologies... At least, the good >> point is that it would make sure that we have a truly open smalltalk ;) >> >> >> >>> >>> -- >>> View this message in context: http://forum.world.st/Smalltal >>> k-Internet-Browser-tp4944879.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at >>> Nabble.com. >>> >>> >> > |
|
Administrator
|
In reply to this post by Nicolas Cellier
Let me clarify that this browser is to enhance software development and not for mainstream use - at least not yet.
Imagine have the full power of Smalltalk IDE while browsing the internet. I click on a photo and run image processing on it to see if it is natural or artificial, recognize objects or people, etc. I can have my own algorithm to suppress ads or popups. I can invent and test security models. I can download and upload from within the environment. I can search the environment and web at the same time. Indeed, Smalltalk lacks many technologies. But internet technologies are so so important we must have them ASAP. Having a GOAL to create a Smalltalk native Internet Browser (SIB) inside the environment will ensure we are not left behind. The synergy (IDE+SIB) will bring software development to the next level. Again it's something Smalltalk can pioneer. Every Smalltalk application will be web enabled automatically. Javascript is popular because it is embedded into all internet browsers. Google intentionally embed Dart into Chrome. We can have Smalltalk in SIB. SIB will improve Smalltalk programming productivity. We start out by embedding Chrome inside the IDE. Make them communicate well. We then port bit by bit to Smalltalk based on needs and priorities. All the best, Aik-Siong Koh |
Re: Smalltalk Internet Browser
|
|
What you can try is to resurrect the old web browser plugin. Now if you want to help why don;t you join the community and help? Stef On Sat, Apr 29, 2017 at 7:00 PM, askoh <[hidden email]> wrote: Let me clarify that this browser is to enhance software development and not |
Re: Smalltalk Internet Browser
|
|
In reply to this post by askoh
2017-04-29 19:00 GMT+02:00 askoh <[hidden email]>:
I am wondering, when you said "we" what you mean? Did you found team to work on such project? |
|
Administrator
|
We means all communities of Smalltalk environments. Pharo is of course the biggest, hence my post here first. I am verifying the soundness of the idea of SIB and then do a student project on it. I am from the VisualWork community. I look forward to porting freeCAD: 3D CAD with Motion Simulation to Pharo when it has 64bit version on Windows.
Aik-Siong Koh
|
|
Did you tried Amber? Is Smalltalk on the browser. I believe that what you mean is embedding the V8 engine into Pharo. But man, thats a huge work. Really... my 2c. Lic. Ignacio Sniechowski, MBA Prosavic SRL ☎ (5411) 4542-6712 📱 (54911) 6749-4721 On Sat, Apr 29, 2017 at 7:53 PM, askoh [via Smalltalk] <[hidden email]> wrote: We means all communities of Smalltalk environments. Pharo is of course the biggest, hence my post here first. I am verifying the soundness of the idea of SIB and then do a student project on it. I am from the VisualWork community. I look forward to porting freeCAD: 3D CAD with Motion Simulation to Pharo when it has 64bit version on Windows.
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
|
|
|
An interesting way would rather do something like electron. In fact, I would even go so far as to add Pharo to electron. Phil On Sun, Apr 30, 2017 at 1:34 AM, nacho <[hidden email]> wrote:
|
|
Beyond the barrier of this being a huge vaporware effort, bare in mind that a large percentage of Browsers are implemented in C/C++ for performance reasons.
In the cases of Firefox and Chrome its 50% in both cases that is made in C/C++. So immediately that means you have 3 options 1) Code it yourself/ your team in C/C++ that 50% 2) Use the existing code bases of either Firefox or Chrome 3) Code it all in pure Pharo (3) is the most attracting for Pharo devs and it will really prove that Pharo can make a Internet browser but you can forget about it. Pharo is around 10-50 times slower than C/C++ and if we take into account that Firefox alone can easily eat alive a quad core cpu and 1GB of memory , numbers that are unheard of to Pharo developer in large , it make the use of Pharo a non choice. So he erase (3) from the list. (1) Code it yourself C/C++ is again not doable since we are talking about milions and millions of lines of code , that means your browser will end up being 3-10 times larger to Pharo itself. Good luck with that. (2) is your realistic options that 50% that is coded in C/C++ will save you quite a lot of developing time and give you the performance you need but even this option comes with huge drawbacks of having to wrap millions and millions of lines of code so Pharo can have access to it, you could automate it to an extend but still A TON of work. Also do not be misled by that 50% if you think it covers 50% of the features, it does not. I would not be surprised if it covers 80-90% of the features so its not the 50% you can ignore or not focus on. Simply put Pharo is not a language designed for high performance coding. Bare in mind that we only recently got 64 bit support , something that would make C/C++ developers laugh. Not to exclude the sheer number of tools that C/C++ have that can debug and optimise code especially when it comes to memory management. We talking here not about 5-10 tools/libraries but an entire universe of options. I am not saying that Pharo is a bad language by any means. We would laugh at C/C++ coders with the way they try to implement OOP or dynamic coding. Pharo is amazing for low performance coding and if you want to quickly put together applications on the fly. If you want to do something realistic then your best bet will be to assist the PharoJS folks because the number one thing you need to even got the attention of web devs is excellent JS , HTML and CSS support out of the box. An area that I have worked with Pharo is IPC (Inter Process Communication) that makes it possible for Pharo to communicate with any software and language and use any tool, any library of any language etc. Embedding a browser inside Pharo could be beneficial for the community under a single scenario. Abandoning Morphic and Bloc and moving to QT. I know this is enough to start people throwing tomatoes at me but I do believe it would be of immense value to Pharo. QT is de facto THE KING of GUIs , not only QT can embed a browser , OpenGL contexts it can also embed itself inside mobile apps and web apps. Its an extremely powerful API that will open the doors for us to all enviroments and OSes, web dev, iOS, Android, Macos, Windows, Linux etc. But realistically this will never happen because it will require for Pharo devs to start coding in C++ to wrap QT for Pharo (its a C++ lib) and then they will stop throwing tomatoes at me and start throwing knifes and I would not even blame them. Good luck with anything you decide doing you are going needs tons of it and tons of patience. |
|
|
A thoughtful description Mr. Kilon, couldn't agree more.
Even if the solution is based in node/v8 or derivate technologies like electron it will be a nightmare to integrate that. And IMHO, electron should be killed!! It's really a bad bad idea. You have like 10 single apps that run a full V8/node stack. Atom, Discord, LightTable, Chrome itself...it's so RAM & CPU consuming. For me it is like saying that a desktop application is pure front-end development. best
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
|
Re: Smalltalk Internet Browser
|
|
In reply to this post by askoh
On 29/04/17 04:11, askoh wrote:
> Being connected to the internet is going to be a necessity for any piece of > software in the immediate future. So every Smalltalk development environment > or application should have that capability as default. To push that envelop, > every image should have a Smalltalk native Internet Browser. Web is a very bad platform from an engineering point of view. The amount of accidental complexity is astounding, as is the number of useless layers obfuscating this all. I don't think we are ready to waste the amount of engineering needed to do something useful at the browser implementation side of the web (except for things like amber, pharojs and squeakjs). Stephan |
|
|
+1
i think the development of pharo should more focus on an "easy to use and adaptive live data analysis environment" which supports data science tasks with easy to use data retrieving, data preparation, data exploration, data modelling, scripting capabilities. We already have so many pieces and knowledge for this kind of platform around. I think only the cool story is missing .. And yes i know Moose, but i have the feeling this environment is not Moose. For me Moose is to much associated with software analysis ... Volkert Am 30.04.2017 um 17:06 schrieb Stephan Eggermont: > On 29/04/17 04:11, askoh wrote: >> Being connected to the internet is going to be a necessity for any >> piece of >> software in the immediate future. So every Smalltalk development >> environment >> or application should have that capability as default. To push that >> envelop, >> every image should have a Smalltalk native Internet Browser. > > Web is a very bad platform from an engineering point of view. The > amount of accidental complexity is astounding, as is the number of > useless layers obfuscating this all. I don't think we are ready to > waste the amount of engineering needed to do something useful at the > browser implementation side of the web (except for things like amber, > pharojs and squeakjs). > > Stephan > > > |
|
|
In reply to this post by nacho
And IMHO, electron should be killed!! It's really a bad bad idea. You have The appeal of electron is not that it will be very good performance wise but that its much easier for a web dev to move his/her web app to desktop with minimum amount of effort. Of course minimum effort has the side effect of lousy performance but in the case of apps like Discord which they do not do much its ok. So electron makes sense. Whether we should support such a framework is something that is up to the Pharo devs themselves. Take a look at Ruby on Rails, it was started from a single person for his own needs. Like many of our own Pharo libraries. You make something you need, you release it and if people find it useful they will contribute , if not its still useful to you ;) Such libs/tools like Electron have zero appeal to us desktop developers mainly because even web devs do not like web development for the known problem it has. Also web devs tend to over exaggerate about the appeal of individual web frameworks , I read an article making the bold claims of massive success for Node.js as a server API , I did some research and I came in front page evidence of massive failure, servers remain firmly committed to Apache which yes its written in C. Not that I doubt for a second that an API for a dynamic language would be able to compete with the behemoth of performance that C really is on its own field, obviously servers needs top performance because of the big load they have to manage. I enjoy ninja attacking such web posts and expose them for what they really are, fake. The other day another web dev made the bold claim that web games are on the rise, took me a second to do my research and find one of the most highly regarded research surveys in game industry that clearly show not only that web games are no more than 4% but they going straight to the hell of 0%. Apparently the one ones excited to play games inside the web browser are web devs that want to make blog post with ridiculous claims. Web remains and will remain strictly inside the web browser, outside it, very few people like it and actually choose it as they are preferred way of development. The same way none would pick C/C++ for a non performance orientated app well at least most logical people, unless of course there is a very good reason for such a choice. Of course C devs do not feel the need , at least AFAIK , to exaggerate the usefulness of their own language in blog posts with zero reference to actual reliable sources. But they are no angels either. Personally I think the future of the Web which will only grow in popularity will be outside the browser and already desktop apps have taken advantage of this. We see this a lot with mobile apps that steal away the users of web browsers. How many people use the web browser to like and chat on facebook compared to the ones using the native mobile clients ? Not many. |
Re: Smalltalk Internet Browser
|
|
In reply to this post by Volkert
I tried to convince alex to focus on the missing pieces around roassal: On Sun, Apr 30, 2017 at 6:03 PM, volkert <[hidden email]> wrote: +1 |
Re: Smalltalk Internet Browser
|
|
- data manipulation - some math libraries - handling large file (yes you will not load 128 Gb file even in Java :) But so far I failed :) On Sun, Apr 30, 2017 at 7:33 PM, Stephane Ducasse <[hidden email]> wrote:
|
Re: Smalltalk Internet Browser
|
|
In reply to this post by askoh
Hi Askoh, are you also aware of Snowglobe https://thiscontext.com/2016/10/31/app-streaming-with-snowglobe/ ? This allows one to use a standard Smalltalk image running on the native Cog VM to render in a web browser. _,,,^..^,,,_ (phone)
|
|
Administrator
|
In reply to this post by nacho
Thanks everyone for your input.
I am aware of Amber - worthy effort. I am more interested in Smalltalk IDE or app having a Browser. I am thinking more of Smalltalk calling Chromium Embedded Framework (CEF) via APIs. The browser is in direct two-way communication with the Smalltalk app. The complete API may be huge, but we can start with 1, 10, 100 APIs and still do useful stuff. Smalltalk missed out to Java because it did not embrace the internet. Let's not continue to miss out. Someone mentioned Pharo should be good with data analysis. Well, I think a lot, if not all, that data is going to come from the internet. Hence an embedded browser is a great helper. Python rode on C/C++. Ruby rode on Rails and on Web. What can Smalltalk ride on? VisualWorks Appex seems to be an attempt to ride on Javascript. VW Appex manages both Smalltalk and Javascript in the same image. Javascript edits in Appex are reflected to the Internet Browser when it is refreshed. Most interestingly, Javascript edits in the Internet Browser Dev Tools are picked up by Appex and put into the image. What do you think of this strategy? Aik-Siong Koh
|
|
Administrator
|
In reply to this post by Eliot Miranda-2
Yes. It is a novel way of remote desktop. Perhaps Craig can tell if it can do the following.
I want to go to a web page, select a body of text and have Smalltalk code analyze the text in some way and return the answer in the browser or in the Smalltalk app or file output. There should be two-way communication between app and browser. I would like to do live debugging too. Aik-Siong Koh <quote author="Eliot Miranda-2"> Hi Askoh, are you also aware of Snowglobe https://thiscontext.com/2016/10/31/app-streaming-with-snowglobe/ ? This allows one to use a standard Smalltalk image running on the native Cog VM to render in a web browser. _,,,^..^,,,_ (phone) |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |