621–630 of 953 posts
Earlier quoted context omitted.
I just in the past month upgraded my main work laptop from 16 GB from 40 GB (8 GB soldered + 32 GB SODIMM). So your point is granted, but on the other hand, DDR4 prices have collapsed ~50% from 2018 (I couldn't believe it either, given all of the other semiconductor issues).
nice, but you are lucky to have laptop that have extra RAM slot. not everyone can do that.
Earlier quoted context omitted.
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.
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…
Earlier quoted context omitted.
I believe this 100%. After using google office for years (just because it's free and cloud-based), I recently tried MS Word and Excel recently at work. The different was mind-blowing. I forgot just how functional and straightforward MS Office is compared to the clunky, barebones google options. If I wanted a desktop-first, cloud-backed solution, what would be the most future-proof and durable? Can I use Open Office a…
I also prefer desktop-first, cloud-backed solutions, but I have quite the opposite experience. Working with MS Office has been a pain and I've been a happy Google Docs user for about 10 years. My wife who isn't an especially technical person also finds Google Docs quite a lot more intuitive and laments when she has to use MS Office products for work (she is a consultant for Microsoft including their 365 line of busin…
Earlier quoted context omitted.
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.
but i think screenshots are not considered accessible
Earlier quoted context omitted.
Well... sort of. For specific apps, or parts of apps, yes. Doing less is how you make things faster, highly agreed. And sometimes canvas allows you to do that, and then your app is much faster. The problem is that in many cases, moving to canvas eventually turns into having a UI framework that renders to canvas, which turns into a layer of abstractions that handle keyboard and mouse events for you, including stuff li…
Are you sure you meant Figma? It's an image editor, not a framework.
Figma is not only not a framework, it's also not completely canvas based, or at least wasn't last time I checked.
Earlier quoted context omitted.
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.
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-...
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…
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…
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.
Earlier quoted context omitted.
Microsoft Word, Pages and Open Office don't seem to be bottlenecked by rendering performance like Google Docs. Perhaps the browser is the wrong platform for document editing.
I believe this 100%. After using google office for years (just because it's free and cloud-based), I recently tried MS Word and Excel recently at work. The different was mind-blowing. I forgot just how functional and straightforward MS Office is compared to the clunky, barebones google options. If I wanted a desktop-first, cloud-backed solution, what would be the most future-proof and durable? Can I use Open Office a…
(That said, I'm really excited about the recent changes Microsoft is making for Excel, with LET and LAMBDA, and I look forward to trying it out again in the future. Maybe this is the thing that finally gets me to switch! I've also enjoyed doing some more ~fancy~ graphic design in Pages on Mac, but overall the clunkiness was just so frustrating that I can't in good faith recommend it to anyone)
Earlier quoted context omitted.
Performance of DOM based rendering is very problematic and not unified across browser implementations. Canvas rendering will likely increase the performance of Google Docs, and make the UX more unified across platforms. Google Docs is really an application built on the web platform. HTML DOM rendering was never intended to give developers the control they need to build fully featured high performant applications, we…
I think this is the real reason for the change as well. A few years ago Visual Studio Code underwent a similar change where rendering the terminal moved from using DOM to canvas. I never noticed a huge difference between the two methods but I imagine using canvas gave them a lot more flexibility in addition to being more performant.
It's the only thing about VS Code I would change: have it use native APIs for text rendering so we can get the same framerate as native apps.
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 D…
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?