Is it possible that there's also just more software in different domains being written, hence making it more difficult to keep track of everything that is going on?
I understand that. But that was the case with popups as well. Remember when we needed popup blockers? Straight up removing the functionality is of course a drastic measure, so realistically I could see something like what we did with popups, where the browser first asks you if you'd like to allow alerts on the page, and only allow them to be shown if the user explicitly chooses so.
Perhaps a controversial take, but I would be happy to see alerts removed altogether. I'm sure someone can point to a few legitimate uses of them, but in the grand scheme of things, they're usually terrible for user experience, as they block everything else (which is the point). This is also often used as a way to scam less computer literate people with "microsort security" alerts, that keep getting reopened when closed.
I get that there are lots of JS tutorials out there that use it as a way to show simple interactions, but that's a very weak argument for keeping an API that is potentially harmful.
This is quite interesting, I've been considering making a todo app to help with ADHD. I've definitely experienced many of the same issues mentioned by the author, and even some apps labelled specifically for ADHD seem to fail on many of these issues.
If it's a chore to add a task, I won't add them. If it's a chore to go through tasks, I won't come back to the app.
It's also a really important point about some tasks being inherently different in scale to others, and the importance of separating them.
I feel like many todo apps focus too much on being a "todo app" rather than actually trying to get you to get things done. All this tagging and categorizing and such are features that take effort and time for me to manage, which in turn help make those apps into huge graveyards of stuff to do, which in turn make me want to not open them ever again.
IMO a todo apps that is blank most of the time is the best. Meaning, you haven't got anything you need to do. Help me keep track of small tasks, and repeating tasks, and let me either complete them or postpone them. If there's something I've postponed too many times, just delete it. It shoudn't become a notes app, it's about getting stuff done.
The the main problem is the fact that this audit happens with no context, and the audit results offer no information about the context an issue applies to either. Every issue should have a clear explanation about why and where it's an issue, and be tagged. Then we'd just need a way to hint npm what context a package will be used in, similarly to what we already do for devDependencies.
Also going through an audit result in a CLI isn't really the best experience. I wish I could just click a link and open up the report in a browser to drill down into issues.
Seeing a lot of distain for JavaScript in here, but not enough examples of what's actually wrong with it. It's fine to criticize the language, there certainly are issues with it, but I'd like to see some actual constructive comments and examples from other languages where it's done better.
> There are already many steps taken to improve DOM performance over these years. However, DOM is designed for documents. The performance can never be good enough when it is abused for non-document usage.
JavaScript was originally designed for simple tweaks, but we've significantly expanded and improved the language over the years to adjust it for what it's used for *today*. I don't see why DOM is special. Sure it was designed to handle small, unchanging documents, but it's used for much more now, just the same as JavaScript. Also it's worth noting we're talking about Google Docs here, so it looks like DOM fails even at its intended use-case (I'm saying this *mostly* jokingly).
> Because other browser engines are unlikely to adopt these APIs just so that Google Docs can have better performance. Not to mention that these new APIs will take years to be present in every user's devices.
We wouldn't have fetch, canvas, async/await, PWAs, websockets, etc. if those things had to be available immediately and/or be guaranteed to be adopted. I'd rather it take years to get improvements, but eventually have them, than not doing anything and still be talking about how bad X, Y, or Z is 10 more years from now.
I'll take FLIP animations as a specific example. If I want to have a box animate from one part of the page to another (where it's position in the DOM hierarchy changes), we're having to do all kinds of crazy gymnastics around when you read the DOM, when you write to it, how do you update it, etc. And even still, you're unable to do this without using JavaScript animations (if your box contains content and it happens to change size, we'd have to do a reverse scale animation on the content).
This is stuff that's trivial in iOS and Android, and commonly used. In the web land, we're stuck doing this poorly both from a development point of view, and with bad performance, resulting in poor end user experience.
The FLIP hack has been talked about for 6+ years [1], and yet here we still are, unable to simply move and animate a box from one place in the tree to another. Want nice drag and drop interactions? Good luck. Limited animations, or slow, and often both.
Why are we getting articles from Google about how it's bad to change the size of something on the screen [2], instead of seeing improvements to the underlying APIs that cause it to be slow in the first place? If a hacky JavaScript based solution is able to make this performant, surely a native API would do better.
The DOM has to evolve to support interactive apps in a performant way, or risk being replaced by custom things like the canvas or WASM, that are not easy for machines to parse, that won't have nearly as much consideration for accessibility and extensibility. That aren't as easy to enforce good usage of, or share knowledge about. It should not be "DOM is slow, oh well", or "DOM is slow, lets drop it", or "DOM is slow, so lets build a JS scaffolding around it (VDOM)." It should be "DOM is slow. What are the contexts in which it matters most, and how can we improve the APIs such that it can natively do those things performantly and easier?" Be that better selection APIs, animation APIs, better ways to read/write to styles, the list is endless. The DOM is slow, but it does not have to be slow. We *choose* not to make significant improvements to it, and one can come up with plenty of reasons why or excuses for it.
My point is that we should choose to improve it, because the alternative will lead us down a worse path. Years of neglect has led us here, where Google, a browser vendor themselves, has to give up on DOM because it's bad. This is fundamentally messed up.
I don't see how or why these things have to be related in any way whatsoever? Atlassian offers self hosted solutions and presumably do so because it's profitable. I don't see why offering a self hosted solution has to somehow mean less profit, or to the extent of non-profitability for that matter.
You could make it *more* expensive to use the self hosted version. It's straightforward to justify if you consider the additional development overhead, and if you include some kind of a support package.
My question is genuine. I see strange justifications like this often when it comes to self hosted versions of X, Y, or Z product. What exactly is the risk to profit here? I can see extra engineering overhead as a possible risk, but that's a solvable problem. There are many ways to handle software updates. Spinning up new backend environments is often done on devs machines daily when developing. I don't see any novel problem that hasn't been solved.
The "we have no plans for this", or "we are looking into it" are all often used ways of avoiding the question of "why aren't you doing this?" There are plenty of companies out there that for one reason or another, need to control the environment where their data lives. Why give up that business? Why do people who work at those places have to often settle for worse products because of this? Why not give businesses *choice* of storing their data or having someone else deal with the complexity?
Is it that the presumed market for this is too small? And why is nobody being transparent about this?
In this case, I think the switch is most likely entirely based on technical merits, rather than some way of asserting more control.
So with that in mind, the fact that the team behind one of Google's most interactive pieces of software has to throw up their hands and say "DOM is too slow, we gotta roll our own" should be a wakeup call for everyone working on Chrome and other browsers, but mostly for Google itself.
When you escape the DOM, you're going to be doing pretty much everything yourself. And for someone like Google, that might be worth the absolutely insane amount of effort, but what about everyone else? You're Google, Chrome has 60%+ market share. Why isn't the plan here to systematically start improving DOM performance, or create APIs to more directly modify how elements are laid out and created? Why do all of this work to benefit only Google Docs?
We've had years (decades!) of articles and talk about how the DOM is slow (including a bunch from Google), so why not improve it? Why give up and waste all this time on a custom solution? Why not create something that is *actually* capable of handling the complexity of modern, highly interactive applications, including Google's own products?
You can say it's Flutter, but that's yet another effort to escape the DOM, rather than actually improve it.
Maybe this has been the plan behind the Google Docs team, to push people on the browser side and other Google teams to start seriously looking at what to do with the DOM, if so, I hope this actually has the intended effect. We all deserve a better, more performant web.
This is a good topic overall, I'm not convinced of the particular example of infinite scrolling, but I do definitely want to see a movement toward products that don't try to overtake your life, and also make a point of it.
Why am I not convinced of the seemingly obvious infinite scroll example? It's not addressing the root problem, and we need to first and foremost think critically of the substance, rather than UI ergonomics. No doubt UI ergonomics can play a role, but I'd rather see people think about how to avoid having an infinite pool of addictive content in the first place. How can we create systems that are inherently limited by their intent, rather than just making the UI worse (although pagination in terms of design is anyway a contentious subject).
That sounds vague, so I'll give a few examples:
- An email service that only sends you your mail every day or x time interval, so you don't feel compelled to keep checking for new things.
- A social network that only lets you make small groups of friends with no global feed at all, so you don't need an algorithm to filter out all the noise and rank everyone's post behind the scenes.
As an aside, just take a moment to let that sink in, in case you haven't. There's a hidden AI deciding how important your friends' thoughts and photos are to you, to keep you addicted to content and keep scrolling, in an effort to show you more ads and make more money. It does so by recording everything you do on the service, and also things you do on other websites. This is not a sci-fi dystopia movie plot, this is what Facebook fundamentally is.
The "but it's free" argument I understand, and accepted for a long while also, but more recently I've started to reject this as a sound argument. Is it really so that if something is free, it gets a pass? I don't think that's true outside the internet. If someone's giving away free home insurance, and "only" requires you to have cameras installed in every room so they can better asses the responsible party, etc., would we as a society really look at that and say "but it's free" and move on with our lives? Hard to prove, but I'm doubtful that this wouldn't receive a massive backlash. What if the "free" plan was the only one available, and there were no comparable insurance companies around to reasonably switch to? What if they were using the recordings to sell data about you to ad companies?
It's free, yes, and sure, I could have "nothing to hide", but the idea of a company recording me in my home and selling how I behave to other companies to make money and get me to buy more stuff is still a fundamentally perverse arrangement.
Well, went a little off topic there, I suppose. But my point being is that I'd like to see services that actively try to make the product usage time finite from the concept, rather than just making the UI more frustrating to use.
This is probably one of the bigger issues holding me back from adopting Deno (at least for personal projects anyway). I'm sorry, I don't want to go back to early 2000s where we're copy pasting random links to script tags. Those days are over and for the better. NPM has proved pretty much undeniably that people prefer the simplicity of just typing in the name of something to install it, and import it. Does it have issues? Absolutely. I'd rather those issues be resolved than completely throwing away the concept though.
This feels to me a bit like if a new browser came around and said "DNS is the root of all evil" and only allowed you to directly type in the IP address of websites.
You can make all kinds of excuses, like "oh, but you can keep a list of your own!" or "hey, you can install this plugin that gives you DNS lookups back", but ultimately as a user I'm gonna say "No thanks, I'll keep using a browser that doesn't needlessly complicate my day."
I'm usually an early adopter for this kind of stuff, and I really like a lot about Deno, which is why this situation just makes me very sad.
The problem is boredom. We've become accustomed to having an instant excitement dispenser, and are now addicted to it. Boredom has become even more uncomfortable than it used to be, because we're no longer used to being bored.
That's fair enough, "x, but actually fast" is definitely a strong selling point and a differentiator in my book. That wasn't mentioned on the landing page.
These are standard material design icons. Most likely someone needed to add a new button/feature and just picked whatever icon best fit the purpose, or someone designed a new icon that would fit the purpose of whatever feature/button was being added.
With huge apps like Gmail, there's likely just so many different things happening that there's no time allocated to check every small change in a broader context, and these kinds of things slip in and pile up.
Over time, more and more "small" things pile up, and eventually a redesign is necessary because the palette has been polluted with too many things and the software becomes too clunky.
Another option is that no designer even gave this a look, or they saw it too late. This happens often too, designers might be busy working on a big new design and an engineer needs to just put in a button and doesn't think twice about just using one of the icons from the icon library.
Incompetence can explain stuff sometimes, but just like engineering, design is also often a collection of compromises and sometimes a lot of compromises can collude together to form a bigger disaster. The call icon is a good example of this. It's constrained by a lot of things, like overall language rules of material design, and any prior interface design choices made about button styles, toggles, etc. If the designer came up with a totally new style of button, they'd also be scolded by their peers for not maintaining consistency.
All of that said, I'm not making excuses, I'm providing an explanation. I think overall, with any kind of iconography based interactions, when in doubt, add a label. It just works. Icons are abstractions of language and actions, when it's no longer clear what they are abstracting, it's time to use language. It really is that simple.
I'd look at it from another perspective. Committing to learning an entirely new language is a big undertaking, so ideally you want to make sure that the resources you're using are of high quality. In that sense, it costing money is actually a good thing, since it signals that this is premium quality content and worth spending your time on. Of course this needs to be clearly communicated as such, like Brilliant.org for example (at least their marketing communication focuses on the quality).
This is a big reason why I get frustrated with comments about high refresh rate monitors being mostly for gaming, or it not being that important for productivity applications.
There's a reason why it's hard to ever go back, once you've experienced the fluidity of even just your mouse cursor reacting instantly to your movements.
If you've ever used the iPad Pro, there's clearly something special about the experience. It just _feels_ better, and for all the same reasons described in the article.
60hz is far from smooth, and that number is a leftover from days past, not what is actually optimal or good.
Display technologies unfortunately still have ways to go when it comes to high resolution, color accurate panels, with high refresh rates, but the general direction on the market is that high refresh rates are not available in the "productivity" category of monitors, even if sometimes the manufacturer has panels that would fit the bill. You unfortunately always need to look in the gaming category, which usually lack many of the features you'd like in a more productivity centered display. Such as a fully adjustable stand, high color accuracy and viewing angles, virtual display splitting, or just overall design of the enclosure.
I could go on another rant about display enclosure designs... Why isn't there a single company out there (with perhaps the exception of Dell) that's creating nice and minimal display enclosures that aren't covered in cheap plastic and "aesthetic" ornaments? Apple's Cinema Display from 2004 is to this day one of the better looking enclosures out there.
I don't think you can blame this on the consumers really. For the higher end market that I'm talking about in general here, I'd be willing to take a bet on if you build it they will come. I'd certainly be praising any company willing to take this on to high heavens.
I want a great, fast, accurate panel with a nice, minimal, aluminum enclosure. Is that just too much to ask?
Many of these types of articles (and the comments discussing them) seem to focus on the increased productivity of those 4 days, without talking too much about the reason _why_ they're (perceived) as more productive, or why that time off might be beneficial in its own right.
So firstly, a lot of this is incredibly subjective (so far) and somewhat difficult to measure accurately (again, so far), however based on past history of movements to decrease work days (probably most famously Ford), I'd wager to say there's a good chance that this is true now, as it was then. My personal bias would definitely lean on the side of it having a positive effect on productivity.
With that said, while the jury is out on the actual productivity increases, I don't think there's any doubt about the benefit of the extra weekend day. For example, it would probably be difficult to find anyone that would find positives in Saturday being a work day again, and having to work 6 days instead of 5.
Anyway, that being said... There are some subjective and anecdotal observations from my perspective that I feel are important to consider in this discussion, and to me even more important than the elusive "productivity" aspect. What I've observed is that taking time off to distance from the daily issues, especially during times of stress tends to have a positive effect on being able to solve problems effectively. The instinct while faced with a problem is to keep hammering at the problem until it is solved, and while that works for a while, over a longer period of time, or over prolonged periods of working without a break, I've usually witnessed either myself or collogues get frustrated and less engaged in their work, or making poor decisions that wouldn't otherwise be made.
My intuition based on this tells me that it is important to give the brain time to rest and disconnect from a problem in order to come up with better _quality_ solutions. So my hypothesis would be that if you want better _quality_ results, it's better to give people more time to rest and disconnect.
But that's just based on what I've read and observed so far. I would love to see more research into this, especially more nuanced takes on it. We need to be clear about what we mean by "productivity" in these discussions, and also realize that sheer output does not give us a full picture of this subject. _Quality_ matters just as much, if not more in some circumstances.