4 ms·
> The recent evolution of JS frameworks has been really nice. Performance is basically getting identical to desktop. It's getting much much better but performa
by BeefWellington 4y ago
> The recent evolution of JS frameworks has been really nice. Performance is basically getting identical to desktop.
It's getting much much better but performance is only "identical to desktop" if you ignore anything about its resource usage or speed increases in processors over the past decades.
> For people not following JS these might all seem like constantly reinventing past lessons, but there is a logical evolution happening here towards desktop-style performance and interactivity on the web. Or pure server-side performance but with full JS interactivity.
For people following JS these are examples of constantly relearning past lessons.
I'm not sure how anyone could reliably expect 100+ms round-trip time (on a good connection) to offer the same experience as something local but I think what it actually means is that the people writing JS-based software haven't actually used a native desktop app for years and have done mostly web-based things.
You could be forgiven it since HTML/JS as a user interface design language appears to have taken over completely, to the point where even the most popular code editors are now web browser-based.
Seriously though, go load up any natively compiled app on your OS of choice and compare the speed of it doing any given task to what you get out of web-based versions, electron versions, etc. There isn't a comparison.
My griping aside, I recognize JS as a language is here to stay and it's important to stay on top of its developments and improvements.
- acover 4y agoI find myself hating visual studios lag but okay with visual studio code. Maybe visual studio isn't getting attention but it's painful to use.
- BeefWellington 4y agoAgreed. Visual Studio is awful. I actually just updated a bunch of old Java code in Eclipse. It is simply faster than VSCode at everything -- syntax highlighting (noticeable delay in VSCode on a 1000+ line Java class), switching between files, loading files, etc. I only updated and used Eclipse because VSCode was being noticeably slow. That was in a bare J2EE Eclipse instance, and didn't have any of dozens of plugins running that I typically would have back in my enterprise-y Java dev days. Visual Studio seems to have gone the "kitchen sink" route. JetBrains' IDEs typically wind up crammed with plugins from what I've seen. I wonder how much that screws with people's perceptions.
- dmix 4y ago> Seriously though, go load up any natively compiled app on your OS of choice and compare the speed of it doing any given task to what you get out of web-based versions, electron versions, etc. There isn't a comparison. I highly recommend trying out Linear.app, it's as fast as any desktop app I use. Replicache made a clone demo https://repliear.herokuapp.com/ https://repliear.herokuapp.com/ the production linear app is even faster But if you're comparing the current era of React/electron apps (or even most Next.js apps) of course you're not going to see Desktop-type speeds yet... these new developments are closing the gap but it's only just starting to be adopted.
- BeefWellington 4y agoThat demo literally shows a brief "Loading..." screen for the first open issue, which was pretty much my point. I'm not sure what other desktop apps you use but for something as simple as viewing a single database record I've not seen loading screens since about 2000 on any native apps.
- dmix 4y ago> That demo literally shows a brief "Loading..." screen for the first open issue, which was pretty much my point. Yes when you open a desktop app that has to load the data from the internet it has to load first... You can't get around that fact unless you have zero data remote? Which defeats the purpose of a collaborative B2B app. After that first load, strictly the first time you open the app, you never see another loading screen. Saying desktop apps don't do the same thing is disingenuous. And as I mentioned, that's a simple demo for a new framework in beta hosted on a free Heroku instance. Linear's production app is even faster. Especially when you download the desktop version.
- BeefWellington 4y ago> Yes when you open a desktop app that has to load the data from the internet it has to load first... You can't get around that fact unless you have zero data remote? Which defeats the purpose of a collaborative B2B app. This could be true for data being loaded from the Internet, yes, though it assumes the premise that JS based applications will still do this faster. However, collaborative B2B apps existed before the JS craze and worked perfectly well (and faster) without it. They also don't strictly need to be querying data from the broader 'net but can be doing things like talking to a local database server, asynchronously retrieved local cache, etc. > After that first load, strictly the first time you open the app, you never see another loading screen. That's actually only half true. The "Loading" screen does indeed not popup. Instead, you just get broken empty UI until it eventually loads the record. What I observed was scrolling to the end and selecting any of the final few records there was a substantial and noticeable second-plus delay loading the record data into the view. Steps are: Load page -> scroll to very end using scrollbar -> pick last record. For fun, I profiled it. According to the profiler it takes 3.8s for it to successfully load and process the record, of which 2.1s is just in one promise. It's also a demo site and could easily cheat this (but to their credit appears as though they are not quite doing so at the expense of heavier page loads). It's not a compelling example of what you're talking about.
- tln 4y ago> Seriously though, go load up any natively compiled app on your OS of choice and compare the speed of it doing any given task to what you get out of web-based versions, electron versions, etc. There isn't a comparison. My experience is a bit different... Google Docs loads faster than Numbers Figma loads faster than Illustrator VS code loads faster than Xcode (not a fair comparison) Quicknote.io loads faster than SimpleNote (which is blazing fast!) Google Meet loads faster than Zoom For VS code, it creates a whole new chromium process, but for websites like quicknote.io, do you count the browser base usage and loading time? Or just the incremental time to load up in a new tab?
- pwinnski 4y agoThe initial claim wasn't about load-time, it was about "doing any given task," and I frequently encounter delays when actually using Google Doc, delays I never experience with compiled text editors or spreadsheets. All that and TextEdit still starts up much more quickly than Google Docs for me. Your mileage may vary, of course.
- brigandish 4y agoSlight nitpick, the equivalent for Google Docs would be Pages, and the equivalent for Numbers would Google Sheets.
- BeefWellington 4y ago"Loads" is an interesting take to consider when looking at application performance. Simply starting the application is largely irrelevant. What's the experience using it? What features do you have access to? Those are the things that matter. If we wanted to take that point though, even if we assume the browser-based stuff gets the startup time for free (since most people have a browser open most of the time I'd wager), what's the process of loading a local file on my system like? Docs or Sheets might "load" faster than LibreOffice but what's the time-to-use look like? Do I have to sync files somewhere Docs/Sheets can have access to it? What's the "[double-]click to load local file" part of the equation here? What about the actual use of the application? Is there the instant responsiveness to open color selection dialogs in the case of Illustrator? How useable is it from a plugin perspective? Are we actually comparing comparable applications? There's lots to ask there. This is why I don't think startup time actually matters. What matters is what the experience of using something like Figma is over Illustrator, Sheets vs Numbers, XCode vs VSCode, etc. The example I gave of two local apps is a relevant and more directly comparable one. Eclipse does everything just faster than VSCode. VSCode is my typical "general editor of choice" for a variety of things but the slowness of reading a few large Java packages led me to get a current version of Eclipse and give it a go. Seriously, go try it out on any substantially large Java project. There's measurable lag in syntax highlighting upon opening a file, switching between files, performing some basic "find references" type tasks, and so on. In Eclipse it's just fast. Maybe everything will eventually be JS-based and it will become a meaningless comparison. I don't buy that we're there yet.
- yamtaddle 4y ago> It's getting much much better but performance is only "identical to desktop" if you ignore anything about its resource usage or speed increases in processors over the past decades. The high power use is what kills me. That and input lag. Fix those and I'd give way fewer shits that an Electron app eats 10x the memory that's remotely justifiable by what it's doing, and more like 20-100x what a well-made desktop program would for the same purpose. [EDIT] Yeah, I know, high power use and input lag are in part because Webtech disrespects things like system memory, so in practice I'm not going to see one fixed without the other.
- woojoo666 4y agoThe web apps that take 100+ms round trip are ones that have to download the entire page. Downloading a new desktop app takes even longer. If you use a local-first webapp that is cached on your desktop, that's a fairer comparison
- BeefWellington 4y agoThis makes no sense. Downloading a web browser takes even longer. It's an insane comparison to draw in the context of the experience of actually using an application. Nobody cares about startup time when it's a task you do once a day compared to using the application which might be constant throughout the day. How often are people booting up their IDEs?
- woojoo666 4y agoIt's equally unfair to compare the round-trip load of an application that people expect to download on-demand, versus an application that is already installed on the client