jtokoph 7 years ago

> But if we’re going so far as to bypass Chrome’s CSS engine, maybe we should try to bypass the DOM entirely.

Seems like Atom will eventually just be a native app.

  • djfm 7 years ago

    Yeah, technology loves cycles.

    "Hey, let's write an editor for a browser. Oh wait, we need a browser for that editor".

    Something good will probably come out of this eventually. I mean if they manage to turn electron into a true native cross platform app framework it's nice.

    • kuschku 7 years ago

      > I mean if they manage to turn electron into a true native cross platform app framework

      …then you’ll end up back where you started with the JVM.

      • djfm 7 years ago

        Right. We might as well just compile our JS to Java.

        Instead of using web tech to build native apps I think we should focus on improving browsers so that web apps behave more like native apps and have the same capabilities. Browsers should be the cross-platform VM and webassembly is a good step in that direction.

  • mrmondo 7 years ago

    If it does, I'll reconsider using it. I truly can't stand JavaScript 'apps'.

LorenzoLlamas 7 years ago

Yet another post about "technology improvements" that basically is some company (Github) with an axe to grind that wants to reinvent the wheel but has nothing new to offer.

To be more clear, no one is writhing in their sleep, or bemoaning to their team mates, this: "We have no good way to edit text in the 21st century". No one. At best, it's a nice idea to see "what if" we could build an emacs-like text editor using modern day web technologies, just to see what browsers and HTML5, etc, can do these days, and hey, maybe we will learn something and push the browser technology a bit, too. At worst, it's bunch of people with no other interesting ideas and who need to bring attention to their company.

What's next for this Electron crowd? Let's see if we can build a whole operating system into a browser? Oh wait. That's also been done with a lot of noise and no real-world impact. Well then, what about a new kind of spreadsheet? Or maybe we could do some cool photo-processing using only a TI-84 calculator!

Ugh. I'm so tired of this, and this massive post by the dev team at Atom proves the insanity of all this.

They have spent thousands of man-hours "improving" their text editing rendering for their slow text editor (but hey, we saved time by building it on top of Chrome!), and yet they are nowhere near text-rendering speeds of 40 years ago.

But never mind that. They will continue to plug ahead and write more posts about it. Meanwhile, emacs (and Vim) plug along as always.

