[HN Gopher] Forking Chrome to render in a terminal
___________________________________________________________________
 
Forking Chrome to render in a terminal
 
Author : fathyb
Score  : 279 points
Date   : 2023-01-27 15:42 UTC (7 hours ago)
 
web link (fathy.fr)
w3m dump (fathy.fr)
 
| anthk wrote:
| Meh, electron. I'd prefer elinks being boosted with QuickJS
| support instead of the old engine based on... Mozilla?
| 
| Edbrowse uses it and it has enough JS support to even login and
| comment against JS ridden sites.
| 
| https://edbrowse.org
| 
| Browser, email, irc, SQL client, file manager and editor for the
| blind with an ed philosophy.
 
| wwarner wrote:
| I mean. This works really really well. I almost made it through a
| captcha.
 
  | comfypotato wrote:
  | Could probably zoom into the captcha with some elbow grease.
  | The resolution is there if it filled the terminal.
  | 
  | This is actually the showstopper for me with any kind of
  | terminal browser. I enjoyed playing with browsh (or what was it
  | called?) a few years ago, but this is much better.
  | 
  | I wonder if my suggested workaround has any meat to it.
 
| kps wrote:
| Time to dig out my Wyse 50 again!
| https://chromium.googlesource.com/chromium/src/+/HEAD/docs/o...
 
| SirRockALot wrote:
| This is really neat. Did you consider using the full range of
| Unicode block glyphs to squeeze out a little bit more resolution
| from the terminal vs just using the half-block?
| 
| https://github.com/blitzcode/term-gfx/blob/master/src/main.r...
| 
| You're still just getting two colors per character, but I think
| it works quite nicely.
 
  | fathyb wrote:
  | It's a great idea, I did explore it but ended up falling in the
  | dithering and Fourier rabbit hole.. I'll give it another try
  | without any color tricks!
 
| lights0123 wrote:
| > One of the unicode characters we can render is the lower half
| block element U+2584: . Knowing that cells generally have an
| aspect ratio of 1:2, we can render perfectly square pixels by
| setting the background color to the top pixel color, and the
| foregound color to the bottom pixel color.
| 
| Even better: https://en.wikipedia.org/wiki/Sixel Doesn't support
| 24-bit color though.
 
  | fathyb wrote:
  | I did write a very fast SIXEL back-end [0] with adaptative
  | quantizing and GPU acceleration, but most emulators have a very
  | inefficient implementation unfortunately. For example iTerm
  | converts the SIXEL data to PNG, writes it to tmpdir, and
  | displays it as an image you can drag and drop.
  | 
  | I'm still exploring it thought, but as a separate program to
  | run any X apps through SSH.
  | 
  | [0]: https://news.ycombinator.com/item?id=34288262
 
    | [deleted]
 
| whatever1 wrote:
| Newbie question: why the terminal cannot have full high
| definition graphics ?
 
| ShowalkKama wrote:
| Reminds me of https://www.brow.sh/
 
| dodslaser wrote:
| Super neat. If you want to go even deeper down the terminal
| graphics rabbit hole you should look into adding sixel support.
| 
| https://github.com/saitoha/libsixel
 
  | csdvrx wrote:
  | And for terminals that don't support sixel yet, sixel-tmux will
  | let you see them:
  | 
  | http://github.com/csdvrx/sixel-tmux
  | 
  | For example with Windows Terminal:
  | https://raw.githubusercontent.com/csdvrx/sixel-tmux/main/exa...
  | 
  | OP, if you want to keep your current solution, check how going
  | beyond unicode halfblocks can help:
  | https://github.com/csdvrx/derasterize
 
    | wing-_-nuts wrote:
    | This is really cool. Is it supported on the framebuffer
    | terminal as well?
 
  | [deleted]
 
| azalemeth wrote:
| This is both genuinely very impressive and also brings me hope
| that I can finally use Microsoft SSO only services natively in
| the console...
 
  | sramsay wrote:
  | Hadn't thought of that. Take my money!
 
| randall wrote:
| This is the coolest shit ever.
 
| synergy20 wrote:
| xterm + w3m can browse with images for me.
| 
| kitty + w3m is getting there as well.
 
| michaelmior wrote:
| I'm incredibly impressed with how smooth this is. (And how small
| the Docker container is!) I might actually use this for real
| things.
 
| rubatuga wrote:
| Absolutely insane engineering. Hope this is an alternative to
| elinks
 
| realworldperson wrote:
| [dead]
 
| sylware wrote:
| What we actually need would be a full-blown modern javascript-
| enabled browser written in simple and plain C (c89 with benign
| bits of c99/c11), namely with a compile-time/runtime object model
| suited for the "web".
| 
| I good start: re-use the parsers from netsurf, get mr Bellard and
| friends quickJS... and then the ez part: get 748392749324732984
| full-time devs full for 748937489234 centuries in order to get
| such engine working... BUT it is not finish since, once
| "working", you will have to play catch up with blackrock/vanguard
| financed web engines and everything they will do to break compat
| with your engine.
| 
| Some ppl are still trying with rust? servo something?
 
  | anthk wrote:
  | QuickJS it's being used in the edbrowse terminal browser and
  | it's good enough to login and post on a lot of web sites.
 
    | sylware wrote:
    | Been a user of it for a while now. But don't worry, where it
    | was used to work, well... it usually do not last very long:
    | it feels like there is active work done to "break" any
    | alternative from vanguard/blackrock financed javascript-able
    | browers from "working".
 
  | rightbyte wrote:
  | Ye the problem is the web sorta standard themself. A never
  | ending bloat race that you need 100s of programmers to keep up
  | with.
  | 
  | Thatcher is by design and I guess Google is mainly to blame by
  | now.
 
    | sylware wrote:
    | Well geeko/webkit and blink are all financed by the big tech
    | controlling funds. webkit(apple) and blink(google=alphabet)
    | are own and steered by those same ppl.
    | 
    | Oh, and those ppl own and steer microsoft too, and some
    | wonder why those are using blink now. I do ask myself how
    | long they will keep webkit and blink since they have already
    | geeko to feint the anti-trust laws.
    | 
    | But your are right, they made the "Standard" so insanely
    | complex on top of the core noscript/basic (x)html, that it
    | "works" only in their implementations with their armies of
    | devs.
    | 
    | This is accutely toxic for humanity. The only "real" ways out
    | of this: restore noscript/basic (x)html where it is still
    | doing a good enough job, and if a "new" web has to be born:
    | an implemention must be something reasonable in time/skills
    | and efforts for a small team of devs.
 
| igneo676 wrote:
| Huh, built on electron. I wonder how difficult it would be to
| bolt this onto vieb and have the ultimate vim-terminal browser
 
| oldgradstudent wrote:
| Next step: vscode on the terminal.
 
  | yuck39 wrote:
  | Install the VIM plugin and we go full circle
 
| SeanAnderson wrote:
| My jaw is on the floor. I would've been fully impressed with the
| unoptimized version, but pushing it to squeak out significant
| rendering performance improvements was a surprise treat!
 
___________________________________________________________________
(page generated 2023-01-27 23:00 UTC)