Live data from Hacker News

Building a hackable editor in the browser

bjenik.com

21–30 of 74 posts

Re: Building a hackable editor in the browser

#21
post #9
post #7

Earlier quoted context omitted.

My browser is not slow, for me starting and using a lot of desktop apps feels slower than browser apps to be honest.

Probably because your desktop apps are bloated, too. Any software that needs longer than zero point two seconds reacting to user action (this includes starting the program) should be improved upon.

What desktop programs do you use that take fewer than 0.2 seconds to start?

Re: Building a hackable editor in the browser

#22
post #7
post #6

...how about moving things out of the browser? It's cramped as it is. And then people wonder why their browser is so slow... "it's just displaying documents!"

My browser is not slow, for me starting and using a lot of desktop apps feels slower than browser apps to be honest.

If you think you browser is fast, you'd be blown away by any decent application.

Too bad all apps are now electron.

Re: Building a hackable editor in the browser

#23
post #7

Earlier quoted context omitted.

My browser is not slow, for me starting and using a lot of desktop apps feels slower than browser apps to be honest.

If you think you browser is fast, you'd be blown away by any decent application. Too bad all apps are now electron.

> If you think you browser is fast, you'd be blown away by any decent application.

In data centers, loading data from networked server, where it's in memory, can be used over loading data from a disk, because disk is comparatively slow.

A web app can load JavaScript assembler, which isn't much slower than a desktop app written in C.

Bigger - and slower - parts of the web app can be loaded after the app starts interacting. So - at least in principle - no sizeable speed difference, which would blow somebody away.

Advantage of web app is cross platform uniformity. Write once, run everywhere.

Of course, reality can make adjustments, but we can see and invent things.

Re: Building a hackable editor in the browser

#24
post #9
post #7

Earlier quoted context omitted.

My browser is not slow, for me starting and using a lot of desktop apps feels slower than browser apps to be honest.

Probably because your desktop apps are bloated, too. Any software that needs longer than zero point two seconds reacting to user action (this includes starting the program) should be improved upon.

I do like performant apps, but I've never understood the emphasis on startup time for most of them. There's the odd utility (eg. screenshotting) where an instant start is desirable. But the main things I use (terminal, editor/ide, browser etc) are started once per week at most.

I personally wouldn't want the developers of the software I depend on most to waste resources speeding up something of such marginal significance.

[Edit: an instant-start editor for config file, vim commit edits etc is of course crucial]

Re: Building a hackable editor in the browser

#25
post #14
post #5

Earlier quoted context omitted.

This is a discussion forum. Putting things into words is the purpose of commenting. If you can’t, then maybe you shouldn’t.

I did put something into words, didn't I? ;) Joking aside, I would have thought this was possible.

*never thought

Re: Building a hackable editor in the browser

#26
post #15

Earlier quoted context omitted.

Yeah, I've been writing CSS and HTML for over 20 years and I would have thought these tags were in the actual DOM and could be rendered.

You would or would not have thought? I suspect you forgot a negation.

Thanks, yes I forgot "never".

Re: Building a hackable editor in the browser

#29
post #6

...how about moving things out of the browser? It's cramped as it is. And then people wonder why their browser is so slow... "it's just displaying documents!"

For that we’ll need an adequate cross-platform (-ish) way of doing UI. I’m not a fan of React Native, but it seems to be the technology we’re looking for, though it doesn’t seem to be as ready for the desktop yet.

An all-native solution on top of a powerful modern language (rust?) would be ideal, but that doesn’t seem to be the direction things are moving. We’ll probably end up with Flutter/Native.

Post reply on HN