How bad is it (to me)? I'll tell you. Even though I alter between Sublime (written in real code and not on 'borrowed' code) and BBEdit sometimes, along with Vim (still learning), and even MacVim (the horrors!)... THIS is how bad it is. It's so bad... that I would use TextEdit to edit code before I used Atom. I promise you. I actually like TextEdit and often use it anyway. I sometimes wish Apple would just add a few tiny improvements (but I'm daydreaming) and I would use it for 90% of files and projects.

But Atom? Like a lot of modern day projects (React, Bootstrap, WordPress, Facebook, etc), it's a total step backwards to reinvent what we already had. So that basically "new" people can come along and play - with less understanding, IMHO.

  • johnfn 7 years ago

    The fact that the only important factor you can think for a text editor to improve on is text rendering speed shows that you're not really on Atom's target demographic.

    You'd think that hundreds of thousands of Atom users would convince you that maybe there's something to the editor that works for others if not for you. But nope, all those guys are happy with switching their main IDE to "a total step backwards", for some reason.

    • biocomputation 7 years ago

      >> main IDE to "a total step backwards", for some reason.

      Cargo cult is the reason.

      • johnfn 7 years ago

        Yeah but isn't it amazing how cargo cult only applies to the things I don't like?

pugio 7 years ago

I've maintained restrained excitement about Atom for years. A super hackable editor (what more could a tool-obsessed coder want)... but frustratingly laggy. This release finally feels snappy enough that I may switch.

Large files, slowish startup, and the like are all special case problems that I can use Sublime for, but until now, the almost subliminal typing sluggishness always drove me away.

Bravo Atom team for making it fast enough. I look forward to continued improvements in this space.

  • nicpottier 7 years ago

    You may also want to give VSCode a go. I haven't used a Microsoft product (willingly) for decades, but it is a really, really nice and much snappier than Atom in my experience with things like key echos.

    Their integration for TypeScript and GoLang are first class as well. Overall though I held the same excitement for Atom as you did (and I used to use Emacs for everything because I wanted an open editor in my tool belt) I've really come to appreciate the approach and polish of VSCode.

    • giancarlostoro 7 years ago

      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 not using it at all.

      • flukus 7 years ago

        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.

        • giancarlostoro 7 years ago

          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.

        • Sacho 7 years ago

          Have you tried disabling package restore on open?

          • flukus 7 years ago

            I'm talking about just to start the IDE with no project, opening a project is time on top of that.

            I don't see how it would make a difference though, running "nuget restore" only takes a second or two.

    • jcalabro 7 years ago

      I'm not sure why it was, but I couldn't use vs code because all the vim plugins available made it lag like crazy (~1sec per cursor movement). It's also worth noting that it only lagged on my work machine, not at all sure why :/ it was fine on my personal machine but it dissuaded me from switching because of it

      • chillee 7 years ago

        All the vim plugins? That's bizarre. VSCodeVim had a bug if you were using `useSolidBlockCursor` that would slow it down, but I'd be surprised if all the vim plugins had the same bug.

  • LeoNatan25 7 years ago

    > what more could a tool-obsessed coder want

    An editor that is not "hacked" together on idiotic technologies ("web" "dev"), but a well designed editor, written for performance, on top of the best technology for that specific job.

    • amcca029 7 years ago

      yeah, portability is stupid.

      • cpburns2009 7 years ago

        Portability isn't stupid. However, one could argue that embedding a full web browser to achieve portability is.

      • benibela 7 years ago

        you do not need javascript for portability

        emacs pretty much runs everywhere

        And there is a webkit extension to turn emacs into a browser. I wonder how well atom will run in emacs

      • coldtea 7 years ago

        Portability that goes against essential features of a product IS silly.

  • torrent-of-ions 7 years ago

    > A super hackable editor (what more could a tool-obsessed coder want)

    That's why emacs has existed for decades now.

pcwalton 7 years ago

> 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. :)

  • panic 7 years ago

    I dunno, I'd say it's more an example of why CSS isn't the right abstraction for styles in a text editor…

    • pcwalton 7 years ago

      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 browser must.

      Is it worth restricting an editor to only styles that don't influence block layout? For example, should it be impossible for a theme to make comment lines taller or shorter? I don't know; it's a tradeoff between performance and flexibility. My feeling is that there's a lot more room to improve the implementation before we have to resort to reducing capabilities, but reasonable people can disagree.

      • kazinator 7 years ago

        Should it be impossible for a theme to make comment lines taller or shorter?

        Of course not; everyting should be in the same damned monospaced font in a text editor for writing code.

        • capnrefsmmat 7 years ago

          My Emacs Org-mode setup already has larger font (and taller lines) for headings, so this isn't too crazy. Not everything in a text editor is code; some of it is text.

        • aninhumer 7 years ago

          Why does code need to be monospaced? I feel like the only reason we all do it is that it's always been done like that so it feels wrong not to.

          The only actual reason I can think of for it is alignment, and that seems like a minimal benefit really. Variable width text is generally considered easier to read, so why couldn't this also apply to code?

          • kazinator 7 years ago

            Alignment isn't a minimal benefit; it is super important.

            It's not just for neatness; either. Alignment shows where differences are between similar lines. And not necessarily consecutive lines. For instance, if we rapidly flip the editing window back and forth between two buffers showing similar code, we can see the differences as the moving parts in a two-frame animation.

            Even in proportional fonts, the digits 0 to 9 get the same width. Why? So that tables of figures will look reasonable.

            We don't want 1111.11 looking narrower than the 100.00 in the preceding row.

            I want everything to be crisply aligned between lines like:

               xr = x * cos(theta) - y * sin(theta);
               yr = x * sin(theta) + y * cos(theta);
            
            This makes it easy to see where the differences are. Any gratuitous deviation from the alignment is visually distracting. I want to be able to scan the thing vertically y and see that I have two x's, two y's, cos/sin sin/cos, and -/+ at a glance.
            • patrec 7 years ago

              This must be why math literature has been using fixed width fonts for hundreds of years! No way you could ever align something with (hugely more readable) proportional fonts. BTW, numerals are not automatically same width in proportional fonts; a good font will often have both (and for tables you'd explicitly switch to tabular figures, which will align properly).

          • coldtea 7 years ago

            >Why does code need to be monospaced? I feel like the only reason we all do it is that it's always been done like that so it feels wrong not to.

            Because alignment.

            >The only actual reason I can think of for it is alignment, and that seems like a minimal benefit really.

            Most programmers I know would argue otherwise, including me. Wanna try a poll?

            >Variable width text is generally considered easier to read, so why couldn't this also apply to code?

            Because it's only considered "easier to read" for general text (books, articles, etc) where you don't need to quickly see anything standing out of the ordinary, and alignment doesn't matter.

            Even for traditional uses like accounting, "variable width" is not considered easier to read.

          • NTripleOne 7 years ago

            Fuck knows why it couldn't - but in my personal experience code is infinitely more difficult to read without a monospaced font.

      • coldtea 7 years ago

        >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 layout? For example, should it be impossible for a theme to make comment lines taller or shorter?

        I'm pretty sure existing editors can do that today too, without CSS. Setting a different font size for comment lines for example.

        • pcwalton 7 years ago

          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.

      • cwzwarich 7 years ago

        Why do you need style information for off-screen content in a text editor? It's not like you're going to have JS running that can query the computed style at any point. If it's for scrollbars then you can probably just use an approximation, or compute metrics without actually computing full style information.

        Based on my limited experience, most text editors don't have correct information for off-screen content anyways, as they tend to do lazy syntax highlighting, which you can sometimes see adjusting while you scroll.

        • pcwalton 7 years ago

          > Why do you need style information for off-screen content in a text editor? It's not like you're going to have JS running that can query the computed style at any point. If it's for scrollbars then you can probably just use an approximation, or compute metrics without actually computing full style information.

          To know how high the editor is, for scroll bars, Sublime Text-style minimaps, etc.

          Computing metrics basically requires computing full style information. Doing cascading for any property isn't much more expensive than doing cascading for all properties.

          > Based on my limited experience, most text editors don't have correct information for off-screen content anyways, as they tend to do lazy syntax highlighting, which you can sometimes see adjusting while you scroll.

          Sure. The way to do that in the Web platform is to do what Atom is doing here: adjust styles only when elements come into view. IntersectionObserver can be useful for that.

      • nine_k 7 years ago

        CSS gives a lot of power; I'd say too much for a code editor.

        It would be great to have a small high-performance subset. The subset needs not have low expression power, though.

      • pdkl95 7 years ago

        > Is it worth restricting an editor to only styles that don't influence block layout?

        That includes font-* and many other attributes that affect text rendering. It isn't possible to know the length of a line of text without computing most of the text layout in modern font rendering. Font family/size/variant, weight, kerning, vertical hinting, traditional horizontal hinting, and LCD subpixel hinting all influence character positions at 1/256 pixel resolution. I highly recommend this[1] paper for a good overview of how this works, which includes an analysis of why Microsoft's older font handling caused serious layout issues (cumulative x-length error) due to over-hinting that forced glyphs onto the pixel grid.

        > editors

        Monospace fonts usually let you ignore most of these issues, but some (crazy?) people program with proportional fonts[2], and we can't actually ignore Unicode...

        (I just use an 80/20 solution: fast - and predictable - Terminus and Dina bitmap fonts most of the time, and let Unicode distort the layout with other stuff as needed)

        [1] http://www.antigrain.com/research/font_rasterization/index.h...

        [2] https://news.ycombinator.com/item?id=1056683

  • pjmlp 7 years ago

    This is a perfect example of why Atom should have been a native application to start with.

    • geodel 7 years ago

      But Github is doubling down on Electron with their next github client on Mac/Windows etc. Also how would they write blogs about performance if it is plain old native text editor.

      • pjmlp 7 years ago

        Also known as CV driven development.

        I use TortoiseGit and IDEs to access Github.

    • aninhumer 7 years ago

      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.

      • pjmlp 7 years ago

        As an Emacs fan, not really.

        • foldr 7 years ago

          This isn't about emacs. Atom is for people who want an alternative to Emacs. If you only need to know JS and CSS to write an extension, that vastly increases the pool of people who are able to write extensions.

          • LeoNatan25 7 years ago

            That "pool" of people "able" to "write" "extensions" is exactly the people you don't want touching your text editor, or any software for that matter. Anyone that has a psychological barrier to take a look at a language that they are not familiar with, let alone a framework or an ecosystem, is not someone that I want being anywhere near the software I use. In an ideal world, I wouldn't want them to be anywhere near the web I visit either, but that is a lost cause.

            • foldr 7 years ago

              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.

              • LeoNatan25 7 years ago

                > 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.

                • foldr 7 years ago

                  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.

                  • LeoNatan25 7 years ago

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

                    • foldr 7 years ago

                      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.

                      • LeoNatan25 7 years ago

                        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.

                        • foldr 7 years ago

                          But this very post shows that they are performance conscious!

        • Veedrac 7 years ago

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

          • pjmlp 7 years ago

            I though that was the purpose of a text editor, go figure!

  • twhb 7 years ago

    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 that it can now be done in a way that's fast and suitable.

    • pcwalton 7 years ago

      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.

  • Xeoncross 7 years ago

    How would that work? Breakup the screen into chunks each CPU/GPU renders?

    • pcwalton 7 years ago

      The same way Servo (and the work-in-progress Servo port to Gecko) does it. Compute styles for every DOM node in parallel, using a work-stealing scheduler to distribute nodes among threads in a thread pool. Parent nodes must have their styles computed before children, but other than that constraint it's an embarrassingly parallel problem.

      • thomasahle 7 years ago

        In css sibling nodes can certainly affect the position of each other, but that might be ok. A harder problem will be siblings that "run in" to each other, and overlap in various ways.

        • pcwalton 7 years ago

          I'm talking about styling, not layout.

      • revelation 7 years ago

        Work-stealing scheduler, thread pool? What is going on here?

        Have any of you seen the kind of stuff recent games draw in 16 ms? It's amazing! They sure as hell don't use a work-stealing scheduler in a thread pool for single vertices, though.

        • pcwalton 7 years ago

          Games are at an advantage because they can do a lot of up-front processing. They can statically schedule their content based on knowledge of the hardware, and programmers can and do even tell the artists to tailor their content directly to the system. Conversely, on the Web, we can't do any of this: we have no idea what the content is going to be like until we receive it, and we have to handle specifications that were written without parallelism in mind. All of the decisions we make have to be dynamic rather than static, which is why work stealing is especially effective.

          Besides, vertices are a much simpler problem than CSS styling. CSS supports hundreds of properties, all of which are parsed and cascaded differently. You have properties that are inherited and properties that are noninherited. You have properties that depend on other properties: for example, any lengths might be specified in terms of ems, which means you have to have resolved the font size first. You have properties that result in completely different render trees, for example "display". You can't effectively throw stream processors like GPUs at the problem (believe me, I've tried).

          Could we do better? Sure. But every proposed replacement for CSS I've seen (e.g. Cassowary) has made the complexity problem worse. And most native styling solutions I've seen are usually just very slow implementations of CSS. Separating presentation and markup is just hard, no matter what.

          • teleclimber 7 years ago

            > But every proposed replacement for CSS I've seen (e.g. Cassowary) has made the complexity problem worse.

            Hi, what other proposed replacements for CSS do you know about? I'm interested in seeing what problems they ran into.

            I need to go look at Cassowary again. IIRC it's a solver, so sometimes the layout won't be what you expected, and it's very hard to know what to change such that it does what you want.

            • pcwalton 7 years ago

              Cassowary was admittedly a bad example, because it's a layout algorithm rather than a style system. But I've seen folks suggest that we just replace CSS with TeX, for example. Using TeX would make this problem a lot worse, because styling TeX involves expanding textual macros. You would lose any possibility of parallelism, ever.

        • zubat 7 years ago

          Or to put it in other words: browser technology is asked to do so much that they had to go invent a new language to keep up. So that they could serve ads.

          For us ordinary folks trying to write good applications that can be maintained by one person and scale reasonably well, there's justifiable reason to jump off this rollercoaster and work in a more humble environment with modest perf/safety tradeoffs and native code executables(e.g. Go, Basic, Pascal).

          • justinmk 7 years ago

            The "so they could serve ads" meme is facile, reductionist, sophomoric. Actually, the fact that Google et al. were able to identify a profit function that could be optimized to fund the last 15 years of technology is an incredible achievement. In ~2000 it wasn't at all obvious that the internet could find a robust funding model.

            Where the funding comes from is practically irrelevant, specially if it is a feedback function (i.e., an economic phenomenon, not "phone the legislature to fund more research!!1").

            New funding models are good, too, of course. But the tone of the anti-ad camp is asinine.

            • zubat 7 years ago

              A realpolitik view of tech only holds under the assumption that any new technology is good technology. It allows nothing to balance or sustainability, and I believe the trajectory of the Web is unsustainable and therefore fundamentally doomed despite its near-term wonders.

              The SV camp has said nothing to convince me otherwise.

            • coldtea 7 years ago

              >Where the funding comes from is practically irrelevant, specially if it is a feedback function (i.e., an economic phenomenon, not "phone the legislature to fund more research!!1").

              I preper phoning the legislature -- more democratic and less private interests-driven.

        • Rusky 7 years ago

          Games do, however, use job systems just like that for plenty of things that aren't single vertices.

        • Manishearth 7 years ago

          Games are a completely different problem space. "styling" is a concept that games don't have; games don't deal with deciding which thing has which style at runtime. Browsers do, because they are just given CSS and have to handle the cascading and assigning of styles on their own.

          • intoverflow2 7 years ago

            > "styling" is a concept that games don't have

            I disagree. Look up how modern material systems work. There absolutely are analogous things going on to CSS in PBR rendering, shaders, multipass compositing etc.

          • revelation 7 years ago

            Of course they do, modern games are a complex interaction of many different shaders operating on all levels of abstraction on many different classes of runtime data that they compose, renew and adapt many many times in 16 ms.

            Is the whole CSS debacle a particularly unlikely concept to yield anything close to a reasonable performing implementation? Sure, but that is because nobody has applied the pressure necessary. People won't play a game that doesn't consistently meet a 30 ms deadline but they seem to happily put up with 3 seconds to final render and call it "amazing".

            • Manishearth 7 years ago

              Shaders are a completely different thing from styling (cascading).

              GPUs work here because games fundamentally operate on a list-like datastructure (the display list), with little interdependence.

              Styling on the other hand operates on a tree like datastructure (the DOM), with lots of interdependence.

              Cascading isn't something games need at all, and if it was, it could be precomputed. THis can't be done in webpages.

              • mianos 7 years ago

                Game engines are pretty much completely sitting on complex tree structures. Way more than the DOM. The main reason the DOM all looks so tricky is it is a hack on a hack on a hack. A lot of game engines have been rewritten from scratch many times over.

                • Manishearth 7 years ago

                  Yes, trees are involved in games too, but not at the level I'm talking about.

                  You don't have analogues for tree-structure-based "selectors" and anything more than straightforward property inheritance (e.g. inheritance of transformations in a skeleton) in game engines. CSS is much more complex in this aspect.

                  The DOM having lots of legacy issues is not the reason styling is slow.

                  CSS is designed for a lot of flexibility and can't be precompiled, which is why it is slow to style.

