|
| crazygringo wrote:
| This is great news.
|
| If you've tried using Google Docs extensively for layout-heavy
| things, you've probably noticed a bunch of subtle things break a
| little bit, for example as pixel rounding errors accumulate down
| a page. This can be especially evident when using things like
| lots of table cells, borders, and zoom levels different from
| 100%. The blinking cursor can sometimes be almost a full line
| misaligned from the text being edited.
|
| Also if you've tried using Docs across different platforms and
| browsers, there can be subtle differences in line heights, word-
| wrapping, and so on. Which might not seem like a big deal, until
| you try to write your term paper to be no more than 25 pages
| long, and then when you go to a shared computer to print it, it's
| now 26 pages because a bunch of lines are now wrapping that
| weren't before, and your professor won't accept it!
|
| If canvas means Google now has total control over precise element
| and letter positioning and wrapping, this will be a BIG step
| forwards in truly being a consistent, cross-platform, WYSIWYG
| word processor, as opposed to the way it's often been "usually
| mostly right but not always exactly".
|
| _Websites_ are supposed to be responsive and flexible and not
| depend on exact font rendering. But _word processors_ really do
| need reliable control over layout when producing serious
| documents like papers, resumes, etc.
| eitland wrote:
| Here's one thing Google hasn't yet realized it seems:
|
| They are neither the coolest kid in the class anymore nor the
| teachers favorite; they can't just do whatever they want anymore.
|
| This is a good thing but I wonder how long it will be before
| Google get the message.
|
| Seing how long Microsoft pushed Silverlight I'm afraid well have
| to live with this for years to come.
| stephc_int13 wrote:
| I think this is a pretty logical evolution.
|
| In my opinion they should wait a bit and build a solid C++/WebGPU
| on WebAssembly renderer to skip a few steps and avoid doing the
| same work a few years down the line.
|
| The web was designed to display document, not to host
| application, it was stretched very far but is also extremely
| complex and kind of slow.
| dangoor wrote:
| In 2009, I joined Mozilla and started working on the Bespin[1]
| project, which Ben Galbraith & Dion Almaer had brought to Moz.
| Bespin was built with a canvas-based renderer. Bespin was way
| faster than other browser-based code editors at the time.
|
| Then the Ajax.org/Cloud9 folks came along with their Ace
| editor[2], which was DOM-based and still very fast. We ended up
| merging the projects. edit to add: and switching to DOM rendering
|
| Rik Arends[3] was one of the Ajax.org folks and he's been working
| on a WebGL-based code environment called Makepad[4], which is
| entirely built in Rust and has its own UI toolkit. He's
| complained a lot about how difficult it is to make a performant
| JS-based editing environment.
|
| My point in all of this is just that there are absolutely
| tradeoffs in performance, accessibility, ease-of-development,
| internationalization, and likely other aspects. If raw
| performance is what you're going for, it's hard to beat just
| drawing on a canvas or using WebGL. Google Docs needs to worry
| about all of that other stuff, too, so I'll be interested to see
| how this shapes up.
|
| [1]: https://en.wikipedia.org/wiki/Mozilla_Skywriter
|
| [2]: https://en.wikipedia.org/wiki/Ace_(editor)
|
| [3]: https://twitter.com/rikarends
|
| [4]: https://makepad.dev
| IshKebab wrote:
| Try holding down Alt on https://makepad.dev/
|
| Such a cool feature that you can't really do with DOM based
| solutions (VSCode could never do this).
| rikarendsmp wrote:
| It may sound stupid, but this was the feature i tried to add
| to ACE and i couldn't. And i spent the last decade trying to
| invent a drawing API that would let me do this effect.
| incrudible wrote:
| > ... it's hard to beat just drawing on a canvas or using
| WebGL.
|
| Both of these APIs perform quite poorly for what they're doing.
|
| To compete with native, the web platform needs simple low-level
| APIs that do not have a lot of Javascript marshalling overhead
| and other performance cliffs. You can always build a more
| convenient library above low-level interfaces, but the opposite
| is not true.
| blacktriangle wrote:
| They don't need to be better than native, they just need to
| be better than the DOM plus have the advantages of web-based
| distribution.
| axguscbklp wrote:
| >Both of these APIs perform quite poorly for what they're
| doing.
|
| When it comes to Canvas, do you mean that it actually
| performs poorly when putting pixels on the screen using
| putImageData, or do you mean that it does that fine but it
| performs poorly when it comes to drawing vector graphics? In
| either case, do you know why it performs poorly?
|
| Personally, I would be happy if Canvas just let you put raw
| pixel data on the screen and did that as well as possible. I
| have never felt any need for its vector graphics features. To
| me, they seem too high-level for what Canvas is supposed to
| be. But I guess things are different when it comes to using
| the graphics card, since from what I understand it is
| actually optimized for drawing polygons.
| fock wrote:
| I think this is a problem of the mainstream conception
| seeing the future browser mainly as a monopolized, walled
| garden (compared to GNU/Linux, which nowadays would do
| everything one wanted from a computer and more) with the
| canvas being a kind of framebuffer.
|
| Back when I first read about the canvas, iirc there was no
| fancy CSS, no fancy custom elements and making a simple
| doodle-element or the famous doodle-jump as a webapp was
| ... - well, I guess there was flash. So if you think of
| HTML and DOM as a GUI toolkit, it filled an important void
| (and continues to do so) but nowadays noone wants to use
| (standardized) HTML anymore, so...
|
| If you look into tk (or nowadays tkinter) you basically see
| the same with the Canvas-class (I think you can't draw
| anything custom at all in tk easily)!
| incrudible wrote:
| It performs poorly in either case. For one, Javascript APIs
| have significant marshalling overhead.
|
| Secondly, Canvas is often "hardware-accelerated", which can
| make _some_ things faster, but also slower because this
| kind of immediate-mode drawing doesn 't match the GPU
| interface well. It's particularly slow at vector graphics.
| Some effects would require pixel readback, which is slow
| for the same reason.
|
| > Personally, I would be happy if Canvas just let you put
| raw pixel data on the screen and did that as well as
| possible.
|
| Drawing cached Bitmaps is relatively fast in Canvas, if you
| don't need too many calls. Getting arbitrary data into such
| a Bitmap is slow, so if you want to do it every frame you
| may run into issues.
| habitue wrote:
| It seems like WebGPU is the next thing:
|
| https://github.com/gpuweb/gpuweb/wiki/Implementation-Status
| jd3 wrote:
| It's funny -- Google's approach here reminds me of the
| Netscape/Mozilla XUL tree[0] element.
|
| For those unfamiliar, the XUL tree is a performant 1990s-era
| virtualized list that is able to render millions to tens of
| millions of rows of content without slowdown since it gives you
| the option of rendering internally in Firefox rather than
| through the DOM.
|
| I still don't completely understand why Mozilla is/was planning
| to axe[1][2] it since there's no web-based HTML5/JS replacement
| (the virtualized "tree" is implemented in C++, iirc) and it's
| still being actively used in places.{xul/xhtml}[3] and the
| Thunderbird/SeaMonkey[4][5] products.
|
| It's interesting that both Google's canvas bet (Flutter, Docs,
| etc.) and the Mozilla XUL tree are basically trying to solve a
| nearly identical problem (DOM nodes are expensive and DOM
| manipulation is slow) ~20-25 years apart.
|
| [0]: https://developer.mozilla.org/en-
| US/docs/Archive/Mozilla/XUL...
|
| [1]:
| https://docs.google.com/document/d/1ORqed8SW_7fPnPdjfz42RoGf...
|
| [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1446341
|
| [3]: chrome://browser/content/places/places.xhtml
|
| [4]: https://www.thunderbird.net/
|
| [5]: https://www.seamonkey-project.org/
| alisonkisk wrote:
| Why can't XUL vs DOM just be the same data with a fast C++
| API and a slow JS API?
| jd3 wrote:
| > Why can't XUL vs DOM just be the same data with a fast
| C++ API and a slow JS API?
|
| This is a great question! I'm not really qualified to
| answer it, but I'll give it a try.
|
| My understanding is that the XUL tree is fast because it
| implements the XPCOM C++ nsITreeView[0][1][2] interface.
|
| If you're writing a XULRunner program ...
|
| (Firefox "is distributed as the combination of a Gecko XUL
| runtime -- libxul, other shared libraries, and non-browser-
| specific resources like those in toolkit/ -- plus a Firefox
| XUL application -- mostly just the files in
| Contents/Resources/browser/, plus the 'firefox' stub
| executable that loads Gecko and points it at a XUL
| application", see [3])
|
| ..., XPCOM[4] allows you invoke those implemented interface
| methods directly from JavaScript.
|
| XPCOM is a technology that, since the removal of XUL/XPCOM
| addons, is inaccessible to everyone except for Mozilla devs
| and those who write XULRunner programs using `firefox --app
| /path/to/application.ini`.
|
| So, some XUL elements (like ) implement an XPCOM
| interface that invokes native C++ (or rust, python, java,
| etc.) code, which is statically compiled directly into the
| Gecko XUL runtime.
|
| Modern HTML5 elements, in general, must utilize the native
| interpreted browser DOM/JavaScript and cannot choose to
| implement/satisfy an arbitrary internal XPCOM interface.
| While I'm sure that Mozilla has figured out a way to make
| these elements fast (C++, Rust, I have no idea), you are
| always bounded by the limitations of the DOM.
|
| So, my understanding is that, because we are relying on
| standards-compliant HTML5 elements which mutate the DOM, we
| cannot specify and implement new XPCOM interfaces ("with a
| fast C++ API") that could theoretically bypass the DOM --
| we /must/ rely on the "slow JS API."
|
| [0]: https://developer.mozilla.org/en-
| US/docs/Mozilla/Tech/XPCOM/...
|
| [1]: https://searchfox.org/mozilla-
| central/source/layout/xul/tree...
|
| [2]: https://searchfox.org/mozilla-
| central/source/layout/xul/tree...
|
| [3]: https://mykzilla.org/2017/03/08/positron-
| discontinued/#comme...
|
| [4]: https://developer.mozilla.org/en-
| US/docs/Mozilla/Tech/XPCOM
| pcwalton wrote:
| > I still don't completely understand why Mozilla is/was
| planning to axe[1][2] it since there's no web-based HTML5/JS
| replacement (the virtualized "tree" is implemented in C++,
| iirc) and it's still being actively used in
| places.{xul/xhtml}[3] and the Thunderbird/SeaMonkey[4][5]
| products.
|
| XUL is a maintenance burden and exacts a development tax on
| new features (having to make the Servo CSS engine support XUL
| so that it could be uplifted to Firefox was extremely
| annoying). It's also full of security problems, as it's
| written in '90s C++ that nobody is around to maintain
| properly. Getting rid of it is an inevitability.
| jd3 wrote:
| Thanks for the reply! I'm a big fan of your work. I can
| only imagine the nightmare of trying to implement two
| separate XUL <=> HTML/CSS flex/box models in Servo/Rust.
|
| For readers that are unaware, there is also a great blog
| post breaking down some of these points in finer detail
| [0][1].
|
| I guess my question is -- are there replacements planned
| for any of the legacy yet performant XPCOM interfaces / XUL
| elements like nsITreeView/tree? My tl;dr understanding of
| XUL trees is that the DOM is and always has been too slow
| to render millions of scrollable rows in a performant
| manner (bookmarks, thunderbird, etc.). Would it not be
| possible to re-implement the XUL tree logic in Rust, for
| example? Is the goal to completely get rid of all non-
| standards compliant elements in the long-run?
|
| It seems like there will always be some custom elements
| necessary for a native desktop interface which can never be
| integrated into HTML...
|
| "I've talked about this before, but things like panel,
| browser, the menu elements (menu, menupopup, menucaption,
| menuitem, menulist) don't have HTML equivalents and are
| important for our desktop browser experience. While we
| could invent a way to do this in chrome HTML, I don't think
| the cost/benefit justifies doing that ahead of the rest of
| the things in our list." [2]
|
| ..., yet I don't see much discussion about this anywhere.
|
| I'm particularly interested because I'm currently working
| on a XULRunner project where a is central to the
| user interface (millions of rows, image column, embedded
| data, must run on macOS/Windows/Linux/*BSD, etc.), and it's
| a little alarming that there is an open bugzilla ticket
| that did not initially mention either the performance nor
| ecosystem implications (essentially kill Thunderbird, kill
| SeaMonkey more than it already has been) of its removal.
|
| I think the one part I have trouble with is that
| implementing a native looking/performant cross-platform
| desktop UI is still a nightmare and XUL could have
| potentially been a fantastic desktop-focused
| superset/companion of/to HTML.
|
| [0]: https://yoric.github.io/post/why-did-mozilla-remove-
| xul-addo...
|
| [1]: https://news.ycombinator.com/item?id=24231017
|
| [2]: https://briangrinstead.com/blog/xbl-replacement-
| newsletter-2...
| pcwalton wrote:
| I mean, you probably won't like this answer, but I don't
| think you should be writing a XUL-based app in 2021 if
| you want it to be useful, as opposed to for fun. XUL is
| 25-year old legacy technology, and using it is an
| exercise in retrocomputing.
| jd3 wrote:
| Fair enough.
|
| Sorry, I should have clarified a bit more -- I'm writing
| a cross-platform desktop application that has a preact[0]
| frontend (+ a Go backend) using `firefox --app
| application.ini`.
|
| I have been experimenting with performant lists (which is
| why I brought up the XUL tree -- it's currently central
| to the interface, though not the final implementation for
| sure) -- I'm currently only using the XUL window/menubar
| elements in order to populate the native macOS menubar.
|
| I am a fullstack web dev in my day job, so my goal here
| is to write a fast, easily extendable UI that I can
| quickly iterate upon using modern html/js/css/etc.
|
| I love gecko and used to write XUL add-ons many years
| ago, so I'm already familiar with JS code modules, XPCOM,
| XUL, the internal browser architecture etc.
|
| Basically, I'm now using XULRunner (`firefox --app
| application.ini` as previously mentioned -- will
| eventually be stubbed into a native macOS .app/OS
| program) as a replacement for Electron / Chromium
| Embedded Framework[1].
|
| I'm basically doing the same thing as
| Positron[2]/qbrt[3].
|
| [0]: https://preactjs.com/
|
| [1]:
| https://en.wikipedia.org/wiki/Chromium_Embedded_Framework
|
| [2]: https://github.com/mozilla/positron
|
| [3]: https://github.com/mozilla/qbrt
| MarkSweep wrote:
| I'm not a XUL or JavaScript expert, but there is evidence
| that you can implement a virtualized list in regular
| HTML:
|
| https://react-window.vercel.app/
| jd3 wrote:
| I recently wrote a somewhat performant react-
| virtualized[0] list for a project at work, though it's
| definitely a bit trickier in plain HTML/JS.
|
| As far as the XUL virtualized tree goes, a couple of
| Mozilla engineers wrote some examples using plain
| html/javascript + DOM node manipulation[1]. While
| promising, I can't imagine that this implementation could
| ever be as fast as the compiled C++ one[2].
|
| [0]: https://github.com/bvaughn/react-virtualized
|
| [1]: http://benbucksch.github.io/trex/fastlist-test.html
|
| [2]: https://searchfox.org/mozilla-
| central/source/layout/xul/tree...
|
| https://news.ycombinator.com/item?id=14158170
| zxzax wrote:
| I really doubt anyone is going to revive those old legacy
| widgets. That style of widget is flawed and predates MVC-
| style design, you'll find it becomes very impossible to
| present non-string data with that tree. Most applications
| now will want to show arbitrary widgets within the table,
| and for that they'll use the standard HTML/CSS. I would
| expect you can do something comparably fast by using
| IndexedDB.
| jd3 wrote:
| tangential but amusing -- the old
| chrome://global/content/config.{xul/xhtml} used a XUL tree
| and rendered 0 DOM nodes to display its treechildren whereas
| the new about:config renders upwards of 4500 DOM nodes
| by default
|
| ignoring the fact that you can no longer sort by specific
| columns (name, status, type, value, etc), you can really feel
| how slow the new implementation is if you click the "Show
| Only Modified Preferences" button -- the DOM update feels
| incredibly sluggish whereas both searching and sorting
| columns in the old xul tree always felt snappy and
| instantaneous
|
| https://imgur.com/a/abhYoW8
| lol768 wrote:
| Yeah it's a real shame it's all moving to HTML/JS for the
| chrome & e.g. devtools, even if it's more "maintainable".
| jd3 wrote:
| I use the modern Firefox HTML5/JS dev tools on a daily
| basis and love the featureset that they provide, though
| it is equally shocking to compare the feel to that of the
| old DOM Inspector[0] (and Venkman[1], the old JS
| debugger), which was a XUL add-on for DOM inspection that
| used to run in Firefox, Thunderbird, and SeaMonkey.
|
| What feels snappy and instantaneous in DOM Inspector
| feels somewhat muddy and laggy in the modern devtools.
|
| While I greatly appreciate the amount of features that
| Mozilla has integrated into the modern (post-firebug)
| devtools over the years, it is a little sad that the next
| generation will never get to experience just how fast
| some narrow aspects of web development used to be.
|
| https://imgur.com/a/JZoSTXf
|
| [0]: https://addons.thunderbird.net/en-
| us/firefox/addon/dom-inspe...
|
| [1]: https://addons.thunderbird.net/en-
| us/firefox/addon/javascrip...
| cxr wrote:
| Thanks for the shoutout to the legacy DOM Inspector
| (which I used to maintain) and Venkman (which I have both
| admired and used in anger). When Mozilla decided to put
| together a devtools team for Firefox 4, I was
| disappointed when I realized that they weren't going to
| take any effort to make sure the fruits of their labor
| sidestepped any of the performance issues that Firebug
| had exhibited for most of its lifetime. I do want to
| quibble, though, about the suggestion that this is a
| matter of XUL+JS versus HTML+JS. I say this even as
| someone with strong feelings about what a joy XUL was in
| comparison, and a long-lasting bitterness over the
| decision (among many) that Mozilla made in mishandling
| its own future.
|
| WebKit's Web Inspector has for a long time gone with
| HTML, and in all its incarnations I've ever tried out, it
| has always been snappier than either Firebug and or the
| devtools that ships with Firefox.
|
| When making comparisons like this, it's important to keep
| in mind that you're comparing/contrasting teams and their
| output, and it's not just a matter of the building blocks
| they're using. Some teams do better work than others.
| skyde wrote:
| Can someone explain why https://makepad.dev/ is extremely slow
| and "unusable" on Microsoft Edge browser but run smoothly on
| Chrome? Is it because of bad WebGL perf on JavasSript perf in
| general?
| yonl wrote:
| For me, it's not very fast in chrome.
| ehsankia wrote:
| Can you give a bit more flavor to "not very fast"? I'm on a
| measly chromebook and scrolling, selecting text, expanding
| directories, everything is smooth and high framerate.
|
| Is there a specific operation that is not fast? Opening it
| for the first time took a few seconds but afterwards it was
| pretty buttery.
| rikarendsmp wrote:
| Makepad kinda has a minimum GPU spec. It's aging-out for
| the people who don't have this, but some people still
| don't have gpu's that can bitblit their screen with a
| solid color.
| slaymaker1907 wrote:
| Did you try using dev/canary Edge? It should pretty much be
| the same rendering engine and JS engine as Chrome. Definitely
| report this to the Edge team if you have the time (very easy
| to do from the dev version of Edge). In my experience, they
| are very responsive to bug reports and feature suggestions.
| rikarendsmp wrote:
| Back in the day i made it work on Edge on an xbox. This was
| microsofts browser +JS engine. Nowadays its just chrome
| though. If it has problems, i'd be highly surprised.
| ComputerGuru wrote:
| Edge or Edgium?
| tyingq wrote:
| Another possibility is code that acts differently depending
| on user-agent.
| rikarendsmp wrote:
| It most definitely does not.
| rikarendsmp wrote:
| I tried for it not to be, however there is no technically
| specific reason no.
| KhalPanda wrote:
| If they're going to make the leap of switching the render layer,
| I'm surprised the leap isn't to flutter (which is supposedly
| stable/ready for production web apps?).
| defrex wrote:
| Flutter is Canvas-based on the web, so this post well-could
| mean a switch to Flutter. Hard to see how non-Flutter customer
| Canvas-renderer for Google Docs makes sense.
| sime2009 wrote:
| Flutter is for doing UIs. Google are using canvas to render the
| (text) document the user is working on, not the UI elements.
| Tyriar wrote:
| I wrote the terminal canvas renderers in VS Code that has been
| called out a few times here. Initially I implemented a canvas
| renderer using just a 2d context to draw many textures which sped
| things up "5 to 45 times"[1] over the older DOM renderer.
|
| Since then I moved onto a WebGL renderer[2] which was mostly a
| personal project, it's basically the first canvas renderer but
| better in every way since it works by organizing a typed array
| (very fast) and sending it to the GPU in one go, as opposed to
| piece meal and having the browser do its best to optimize/reduce
| calls. This was measured to improve performance by up to 900% in
| some cases over the canvas renderer, but actually much more than
| that if for example the browser has GPU rendering disabled and
| tried to user the canvas renderer on the CPU.
|
| My opinion here is that canvas is a great technology, capable of
| speeding things up significantly and getting close to native app
| performance. It comes with very real trade offs though:
|
| - Cost of implementation and maintenance is much higher with
| canvas. This is particularly the case with WebGL, there have been
| very few contributions to xterm.js (the terminal frontend
| component) in the WebGL renderer because of the knowledge
| required. - Accessibility needs to be implemented from scratch
| using a parallel DOM structure that only gets exposed to the
| screen reader. Supporting screen readers will probably also
| negate the benefits of using canvas to begin with since you need
| to maintain the DOM structure anyway (the Accessibility Object
| Model DOM API should help here). - Plugins/extensibility for
| webapps are still very possible but requires extra thinking and
| explicit APIs. For xterm.js we're hoping to allow decorating
| cells in the terminal by giving embedders DOM elements that are
| managed/positioned by the library[3].
|
| More recently I built an extension for VS Code called Luna
| Paint[4] which is an image editor built on WebGL, taking the
| lessons I learned from working on the terminal canvas renderer to
| make a surprisingly capable image editor embedded in a VS Code
| webview.
|
| [1]: https://code.visualstudio.com/blogs/2017/10/03/terminal-
| rend...
|
| [2]: https://code.visualstudio.com/updates/v1_55#_webgl-
| renderer-...
|
| [3]: https://github.com/xtermjs/xterm.js/issues/1852
|
| [4]:
| https://marketplace.visualstudio.com/items?itemName=Tyriar.l...
| trinovantes wrote:
| Do you think the large performance benefits can be achieved for
| any general web app (e.g. if I rewrite my Vue app's render
| functions to using a canvas instead of the DOM) or is the
| canvas' benefits mainly for niche workloads?
| Tyriar wrote:
| Definitely niche workloads or when the performance benefit
| from a UX perspective is worth the cost of implementation.
| Start out with virtualizing the DOM so only the visible parts
| are showing, if the framerate isn't acceptable after that
| then consider switching to canvas.
|
| Using the terminal as a case study, its DOM renderer needs to
| swap out many elements per row in the terminal every frame
| (the number depends on text styles and character widths) and
| we want to maintain 60fps. It's also not just a matter of
| maintaining low fps since more time rendering means less time
| processing incoming data because they share the main thread,
| which means commands will run slower.
| Secretmapper wrote:
| I remember Flipboard using canvas to render their UI before
| using react, which has the same idea, you can look at the
| repo and their post about it:
|
| https://github.com/Flipboard/react-canvas
| kizer wrote:
| I've been working on a canvas-mostly render library. Some things
| like text input would require using the native component to some
| degree; e.g., the input element could be invisible while the
| canvas would render the text field in its place.
|
| Honestly, why even bother with the DOM? Even for "article" sites;
| you can have pixel perfect control over your rendering,
| especially if you even implement your own anti-aliased bezier
| curve rendering algorithms. There's already a library that
| processes fonts (opentype.js) and returns the parameters of the
| bezier curves that need to be drawn to construct the glyphs.
|
| You're fine still using HTML/CSS for a bunch of reasons (lighter
| static sites, already have developed codebases for each).
|
| But, why not own the whole thing in TS/JS? For web applications,
| you'd then have pixel perfect consistency across browsers and
| mobile devices. There are two ways Flutter, for example, compiles
| to a web application[0]: either to a mix of canvas, CSS, SVG, and
| HTML, or just to pure WebGL Canvas using a WASM build of Skia
| (that's right - the engine that renders HTML/CSS in the first
| place).
|
| So with WebAssembly and the Canvas, especially taking into
| account the upcoming WebGPU API which will unlock even better
| render performance, I'd rather have my whole application be
| defined in JS/TS and own all of the experience down to the pixel
| -- complete control. Obviously this is assuming convenient
| libraries (in WASM/JS) for rendering text/curves/etc. to canvas
| will exist.
|
| Would be awesome for certain web app usecases.
|
| [0] https://flutter.dev/docs/development/tools/web-renderers
| tinyhouse wrote:
| Is this going to make it faster? It's so slow and I use Chrome.
| austincheney wrote:
| How will they achieve accessibility? I can only imagine screen
| readers trying to parse a bunch of vectors.
| zdragnar wrote:
| You can render elements inside of the canvas tag, they simply
| won't be visible. This gives screen readers something to do,
| though it becomes trickier since they also have to bugger
| keyboard shortcuts to implement key navigation for sighted
| users.
| jerry1979 wrote:
| The programmers will need to add accessibility features to
| their apps:
| https://html.spec.whatwg.org/multipage/canvas.html#best-prac...
| austincheney wrote:
| _This is a huge amount of work, and authors are most strongly
| encouraged to avoid doing any of it by instead using the
| input element, the textarea element, or the contenteditable
| attribute._
|
| When the spec warns you in advance that this is a high risk
| approach.
| quotemstr wrote:
| High work != high risk
| larodi wrote:
| This is absolutely expected, reasonable and the way to go for an
| rich GUI app such as Google DOX. Particularly since WASM is so
| widely adopted, so does Canvas, WebGL etc... and Rust compiles to
| WASM, not to forget. So it was about time that some major apps
| ditched all the DOM glory.
|
| Wonder whether they're using the greatly overrated Angular to
| render the canvas, i guess not, but that's for Google insiders to
| say.
| LightG wrote:
| I'll give up HTML when you pry it from my cold, dead hands ...
| abxytg wrote:
| Would love to hear a Googler justify this. It's just closing down
| the web. No more view source for the curious kids. Shame on you.
| thehappypm wrote:
| Not a Googler, but I've done many projects in both Canvas and
| HTML/CSS/JS.
|
| Canvas is actually really hard to get right. You basically are
| given these super basic tools and have to go do everything
| yourself. With HTML and CSS you're standing on the shoulders of
| giants. With Canvas you're drawing arcs and squares and lines.
|
| That being said, canvas is the kind of thing if you DO get it
| right, it's awesome. It's just fast. And really portable: every
| platform supports a canvas of some kind, and the primitives
| tend to be really similar.
| nine_k wrote:
| The Web started as a document display and delivery framework.
|
| Now it has turned into an application delivery framework, which
| uses the old document-rendering abilities to display the UI, with
| many quirks and workarounds, because DOM was never intended as a
| performant dynamic medium.
|
| With canvas and WebGL taking more and more, it will turn back
| into an X terminal, with more advanced network capabilities.
|
| If most important sites switch to canvas rendering, what used to
| be the browser can be radically simplified and made lightweight
| and much faster. The 'legacy' full-web sites can be shown using a
| plugin that does all the fancy and heavyweight HTML 5 and CSS 3
| stuff.
|
| Also, with webassembly running JITted platform-independent code
| delivered over the network, and displaying it in a platform-
| independent graphical client (nee browser), the promise of Java
| from 30 years ago will finally come true -- sans Java proper,
| though.
| flowerlad wrote:
| > _With canvas and WebGL taking more and more, it will turn
| back into an X terminal, with more advanced network
| capabilities._
|
| For some specialized apps this will be great, but for apps in
| general this is not a good idea at all. If it was, we'd be
| using Java applets today. HTML+CSS based apps are highly
| constrained. But that's a positive, not a negative, because it
| is the constraints that makes HTML based apps predictable,
| consistent and usable.
| hobs wrote:
| You say this like it wont be used to completely remove all user
| choice and be an utter disaster.
| foolfoolz wrote:
| your choices are still there. go to whatever website you
| want. but i think users will want to go to the best websites
| that have the highest production value and may not be built
| the same way as we did 20 years ago
|
| most people don't come to the web for choice, they come for
| the apps
| tshaddox wrote:
| If a developer _wants_ to "remove all user choice" on the web
| it's already very easy for them to do that. The only new
| concern here is that developers will be tempted to use tools
| /frameworks for unrelated reasons (maybe convenience, cross-
| platform support, etc.) and those tools/frameworks will just
| happen to also remove user choice.
| nine_k wrote:
| Many developers work on removing the user's choice (not) to
| see ads.
|
| But the pesky open nature of the web gets in the way.
| tshaddox wrote:
| I don't think the open nature of the web gets in the way.
| Those developers could quite easily generate a screenshot
| of the website they're building and ship the screenshot
| instead of the HTML/CSS/JS.
| Sophira wrote:
| They could... except:
|
| a) It would be completely inaccessible to blind users;
|
| b) Sometimes devs _want_ to be able to give users some
| choice, like copying text, and this is impossible with
| your proposed method.
|
| These two reasons alone mean it's undesirable for devs to
| use these, and they're problems that Canvas addresses -
| albeit by letting the _devs_ have that choice, but not
| the _users_.
| tshaddox wrote:
| There are several other ways to prevent copying text or
| making it difficult, some of which probably don't impact
| screen readers (although I'm skeptical that many
| developers would be intent on preventing the copying of
| text while also caring about screen readers). And, of
| course, if the developer wants to allow copying text,
| that's trivial. How does canvas give a developer more
| ability to choose which things the user can and cannot
| do?
| nine_k wrote:
| You cannot Ctrl+U and see the source. You cannot
| Shift+Ctrl+I and inspect the DOM.
|
| All you get is a bitmap, which is not even that easy to
| access. Much like a frame generated by a game engine.
| tshaddox wrote:
| Indeed. That's why my comparison was to image files sent
| from the server.
| overtomanu wrote:
| but i think screenshots are not considered accessible
| tshaddox wrote:
| Neither is text rendered in a canvas tag (without doing
| some extra work specifically to improve accessibility).
| Sophira wrote:
| Except it's not that easy. Web developers have been trying
| to remove user choice all the time - disabling right-click
| menus, preventing copying on websites, forcing the page to
| look blank unless you turn JavaScript on - and yet it's
| fairly easy to get around most of this using extensions.
|
| That's because how websites display information in the
| browser is pretty standardised. Before the Canvas element,
| your choice was basically HTML/CSS or nothing (unless you
| did something incredibly strange like rendering output to a
| data:image/png URL and updating an image tag with it).
|
| The Canvas element, on the other hand, doesn't force a
| standard way of displaying information. It's essentially
| your dynamic data:image/png render output method on
| steroids, and users can't even use it unless they have
| JavaScript on. As it is, many sites are still usable even
| without JavaScript, including Hacker News.
|
| Using Canvas means no user choice _by default_.
| tshaddox wrote:
| The canvas element is essentially a bitmap that you can
| draw on using JavaScript. As far as I know, it doesn't
| introduce any features that increase the developer's
| ability to control the user over simply generating
| bitmaps on the server. (There are some fingerprinting
| techniques that use canvas and have bad privacy
| implications, but I believe that's a separate topic.) The
| only difference is that the bitmaps can be changed
| dynamically by client-side code. Everything you mention:
| disabling right-click menus, preventing text copying,
| making the site not work without JavaScript etc. can be
| done with canvas or without canvas. Moreover, the canvas
| tag has been well-supported for over 10 years.
| nine_k wrote:
| Why, I thought I was describing an anti-utopia, a kind of a
| dark cyberpunk future, because half of the dark cyberpunk
| future predictions from 1980s have come true already.
| artificial wrote:
| You're going to own nothing and be happy.
| quickthrower2 wrote:
| What do I "own" when I open a site that is a tiny HTML doc
| and 300kB of minified JS, plus 100 fetch calls for JSON
| data to render? At that point, use the DOM, use a canvas or
| a literal paint brush, I don't care.
| jtsiskin wrote:
| Can at least block ads still (mostly...)
| quickthrower2 wrote:
| That's a good point. The only way to block now is to
| refuse to use the site.
| lawwantsin17 wrote:
| Ah, a plugin you say. What does this magic plugin do again?
| manx wrote:
| I'm wondering if at some point it makes sense to compile servo
| to webassembly and let it render to a canvas.
|
| Producing a good user experience with pure canvas rendering is
| a lot of work. A tree stucture to manage UI elements makes this
| easier. Flutter is going in a similar direction here.
|
| The interesting thing would be that the engine wouldn't need to
| conform to web standards anymore, while providing a guaranteed
| consistent cross browser experience. One could probably strip
| away lots of old dom concepts that make the dom slow today.
| throw_m239339 wrote:
| > With canvas and WebGL taking more and more, it will turn back
| into an X terminal, with more advanced network capabilities.
|
| Not really, Canvas is just that, a blank canvas. The issue is
| that it's up to the developer to implement everything on top.
| It's very hard for me to believe that Canvas would be more
| efficient than DOM for creating text documents. Obviously there
| are limitations to CSS or the DOM. But then wouldn't SVG be a
| better alternative than straight out drawing pixels on screen?
| jokoon wrote:
| I wonder how much simpler and lighter a browser would be if it
| only supported canvas.
| tmalsburg2 wrote:
| Perhaps Java applets were not such a bad idea after all?
| spankalee wrote:
| This is one reason I think projects like Servo are potentially
| very beneficial even well before they can render every legacy
| quirk you find on the open web.
|
| Instead of bringing a custom rendering engine to the web via WASM
| and canvas, it'd be better in so many ways to bring a subset of
| spec-compliant HTML rendering to embedded contexts. If your
| content renderer can run on Servo, and render the same in modern
| browsers, you can use HTML as the basis for cross-platform
| rendering.
|
| At least I would hope that would be possible by now so we don't
| have to write renderers for every platform anymore.
| quickthrower2 wrote:
| Are accessibility features like aria available for canvas based
| apps?
| slmjkdbtl wrote:
| DOM is just not the way to build complex UI, we need to have
| control over the lower level draw loop and graphics, it's a pain
| to build a high level system on top of another high level system,
| it leads to hacks and unintuitiveness like react hooks. Building
| UI framework in canvas is way more fun and clean and the only way
| (in the browser) to think about UI programming from first
| principal, I dream of a browser environment where DOM / HTML is
| an optional library.
| khc wrote:
| All I want to know is: is this going to make google docs on
| firefox faster or slower?
| aranchelk wrote:
| On multiple levels it seems nuts to use canvas for a stylized
| text editor.
|
| There are layout consistency issues across browser and OS. The
| place I've seen this is page breaks changing between computers
| (or even zoom levels). Line length isn't controlled solely by the
| browser, IIRC both kerning (letter spacing) and word spacing is
| determined by the OS.
|
| I implemented something like Docs myself, but with the goal of
| total consistency of line/page breaks. Knowing about these issues
| I used SVG. In SVG text you can override line length, but you
| still need to have a value in mind, a reference to be calculated
| independent of user environment details.
|
| Regarding performance, one issue I can speak to is the cascading
| changes to line breaks. This can be pretty brutal when making a
| change to the beginning of a long document. To get acceptable
| performance I had to partially remove the application framework I
| had been using.
|
| I liked my solution and it worked quite well in prototypes, but I
| don't know how it would have faired in the wild.
| jgalt212 wrote:
| I'd be very curious to hear if they looked at SVG. I assume it's
| less peformant, but maybe for word processor it would be about
| equal. Easy to imagine canvas outperforming SVG for a spreadsheet
| app.
| p1mrx wrote:
| Does this mean I'll be able to jump to the end of a document
| without, like, 30 seconds of rendering computation?
| specialist wrote:
| One step closer to Display PostScript. Woot!
|
| https://en.wikipedia.org/wiki/Display_PostScript
|
| As the original HTML-hater, I've been joking for a while that
| we're slowly, painfully recreating X-Windows.
|
| I've been wondering if I'll live long enough to see a return to
| sanity.
|
| https://en.wikipedia.org/wiki/NeWS
| easton wrote:
| Example doc:
| https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxS...
| jpeter wrote:
| Even has fake text search. Not bad.
| neurostimulant wrote:
| Browser's built-in search feature (e.g. "find in this
| page..." on firefox) doesn't work though.
| bhl wrote:
| Given for a text editor, find-and-replace is a feature
| anyways that's not natively supported by contenteditable..,
| you will need to build out a custom app search feature
| anyways. But yeah, for preview only mode, sad to see native
| features not work on a static document.
| yayr wrote:
| Am I right to assume that also parts of the interaction UX are
| now rendered by canvas? I looked at the source and even text
| selections etc. do not have DOM tree elements anymore.
| cblconfederate wrote:
| Oh good , Flash is back! Or maybe java applets. Or silverlight,
| but this time it's gonna be different
| agilob wrote:
| Can this be because of Dart and Flutter? Flutter for Web uses own
| canvas rendering system instead converting to html/js.
| neals wrote:
| I believe this is an example output?
| https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxS...
| neurostimulant wrote:
| Interesting. Looks like each page is a separate canvas, and the
| canvas are reused as you scroll the pages (just like how list
| view reuse cells when you scroll in a mobile app). The canvas
| seem to be only used for rendering text and tables though,
| images and graphic elements are still drawn as svg dom
| elements.
| olliej wrote:
| Sample doc isn't editable affect, presumably to hide the fact
| that in addition to overriding standard scrolling it also doesn't
| support international text entry or, 50/50, standard and custom
| key shortcuts from the OS
|
| [edit: I was right - cmd-f doesn't use the proper find ui, cmd-e
| doesn't update the search pasteboard, and cmd-f doesn't track the
| system search pasteboard.]
| BiteCode_dev wrote:
| And just like that, flash is back
| Animats wrote:
| The next step will be that they just send you images.
| deafcalculus wrote:
| Mighty seems to want to do that even sooner!
| chadlavi wrote:
| not really relevant to the topic at hand, but it's wild that
| google still uses blogger
| Yuioup wrote:
| What's next, a Canvas rendered web browser?
| qunabu wrote:
| It's like going back in time with Flash Player, There were many
| WYSIWYG flash based editors around 2010. The problem was it
| required a browser plugin but it did work much better then HTML4
| at that time. For canvas rendering no plugin is needed. Even
| there was a feature to export SWF file to canvas.
|
| There are some issues like accessibility, browser features like
| search or text highlighting, lazy loading etc. What HTML provides
| out of the box must be implemented from scratch.
| pjmlp wrote:
| Padora box was already open the day, WebAssembly and WebGL came
| into the browser.
| qunabu wrote:
| You can render in canvas with JavaScript only, no WebAssembly
| nor WebGL is needed.
| pjmlp wrote:
| Naturally, the point being made was about Flash.
| stuaxo wrote:
| No easy extraction of the data then.
| perfunctory wrote:
| Strangely, this reminded me of Bret Victor
|
| > To deliver her message most effectively, the visual designer
| needs as much control as possible over what the viewer sees. But,
| by definition, the designer only has direct control over the
| tool. She is at the mercy of whatever platform implementation the
| recipient happens to supply. This implies that a good platform
| must be as simple and as general as possible.
|
| > From a practical (and historical) standpoint, we can assume
| that no complex specification will be implemented exactly. This,
| in itself, is not a problem. However, multiple, decentralized
| implementations of a complex specification will be incorrect in
| different ways. A platform consisting of the union of all
| possible implementations is thus arbitrarily unreliable--the
| designer can have no assurance of what a recipient actually
| receives. For a platform to be reliable, it must either have a
| single implementation, or be so utterly simple that it can be
| implemented uniformly. If we assume a practical need for open,
| freely implementable standards, the only option is simplicity.
| larodi wrote:
| ...how long before someone strips the browser and ships a runtime
| with no DOM, canvas and WASM/v9 only. Very platform independent
| and perhaps fast also...
| ok123456 wrote:
| It's sort of clear they intend to do a rewrite of Google Docs in
| C++ or some other systems language and compile it to webasm
| because of better tooling.
|
| That's why they went went canvas instead of webgl, since
| webasm+gl was never widely adopted or complete.
| lewisjoe wrote:
| We are working on a full-featured Google Docs alternative -
| https://writer.zoho.com . We are already capitalizing canvas
| technology for rendering documents across devices, except for the
| Web which still is DOM.
|
| Having a single codebase that renders across all platforms is our
| long-term motive, and it does require rendering to a cross-
| platform canvas backend - like Skia.
|
| I'm assuming Google Docs is already on that direction as well.
| Would be great if someone from Google can clarify the technical
| internals.
| Andrew_nenakhov wrote:
| Does Zoho have a self-hosted version? If not, is there any
| reason to trade one vendor lock for another?
| heipei wrote:
| I consider neither Zoho nor Google Docs to be vendor lock-in
| since you can always download the documents as docx and
| continue working on them locally.
|
| I'm gonna give Zoho Writer a spin since Google Docs is
| missing some vital features for me, most notably the option
| to have custom page designs (font/colors/footers) that you
| can centrally update and apply to a bunch of documents. If
| anyone has another Google Docs alternative, I'm all ears.
| Andrew_nenakhov wrote:
| Vendor lock-in is an inability to use another vendor
| without substantial switching costs. [1]
|
| Changing Google Docs for .docx has significant costs,
| because their compatibility with MS Office is far from
| ideal. That said, using .docx is yet another vendor lock-
| in. As you might know, OOXML is not a true open standard:
| it was recognized as such by ISO only due to Microsoft's
| shenanigans. That's why it is not fully supported by any
| other software and trying to use alternative applications
| results in numerous compatibility issues.
|
| So your best option is to use LibreOffice, because it is
| libre software, capable, available from several vendors,
| and is based on true open standard, OpenDocument.
|
| [1]: https://en.wikipedia.org/wiki/Vendor_lock-in
| vishnumohandas wrote:
| Are there plans to launch an end-to-end encrypted version of
| Writer?
| Andrew_nenakhov wrote:
| We develop app that does have end-to-end encryption. From my
| experience, people who demand it rarely understand what it
| means and how many inconveniences true e2ee introduces to a
| product.
|
| Anyway, if you are seriously worrying about the privacy of
| your documents, just use a localy deployed libreoffice and
| send encrypted files to your contacts.
| sambroner wrote:
| What app are you developing?
| Andrew_nenakhov wrote:
| https://github.com/redsolution/xabber/ this one. Page is
| rather dated, though.
| JaggedJax wrote:
| I do like seeing the new Writer interface consistent across
| multiple applications, and it's very intuitive to use.
|
| I do find this interface is slow to load of even semi-large
| documents, especially when large tables are involved. That and
| a few formatting/editing quirks are the only real complaints I
| have. Otherwise I find Writer a great alternative.
| cphoover wrote:
| I love zoho's suite of free tools. When I first got started in
| web development business 10+ years ago, I used their invoicing
| tool, and thought it was perfect for a freelancer like I was at
| the time.
| coffeefamine wrote:
| As a small business owner, I found refrens.com extremely
| useful for invoicing.
| WA wrote:
| How do you deal with the fact that fonts render differently on
| different platforms and it might look off on one of them,
| because the user isn't used to the Canvas font rendering? Or is
| this not an issue?
| sambroner wrote:
| Is Zoho investing in WASM to do other canvases? I'd love to
| learn more about that solution.
| anfilt wrote:
| I have the canvas element disabled to prevent fingerprinting,
| good thing I don't really use google docs.
| stadium wrote:
| Is this similar to how flash was used for dynamics content before
| html/css could do it?
| est31 wrote:
| Btw there is a project to compile LibreOffice to wasm and render
| it to canvas as well:
| https://wiki.documentfoundation.org/Development/WASM
| bob1029 wrote:
| I've been playing around with pure-canvas web apps that are set
| up as follows: Client -> Server: Raw event stream
| (keyboard/mouse/touch/resize events) Server -> Client:
| Canvas draw batch stream
|
| The server provides a small javascript shim that bootstraps a
| websocket & subscribes to all required event sources. It also
| subscribes to the server issued batch events and has logic to
| dispatch draw commands to the canvas element.
|
| On the server, I use LMAX Disruptor to aggregate the client
| events and process them in micro batches (the size of which are
| determined dynamically based on backpressure). This results in an
| incredibly low-latency/low-jitter UI. Client events are passed
| around as readonly structs, so very little allocation or GC is
| involved throughout (.NET5/C# codebase). Processing is concluded
| with async/parallel dispatch of the appropriate client-side draw
| batches as they are ready to be issued. Not all client events
| result in a draw, and not all client events result in draws on
| the same client. There are some synchronous concerns between
| clients in my application, so having a single fast thread allows
| for lock-free processing of all events at the same time.
|
| The only caveat I have encountered is the latency constraint.
| Going over ~100ms makes this sort of interface feel like crap.
| For LAN/localhost, this approach is effectively instantaneous.
| joeberon wrote:
| Slowly adding more features to the web, a system really not
| designed for those features, seems to have been the only way to
| get a really cross platform application ecosystem. Very weird for
| it to happen through this random technology, but obvious in
| retrospect.
| kyrra wrote:
| (googler, opinions are my own. I know nothing about this
| project).
|
| I really hope this fixes the large-document problem. As someone
| that has to deal with large specs (1000+ page MS Word documents),
| Google Docs does a not-so-great job of handling them. I also
| understand this is why many writers don't like Google Docs to
| write the entire book in, as things start slowing down when you
| get into the hundreds-of-pages. I don't know if this is a
| javascript limit issue or a rendering issue, but if it's
| rendering, Canvas should hopefully help.
| k__ wrote:
| I hope so too.
|
| But I once read, most performance problems come from all the
| changes that are chached for a document and yoh can fix the
| problem by copying the text of an old document in a new one.
|
| This doesn't let me hope for huge performance gains.
| worldsayshi wrote:
| Yeah cached changes shouldn't have anything to do with dom
| performance.
| joelthelion wrote:
| Sounds like your problem is the process that requires you to
| use 1000-page Word documents, not Google doc performance...
| missblit wrote:
| Regardless 1000 page documents _are_ the sort of things that
| full-fledged word processors should be able to support.
|
| Writers need to write books, readers need to read books, and
| computers have more than enough resources to support these
| use cases.
| paxys wrote:
| Virtual DOM is already a thing. I'm sure canvas has a ton of
| advantages, but memory management isn't one of them.
| worldsayshi wrote:
| Switching to canvas sounds like a very roundabout way to handle
| an issue related to the dom growing out of hand. Surely
| unmounting pages that you you're not currently looking at
| should work?
|
| Of course there could be many reasons but we're left to
| speculate...
| cellularmitosis wrote:
| You can ditch the off-screen rendered pages but you are still
| stuck with the entire 1000-page data structure. Should your
| current line be on page 997 or 998? You have to calculate the
| size of every line of every page to answer that.
| williamscs wrote:
| But does switching to using canvas solve that problem?
| nwsm wrote:
| The argument is that the application would be much more
| performant, and would handle that issue better, not
| necessarily avoid it.
| hctaw wrote:
| Efficient 3 dimensional position or range queries
| (line/column/page) is a pretty well studied problem. You
| don't need to query every point of the space to answer
| anything.
| jasim wrote:
| I could not find clear references with an initial search.
| Can you expand a bit more about this approach? Thanks.
| hctaw wrote:
| It's a task more commonly found in computational geometry
| (3D range query == find all the points in a data set
| enclosed by a cube).
|
| There are numerous data structures that are well suited
| for various geometric queries like ranges/lookups
| (interval trees, quadtrees) as well as more text-oriented
| operations like cut/copy/paste/insert/merge/etc (like
| ropes).
|
| I'm not familiar with the operations required to put a
| cursor at the right place in a document, but knowing how
| much research has gone into storing similar data and
| looking up what you need efficiently the idea of "going
| through all the text every time" is a big code smell.
| ctoth wrote:
| I've used a segment tree[0] for a similar problem before.
| For 3D queries an R-tree may be more appropriate.
|
| [0]: https://en.wikipedia.org/wiki/Segment_tree
| ZeroCool2u wrote:
| I've looked at some of the public spec documents (Specifically
| the windowing system for Flutter desktop) that Google has
| hosted in GDocs and that was also the first time I noticed
| performance degradation. If I had to guess, I'd say there's not
| a better way around this performance barrier.
| contravariant wrote:
| Great now it's even less useful if I don't allow fingerprinting.
| spdustin wrote:
| A lot of discussion going on here, but I want to add two things
| in support of this change:
|
| 1. A browser- and OS-agnostic layout experience will have real
| effects. Just last week, a doc I wrote on my Mac (with Chrome)
| ended up with several pages with orphaned text, because the
| page/section breaks I inserted near the end of a page _on
| purpose_ ended up breaking for Windows Chrome users due to slight
| variations in font rendering.
|
| 2. They have a sample document linked in that post. The text is
| still 100% selectable/copyable, and assistive technology is able
| to read and navigate it.
| devongovett wrote:
| This is very bad for accessibility. Rendering things in canvas
| means there is no DOM, which means nothing for screen readers to
| read. To be fair, the old google docs editor was also very bad
| for a11y, but at least there was potential to improve it. This
| removes that option. They could have worked with the Chrome team
| to help improve standards for everyone, but decided to
| reimplement the rendering engine from scratch without regard for
| accessibility. I'm very disappointed that this wasn't flagged at
| a company the size of Google.
| lhnz wrote:
| The example that Google shows in their post has accessibility
| features [0], although currently these need to be switched on
| with a keyboard shortcut ([?]+Option+Z).
|
| Pay attention to `document.getElementById('docs-aria-
| speakable')`.
|
| [0]
| https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxS...
| gnicholas wrote:
| I give the gdocs team credit for reaching out to developers of
| Chrome extensions that may be affected. My accessibility Chrome
| extension [1] will be broken by this change, and I reported this
| when asked by the gdocs team a couple months back.
|
| I don't know if feedback from my company and others might sway
| this decision, or if it's set in stone (it's kind of weird to ask
| for feedback on something that has already been fully decided). I
| also don't know if they'll be providing more details regarding
| the timing of the rollout, which seems important since this will
| break third-party products.
|
| 1: https://chrome.google.com/webstore/detail/beeline-
| reader/ifj...
| [deleted]
| ericls wrote:
| Are they going to duplicate all the logic to handle all the
| keyboard events, mouse events, composition events? Wow
| vjeux wrote:
| They unfortunately already do. The state of contentEditable on
| the web is such that you need to if you want to have a non
| standard experience like google docs.
| [deleted]
| altcognito wrote:
| The dom is really, really fast, we have spent decades refining
| the process and there is deep tooling to support it built right
| into the browser. What a bunch of nonsense.
| dmitriid wrote:
| The DOM is abysmally slow for everything except one use case:
| displaying a simple text page with a couple of images.
|
| The core of the web is designed to display that on a 1990s
| computer in a single rendering pass. Everything bolted on top
| adds layers of complexity and indirection resulting in a
| laughably slow and inefficient system.
|
| The web can't even reliably animate an item in a list for
| laughing out loud.
| jcelerier wrote:
| > The dom is really, really fast,
|
| no, it is barely tolerable. Web apps in 2021 have trouble
| reaching the UI performance (latency) of early 2000 desktop
| software.
| Jaygles wrote:
| Looking at the DOM in isolation, its pretty quick. The
| primary reason web apps are slow is because the business
| logic is typically un-optimized.
|
| I've encountered a web app that persisted its state by
| stringifying it and putting it into localStorage with every
| UI change. The resulting string was ~5MB and took 200-300ms
| each time (freezing the UI) on my tablet.
|
| I've encountered an app that used an in-house built chart
| library using jquery and D3. For each chart rendered it
| created a 50MB array of x-axis labels that wasn't cleaned up
| when the chart was destroyed.
|
| The reasons for why these inefficiencies exist is another
| topic. But there's nothing stopping someone from creating a
| complex web application that's performant.
| MaxBarraclough wrote:
| > The primary reason web apps are slow is because the
| business logic is typically un-optimized.
|
| This crops up a lot, shifting the blame from the web
| technologies to the developers who target those
| technologies, but where are the exceptions? What's the best
| example of a large, complex, _efficient and responsive_
| web-based application? It 's easy to give examples of
| tragically inefficient and unresponsive web-based
| applications (Teams, Slack), but no one ever seems able to
| give a counterexample.
|
| Pinboard and Hacker News are fast and efficient precisely
| because they make minimal 'application-like' use of the web
| platform.
|
| Visual Studio Code is generally pretty responsive, but if I
| understand correctly there's little question that it uses
| vastly more computational resources than if it had been
| built using a 'conventional' (non-web-based) GUI toolkit.
| sethhochberg wrote:
| Figma is one of my favorite examples of something which
| is a nontrivial webapp that avoid feeling like a webapp a
| lot of the time, even when running in a browser instead
| of their Electron wrapper.
|
| But their technical leadership contains some of the
| (arguably) most accomplished folks working in the
| Javascript world these days, they might be an outlier in
| this area.
| SheinhardtWigCo wrote:
| It's easy to forget that Figma is a webapp, until you
| leave it running in the background and your $2000
| computer grinds to a halt.
| habryka wrote:
| Figma is built in Web-Assembly (compiled from C++) [1]
| and Canvas, basically sidestepping the vast majority of
| the web stack. That's why it's fast.
|
| [1]: https://www.figma.com/blog/webassembly-cut-figmas-
| load-time-...
| sethhochberg wrote:
| Neat, I had no idea it wasn't a normal old DOM
| application. Certainly does add a lot of validation to
| Google's approach here.
| p_j_w wrote:
| This exchange is absolutely hilarious to me. We've got
| people complaining about Google doing something while
| praising Figma for not being so foolish or evil and
| extolling them as being exceptionally clever. Except
| oops, turns out Figma is doing the same thing that is
| believed to be foolish or evil.
|
| It turns out HN is prone to the same sort of knee jerk
| reactions as most every other "social news" site (even if
| to a lesser degree). Who would've thought?!
| MaxBarraclough wrote:
| How is it on resource-usage though?
|
| Another example: Google Docs seems ok on responsiveness,
| but not on efficiency (especially memory).
| throwaway894345 wrote:
| > But there's nothing stopping someone from creating a
| complex web application that's performant.
|
| Google--the folks who _make V8_ --seem to disagree with you
| here. If they find canvas rendering to be more performant,
| then I'm going to believe them absent more information.
| sgslo wrote:
| Engineers will figure out how to make mistakes like this
| whether its in the browser or in a native app
| zo1 wrote:
| Perhaps - but then the question just becomes "which one
| of those makes it easier for such mistakes to occur".
| est31 wrote:
| It depends on what you do with it. HN is extremely fast.
| chalcolithic wrote:
| (Un)folding a 100+ comment subtree is kind of slow, don't
| you think?
| kazoomonger wrote:
| Out of curiosity, I just tested a 100-comment thread on
| my phone with Firefox. Folding it was instantaneous,
| unfolding it took ~4 seconds. That makes me wonder what
| takes so long, given that the initial page load didn't
| take anywhere near that long.
| zo1 wrote:
| Tried it with a sub-tree of ~240 comments just now. Less
| than a second on Firefox. Perfectly usable and acceptable
| in my opinion. To me there are probably hundreds of more
| annoying or slower things currently out there on the web
| that frustrate me.
| jcelerier wrote:
| "Less than a second" is definitely not an acceptable
| metric for any kind of UI latency. It should be at most a
| frame FFS, and that means 8 milliseconds on today's
| screens.
| est31 wrote:
| I don't have any large such subtree at hand, but visiting
| large 200+ comment threads is really fast.
| maple3142 wrote:
| Same experience on my Android phone. I just tried to
| unfold 75 comment, it has a noticeable latency in both
| chrome and firefox.
| jcelerier wrote:
| Same here, just this comment's tree starts to have some
| perceptible latency on my one+ 8 pro (which should be
| pretty powerful. In contrast I have some Qt apps where
| unfolding trees with tens of thousands of nodes is
| instant.
| [deleted]
| Red_Leaves_Flyy wrote:
| Is that the fault of the web apps programmers (or their
| library/design choices!) or the engine?
| shadowgovt wrote:
| A little bit of both. The DOM enforces a specific model of
| presentation focused on a structural, hierarchical,
| declarative description with layout including an automated
| vertical bias. Great if I want to layout something
| "document-shaped," a colossally bad match to the problem
| domain if I just want to draw a pentagon and animate it
| around the screen.
|
| The libraries exist to mitigate the huge problem-domain gap
| between the DOM model and other models.
| minusf wrote:
| quite a blanket statement both for web and desktop apps...
|
| some are fast some are slow on both platforms, no?
| altcognito wrote:
| It's a blanket statement because the time to render a
| standards based user interface is very small. Once we bring
| in the latency of the internet, (or on the desktop side,
| database or any other networked resource) all bets are off.
|
| It makes sense for Google to make this change. Why should I
| care anyway? Its not like anybody has cared about open
| document formats in this space anyway. This never was and
| never will be an open platform.
|
| I find it frustrating because this is just another nail in
| the coffin for open documents.
| jcelerier wrote:
| the immense majority of my experience on the web is slow,
| and on the non-web is fast, it's definitely not 50/50. I
| wouldn't be able to give you the name of a slow desktop app
| I use actually.
| altcognito wrote:
| It's never about the UI, it's what it's trying to do
| before it renders.
|
| Oracle on the desktop? Slow. Heck, grep is "slow" by this
| definition. The web renders quite quick if you serve the
| content quickly.
|
| Even when the possibility of fast is there, companies
| like Apple and Microsoft overlay things with animations
| because it is "too jarring"
| moshmosh wrote:
| React (not just React, but they "meme"'d it) sold everyone on
| the DOM being slow. What they actually meant was that if you
| add & remove 5,000 elements one at a time in a loop, it's slow.
| If you don't do that it's plenty fast and all of React's tricks
| to "make it fast" are just overhead that are bloating and
| slowing down your "app". (FWIW, I actually kind of like writing
| React, if I must do front-end JS, so I'm not hating on it just
| for hating's sake)
| MaxBarraclough wrote:
| > What they actually meant was that if you add & remove 5,000
| elements one at a time in a loop, it's slow.
|
| Ok, but it's not trivial to build complex web-based
| applications that _don 't_ do exactly that. This is why there
| are so many frameworks out there that take care of that
| problem for you. React isn't the only one. Angular, Vue, and
| Svelte also handle this for the developer, using various
| different approaches. It's not just a gimmick. If the web
| standards themselves were up to the task, there'd be far less
| need for frameworks.
| moshmosh wrote:
| I would agree that companies have mostly settled on paying
| 20% as much for development, at the cost of 5-10x the
| memory footprint and 5-10x the input latency in the
| finished program. I think the web tends to get hit the
| hardest by that because if a company is targeting the web
| for an "app" in the first place, they've already chosen
| cost savings over performance and UX, so they'll be prone
| to make even more trade-offs for the same reason _within_
| the web platform.
| Leherenn wrote:
| I disagree, I prefer to Google something and have it
| instantly in my browser instead of having to find and
| install yet another app, then uninstall it when I'm done
| with it. Especially for stuff I only use once/rarely.
|
| Also, I might be using the latest iPhone, an old Android,
| Windows or Linux, or hell maybe my TV browser, and it's
| most likely going to work. The app wouldn't exist on at
| least half those platforms.
|
| There certainly are issues with webapps, but well done it
| can a really good UX.
| MaxBarraclough wrote:
| You're right that the web scores extremely well on
| portability and on having zero installation hassle. The
| points about efficiency still stand though. To put that
| another way: the web's upsides are real, and so are its
| downsides.
| ctvo wrote:
| > I think the web tends to get hit the hardest by that
| because if a company is targeting the web for an "app" in
| the first place, they've already chosen cost savings over
| performance and UX
|
| Or it could be they're choosing a ubiquitous, open, cross
| platform distribution model for their app?
| refulgentis wrote:
| I must be missing something, its a "bunch of nonsense" whenever
| someone claims they're better off rendering to canvas for
| performance?
| dang wrote:
| Please don't call names in HN comments. Your post would be fine
| (well, a little unsubstantive and flamebaity, but nothing too
| serious) without the swipe at the end.
|
| If you wouldn't mind reviewing
| https://news.ycombinator.com/newsguidelines.html and taking the
| intended spirit of the site more to heart, we'd be grateful.
| We're trying for a bit higher quality of discussion here, if
| possible.
|
| We detached this subthread from
| https://news.ycombinator.com/item?id=27130438.
| altcognito wrote:
| I'll review and I respect that youre trying to keep it civil.
|
| My swipe was more at the argument, but this could be better,
| sorry.
| [deleted]
| umanwizard wrote:
| I have never used a web or electron app that felt subjectively
| as "snappy" as equivalent desktop apps.
| scoopertrooper wrote:
| I just tried the example they provided on an iPad and the
| scrolling experience is... not great.
|
| https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxS...
| lwhi wrote:
| Feels to me like this could _partly_ be a line of attack.
|
| The fight for advertising and tracking on the open web is being
| lost, which is detrimental to Google.
|
| If you have your own ecosystem, what does it matter?
| lwhi wrote:
| To the down-voter - please elucidate your displeasure.
| lenkite wrote:
| Huh - might as well use WASM then if canvas is going to be the
| display target.
| pbnjay wrote:
| As someone who spends an inordinate amount of time in Docs, some
| speedups would definitely be welcome... but if this is going to
| break the workflows I'm using now (most importantly Zotero
| integration) you can be damn sure I'll go back to Word.
| Ajedi32 wrote:
| I think this is actually one of the few cases where canvas-based
| rendering makes sense as a replacement for the DOM.
|
| Docs is a full-featured application which already has to re-
| implement a lot of DOM-like features in order to fulfill its
| primary function (things like text formatting and layout, spell
| checking, etc). Doing it all in canvas doesn't sound
| significantly more difficult than what they're already doing.
|
| The loss of extensibility is regrettable, but probably worth the
| trade-off for better performance.
|
| If this starts happening with more traditional websites, then yes
| I'd agree that'd be a bad thing. We're certainly not there yet
| though.
| irrational wrote:
| > We're certainly not there yet though.
|
| Won't it be too late when we are there?
| pwdisswordfish8 wrote:
| This is a great example of a comment written by a developer or
| some otherwise technical person who is so used to thinking and
| speaking in terms of trees that they can't see the forest, let
| alone the village it's situated next to and the people
| inhabiting it.
|
| Google Docs may be an app, but a big part of the app, and
| confirmed to be one of the reasons for the migration here, is
| the part that renders the document to the screen. Only the
| sorts of techno-fetishists found on this site and in programmer
| circles would be able to make the argument you just have and
| not recognize the perverseness of what you're saying and what
| this decision by Google really means.
|
| Documents are the quintessential use case for the Web, full
| stop, and they're the direct object of whatever the verb form
| of "Google Docs" would be. Google's decision here reflects the
| belief that, despite this, the Web _is not suited for
| documents_. We 're not talking here about the mere act of the
| "app" chrome at the edges (surrounding the edited document
| itself) being switched over to use some more perfect framework
| better suited for e.g. painting interactive widgets, etc. No,
| it's right there in the announcement: "we'll be migrating the
| underlying technical implementation of Docs from the current
| HTML-based rendering approach to a canvas-based approach".
|
| Google is completely dropping the ball here and leading us down
| the path towards the picture painted in the top comment; what
| this is is just shy of an abrogation of their responsibility to
| act as a steward for the Web and the intention that it best
| serve users (rather than overpaid frontend developers
| trafficking in flavour-of-the-month fads, frameworks, etc and
| who already disproportionately receive attention under the
| status quo).
|
| If the Docs team has identified deficiencies in the underlying
| standards-based model for--let's repeat it-- _presenting
| documents_ , then they are _perfectly_ situated for translating
| that into feedback about how to improve things so that the Web
| is better fit for that use case. Even if that meant the Docs
| team going off into a corner, identifying what the problems
| with the Web are down to its fundamentals (DOM, etc), and then
| emerging with an entirely new approach for how to lay down bits
| so they might be better interpreted by the viewer running on
| the end user 's computer, and then get the Chrome team to bake
| native support into Blink while disregarding every other
| vendor's possible objection to this act of steamrolling the
| standards process, then that would _still_ be better in the
| long-term than what Google is doing here.
| dahart wrote:
| > Google's decision here reflects the belief that, despite
| this, the Web is not suited for documents.
|
| I don't see how you jumped to that conclusion. They're not
| changing the way documents are stored, they're only changing
| how documents are rendered.
|
| Who's relying on the render API? What functionality do you
| think you're losing, as a web user?
|
| The web of HTML+CSS is good for some kinds of documents -
| static documents, but it has never been good at _editing_
| documents, and it has never been good at all documents, and
| it has never been the best platform for high performance
| applications like editors or games.
|
| > this is just shy of an abrogation of their responsibility
| to act as a steward for the Web and the intention that it
| best serve users
|
| Ignoring the problems with your assumption that Google should
| act as a steward for today's Web (Google's mission statement
| doesn't mention preserving HTML. And it's better if public,
| not private for-profit entities are our stewards) -- this
| decision is being made to best serve users, no? As a user, I
| want Docs to render faster, don't you?
|
| I'm not quite seeing your reasoning why this affects the long
| term health of the Web. I can't help but note that many large
| web apps have transitioned to canvas rendering for
| performance, and the internet is still growing. There is, in
| fact, a problem with rendering HTML+CSS in a performant way
| when editing things, and it might be too late, and there
| might be too much legacy to fix it... _maybe_. It's still
| pretty good at what it does, and not likely to go away.
| gentleman11 wrote:
| You make some good points, but the tone towards the op is a
| little bit more unpleasant than I think you intended
| ctoth wrote:
| Thank you for articulating this. For the last decade we have
| had frontend developers trying to force the web to be an app
| delivery platform. We have bent over backwards to accommodate
| this. We have turned browsers into a giant pile of hacks
| essentially emulating their own operating systems. And for
| what? As soon as they're able, they say oh, the browser is a
| giant bundle of hacks now, let's implement our own app
| delivery system on top of it.
|
| Next time we get a document delivery format and people start
| trying to make it something it's not, because oh gosh it's
| easier to install the app, we need to push back and say hey,
| maybe clicking a few buttons in an installer isn't the worst
| thing in the world.
| vkou wrote:
| So, because you don't want binary blobs to be deployed over
| the web, you would like users to download and install
| binary blob native applications... And that makes things
| better in what way, for whom, exactly?
| AlexandrB wrote:
| I'll bite.
|
| For starters, a binary blob on your computer can be
| prevented from "phoning home" to collect personal data
| much more effectively than a web app can. Additionally,
| the vendor is often forced to compete with their own old
| software because they can't always force you to run the
| newest binary blob. This prevents the wholesale loss of
| features from products you rely on at the whim of the
| vendor.
| vkou wrote:
| > For starters, a binary blob on your computer can be
| prevented from "phoning home" to collect personal data
| much more effectively than a web app can.
|
| In theory, it _can_ be. In practice, the average user
| doesn 't do a damn thing to do so, and installing a
| random native blob from the internet is far more
| dangerous than a webapp running in a browser sandbox.
|
| > Additionally, the vendor is often forced to compete
| with their own old software because they can't always
| force you to run the newest binary blob.
|
| This is also how we get people running years-old software
| instead of deploying security patches.
|
| I understand that a power user may prefer these trade-
| offs. Most users are not power users.
| Dylan16807 wrote:
| Security patches aren't important for most software, when
| it's not connecting out to any servers.
| ctoth wrote:
| Let's start with accessibility, because this is a field I
| am forced to be an expert in. Native "binary blobs" have
| access to the operating system accessibility APIs, and
| consequently any native app is a lot more likely to be
| accessible out of the box than something rendered to a
| canvas. People have spent literally decades building out
| APIs for the native platforms [0] [1] [2].
|
| To think that a native app is equivalent to a canvas-
| rendered app is to not understand either.
|
| [0] https://en.wikipedia.org/wiki/Microsoft_Active_Access
| ibility
|
| [1] https://en.wikipedia.org/wiki/IAccessible2
|
| [2] https://en.wikipedia.org/wiki/Assistive_Technology_Se
| rvice_P...
| beaconstudios wrote:
| it's viable to make accessible apps in DOM though - it's
| just canvas apps that can't be made accessible, and I
| agree with the GP that Google should not be trying to
| circumvent the DOM for the Docs interface.
| lhnz wrote:
| Canvas apps can be made accessible.
|
| The example that Google shows in their post has
| accessibility features [0], although currently these need
| to be switched on with a keyboard shortcut
| ([?]+Option+Z).
|
| Pay attention to `document.getElementById('docs-aria-
| speakable')`.
|
| [0] https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBX
| JUBFjxS...
| thehappypm wrote:
| You know what I'm tired of? Slow apps. Google Docs is a great
| platform but performance has always been slow compared to
| native Office. I welcome this change. Draw the document
| quickly and make me more productive.
| neysofu wrote:
| > Documents are the quintessential use case for the Web, full
| stop, and they're the direct object of whatever the verb form
| of "Google Docs" would be.
|
| You seem to be basing your whole point on the misplaced idea
| that the web is great at displaying, nay _was specifically
| made_ to display Google Docs ' class of content. This is
| incorrect. At its core, Google Docs is a typesetting engine
| with semantics and features that don't align well with
| HTML+CSS. Typesetting is about _graphics_ , the web (and
| HTML) is about _content_. They 're very different use cases.
|
| > [...] what this is is just shy of an abrogation of their
| responsibility to act as a steward for the Web
|
| Google has no obligation, either moral or legal, to be a
| technical leader. They're simply a market player. The only
| way in which I care about this change is how it affects me as
| a user and it's nowhere near as catastrophic as you make it
| sound imho.
| Shorel wrote:
| If that's your point of view then no, the web has never been
| suited to spreadsheets, it was only suited to PowerPoint-like
| presentations when Opera had some nice markup for that
| functionality, and it is only suited for Word-like documents,
| with ugly hacks for equations.
|
| In the end, you end up making Google's argument just
| stronger.
| chromanoid wrote:
| It's about producing PDF vs producing HTML.
|
| Google Docs produces printable documents not hypertext. Print
| was never a priority of HTML. And I guess it shouldn't be
| either. Just look at the complexities of DocBook, LaTeX or
| Open Office XML.
| vkou wrote:
| > Documents are the quintessential use case for the Web, full
| stop
|
| In 1996, yes. And you can still use the Web that way.
| Nobody's stopping you. Much of the Web is still used that
| way, and that's not going to change.
|
| But in 2021, the web serves documents, _and_ applications.
| And HTML /CSS was never intended as a way to build
| _applications_.
|
| It's why people came up with Flash, Java Applets, ActiveX,
| and all that other shit. And the web today wouldn't be one
| whit better off if the vendors of those technologies took
| your advice, and rolled their functionality into the core
| web. In fact, it would be in many, many ways worse off.
| pwdisswordfish8 wrote:
| This is not a response to the point being made at the point
| where the quoted text originates, even though superficially
| it looks like it is. Please re-read the comment you're
| responding to.
| vkou wrote:
| Actually, it responds to the entire[1] train of thought
| that follows that statement. Please re-read what I am
| saying, and consider it in context. You are suggesting
| that Google work on updating the standards to make their
| desired use case work better. I am suggesting that
| Google's desired use case will never be served by
| document-oriented standards, and that is why it shouldn't
| mess with those standards.
|
| Again, the world would not be better off if ActiveX were
| rolled into web standards back in the oughts.
|
| Leave document standards responsible for displaying
| documents, and don't let the needs of application people
| get in the way of that.
|
| [1] Well, I don't respond to your point that Google Docs
| is intended to display documents - because, as another
| commenter points out, it's incredibly obvious that its
| most important function is to _edit_ documents.
| s17n wrote:
| > Well, I don't respond to your point that Google Docs is
| intended to display documents
|
| That was the entire point
| vkou wrote:
| > as another commenter points out, it's incredibly
| obvious that its most important function is to _edit_
| documents.
| delroth wrote:
| "Displaying documents" and "displaying editable documents"
| are two completely different beasts. The web browser has
| never dealt well with displaying editable documents, the
| closest standard that exists is contentEditable and pretty
| much everyone agrees that it sucks and is not fit for complex
| use cases.
| felixfbecker wrote:
| Why can't Google work on improving `contenteditable`? It
| would benefit so many and the problems are well-known. It's
| probably even used by Google _somewhere_
| erlich wrote:
| Good point. Imagine the millions of collective hours that
| would have been saved by everyone hacking their own text
| editors together.
| pshc wrote:
| You could easily burn five years trying to fix
| `contenteditable` and get nowhere. There's too much
| legacy and impedance mismatch. Better to start fresh at
| this point.
| warkdarrior wrote:
| All web pages are editable currently, they are editable via
| Javascript. Not sure the distinction you are making is
| meaningful. The only thing we are missing is a good edit
| UI.
| zamadatix wrote:
| Isn't "the only thing we're missing is a good edit UI"
| lke saying "the only the the browser is missing is what
| Google Docs is building itself here"?
| fwip wrote:
| Google Docs is what happens when you write a good editing
| UI.
| asumandiras wrote:
| despite the fears of locking down the web, this is really neat
| from a UI/UX perspective. i'm assuming they're using flutter to
| do the rendering. is anyone working on an open sourced js
| framework that also does render to canvas UI?
| resters wrote:
| It will be interesting to see if Google Docs undergoes a feature
| explosion and achieves parity with MS Word after the rendering
| engine enhancements.
|
| I wonder what competitive pressures Google is responding to with
| this decision. My guess would be adding features taht facilitate
| selling into businesses that have significant dependency on MS
| Office.
| xnx wrote:
| 26 years later and we're back to java applets. It was fun while
| it lasted.
| pictur wrote:
| https://github.com/myliang/x-spreadsheet
| pictur wrote:
| I don't understand why stupid people downvote my comment. I
| just posted a link. Why are you so dumb?
| dang wrote:
| Your link was fine, and has since been upvoted (see https://h
| n.algolia.com/?dateRange=all&page=0&prefix=true&sor...), but
| a comment like this one breaks the site guidelines. Would you
| mind reviewing them?
| https://news.ycombinator.com/newsguidelines.html
|
| Edit: could you please stop posting unsubstantive comments
| generally? Your account has been doing a lot of that, and
| we're hoping for a little higher quality of discussion here.
| pictur wrote:
| You can delete my account. I do not want to be on this site
| any longer. There can be no quality in an environment with
| moderators like you.
| pictur wrote:
| I was going to write at length how bad a moderator you are,
| but I don't think you are capable of understanding it. I
| just feel sorry for you. You can be a better moderator.
| this is not your potential. let's delete my account and
| relax.
| catchmeifyoucan wrote:
| HTML Canvas is really smooth. Especially with all graphics
| acceleration work. Afaik, it's smart enough to load elements that
| aren't in the view port. I believe text rendering was an issue,
| but it's mostly usable now.
|
| It might work well for rendering logs as well :)
|
| [1]https://news.ycombinator.com/item?id=26587951
| llacb47 wrote:
| Not thrilled about this.
| [deleted]
| yread wrote:
| I wonder if it will help improve ios canvas performance -
| currently it's somewhere on ie9 level for our use case at least
| jcuenod wrote:
| I wonder what their plans are for accessibility?
| rektide wrote:
| This is incredibly destructive, an attack on the core
| technologies & interoperability of the DOM. It's highly
| concerning, highly scary that they would do this.
| dvvavinash wrote:
| why
| ithkuil wrote:
| I have a vague memory of some people who installed the
| https://github.com/panicsteve/cloud-to-butt extension for fun,
| thinking it only modifies text on the screen, but since it
| modified the dom it caused the changes to somehow end up
| modifying the open google docs
| rlili wrote:
| So Dark Reader won't work anymore. Great.
| svat wrote:
| Noticed something to try: The post links to an example document:
| https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxS...
|
| If you change the /preview to /edit you can then go to File-"Make
| a copy", and you'll have your own editable version of this
| document. If you change that one to /preview again, you
| (unsurprisingly) get something that doesn't use canvas, but uses
| the DOM with the usual div/span soup. Here's an example I
| created:
| https://docs.google.com/document/d/1RnQonRlivBogXxSl1nTZSCfR...
|
| These two /preview versions would be a good basis for comparison
| (until we have examples of editable documents that use canvas-
| based rendering).
|
| Visually, comparing the two /preview documents by alternating
| rapidly back and forth between the two tabs shows some minute
| differences in kerning (on only some of the lines). It might be
| interesting to repeat this experiment on multiple devices and see
| whether and in what way the differences themselves differ across
| devices.
|
| One difference I've been able to find is that using the browser's
| in-built find doesn't work. But all the common ways of triggering
| search (Ctrl-F or Cmd-F, etc) trigger the search function of
| Docs, and that seems to work identically in both versions. And
| anyway the browser's find cannot find things off-page before
| scrolling down the page, so it's not usable in general anyway.
| [deleted]
| vzaliva wrote:
| It it kills grammarly extension I will be so dissapointed. Could
| they keep the old mode as an option for some time?
| aazaa wrote:
| > ... Over the course of the next several months, we'll be
| migrating the underlying technical implementation of Docs from
| the current HTML-based rendering approach to a canvas-based
| approach to improve performance and improve consistency in how
| content appears across different platforms.
|
| This article talks about some of the tradeoffs between Canvas and
| DOM approaches:
|
| https://www.kirupa.com/html5/dom_vs_canvas.htm
|
| The thing that seems least appealing about replacing DOM
| rendering with Canvas rendering is the lack of CSS. You may gain
| performance, but assuming even a fraction of the responsibilities
| CSS handles so well seems very daunting.
|
| That's why I suspect this approach will do best where the content
| least resembles a read-only document, and more resembles a game,
| such as Google Docs.
| disease wrote:
| Attempting to use the 'Read Aloud' feature of my browser on the
| example page lead to no text being read aloud.
| Liskni_si wrote:
| Has anyone found a way to report bugs in the preview
| implementation?
| vaughan wrote:
| If you click `Save as Copy` on the example doc you get an
| editable DOM-based version to compare.
|
| The scrolling is a lot less smooth on the canvas than the DOM.
|
| Text selection seems faster but the canvas version is not
| editable...
|
| Maybe they are working out the kinks though...
| iandanforth wrote:
| "Let's remove the foundations that made the web possible!"
| thekyle wrote:
| This reminds me a lot of those websites that used to be
| implemented in Flash. It's just one giant opaque blob that gets
| downloaded and can do whatever it wants.
|
| When this stuff inevitably starts being used by every news and
| shopping website I wonder how search engines will be able to
| index it.
| Sleepytime wrote:
| Google and their AI won't have any issues, but their
| competitors probably will.
| EvanAnderson wrote:
| _When this stuff inevitably starts being used by every news and
| shopping website I wonder how search engines will be able to
| index it._
|
| Legal agreements and money changing hands between publishers
| and Google.
| MivLives wrote:
| They'll just have a separate version that is SSR'd for
| Googlebot.
| leodriesch wrote:
| Does not make much sense. If search engines can't index it, no
| news website will do it.
| thekyle wrote:
| If news websites can use this to bypass ad blockers then it
| might still be worthwhile, and I imagine a lot of traffic
| comes from social media sites these days.
| willyg123 wrote:
| Someone please ELI5 how this might impact the Grammarly Chrome
| Extension. Thanks in advance!
| notjustanymike wrote:
| It makes a hell of a lot of sense, even from a QA perspective
| alone. Canvas is going to be far more predictable as a rendering
| target than the wide swath of browsers they manage now.
|
| The DOM certainly has a place, but if you've looked at Google
| docs rendered output you'd notice it left web standards behind a
| long long time ago. This is an application which happens to be
| served on the web, not a traditional website.
|
| It's more Figma, less NYTimes.
| ainar-g wrote:
| How would you test something like that using Selenium or
| something like that?
| notjustanymike wrote:
| I can't speak for Google, but my company does 3D medical
| rendering (BioDigital). To test that our 3D engine is
| appropriately rendering the content, we use Cypress with
| image diffing. I'm sure Google has a way more advanced QA
| process for docs, but that'd be an option.
| hajile wrote:
| VS Code already shows why Google would do this. They moved the
| Terminal from DOM nodes to canvas and got somewhere like a 20x
| render improvement (after already having spent a lot of time
| optimizing the DOM implementation). The previous jank all but
| went away too.
|
| EDIT: added their blog article
|
| https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...
| bruce343434 wrote:
| So the previous jank did not go away?
| Wingy wrote:
| : very nearly : almost
|
| https://www.merriam-webster.com/dictionary/all%20but
| pdkl95 wrote:
| Ever since WebAssembly was first introduced, I thought it was
| obvious[1][2] that the end game for those that want to control
| the web is sending opaque binary blobs of code that only use the
| browser for the canvas tag's framebuffer. Font rendering and
| layout can all easily be accomplished by embedding libraries like
| freetype. This breaks all forms of user control - like ad
| blockers - and turns the web back into cable TV.
|
| I didn't expect the first move towards canvas-only rendering to
| be traditional wordprocessors. As usual, this is merely the first
| step. Once the tech has been normalized by developers,
| transitioning regular webpages will be a _fait accompli_.
|
| [1] https://news.ycombinator.com/item?id=10294187
|
| [2] https://news.ycombinator.com/item?id=26351771
| est31 wrote:
| Ad blockers could still "scroll" through a website, run an AI
| model on it to discover the ad sections, and cut them out. Even
| a simple model that filters out visual animations and replaces
| them with a static would be useful as a large annoying
| component of online ads is the movement and blinking etc. that
| make it hard to focus on the content.
|
| Dark mode etc can, too, be implemented to work in terms of
| framebuffers only.
|
| But yes, unless there is a _serious_ need, canvas rendering is
| a severe regression.
| 4684499 wrote:
| Is there any ad blocker that blocks ads rendered within
| videos?
|
| It's possible doesn't mean it's viable.
| Nullabillity wrote:
| SponsorBlock does a surprisingly good job:
| https://sponsor.ajay.app/
| tjpnz wrote:
| I've seen some rather atrocious techniques employed to bake
| ads into source but that can still be done without any
| performance impact. Making that work in WASM would require
| dynamic recompilation, doable perhaps for smaller apps but
| for behemoths like Gmail and Docs I couldn't see even Google
| getting that to scale. I think we'll still have browsers
| performing additional HTTP requests for that stuff, at least
| in the short to medium term. So traditional adblocking
| techniques will still be viable.
| asciimov wrote:
| It will be like cutting out the ads in a newspaper. Lots of
| holes, everywhere.
| exhilaration wrote:
| The difference from a physical newspaper is that on a
| computer we don't have to leave holes, we can replace them
| with beautiful artwork or our favorite cat pictures. That's
| still a hell of a lot better than ads.
| anon_tor_12345 wrote:
| >run an AI model
|
| what exactly would this AI model be trained on?
| iandanforth wrote:
| Ads? The suggested approach is "from pixels" so any
| rendered ad is a source of training pixels.
| xxpor wrote:
| That still defeats the purpose. I want the ads to be blocked
| from loading for performance reasons more than anything else.
| ryandrake wrote:
| User preference and configurability of hyperTEXT display has
| been totally thrown under the bus, increasingly throughout the
| web's existence. I remember when it was straightforward to have
| your own text color and font preference, and web sites didn't
| try to override them. You could even configure a brick wall GIF
| background for sites if you wanted to. Now, these preferences
| are buried and easy for a developer to ignore using CSS and
| JavaScript. And as you say, it'll get even worse. The user
| agent (who, by the way, you're writing your web site for) now
| has very little say in how a web page is rendered.
|
| Unpopular opinion on HN full of web devs, but I don't want my
| browser to be a "canvas" for some developer. I don't want it to
| be a "stable ABI" for some opaque binary app. I already have a
| platform for binary applications: It's called a desktop
| operating system. I wish more developers would go back to
| developing for that and leave the web alone. I want my web
| browser to display hyperTEXT documents, with links out to other
| hyperTEXT documents, and occasionally accept input from me via
| a FORM. And that's it. I understand that opinion makes me a
| minority nowadays, though. Maybe we should revitalize gopher or
| something--something to get back to the roots of fetching,
| displaying, and navigating information.
| macspoofing wrote:
| >I thought it was obvious[1][2] that the end game for those
| that want to control the web is sending opaque binary blobs of
| code that only use the browser for the canvas tag's framebuffer
|
| As opposed to a world where huge, unintelligible minified
| JavaScript blobs are sent to the browser?
| [deleted]
| stefan_ wrote:
| This is what Flutter on the web is, by the way. You can try it
| out here:
|
| https://gallery.flutter.dev/#/
|
| and marvel at the impossible to select text, one of the many
| affordances violently excised here.
|
| If it wasn't still incredibly slow even on a cutting-edge Zen3,
| Nvidia 3070 system they might almost be on to something here.
| ehnto wrote:
| Unselectable text, and links that are actually javascript so
| you can't preview them, or open them in new tabs.
|
| But who are we kidding, the web is javascript all the way
| down now.
| clon wrote:
| It refreshes dormant memories of what Flash used to feel
| like.
|
| For me the balance is still the same. Fine for highly
| interactive things such as games. For everything else, ugh...
| dcchambers wrote:
| Yikes. How does the inability to select or search text pass
| even the most basic of UI/UX and accessibility guidelines?
| selfhoster11 wrote:
| Web UIs are already an incredibly cut-down implementation of
| a real OS GUI. I'm not looking forward to something even
| worse than that.
| mattgreenrocks wrote:
| I had these exact complaints about web apps many years ago,
| and I was dead wrong. Nobody cared that web apps were slow,
| had/has horrible UX compared to native apps, and feel janky
| by comparison. These demos elicit similar feelings. Now,
| they're not as fast as I like, but they feel better than most
| webapps already. (It reminds me of Flash, actually.)
|
| If the Flutter dev experience is good enough, this will eat
| traditional web apps slowly. In a way, the web was designed
| for this sort of scenario: a delivery mechanism agnostic of
| the client implementation. We've gone from pushing server-
| generated HTML to megabytes of JS + SPAs, and now a
| WASM/Canvas hybrid seems inevitable.
|
| It all comes down to how well these perform on mobile
| devices, what the dev experience is like, and how the end
| product feels. There's still a lot up in the air, but, I'm
| honestly impressed with the progress shown by Flutter here.
| There's still a host of considerations unaddressed (including
| accessibility) that I hope they have an approach for.
| mrighele wrote:
| Despite their shortcomings webapps won because they had a
| number of advantages that native lacked, most of all
| software distribution.
|
| What has flutter to offer that a regular webapp lacks? (not
| performance, it seems)
| brabel wrote:
| The fact that it (the same code base with minor changes)
| runs on desktop and mobile platforms?
| mattgreenrocks wrote:
| Great point. It is striking to me how similar many of the
| modern languages are for various platforms (thinking of
| Rust, Kotlin, and Swift here), but it is still quite
| difficult to share business logic among web, Android, and
| iOS devices because of language differences.
|
| If Dart/Flutter is good enough for all of those
| platforms, that is quite the value proposition.
| mattgreenrocks wrote:
| SPAs to Flutter is a much smaller step conceptually than
| native to Web. Most of the world is using a Blink-based
| browser of some sort already. Updates are pushed
| aggressively.
|
| > What has flutter to offer that a regular webapp lacks?
|
| Google branding, novelty, more sane dev UX. I'm not
| saying those are good reasons to choose it, I'm just
| extrapolating from how the industry works.
|
| Let's be honest: end users basically just put up with
| whatever devs release at this point. It doesn't matter if
| the end product murders battery life, doesn't fit the
| target platform, and steals their data. It's not like
| switching to some less-than-web-native framework is
| somehow a bridge too far for end users.
| tomatotomato37 wrote:
| Your last point made me think: for all the flak the gamer
| demographic gets for being over entitled and toxic, they
| seem to actually ultimately end up with nice things like
| programs that run at a performance you'd expect from a
| modern computer and don't swamp you with creepily-
| targeted ads
| morelisp wrote:
| Resume lines.
| lazysheepherd wrote:
| This is correct, I am afraid.
| ape4 wrote:
| A dystopia. You can't control-F in the page. Can't copy and
| paste a word you don't know into a translator or dictionary.
| Can't share text unofficially - like copy a sentence into a
| email, etc.
| amelius wrote:
| It's basically Flash [1]. What's old is new again.
|
| [1] https://en.wikipedia.org/wiki/Adobe_Flash
| slver wrote:
| Do you honestly believe they won't implement copying a
| sentence.
| nofunsir wrote:
| I honestly believe they WILL implement copy paste...
|
| ... along with tracking exactly what you copied, when,
| where you hovered your mouse, inserting all sorts of
| features into your copied piece of "plain text"
|
| ... along with the ability to force-turn off copying from
| server side whenever it benefits them.
|
| You WILL use ChromeOS (by another name) and you WILL like
| it
| [deleted]
| slver wrote:
| All of this is done without canvas. Maybe less drama
| would help.
| nofunsir wrote:
| > All of this is done without canvas.
|
| Currently it's pretty easy to get around such blocks.
| Compare with how hard it is to get around modern, proper
| DRM.
|
| I have faith this implementation will be modern and
| proper, as the fate of the ad industry and those who rely
| on it, rely on it.
| fulafel wrote:
| The copy and paste problem is sidestepped in android by the
| os native ocr, it might become common elsewhere too.
| fmakunbound wrote:
| I can't tell if you're being facetious. Text is rendered
| to a canvas frame buffer and then the solution to text
| selection involves OCR?
| fulafel wrote:
| Cab I be facetious and factually describe the current
| state of affairs simultaneously?
| wizzwizz4 wrote:
| I mean, that's how MacPaint was going to work. (They
| eventually ditched "edit text once it's written"
| entirely, for fear that people would use MacPaint for
| word processing, but the code was all written.)
| davidgay wrote:
| Amusingly, the Amiga lacked cut&paste support in most
| applications, so someone developed a tool that did
| precisely that.
|
| Leading to questions like this:
| http://forum.amiga.org/index.php?topic=10580.0
| DrJokepu wrote:
| Also, you know, accessibility. This could be a real serious
| problem for people with disabilities.
| mumblemumble wrote:
| This is 100% the reason why I decided not to use Flutter
| back when I was shopping.
|
| It probably would have reduced my developer effort
| considerably compared to basically every other option
| that made it to my short list, but I can't in good
| conscience build something that isn't accessible.
| brabel wrote:
| Flutter claims to be fully accessible:
| https://flutter.dev/docs/development/accessibility-and-
| local...
|
| Did you actually try it?
| mumblemumble wrote:
| No, I just looked at the documentation and saw that it
| isn't supported on all the platforms I'd be targeting.
|
| For example, that page you link is specific to iOS and
| Android targets. Nary a mention of what to do when you're
| targeting the Web. But it's also, at least as of when I
| did my comparison, explicitly not supported on at least
| some desktop targets.
| blackbrokkoli wrote:
| Thank you for saying "claims to". Copy pasting a response
| I made elsewhere:
|
| This is making a mockery of accessibility.
|
| It's the equivalent of having a company that actively
| discriminates against everyone not passing a internally
| developed test to check whether you are a "neurotypical"
| and then respond to criticism by pointing at the
| wheelchair ramp you installed on one of your entrances.
|
| If I can't copy paste words from your websites to put
| them into a translator, if I can only use your website
| when I use one of the two corporate-affiliate-selected
| screen readers (not even platform-agnostic ones), when I
| can't look at your website from anything that does not
| have 4+ cores and a 4G or better connection...saying
| accessiblity is a "first class citizen" or even citizen
| at all is laughable at best.
| brabel wrote:
| I said "claims to" because I don't know how I can verify
| if it is. The other person responding to me correctly
| mention how they suggest tools to scan for accessibility
| issues on iOS and Android, but they don't say how to do
| that on the web... have you managed to somehow figure out
| what is not currently working, exactly?
|
| Regarding performance: Chrome uses Skia to render the
| DOM, why do you think rendering Flutter, also based on
| Skia, should be so much worse?
| mumblemumble wrote:
| The thing is, when you're shopping for GUI toolkits, "try
| it and find out" isn't a great decisionmaking rubric.
| Partially because there are a zillion of them and you
| simply can't try them all, and partially because learning
| one is expensive and time-consuming, so, unless you
| genuinely enjoy that kind of thing, you kind of want to
| pick one in one shot.
|
| Meaning that, in a slate of options where one of them can
| definitely do something you need, and another one where
| the official story seems to be -\\_(tsu)_/- and the
| examples you've seen seem to indicate that it's at least
| something you need to go out of your way to accomplish,
| there really isn't any injustice in deciding to expend no
| further mental energy on the latter.
|
| That said, if you want spend your own time digging in and
| finding out, be my guest.
| brabel wrote:
| Flutter is not competing with general GUI toolkits, it's
| competing with fully crossplatform toolkits, of which
| there's only a couple of real contenders for real-world
| apps: React Native and maybe Sciter.
|
| Nothing else is production-ready and can run on the web,
| iOS, Android and desktop OSs (Linux, Windows, MacOS).
|
| It's not competing with pure web frameworks. For this
| reason, yes, I think that if you're going to criticize
| it, you absolutely need to know what you're talking
| about... if Flutter claims it can handle accessibility,
| it's on you to prove it can't if you make this argument
| so eloquently on the Internet without actually knowing
| it.
|
| BTW if you know of any other good UI Toolkits that really
| can run anywhere like Flutter, using the same code base,
| please let me know.
| [deleted]
| bryanrasmussen wrote:
| I'm hoping for a revamped EU accessibility act
| https://ec.europa.eu/social/main.jsp?catId=1202 that also
| covers document and office applications, and with GDPR
| sized fines.
| Silhouette wrote:
| We have to be careful not to throw the baby out with the
| bathwater here, though. Obviously accessibility is an
| important issue for both commercial and ethical reasons,
| but if you're talking about writing laws and severe
| penalties for breaking them then you will always have to
| choose what minimum standards you will always require and
| then accept that it might be unreasonable for a software
| developer to go further.
|
| For example, suppose the entire purpose of a certain
| office application is to draw some clever visualisation
| that helps the office workers to understand complex
| relationships in their business data. Maybe that
| presentation style has been chosen based on years of
| experience and saves a lot of time and avoids a lot of
| mistakes compared to a simple text report or table of
| figures. However, maybe it also doesn't work for someone
| whose vision is too limited to usefully see or interact
| with the visualisation.
|
| Perhaps you could present the same data and relationships
| in a different way, a format that would be more amenable
| to sound- or touch-based interfaces for those with
| severely limited or no vision. In reality, that might
| mean writing a second entirely separate application, one
| that might cost more than the original to implement and
| support, for an audience that will usually be very small
| and often empty.
|
| So where should the line be drawn? In an ideal world we
| want to be as inclusive as possible regardless of
| anyone's individual limitations, but we also want to
| provide the most effective presentation possible to those
| who don't have the same limitations. In general doing
| both might be prohibitively expensive, so how do you make
| realistic, ethical decisions in this space, and given
| that every software application is different, how do you
| codify the standards you want to make mandatory for the
| accessibility reasons?
| calderwoodra wrote:
| Accessibility is a first class citizen in flutter.
| https://flutter.dev/docs/development/accessibility-and-
| local...
| zffr wrote:
| I wish that page mentioned how accessibility works for
| Flutter websites. Seems to only mention Android and iOS.
| blackbrokkoli wrote:
| This is making a mockery of accessibility.
|
| It's the equivalent of having a company that actively
| discriminates against everyone not passing a internally
| developed test to check whether you are a "neurotypical"
| and then respond to criticism by pointing at the
| wheelchair ramp you installed on one of your entrances.
|
| If I can't copy paste words from your websites to put
| them into a translator, if I can only use your website
| when I use one of the _two_ corporate-affiliate-selected
| screen readers (not even platform-agnostic ones), when I
| can 't look at your website from anything that does not
| have 4+ cores and a 4G or better connection...saying
| accessiblity is a "first class citizen" or even citizen
| at all is laughable at best.
| threatofrain wrote:
| You're talking about very different issues of
| accessibility, one of which is the financial
| accessibility of client technology and reliable web
| connection.
|
| That is attacked through very different means. For
| example, FB being free and ad funded addresses that
| issue; but this is a business model and not a
| technological standard. Society subsidizing technology is
| another possibility. But these very serious issues of
| access and the solutions to negotiate with them are very
| different from purely technical solutions to access.
| wizzwizz4 wrote:
| HyperText Markup Language is accessible, doesn't require
| a powerful computer, and can be copy-pasted into a
| translator.
|
| If your website is unreadable in view-source:, it's
| probably inaccessible in some way. It's _not hard_ to
| make an accessible website. If it 's hard to make that
| accessible website look the way you want? Tough luck;
| hire a competent web designer, or scale back your
| artistic vision, because you sure ain't sacrificing the
| ability for people to actually _use_ your website for
| some pretty colours, are you now?
| progval wrote:
| That's only for iOS and Android apps. (Desktop?) screen
| readers do not work at all on gallery.flutter.dev,
| because they can't detect text in a canvas.
| bluetwo wrote:
| Due to Section 508, this sounds like it would make Google
| Docs unsuitable for government work.
| NoGravitas wrote:
| They have played us for absolute fools.
| eitland wrote:
| So basically they are recreating the problems from Flash in
| 2021, but now using web standards ;-) ?
|
| Here's me almost hoping that ADA lawyers will have many
| field days with this tech. Edit: since this time there is
| no good excuse for it.
| agumonkey wrote:
| One step up, two step down.
|
| Progress
| eitland wrote:
| "Poor boy shuffle"
| anthropodie wrote:
| Flutter for web is not ready and flutter devs seriously
| should remove those demos because it's ruining reputation
| of Flutter for Android, iOS and Desktop which is absolutely
| a delight to work with. I never developed apps for mobile
| being a backend developer but now I have developed few in
| record time. Flutter for mobile is amazing and it's going
| to change the game.
|
| I am not really sure about Flutter for web though.
| FlyingSnake wrote:
| Add to that, a11y as a 2nd class citizen.
| fmakunbound wrote:
| Wow, that's truly a masterpiece in awful. Are they also
| rendering everything to canvas and then reinventing layouts,
| controls, etc. to get it so laggy?
| dublinben wrote:
| It's Flash websites all over again!
| calderwoodra wrote:
| The demo doesn't have it, but they did fix the selectable
| text issue, just need to wrap your text in a SelectableText
| widget.
| eitland wrote:
| But this means the default is for text to be unselectable.
|
| Which clearly says all I need to know about it :-/
| agumonkey wrote:
| And I thought Gemini was not polished enough. It might be a
| beacon in this potential darkness
| birktj wrote:
| That is absolutely horrible. I am only waiting for the day
| when people start making desktop apps using electron +
| Flutter on the web.
| anthropodie wrote:
| Flutter for web I don't know where it will be in 5 years
| but flutter for desktop is going to eat electron apps for
| sure.
| zelphirkalt wrote:
| Right now probably some people seeing this on HN will be
| thinking about it.
| gentleman11 wrote:
| As a former angularjs user, I'm not keen to learn another
| framework that will get abandoned or replaced in a few years
| brabel wrote:
| I have to agree, it runs really slowly (really struggles on
| scrolling) on my Macbook Air from last year, which normally
| runs heavy JS sites just fine.
|
| EDIT: to be fair, it runs quite smoothly on Safari and Google
| Chrome... only Firefox seems to have trouble with Flutter on
| the Web for some reason.
| WD-42 wrote:
| I didn't believe you at first, but then I gave it a try.
|
| Yes, they actually built an email client from which you
| cannot copy text: https://gallery.flutter.dev/#/reply
| p_j_w wrote:
| That's a demo for a gallery, not an e-mail client.
| uneekname wrote:
| Oh boy, I can't even scroll smoothly through these pages...
| nindalf wrote:
| Or we could take a look at the example Google Doc linked in
| TFA - https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJU
| BFjxS...
|
| Seems like it's fast (on my machine at least), can select
| text and Ctrl+F works. I totally understand the urge to
| complain and doom say, but could we at least stick to the
| example at hand? I'm sure if you went through this doc you'd
| find things to complain about. That would be more relevant to
| the discussion.
| capitainenemo wrote:
| After trying it for a few seconds, noticed X select-to-copy
| was broken, as well as the browser spellcheck feature that
| my daughter relies on heavily in Google Docs (where a text
| area can be spellchecked in french or english depending on
| the active spellcheck).
|
| I didn't spend more than a few seconds on it, but those
| were the features I immediately noticed. This is going to
| be a painful transition for us since she uses both of those
| a great deal with her schoolwork. Since the doc was read-
| only, I couldn't test IME/XCompose - hopefully those work
| at least.
| nindalf wrote:
| And they speak about plugins being broken in TFA. I'm not
| surprised that your daughter's plugin doesn't work today,
| because they announced the change today. Presumably,
| those plugins can be rewritten to adapt to canvas. Just
| give them time.
| capitainenemo wrote:
| Well, I was referring to the built-in browser spellcheck
| and the X windows copy/paste. Both of those probably rely
| more heavily on normal native widgets. Not saying it is
| impossible of course. The X windows copy/paste could be
| done using the invisible text approach firefox uses in
| PDF.js. That would also help with accessibility somewhat.
|
| But I'm not sure how they could integrate with browser
| spellcheck without basically going back to a less
| canvas-y approach. Invisible text areas surely would have
| layout problems aligning with the rendered font. But, I
| guess we'll see. I'm guessing Linux users are not a major
| factor in their decisions though. Firefox users probably
| even less so.
| mihcsab wrote:
| It`s not slow on an old intel i3 laptop and on a motorola one
| phone. I keep seeing these comments about flutter web with
| different examples, they are never slow on my old devices.
| Also you can make the text selectable if you want to.
| ehnto wrote:
| Which is itself a commentary on the immaturity of the
| technology. I certainly wouldn't run it in production if I
| can't trust that all devices of a certain performance level
| can run it. Random performance issues on top-tier hardware
| is going to be a non-starter.
| barbecue_sauce wrote:
| As a user or as a developer?
| mihcsab wrote:
| Developer. Texts aren't selectable on mobile by default
| and they want the web version to act the same.
| malkia wrote:
| there is an option for flutter to compile for both
| canvaskit and html - and then on mobile might select the
| latter (for reasons being smaller) - it might be that (not
| sure).
|
| I have two stupid flutter apps that are canvas only -
| https://malkia.github.io/game_of_life/ and
| https://malkia.github.io/tictactoe (but haven't rebuilt
| them with latest & greatest)
| aardvarkr wrote:
| Just loaded it and it ran awfully. We all have anecdotal
| experiences and it doesn't make yours any less valid than
| mine but it does point out that they don't show much
| besides what you personally experienced.
| mihcsab wrote:
| wdym by awfully? This makes me crazy, the gallery loaded
| instanltly, every item I click loads instantly, no
| problem with scrolling. There is a five second loading
| delay on the phone when the app loads, the items after
| that open just as fast as on the laptop.
|
| The only thing I saw that didn'r run smoothly on my weak
| phone is the flutter plasma demo[0], but it runs without
| any tearing on the laptop.
|
| [0] https://flutterplasma.dev/
| hokumguru wrote:
| That doesn't even load on my iPhone 12
| Mavvie wrote:
| I clicked the "Shrine" app on a 6-core MBP, it took about
| 3 seconds to render the main gallery page and I got an
| entire 4 frames rendered during that time.
| kejjjiee wrote:
| You are a liar. I just tried the page and it is extremely
| slow. Probably another Google employee trying to protect
| his cash cow.
| duxup wrote:
| I've watched a weird mix of "I don't like javascript" that
| usually actually translates to "I don't like what some people
| do with javascript." along side some cheer leading for
| webassembly...
|
| Now those obviously aren't entirely connected arguments, but
| whatever "I don't like what some people do with javascript" is
| supposed to mean, it has nothing to do with javascript. It's
| just what people do with it.
|
| Here we go now, we've got rando blobs you've got no idea what
| they're doing... this is not better.
| bruce343434 wrote:
| Not like you know what that obfuscated minimized javascript
| was doing anyway.
| bushbaba wrote:
| Reminds me of the pain with Java & flash on the web.
|
| What's old is new again eh.
| dheera wrote:
| I don't blame them, considering how damn hard it is to center
| something with CSS. With a canvas you just tell it where to
| display it and to hell with CSS.
| whoopdedo wrote:
| > turns the web back into cable TV.
|
| You mean turns the web back into Flash. Which is somehow worse.
|
| How are they going to make this accessible? I doubt any screen
| readers would be able to recognize text drawn that way.
| vbezhenar wrote:
| You could do that years ago when canvas was introduced. Wasm is
| more readable than obfuscated JS. You can compile C to JS.
| 86J8oyZv wrote:
| This is the endgame of putting JS/programmability (rather than
| just markup) in browsers at all. HTML and CSS are great for
| formatting documents. But, in spite of years of jQueries,
| Angulars, Reacts, Vues, and 10M other frameworks being
| implemented, HTML+CSS+JS is frankly _awful_ for developing
| applications. Business needs have made us push them to be okay
| for enough form entry to collect credit card numbers and do
| billing stuff, but even then every step forward comes with a
| few steps back.
|
| An optimistic take is that this should mean we get better web
| apps and less JS garbage on web pages where we just want to
| read something and there's no justification for having code
| execute when you visit the document. That's the intent of
| WebAssembly and it makes sense.
|
| The reality is that the NYTs of the world will continue to put
| JS garbage all over pages that have no business executing any
| code. But WebAssembly doesn't really have any bearing on that.
| It offers the opportunity to make things better. The
| organizations who seek to profit off the web and make it worse
| for the rest of us will still do so, with or without
| WebAssembly.
| endisneigh wrote:
| I hear this take a lot. Why is HTML + JS awful for developing
| applications?
| easrng wrote:
| It wasn't designed to, it grew bit by bit with new features
| gradually being tacked on, so the APIs are inconsistent
| (For example,NodeList, HTMLCollection, and Array all have
| different methods and naming conventions) and poorly
| designed.
| burlesona wrote:
| Just for what it's worth, "word processors" are a logical
| starting point specifically because the APIs for text
| manipulation in the DOM are abysmal, and every in-browser
| WYSIWYG text editor is a steaming pile of hacks. Some of them
| work well despite this, but, it's a horrible set of code to
| maintain and very, very hard to make a good user experience.
| One of the very hardest things to do well in the browser,
| actually.
|
| Thus I wouldn't necessarily interpret Google Docs making this
| move as the start of an inescapable trend. It may be, or it may
| just be that certain kinds of applications (like Docs and
| Games) can work a lot better by providing their own rendering
| engine.
| kmeisthax wrote:
| Furthermore, actually implementing your own text renderer and
| input engine in WASM is a _different_ horrible nightmare,
| because you 've now forfitted any chance of supporting IMEs
| (e.g. touch keyboards, pinyin/romaji/kanji input, iPadOS
| Scribble), you need to implement your own text selection
| inputs, your text won't show up in the accessibility tree,
| and you can't copy-paste without additional, browser-specific
| tweaks. The only reason to actually do this is if you _can
| 't_ use HTML.
|
| Source: I am a Ruffle developer and have had to do exactly
| this to support text input in old Flash games.
| pmontra wrote:
| > you can't copy-paste without additional, browser-specific
| tweaks
|
| Expect an AI-based OCR browser extension to copy text to
| the system clipboard. Possibly by sending screenshots to
| some centralized service ;-)
| kbenson wrote:
| This would be more funny if it was less prescient.
| tablespoon wrote:
| > Just for what it's worth, "word processors" are a logical
| starting point specifically because the APIs for text
| manipulation in the DOM are abysmal, and every in-browser
| WYSIWYG text editor is a steaming pile of hacks.
|
| If that's the case, it probably would have been better to
| standardize some better APIs.
| slver wrote:
| You assume the developers of Google Docs are the developers
| of Chrome and WHATWG
| bri3d wrote:
| A million times this - having worked in this space, nobody
| wants to do this. I understand the cynicism, but the
| affordances provided by the browser for things like
| accessibility are very painful to give up. This isn't some
| dark pattern attempt to cut out whatever "openness" remains
| on the web, or to convert the browser into a display-
| streaming client for some sinister DRM reason.
|
| In my past job, we rewrote our spreadsheet rendering to use
| canvas and gained massively in simplicity and
| maintainability. And there was no obfuscation angle to it -
| we even shipped source maps! Handling accessibility and text
| input was hard (we ended up adopting a hybrid-DOM model where
| some things like input fields were still native ones, or
| shadowed by native ones), and even then it was still easier
| than dealing with browser rendering.
|
| This is simply a reasonable way to work around the DOM being
| trash. The way to fix this trend would be to reimagine the
| presentation layer of the browser as something other than a
| stack of hacks over hypertext, but so far nobody seems to
| have a good solution.
| vagrantJin wrote:
| The dom isn't trash. Its good enough. We just need to stop
| making it do things it wasn't supposed to. That's why
| things like electron make sense a little bit. Not perfect
| but sensible.
| bri3d wrote:
| The problem is that the escape hatch from document to
| application is completely broken. The DOM is fine for
| documents, but it's completely awful for applications.
| Admittedly, some things on the web that should be
| documents insist on being applications instead, but many
| things on the web aren't documents.
|
| For these things, using the DOM is painful. When the pain
| becomes great enough, the biggest available escape hatch
| is pure native 2D rendering (canvas), which is a
| nightmare for accessibility and affordance to end-users.
| It would be awesome to have something else to escape to.
| agency wrote:
| Isn't Electron rendering to an embedded Chromium and
| therefore the DOM as well?
| slver wrote:
| Yes
| breck wrote:
| I'd agree. I think the DOM is fantastic, *unless* you are
| doing advanced document manipulation, in which case it is
| trash (for that use case only). This is what I'm assuming
| the author meant.
|
| I spent many years working on that sort of thing, a
| decade ago.
| paxys wrote:
| That's the entire point. DOM is meant for structured web
| pages, not web apps. If you want to build complex web
| apps it is better to use your own renderer..which is
| exactly what Google is doing with Docs.
| avereveard wrote:
| We should just port wine to webassembly and be done with
| it
| littlestymaar wrote:
| http://www.boxedwine.org/
| nindalf wrote:
| > We just need to stop making it do things it wasn't
| supposed to
|
| This is a thread about Google Docs. Your suggestion to
| the Docs team is to ... stop? Just shut down their
| product?
| closeparen wrote:
| Just send LibreOffice files as attachments via your
| personal email server, what's the problem?
|
| /s
| dvfjsdhgfv wrote:
| Well, to be fair Libre Office online exists[0]. However,
| I believe EtherCalc[1] is faster.
|
| [0] https://www.libreoffice.org/download/libreoffice-
| online/
|
| [1] https://ethercalc.net/
| NoGravitas wrote:
| Yes? Most of the web really ought to be shut down. It's
| just providing negative utility to society.
|
| Alternatively: return to monke.
| vagrantJin wrote:
| Oh no. They're google. They make a godforsaken browser.
| They can pay people to do nothing more than think about
| code. By all means. They can launch a satellite with css
| if they want.
|
| But the rest of us plebs...
| scotty79 wrote:
| Btw for NASA css is shorthand for Control Stick Steering,
| which is something you did at later stages of landing
| with a space shuttle.
| todd3834 wrote:
| I read this as sometimes you need to use an exit hatch
| like Canvas instead of a bunch of hacks to make a WYSIWYG
| editor strictly with the DOM. Google seemed to come to
| the same realization and that is why they are using
| Canvas
| SavantIdiot wrote:
| People are trying to make DOM be a WYSWIG text editor.
| You're point is dead on.
|
| The response is to write an opaque, vendor-specific
| "DOM". Which is the complete opposite of what HTML was
| supposed to be. But the browser is now a platform and not
| a browser, so the metaphors are horribly mixed to the
| point where I'm not even sure what a DOM is supposed to
| be anymore.
| wizzwizz4 wrote:
| The DOM was _always_ a WYSIWYG editor - albeit, for HTML,
| not text. Though, back in the day, HTML was a subset of
| text with image and table support; none of this fancy
| `line-height: 1.5em;`...
|
| I wish the web had evolved in a more documenty way.
| SavantIdiot wrote:
| Hmmm... maybe I should have chosen a different acronym.
|
| What you expected to see isn't alwasy what you got.
|
| WYETSIAWYG
|
| Rendering across browsers and operating systems was a
| trainwreck until maybe 5 years ago (over a decade of
| polyfill is finally gone). And even with an ecosystem
| like ElectronJS + Bootstrap, Win10 MacOS and Linux all
| look slightly different.
|
| So yes and no to "DOM was always...", but more "No."
| breck wrote:
| > The way to fix this trend would be to reimagine the
| presentation layer of the browser as something other than a
| stack of hacks over hypertext, but so far nobody seems to
| have a good solution.
|
| About a decade ago I had the start of a Eureka moment on
| how to do this (back then -- https://medium.com/space-
| net/spacenet-51aca95d49a2, nowadays
| https://treenotation.org/). It seems to me we've missed a
| sort of fundamental universal notation of the universe,
| which you can think of as "two-dimensional binary". I
| predict we will soon see a Cambrian Explosion of new
| formats and languages that are simpler and more
| interoperable with each other, and some will have the
| opportunity to build new great languages for rendering
| stacks.
| lambda wrote:
| Hey, nice! I have a notes file experimenting with a
| similar tree-style minimalist data notation; it's
| definitely an area that needs more exploration.
|
| I like what you've done with it, I'll need to take a
| closer look.
|
| While I was thinking about it, I also decided to take a
| look into prior art, which took me all the way back to
| Landin's "The Next 700 Programming Languages" from 1966
| which introduced the hypothetical language ISWIM, which
| was the first to introduce indentation based syntax and
| inspired the ML and Haskell family of languages
| (https://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf)
|
| It wasn't exactly what I was looking for, but it's
| fascinating to see how long we've been thinking about
| these kinds of issues.
| breck wrote:
| Yes, and surprisingly there are not too many that use any
| indentation based syntax (about 1 in 50). However, of the
| ones that do (abc, aldor, boo, buddyscript, cobra,
| coffeescript, csl, curry, elixir, f-sharp, genie, haml,
| haskell, inform, iswim, literate-coffeescript,
| livescript, madcap-vi, madcap, makefile, markdown,
| miranda, nemerle, net-format, nim, occam, org, promal,
| python, restructuredtext, sass, scss, spin, stylus, xl-
| programming-language, yaml) there are some real gems.
|
| Some more interesting read's in this space:
|
| 2003 - Egil Moller's I-expressions -
| https://srfi.schemers.org/srfi-49/srfi-49.html
|
| 1984 - Alan Kay's 3-D spreadsheet - http://worrydream.com
| /refs/Kay%20-%20Computer%20Software%20-...
|
| 1972 - Mark Wells' A Review of Two-Dimensional
| Programming Languages - http://sci-
| hub.cc/10.1145/942576.807009
| lambda wrote:
| Cool! Thanks for some more reading and inspiration.
|
| Here's what I have in my notes buffer; I hadn't gotten
| much further than this. Ssn:
| /([0-9]{9})|([0-9]{3})-([0-9]{2})-([0-9]{4})/\1\2\3/
| People: Table first: String last:
| String dob: Date ssn: SSN
| Csv headings: True load people.csv
| as: People select first last dob
| filter dob.age > 21
|
| Well, I had some discussion, alternate forms of the
| syntax, links to prior art, etc, but not much else worth
| sharing.
|
| Will have to add your TreeNotation and Ohayo to that
| list, as well as these other links you've shared.
| breck wrote:
| Very nice! The nice thing about these kinds of notations
| is that they last. Simplicity is timeless. I can
| immediately grok exactly what you are doing here. :)
| ImprobableTruth wrote:
| How is this not just S-expressions with indentation
| instead of parentheses? What makes it different from say
| Sweet Expressions?
| breck wrote:
| Common question. You cannot do column and matrix
| operations natively against S-Expressions (You need to
| parse the whole thing). This turns out to be very
| important and useful. S-Expressions need to be
| transversed in 1-D linear order.
|
| When you two-dimensionalize S-Expressions and remove the
| parens, you get Tree Notation.
| jamiek88 wrote:
| Wow that tree notation looks super interesting!
|
| Bookmarked for a later in-depth read but my interest is
| piqued!
| mixmastamyk wrote:
| Once the trail has been blazed by pioneers, expect a gold
| rush.
|
| What would a good API look like, I wonder?
| jcuenod wrote:
| I had this instinct as well but I think this is about
| _rendering_ , not necessarily editing. The document link is
| not to something editable. Granted, perhaps these will merge.
| austincheney wrote:
| Whether or not it's a trend will come down only to the
| commonality of skills in the marketplace for a given rate of
| pay.
| nailer wrote:
| > The APIs for text manipulation in the DOM are abysmal
|
| I develop an NLP labelling interface (which is similarly
| document-focused) in JS all day and can attest to this.
|
| Here's some specific examples:
|
| - To work out where some text is being being laid out, eg to
| display some UI around it, the Selection/Range/Rect APIs will
| help but Rects are always viewport-relative, so you'll need
| to convert them to element-relative to position your UI,
| which sucks.
|
| - Firefox supports multiple DOM Ranges per Selection (ie
| allows non continguous text selection), but nearly all other
| browsers support a single range.
|
| - You can't truncate text across multiple lines (the CSS line
| clamp spec is an experimental fix)
|
| - If you want to pop up an interface while some text is
| selected, you'll need to capture and reimplement selection
| because as soon as another item is focused the selection will
| no longer display.
|
| If you're into JS and building anything document related,
| I've written a bunch about the some of the issues at
| https://humanloop.com/blog/how-to-build-an-ml-labelling-
| inte...
| baybal2 wrote:
| > every in-browser WYSIWYG text editor is a steaming pile of
| hacks.
|
| Xforms 2.0, and other opportunities to have rich text in
| browser not suck were there for _the browser maker_ to take
| in the last 15 years.
|
| Instead they tried almost everything instead of choosing the
| most obvious solution, and fixing it.
| intpx wrote:
| teach markdown in schools. who needs word processors anyway?
| need something fancier than headings, lists, block-quotes
| etc? learn LaTeX. Text rendering can be fantastic in the
| browser. I'm half joking, but I think the world would be a
| better place if folks had fewer, more precise ways of making
| words look the way they want
| jamiek88 wrote:
| Shouldn't software serve people rather than the other way
| around?
|
| This comes across as a 'you're holding it wrong' type
| argument.
| nindalf wrote:
| I love markdown, all my blog posts, TILs, book notes are in
| it. Even my presentations are written in markdown. But this
| comment is so obtuse and user hostile. Millions of people
| know how to use word processors. Let's not take that away
| from them or even imply that they're doing it wrong.
| They're fine. Software can always be improved, like the
| Docs team is attempting here. But we can't overnight tell
| people that their skills are obsolete because some
| developers somewhere like Markdown and Latex.
| discreteevent wrote:
| To me this is like saying that because we are no longer
| able to make good bicycles people should walk everywhere.
| spankalee wrote:
| I don't like this change, but it's not being done to "control
| to web".
| simias wrote:
| Google de-facto controls the browser but it doesn't control the
| OS, its motivation is absolutely transparent here: make the
| browser the OS. It even auto-updates transparently by default
| so Google can push its code almost live to its users.
|
| As someone who always fought against the bloat of the web and
| reimplementing everything on top of HTTP and JS I feel a bit
| like an anti-atomic weapon activist who, upon seeing the
| mushroom cloud in the distance, can utter a final "see, I told
| you so!" before being demapped by a G-shapped shockwave.
|
| The open web was fun while it lasted, but ads are more
| important.
| tmcw wrote:
| Agree on all points but
|
| > Font rendering and layout can all easily be accomplished by
| embedding libraries like freetype.
|
| Whoooah no. This stuff is way, way, way harder than dropping in
| freetype.
| icedchai wrote:
| We've come full circle. This could've been done decades ago,
| with Java applets.
| acituan wrote:
| > I thought it was obvious[1][2] that the end game for those
| that want to control the web is sending opaque binary blobs of
| code that only use the browser for the canvas tag's
| framebuffer.
|
| Google is also a search company, the product from which the
| majority of their ad revenue comes. Blobifying the web
| indiscriminately breaks search, so it is not in their interest
| to push this to reap some x% revenue loss from ad blockers.
|
| Incidentally, or not, a traditional wordprocessor itself is not
| an interesting search result and makes a perfect candidate for
| this type of rendering. There already exists compatibility
| layers with search for published documents. So absolutely
| nothing is lost for anyone, and I think it is an
| overgeneralization to take this as a sign of obvious doom to
| come.
| shadowgovt wrote:
| Is ad blocking Google Docs really a concern though?
| slater wrote:
| i think the worry is more about the next steps, not google
| docs per se
| Miraste wrote:
| No, but how much longer do you think it will take them to
| bring this to Google and YouTube and AdWords?
| yhoneycomb wrote:
| Honestly if they did that I think I'd strongly consider
| paid alternatives to YouTube. Most of the channels I like
| are on curiosity stream/nebula. I've never subscribed
| because I don't feel like I have a reason to. But that
| would definitely give me a reason.
| google234123 wrote:
| Or you could just pay for Youtube which removed ads.
| twistedpair wrote:
| > I didn't expect the first move towards canvas-only rendering
| to be traditional wordprocessors.
|
| Google Maps moved to Canvas/WebGL years ago. It's not the first
| move.
| baybal2 wrote:
| You are completely correct. The end goal of people who
| introduced WASM was an ActiveX 2.0.
| eagsalazar2 wrote:
| Man, this is a very dramatic interpretation of their intent.
| Docs doesn't even have ads. They _actually do_ have issues
| rendering consistently across browsers (I ran into this just
| like 2 days ago where something that had been carefully laid
| out on Chrome looked different in Safari).
|
| My bigger criticism of this is that I imagine it was a very
| large refactor at a time when docs has barely evolved for
| _years_ and still remains far behind desktop counterparts in
| many ways (although still slowly taking over because of vastly
| superior online collaboration).
| addison-lee wrote:
| Ahh yes because Google, an ad company, will _never_ implement
| this where they do have ads.
| eagsalazar2 wrote:
| I never said they would never do this. I just said it was
| over dramatic and making big assumptions that _this_ action
| by google was part of some nefarious plot to turn the
| internet back into corporate tv, especially given that
| there are very good reasons in this case to make this
| change without those assumptions.
| crb002 wrote:
| JS minification is old hat, and welcome to shrink binaries.
|
| Google for security reasons should probably release the source.
| Most security types welcome web-assembly over JS since there
| will be more Rust etc.
| sgt wrote:
| It's a bad thing in terms of openness but a good thing in terms
| of performance and making web applications more like real
| desktop applications. A lot of DOM work is a nightmare, so I
| sort of welcome to the Canvas based approach.
| dahfizz wrote:
| > making web applications more like real desktop
| applications.
|
| Web developers are the only people who actually want this.
| Its not something that would benefit society / users.
| gentleman11 wrote:
| "As a user, I want my apps developers to have a good
| experience" - a scrum task
| tengbretson wrote:
| We're just one more concession away from getting the
| performance we had 20 years ago with native applications.
|
| Edit:
|
| The path we're on just seems so obvious I kind of just want
| to skip ahead and get it over with.
|
| - Developers and content publishers love the ergonomics and
| control of just shipping WASM binaries that paint to a canvas
| and it becomes the de facto standard.
|
| - After 2-3 years of everyone's computer being used to
| surreptitiously mine crypto everywhere they go we re-learn
| the lessons of Java applets.
|
| - In comes browsers that require signed WASM binaries _for
| your protection_.
|
| The world is an app store. Curtains.
| goalieca wrote:
| Careful here, these are more like thin clients with high
| network latencies.
| EvanAnderson wrote:
| There's local processing and peripherals. I think you're
| looking for the term "smart terminals". Something like
| these for the "modern era":
| https://www.curiousmarc.com/computing/hp-264x-terminals
| tshaddox wrote:
| Browsers still support arcane HMTL features from decades
| ago (and thus can display most web sites from decades ago).
| Other than things that were already decidedly not part of
| web standards (like Flash), I'm aware of very little if any
| backwards-incompatible changes made by popular browsers. So
| I'm having trouble seeing this slippery slope you're
| describing.
| sgt wrote:
| Funny. And then at some point someone will rediscover
| native apps.
| OscarTheGrinch wrote:
| I, for one, welcome our new canvas based overlords.
| switch007 wrote:
| > but a good thing in terms of performance
|
| Performance is a poison chalice. Many, many people were won
| over by Chrome's blistering speed. Now they won't have proper
| ad blocking.
| Sunspark wrote:
| I offer Firefox as the solution.
| switch007 wrote:
| Absolutely, Quantum was a big leap. But many people are
| devoted to chrome and so are developers. Many sites are
| still worse on Firefox than Chrome.
| Sunspark wrote:
| Ah, but this is in the eye of the beholder. For example,
| Firefox has an option to allow one to deselect the option
| "Allow pages to choose their own fonts, instead of your
| selections above". I usually browse the web in aliased
| legible Verdana as a result. It also allows you to choose
| the colours of the background, links, etc.
|
| Chromium browsers do not allow you this choice. There,
| the philosophy seems to be that the web is a designer-
| driven layout medium and that the viewer should not have
| accessibility choices.
|
| Btw, some of the "sites worse", if you're referring to
| Google, that's them just breaking things intentionally.
| You can sometimes work around it by specifying a
| different useragent and then things are fast again until
| they change things again.
|
| As a browser, Firefox is standards compliant. I agree
| there are many applications that use a web interface as
| the GUI and a bunch were coded for IE6 or IE6 with
| ActiveX and don't display well (or at all) in Chrome. It
| really depends, but the problem isn't that Firefox
| follows standards, but that the developers did not follow
| standards.
| dukeofdoom wrote:
| Couldn't agree more. Developer Lives Matter. Lifetimes have
| been lost to simple things like trying to get a modal popup
| to work.
| pleasedonot wrote:
| Please don't riff on the Black Lives Matter movement with
| things that are more trivial than civil rights. I doubt
| your intentions were to delegitimize the movement, but
| still.
| zozbot234 wrote:
| Isn't that what |