161–170 of 228 posts
Earlier quoted context omitted.
I've seen on perm Jira at large companies get that slow. I'm not sure if it's the plugins or just the company being stingy on hardware.
I can easily believe either, but I am still curious what the failure mode(s) is (/are).
Large numbers of custom workflows and rules can do it, too, but most have been the first.
> For the uninitiated, Linear is a project management tool that feels impossibly fast. Click an issue, it opens instantly. Update a status and watch in a second browser, it updates almost as fast as the source. No loading states, no page refreshes - just instant, interactions. How garbage the web has become for a low-latency click action being qualified as "impossibly fast". This is ridiculous.
If anything it is slow because it is a pain to navigate. I have browser bookmarks for my most frequented pages.
Earlier quoted context omitted.
Hacker News comment sections are the only part of the internet that still feel "impossibly fast" to me. Even on Android, thousands of comments can scroll as fast as the OS permits, and the DOM is so simple that I've reopened day-old tabs to discover the page is still loaded. Even projects like Mastodon and Lemmy, which aren't beholden to modern web standards, have shifted to significant client-side scripting that lac…
The modern webbroswer trick of "you haven't looked at this tab in an hour, so we killed/unloaded it" is infuriating.
> For the uninitiated, Linear is a project management tool that feels impossibly fast. Click an issue, it opens instantly. Update a status and watch in a second browser, it updates almost as fast as the source. No loading states, no page refreshes - just instant, interactions. How garbage the web has become for a low-latency click action being qualified as "impossibly fast". This is ridiculous.
Back in 2018 I worked for a client that required we used Jira. It was so slow that the project manager set everything up in Excel during our planning meetings. After the meeting she would manually transfer it to Jira. She spent most of her time doing this. Each click in the interface took multiple seconds to respond, so it was impossible to get into a flow.
While I see strict safety/reliability/maintainability concerns as a net positive for the ecosystem, I also find that we are dragged down by deprecated concepts at every step of our way.
There's an ever-growing disconnect. On one side we have what hardware offers ways of achieving top performance, be it specialized instruction sets or a completely different type of a chip, such as TPUs and the like. On the other side live the denizens of the peak of software architecture, to whom all of it sounds like wizard talk. Time and time again, what is lauded as convention over configuration, ironically becomes a maintenance nightmare that it tries to solve as these conventions come with configurations for systems that do not actually exist. All the while, these conventions breed an incompetent generation of people who are not capable of understanding underlying contracts and constraints within systems, myself included. It became clear that, for example, there isn't much sense to learn a sql engine's specifics when your job forces you to use Hibernate that puts a lot of intellectual strain into following OOP, a movement characterized by deliberately departing away from performance, in favor of being more intuitive, at least in theory.
As limited as my years of experience are, i can't help but feel complacent in the status quo, as long as I don't take deliberate actions to continuously deepen my knowledge and working on my social skills to gain whatever agency and proficiency that I can get my hands on
Earlier quoted context omitted.
If you could simply drop in a library to any of your existing SSR apps that: - is 50kb (gzipped) - requires no further changes required from you (either now or in the future) - enables offline/low bandwidth use of your app with automatic state syncing and zero UX degradation would you do it? The problem I see with SSR evangelism is that it assumes that compromising that one use case (offline/low bandwidth use of the…
> - enables offline/low bandwidth use of your app with automatic state syncing and zero UX degradation > would you do it? No, because the "automatic state syncing and zero UX degradation" is a "draw the rest of the owl" exercise wherein the specific implementation details are omitted. Everything is domain specific when it comes to sync-based latency hiding techniques. SSR is domain agnostic. > low bandwidth requireme…
You're stating that networks and latency will only improve, and that this is a reason to prefer SSR.
You're also stating that 50kb feels too heavy.
But at 8kb of SSR'd plaintext, you're ~6 page loads away from breaking even with the 50kb of content that will be cached locally, and you yourself are arguing that the transport for that 50kb is only getting better.
Basically: you're arguing it's not a problem to duplicate all the data for the layout on every page load because networks are good and getting better. But also arguing that the network isn't good enough to load a local-first layout engine once, even at low multiples of your page size.
So which is it?
---
Entirely separate of the "rest of the owl" argument, with which I agree.
Earlier quoted context omitted.
A web request to a data center even with a very fast backend server will struggle to beat 8ms (120hz display) or even 16ms (60hz display), the budget for next frame painting a navigation. You need to have the data local to the device and ideally already in memory to hit 8ms navigation.
This is not the point, or other numbers matter more, then yours. In 2005 we wrote entire games for browsers without any frontend framework (jQuery wasn't invented yet) and managed to generate responses in under 80 ms in PHP. Most users had their first bytes in 200 ms and it felt instant to them, because browsers are incredibly fast, when treated right. So the Internet was indeed much faster then, as opposed to now. J…
Earlier quoted context omitted.
Hacker News comment sections are the only part of the internet that still feel "impossibly fast" to me. Even on Android, thousands of comments can scroll as fast as the OS permits, and the DOM is so simple that I've reopened day-old tabs to discover the page is still loaded. Even projects like Mastodon and Lemmy, which aren't beholden to modern web standards, have shifted to significant client-side scripting that lac…
The modern webbroswer trick of "you haven't looked at this tab in an hour, so we killed/unloaded it" is infuriating.
Earlier quoted context omitted.
UI performance is "a weird thing to index on"?
Yes? If that's the primary selling point for a project manager versus being just a really damn good project manager with good visibility? I've never used a project manager and thought to myself "I want to switch because this is too slow". Even Jira. But I have thought to myself "It's too difficult to build a good workflow with this tool" or "It's too much work to surface good visibility". This is not a first-person s…
That said, I really enjoy Linear (it reminds me a lot of buganizer at Google). The speed isn't something I notice much at all, it's more the workflow/features/feel.
> For the uninitiated, Linear is a project management tool that feels impossibly fast. Click an issue, it opens instantly. Update a status and watch in a second browser, it updates almost as fast as the source. No loading states, no page refreshes - just instant, interactions. How garbage the web has become for a low-latency click action being qualified as "impossibly fast". This is ridiculous.
I also winced at "impossibly fast" and realize that it must refer to some technical perspective that is lost on most users. I'm not a front end dev, I use linear, I'd say I didn't notice speed, it seems to work about the same as any other web app. I don't doubt it's got cool optimizations, but I think they're lost on most people that use it. (I don't mean to say optimization isn't cool)
We almost forgot that's the point. Speed is good design, the absence of something being in the way. You notice a janky cross platform app, bad electron implementation, or SharePoint, because of how much speed has been taken away instead of how much has been preserved.
It's not the whole of good design though, just a pretty fundamental part.
Sports cars can go fast even though they totally don't need to, their owners aren't necessarily taking them to the track, but if they step on it, they go, it's power.
If you want to work on Linear's sync infrastructure or product – we're hiring. The day-to-day DX is incredible.