torrent-of-ions 7 years ago

What a waste of time. A text editor where "more responsive typing" is a feature is a joke. These problems were solved decades ago on far more limited hardware.

OberstKrueger 7 years ago

This post mentions how the text storage has already been moved to C++, and the possibility of moving parts of the rendering to C++ as well. Is this part of a trend for Atom to move at least key components to C++ and away from the web stack? Or am I off base with this thought and it's been lower-level to begin with, but these are just optimizations on that?

  • maxbrunsfeld 7 years ago

    Atom has always had some C++ components, but lately we have moved more core data structures to C++. This PR, which re-implements the text-buffer in C++, also landed in the latest beta.

    https://github.com/atom/atom/pull/14435

    • pjmlp 7 years ago

      With enough such improvements, Atom will become a native app, as it should always have been.

  • wbobeirne 7 years ago

    They seem to be adopting a more react native-like mindset of using React to orchestrate what should be happening, but have native code running lower level components. I wouldn't call it "moving away" from the web stack, just having it do more delegating, and less of the nitty-gritty.

andrewmcwatters 7 years ago

Though I use Atom on a daily basis, I maintain the opinion that with software available such as Visual Studio Code, it's painfully obvious that Atom never had performance as a high priority to begin with.

benibela 7 years ago

Recently I had to edit test data for a grading platform (People upload their programs, the programs get called with the test data and they get feedback if their program works correctly). One test file had 900 000 characters in one line. Almost 1 MB, not a single linebreak. The grading platform is a webpage and you upload things through an online editor, so I pasted the file in Firefox and Firefox crashed.

