Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A new approach to text rendering

blog.atom.io

Post reply on HN
Print view View original

101–110 of 112 posts

Re: A new approach to text rendering

#101

Post by foldr »

LeoNatan25 wrote: post #98
foldr wrote: post #94

Earlier quoted context omitted.

The quality of Atom extensions is good, so that's clearly not true. Also, you are going nuts with the scare quotes. I don't even see what point you are trying to make with those.

> The quality of Atom extensions is good That's debatable for the vast majority of them. "Clearly" is a strong word here. And certainly, regardless of how "good" they are, almost none are worth the hit in performance in the most basic of tasks for me.

Emacs Lisp is much less performant than a modern Javascript implementation. I don't see how choosing JS as the extension language raises any serious performance issues.

Extension quality is a bit subjective, sure. But if you are going to claim that emacs extensions are of higher quality because they're written in a more obscure language, then you should give evidence. That is not my experience.

Re: A new approach to text rendering

#102

Post by LeoNatan25 »

foldr wrote: post #101
LeoNatan25 wrote: post #98

Earlier quoted context omitted.

> The quality of Atom extensions is good That's debatable for the vast majority of them. "Clearly" is a strong word here. And certainly, regardless of how "good" they are, almost none are worth the hit in performance in the most basic of tasks for me.

Emacs Lisp is much less performant than a modern Javascript implementation. I don't see how choosing JS as the extension language raises any serious performance issues. Extension quality is a bit subjective, sure. But if you are going to claim that emacs extensions are of higher quality because they're written in a more obscure language, then you should give evidence. That is not my experience.

Where did I make this claim about Emacs plugins? For me, editing performance trumps plugins.

Re: A new approach to text rendering

#103

Post by foldr »

LeoNatan25 wrote: post #102
foldr wrote: post #101

Earlier quoted context omitted.

Emacs Lisp is much less performant than a modern Javascript implementation. I don't see how choosing JS as the extension language raises any serious performance issues. Extension quality is a bit subjective, sure. But if you are going to claim that emacs extensions are of higher quality because they're written in a more obscure language, then you should give evidence. That is not my experience.

Where did I make this claim about Emacs plugins? For me, editing performance trumps plugins.

If you weren't referring to the performance of plugins when you talked about the "hit in performance", then you are changing the subject from the quality of plugins to overall editor performance. I didn't say anything about that.

Re: A new approach to text rendering

#104

Post by Veedrac »

pjmlp wrote: post #70
aninhumer wrote: post #69

Earlier quoted context omitted.

Eh, I feel like the web platform as allowed it to be massively extensible in a much more convenient and familiar way than a lot of other editors. I tried it for a little bit and it felt like the "Sublime Text but more open and flexible" that I really wanted. If they can work out a way to improve performance without sacrificing too much of that, it would be great.

As an Emacs fan, not really.

The difference is that Atom lets you build UIs; Emacs lets you mash together some text and images.

Re: A new approach to text rendering

#105

Post by LeoNatan25 »

foldr wrote: post #103
LeoNatan25 wrote: post #102

Earlier quoted context omitted.

Where did I make this claim about Emacs plugins? For me, editing performance trumps plugins.

If you weren't referring to the performance of plugins when you talked about the "hit in performance", then you are changing the subject from the quality of plugins to overall editor performance. I didn't say anything about that.

That was my point all along. The people that write extensions in this case are also the people "hacking" on the editor itself, and saying they (or web "devs" in general) are not performance conscious is an understatement to say the least.

Re: A new approach to text rendering

#106

Post by giancarlostoro »

flukus wrote: post #57
giancarlostoro wrote: post #35

Earlier quoted context omitted.

Also as a result of developing VS Code they've made HUGE improvements to Visual Studio 2017. If anyone had been programming .NET Core with VS 2015 and switched to VS 2017 you know what I'm talking about. I went from waiting 12 seconds for my project to compile to blinking and Chrome is opening up. Of course you have to turn off their browser debugging integration, that thing just sucks up so much dev time if you're n…

My experience with 2017 has been the polar opposite. It runs glacially slow compared to the 2013 installation on the same machine. The startup time makes eclipse look lean and mean, it takes over a minute to start.

Weird... It takes less time to start up for me, and compiling .NET Core is quicker, it even told me ReSharper is slowing down startup time at one point and suggested I disable it. Also suggested I disabled another component on startup because it was taking longer to start VS as a result. I guess it may vary depending on system specs? Not sure. I run it both on my workstation at work and on a VM on my laptop and at my home desktop.

Re: A new approach to text rendering

#107

Post by foldr »

LeoNatan25 wrote: post #105
foldr wrote: post #103

Earlier quoted context omitted.

If you weren't referring to the performance of plugins when you talked about the "hit in performance", then you are changing the subject from the quality of plugins to overall editor performance. I didn't say anything about that.

That was my point all along. The people that write extensions in this case are also the people "hacking" on the editor itself, and saying they (or web "devs" in general) are not performance conscious is an understatement to say the least.

But this very post shows that they are performance conscious!

Re: A new approach to text rendering

#108

Post by pcwalton »

coldtea wrote: post #87
pcwalton wrote: post #43

Earlier quoted context omitted.

CSS is more powerful than anything that popular native text editors can do. As far as I'm aware, in native text editors, generally, style can't influence (block-direction) layout, and that's why they can get away with determining what's visible before restyling. Once you have styles that can influence layout, this dependency is reversed, so any native text editor will have to restyle off-screen lines just as a browse…

> CSS is more powerful than anything that popular native text editors can do Which give even more credence to what the parent said: that "CSS isn't the right abstraction for styles in a text editor…". We don't really need the "more power" in an editor, but we could use the less slugginess (and less conceptual overhead) than what CSS offer. > Is it worth restricting an editor to only styles that don't influence block…

If any editor has to restyle all lines, even lines that are off screen, and it supports declarative themes, then it must do the very same thing the browser does. And I suspect that any editor that does this styling will end up being slower than browsers are at this task, because of the sheer amount of optimization that has gone into browser styling at this point.

Re: A new approach to text rendering

#109

Post by pcwalton »

twhb wrote: post #79
pcwalton wrote: post #2

> One frustrating component of the above breakdown is the time spent recalculating styles. At this point, it looks like the only way to solve this within the current paradigm is to use CSS less and reduce the number of selectors in the application, but that’s going to be a hard fought battle given the huge number of themes in the ecosystem. This is a perfect example of why we need parallel restyling. :)

Parallel restyling just kicks the can down the road, asking for free perf elsewhere because we still haven't made it fast. What we need is a low-level style interface - .style but for computed, not CSS-integrated, styles - and then to plug into that using CSS where appropriate, or custom JS where appropriate, or even framework JS. Let people control style selection in a real programming language and you've guaranteed…

I don't necessarily disagree, but I'd like to reassess where we are in terms of performance once Typed CSSOM is widely used. Using Typed CSSOM to adjust the "style" properties of individual elements is awfully close to doing what you describe: the difference is that matching and cascading still happens, but the semantics become much simpler if you're adjusting individual styles, and it's not clear to me that most of the overhead can't just be optimized away at that point.
Post reply on HN