tobimensch
commented
6 years ago I might give implementing a vim mode a try, since it's a feature I'd love to have. But I don't promise anything.
Open tombh opened 6 years ago
tobimensch
commented
6 years ago I might give implementing a vim mode a try, since it's a feature I'd love to have. But I don't promise anything.
tombh
commented
6 years ago Great :) There's already experimental support for custom keys here, eg; https://github.com/browsh-org/browsh/issues/52#issuecomment-406782595 But it's not documented yet. It just feels like an ugly syntax at the moment.
j-rewerts
commented
6 years ago I'd love to help out the community however I can. New to Go, but I'm learning.
tobimensch
commented
6 years ago @j-rewerts We need you. Welcome!
jackson-zhipeng-chang
commented
6 years ago Hi! I would like to help the community as well! I will start by supporting more Chinese character from this issue!
bclue
commented
6 years ago I'm also new to Go, but I'm definitely interested in contributing to Browsh however I can!
farhadmak
commented
6 years ago Hi, I'm also interested in this project. Very cool concept! I am new to Go as well, but I will start contributing very soon!
tobimensch
commented
6 years ago @Zhipeng-Chang @bclue @farhadmak Welcome!
ArniDagur
commented
6 years ago How will Vim key-combinations like gg be specified in the config file? One would think it useful to know the answer to that question before implementing Vim-mode. Doesn't introducing Vim-mode before key binding configuration potentially make the former more cumbersome to implement after the introduction of the latter?
tombh
commented
6 years ago @ArniDagur let's take this conversation to the Vim mode thread: https://github.com/browsh-org/browsh/issues/31#issuecomment-414120492
CodyGramlich
commented
5 years ago I'm interested in contributing to this project. I'm new to Go.
tobimensch
commented
5 years ago @CodyGramlich Welcome!
Check out the new guide on how to setup a build environment on Linux #193 . Assuming you're a Linux user.
If you have any questions, you can open an issue about it here. You can also use our gitter or the newly created IR channel #browsh on irc.freenode.org .
I think reading Browsh's source code is an excellent way to learn go.
tombh
commented
5 years ago Another little update about my plans. Firstly aplogies for not being so active. I forget to reply to one issue, then the backlog just builds. I still feel that Browsh has much further to go! I applied to YC recently as a non-profit, but got a rejection letter today. Not that we need YC of course, it's just Browsh has been so popular on Hacker News and the actual YC accelarator would be such a great platform to get exposure.
Also I haven't actually had a computer recently! Which I must say has been quite nice. So I've got to sort myself out now, get a computer and get a job. But hopefully that'll just be for a few months, then I want to give Browsh another push in the direction I was proposing in my YC application, which I'll post in the next comment for anyone that's interested. But basically the gist is that I want to focus more on the browser client.
tombh
commented
5 years ago Browsh
Text-based browsing for slow or expensive internet
Provide a web service that converts any website into pure text, simply by prepending a Browsh domain to a URL (e.g. text.brow.sh/news.ycombinator.com). As any of the great search engines can attest to, the most significant aspect of the web is text content. Therefore Browsh's online services will expose the web in its most essential form. Primarily this will benefit those with poor bandwidth. Other beneficiaries will be those with expensive bandwidth and those that browse the web via screen readers such as the visually impaired.
Whilst the pure text service realises the absolute lower limit of bandwidth for using the web, incremental features and information can be chosen if desired. Currently this is only provided by 'html.brow.sh', offering: clickable links (also loading all successive links inside Browsh) and a pixelated screenshot of the page to offer cues for visual meaning that text by itself cannot provide. It is this 'html.brow.sh' service that I would like to be the main focus of Browsh's future; improving rendering, adding mouse interaction, exploring optimisations, creating branded mobile browsers.
I successfully prototyped as "Texttop" in 2016 receiving a HN front page of 114 upvotes [1]. At the beginning of 2018 I dedicated 7 months to realising a fuller implementation with online services. I launched in July, receiving a full day at the top spot on HN, ultimately achieving 967 upvotes [2]. The launch was focussed on the terminal client, which is an implementation running purely on TTY [3]. This terminal client is capable of rendering everything that Firefox can, therefore: JS, CSS3, HTML5, realtime video, WebAssembly and even WebGL. It also supports basic mouse interaction such that drag n drop and paint/drawing applications work.
The browser-based services (e.g. html.brow.sh), which are the focus of this application, do not yet have feature parity with the terminal client, mainly in terms of realtime updates and mouse interaction.
I first had the idea in 2016. It's mostly been a side project, with a 7 month full time stint in 2018.
Yes
ssh brow.sh -t https://news.ycombinator.comYes
(Please use USD. If none, enter '0') 98
84
87
93
113
900
There is a Carbon ad on the main brow.sh website that generates around $15/month. All other revenue is by donation.
I've been travelling around the world for the last 3 years, mostly in Asian countries, where one is often exposed to networks profoundly inferior to those in the developed world. Whilst in the Indian Himalayas I simply wanted to consume the text from websites (email, twitter, searches, news, etc), so I installed elinks (a terminal browser) on a remote VM and accessed it over SSH. The difference was extreme. At the cost of losing some aesthetics and multimedia content, I could read the web as if connected to a developed nation's network.
However, elinks and their kin do not support modern standards like JS, HTML5, CSS3, video, WebGL and even in some cases SSL. Not to mention that I then needed to do all my browsing in a terminal. This led me to develop Browsh, a modern text-based browser, that, thanks to Hacker News, currently enjoys over 10k stars on Github [1].
I think Browsh's online services will work because most of what is important on the web is text. And text versions of websites can be rendered in all known browsers on all known devices, with consistent formatting, for never more than a few kilobytes. This is not only favourable to the many millions with poor internet but also to those with good but expensive internet.
Example bandwidth comparisons: [Website]: [Normal transfer] // [Browsh HTML] // [Browsh text] India's most popular newspaper [1]: 1.28MB // 69KB // 10KB Wikipedia entry for "Malaria" [2]: 1.40MB // 111KB // 49KB US Tsunami warnings [3]: 1.53MB // 18KB // 7KB Google search for "how to clean water" [4]: 665KB // 20KB // 6KB
The Browsh rendering engine uses Firefox as its backend. Piggybacking off another browser is not new in itself, but it is new in the text browsing space. It has the obvious advantage of off-loading the heavy lifting work of maintaining web standards conformance to a known and proven organisation. In fact it is not Firefox itself that Browsh relies on, but the W3C Browser Extensions specification. This paves the way for Browsh working with multiple backend browsers and perhaps even proposing a formalised specification itself for the human-consumable text representation of the web.
Another way to think about Browsh is: it exposes the simplified interpretation of the web as consumed by search engines but in a human-surfable manner. If machines can extract profound value from the text version of the web, then so too should humans.
Opera Mini [1] (1.73% world browser share [2]) is popular in Africa and Asia because of its use of Opera Binary Markup Language (OBML) which is generated on cloud servers and sent to the user's browser instead of the original markup. This saves both bandwidth and CPU costs. OBML is known to have difficulties maintaining parity with evolving web standards.
The Puffin browser [3] (0.124% world browser share [4]) uses a similar premise to OBML, thus deriving equally significant bandwidth and CPU savings.
(I'd like to briefly note here a common problem with cloud rendering as offered by Opera, Puffin and indeed Browsh: such methods require access to the actual HTML content of the rendered page, which of course has huge security implications. I'm not aware of how either Opera or Puffin overcome this.)
Specialised VNC protocols like TightVNC [5]. This is essentially remote desktop software. It is technical so doesn't have notably wide usage.
I recently discovered that Mozilla was at least researching the possibility of cloud rendering [6].
In some ways Google AMP is responding to the same problem space. Beyond the controversy of the perceived exploitation of power by creating a walled garden under the google.com domain, the attempt to create a universal standard for lightweight websites should be noted.
Superficially it may appear that services such as Mozilla's Reader Mode [7] may be competition to Browsh, but they are fundamentally different in that they format already downloaded websites, thus negating any possible bandwidth and CPU rendering savings.
I've been a software engineering digital nomad for the last 3 years. Having spent a long time in remote regions of Asia I have first hand experience of using poor internet on a daily basis. Also, as a long time web developer I recognise how so much of modern bandwidth is irrelevant to consuming the essential content of the web, namely text. Furthermore, having used Linux for nearly 15 years, Browsh is informed by the Unix philosophy of "writ[ing] programs to handle text streams, because that is a universal interface".
It is an inherent fact of the low-bandwidth browser space that those that would benefit most from Browsh have the least money. Thus my motivation for building Browsh has never been solely profit, but rather a desire that all people should have equal access to the internet. I believe that the world needs a simple means to access the textual web. Any of the major search engines could easily realise a Browsh-like service, but they would likely be viewed with great suspicion for garden walling the entire web. However, I see Browsh either becoming an entity like Wikipedia or being subsumed into an organisation like Mozilla.
(We realize you can't know precisely, but give your best estimate.)
A brief word on growing Browsh as a non-profit. I am open to debate about it, but my own reasons are as follows. Firstly, by the nature of a bandwidth-reducing browser, it is those with the least money that will benefit the most. Secondly, there is a security concern with the fact that cloud-rendering requires access to the HTML of a page, thus breaking the HTTPS paradigm. Considering such a concern, non-profit branding may help improve the perception of the organisation and perhaps dilute any business dynamics tempted to exploit raw browsing data. Finally, as a browser-based service, Browsh will essentially garden wall the entire internet, this is unprecedented and will likely be received with great suspicion. Thus the perception of the Browsh brand will be paramount.
Regarding potential revenue. Taking the Puffin Browser as a cue, a successful startup in the bandwidth-reducing browser space has the potential to capture 0.124%[1] of the world browser market. Assuming there are around 4 billion people online, Puffin potentially reaches around 500 million users. Whatever means Browsh uses to raise funds, exposure to such significant numbers of end users bodes well.
An easy model that has the potential to cover costs is to offer a branded browser on the iOS and Android market places. The browser would simply and transparently prepend 'html.brow.sh' to all URLs, so that users could surf as they would with a normal browser. The Puffin Browser Pro has over 100k downloads on the Google Play store [2], this amounts to around $500k revenue.
There is of course the possibility of benefiting from various grants in the non-profit, open source and charity sectors. Also I have spoken to engineers at both Opera Mini and Mozilla who have expressed interest in working more closely with Browsh.
Finally it must be mentioned, though I am loathed to do so, that by the very nature of cloud rendering, arbitrary content, such as ads, can easily be injected into end user's web pages. Perhaps a middle ground can be found here.
So I, the creator of Browsh, have just started a full time job, that will likely last up to 6 months. Browsh still has some really big issues to face; most notably in text rendering, but also I'd really like to see the Vim mode happen soon. Unfortunately I'm just not going to have much time to take care of these problems in the short-term.
I do now however have some modest sums of donations now coming through on a regular monthly basis, so I want to honour them and try to increase them, such that I might be able to make Browsh my main "job", so to speak.
If you look at the Roadmap project, you'll get an idea of what I'm prioritising, basically it's a mix of what I think are the worst bugs and what I think I could build upon later to charge money for Browsh as a Service. However, of course contributions will still be welcome for any part of Browsh.