Hacker News Reader

Comment by beardicus | Hacker News Reader

Update: Hyper 3 feels super-fast. Startup and new tabs are somewhat sluggish still but actual rendering responsiveness seems real nice.

View on HN

Sad commentary on the state of the world when you feel the need to comment on the speed with which a computer can pain text to the screen.

If you read their changelog you'll see that Hyper 3.0 uses WebGL to achieve this.

OpenGL. To draw text at a reasonable speed. It's not individually an insane thing to do within the context of Electron, etc. but take five steps back and talk about using a sledgehammer to crack a nut...

It's not insane. FYI the fastest terminal (alacritty) achieves its performance by rendering via gpu, and it's written in rust. iTerm recently started doing it too.

But if you look at input latency benchmarks (there was one posted not too long ago on HN, maybe a month or 6 weeks ago) alacritty isn't close to the fastest terminal for pressing a key and being able to see the key on the screen.

IMO pressing a key and seeing it is the primary focus of a terminal.

Here is an output latency benchmark [1]

[1] https://github.com/jwilm/alacritty/issues/673#issuecomment-4...

I wrote the WebGL renderer after explorations in rendering the text using a 2D canvas which simply didn't live up to my expectations. It wasn't so much about drawing text at a "reasonable" speed, that was very easy to accomplish using the DOM, it was about excelling and trying to reach native-level performance from within a web context.

You can argue about the downsides of Electron all you want, but in xterm.js (the component that does the terminal parsing/rendering that Hyper consumes) we have a portable terminal frontend that can run on anything that has a webview and is getting really fast. It's also used in _a lot_ of software[0]. I wouldn't call that particularly sad.

https://github.com/xtermjs/xterm.js#real-world-uses

Actually that's a very reasonable thing to do. macOS has been using hardware accelerated graphics since 10.0, and leveraging this is better than fighting it.

Also see https://github.com/jwilm/alacritty

+1 for Alacritty. I've been using it as my daily driver (switched from iTerm2) for a few months now and I couldn't be happier.

How do people use Alacritty as a daily driver when it can't open more than one window?

Tmux. Alacritty lacks basic things like splits or tabs so tmux or screen are recommended.

I know that's the answer for running multiple sessions at once, but even if you're a tmux expert I don't see how people live with only one window. I constantly have multiple iterm windows open and frequently open new windows for one-off things.

If you're a tmux expert, it'd work something like this:

1) You don't have the default config/bindings.

2) You use some plugins.

3) You use multiple _panes.

4) You use multiple _windows_ (Do not confuse these 2).

5) You save sessions which persist between tmux sessions/reboots.

6) You run your terminal full screen or at least maximized.

Example:

I make a pane with ctrl+a (I don't use ctrl+b as tmux hotkey) plus - or plus |.

I make a window with ctrl+a + c.

I can switch between panes with ctrl+a + hjkl (or pointer).

I can switch between windows with ctrl+a + 1234567890 (or pointer).

So what matters is that running multiple terminal windows side by side is akin to using Tmux panes, and using multiple terminal tabs is akin to using Tmux windows.

It requires some practice to get used to it because basically Tmux becomes more and more your window manager...

(You can even run Firefox in a terminal btw, with Browsh.)

Reply on news.ycombinator.com