dham 7 years ago

I thought this was going to be a post about fixing the horrible font rendering. Although I guess that's really a Chromium issue. Still can't switch to Atom to this day because of the font rendering.

rjzzleep 7 years ago

So, we're sort of simulating offscreen drawing by using a virtual dom? I mean don't get me wrong it's sort of nice that they did this as it's the only thing they could have done to deal with the issues I wrote in my 2014 blog post, but that also means that with a lot of effort the web is now able to do what quickdraw could almost 20 years ago...

  • pcwalton 7 years ago

    You've always been able to query layout information about DOM nodes that are off screen. The virtual DOM is used for other reasons.

    • rjzzleep 7 years ago

      With all due respect, no it's not.

      This is exactly what people used to do to optimize drawing in intensive application. You only render the visible area. The entire post explains the supporting actions needed to accomplish this for the browser. Thats why at the end of the text they talk about exploring the use of the canvas.

      Here's an application from ~2000 https://www.macintoshrepository.org/2214-vncthing

      The actual VNC canvas was offscreen and it would only frequently display the entire thing. Which made it for a long time more efficient than modern vnc clients. I think 2010 it was still better than any other VNC client on macosx. It's by far not an uncommon technique, it's just a pain to do when your target is markup, which is what this post is all about.

      Granted, it's more complex because a tile here is a chunk of markup rather than a piece of a pixmap, but still.

      • pcwalton 7 years ago

        Your confusion (which is understandable) points to the reason why I dislike the word "render": it's extremely overloaded. Rendering as defined by QuickDraw (which you alluded to in your above comment) or the VNC client you linked to is really painting, which browsers only do for areas that are on screen or close to being on screen. Browsers have performed this optimization for decades.

        What Atom is referring to by "rendering" here seems to be applying styles to parts of lines. Styling is a higher level concept than vector graphics. Partial styling is something that browsers have wanted to be able to do for a while, but it's quite complex. I've never seen an implementation of partial styling in any UI library, and certainly not in QuickDraw or VNC, which have no CSS-like concept at all.

        • rjzzleep 7 years ago

          There is no confusion from my side, I'm not sure why you're trying to use that strawman, but given your standing in the Rust community it will probably work anyway.

          As I said I wrote about this issue in my blog post. You're trying all sorts of hacks here, because the fundamental issue is that your data structure is the dom and css styling, so everything that other text editors would attach as few byte metadata you used to put in the dom. Which means a simple threeliner that would be a couple of bytes in a proper designed editor, becomes the following beast in atom. Yes it's better now, but the fundamental issue is that you have a weird love relationship to the browser(and no, i'm not judging, whatever floats your boat).

          This is even separate from the other problem that is the actual way of dealing with strings in javascript.

              <div class="lines" style=
              "height: 54px; min-width: 913px; padding-top: 0px; padding-bottom: 0px; top: 0px;">
                <div class="line">
                  <span class="null-grammar text plain">GNU GENERAL PUBLIC LICENSE</span>
                </div>
          
                <div class="line">
                  <span class="text plain null-grammar">hello</span>
                </div>
          
                <div class="line">
                  <span class="text plain null-grammar">what's up</span>
                </div>
              </div>
          
              <div class="underlayer" style="height: 54px; min-width: 913px; top: 0px;">
                <input class="hidden-input" style="top: 0px; left: 0px;" />
          
                <div class="selection" callattachhooks="true">
                  <div class="region" style="top: 18px; left: 72px; height: 18px; width: 48px;">
                  </div>
                </div>
          
                <div callattachhooks="true">
                  <div class="bracket-matcher" style="display: none"></div>
          
                  <div class="bracket-matcher" style="display: none"></div>
                </div>
          
                <div class="spell-check" callattachhooks="true"></div>
          
                <div class="wrap-guide" callattachhooks="true" style=
                "left: 640px; display: block;"></div>
              </div>
          • dang 7 years ago

            Your comments are crossing into personal incivility. We ban accounts that do that, so please edit such bits out of your posts here, regardless of how wrong anyone else may be.

          • pcwalton 7 years ago

            > You're trying all sorts of hacks here, because the fundamental issue is that your data structure is the dom and css styling, so everything that other text editors would attach as few byte metadata you used to put in the dom.

            That's part of the issue, yes. (The other, and more important, part of the issue is that CSS restyling has to occur in order for the browser to determine the changes that need to be applied to the render tree.) Note that the problem you describe has nothing to do with whether the text is off screen or not.

            > Which means a simple threeliner that would be a couple of bytes in a proper designed editor, becomes the following beast in atom.

            This is a misleading way to describe it, because the in-memory representation is compressed. Most of the identifiers in the DOM are compressed down to a single pointer, so they're treated as integers and only serialized when necessary. The objects are threaded together into a doubly linked tree, so the textual DOM doesn't actually live anywhere most of the time.

            It's as if you took Vim's internal data structures and dumped them out into JSON. They'd be equally bloated and verbose in that format. That doesn't say anything about how efficient Vim is.

            The one issue that does matter here is that the styles are currently stored as strings. It's a frequent bottleneck. There is a proposed Typed CSSOM standard [1] that is designed to address this problem. Note, again, that this has nothing to do with whether rendering happens offscreen or not.

            [1]: https://drafts.css-houdini.org/css-typed-om-1/

draw_down 7 years ago

I still really wonder about the approach of using web tech for this editor. But I haven't tried it in a while so I will do that shortly. I have been wanting more Github integration in my editor recently, ever since I saw the Xcode demo.

  • noway421 7 years ago

    I'd think that the only text editor that web browser is competent to have is <textarea>

y_u_no_rust 7 years ago

Seems like such a wasted effort due to technology choice

Anone33 7 years ago

Then ship Servo. It's getting annoying seeing the Servo devs constantly patting themselves on the back about how smart you are and insulting other engines that are actually serving users.

  • dang 7 years ago

    Comments like this are bannable offences and will eventually get your main account banned as well. If you have a substantive point to make, please make it thoughtfully; otherwise please don't comment until you do.

    We detached this subthread from https://news.ycombinator.com/item?id=14615504 and marked it off-topic.

    • angry-hacker 7 years ago

      Dang, you're a coward and snowflake.

  • matthewmacleod 7 years ago

    That’s unfair. It’s hardly “insulting” to talk about the benefits of a new approach. And as I understand it, Stylo will be shipping in Firefox this year.

    • pcwalton 7 years ago

      I can't reply to the above comment because it's dead (and no, I didn't flag it), but you can try parallel styling out by building Firefox Nightly with --enable-stylo and enabling the preference in about:config.

      • Manishearth 7 years ago

        It should be a pref switch in the next nightly on 64 bit linux and windows, fwiw.

        • nstart 7 years ago

          that's good to know. I'm actively keeping up with FF updates (stable) and it'll be good to try the nightly updates too

  • detaro 7 years ago

    I don't see how comments about current work trying to improve this are "insulting" anyone.