151–160 of 244 posts
Alternatively, this could be titled "do you know how much your computer could do in a second but isn't because of bad design choices, overengineered bloated systems, and dogmatic adherence to the 'premature optimisation' myth?" Computers are fast, but not if all that speed is wasted. A recent related article: https://news.ycombinator.com/item?id=13940014
Earlier quoted context omitted.
>either CSS filtering or WebGL CSS only has basic filters, and WebGL is only possible for per-pixel manipulation, such as brightness or contrast. This is because WebGL is just shaders, and half of shaders are per-pixel, along with some other fun things you can use with multiple buffers, but you can't actually get /back/ the processed data even if you got all the pixels into a single loop. With WebGL 2, this may be di…
> but you can't actually get /back/ the processed data even if you got all the pixels into a single loop Oh if you need the pixels back, you can certainly get them using glReadPixels(). It's a bit expensive in WebGL land, though it is much less expensive than looping over pixels using JS. And often there are ways to get around needing the pixels back, depending on what you're doing. You can also do loads of non per-p…
Earlier quoted context omitted.
>Putting transients before long-term behavior leads to urban programming myths and legacy baggage. Not when the problems still exist. When they stop existing, sure, but the statement generally goes along with how some parts of ES6 are not well optimized yet. Over time, they should be optimized, but I cannot design something for an event that hasn't happened yet and cannot be tested.
You are doing it wrong. let is better than var (in every way), so you should never ever use var. Of course you can design for the future. Designing for the future is using let and transpile to a dialect that is used by most browsers today.
Not in the case I presented. let has benefits, but that does not mean its 'better in every way'. Again, dogmatism. Granted, the case I give is many, many iterations, it still is a problem if you're doing image filtering.
Earlier quoted context omitted.
HTLM + CSS is right now the easiest combo to create a really custom UI. Try to do something very custo with QT or Wx that is portable and you'll notice it's way, way more work. Combine that with the face web dev already know HTML + CSS and the related tooling, and you got the answer. Electron apps are slow, eats a lot of resources, weight a lot of Mo and don't have a native UI integrated with the OS. You really need…
Is it? Looks pretty easy to me: http://doc.qt.io/qt-5/qtquick-canvas-example.html You get a full scene graph to play with. What exactly do you think is missing? http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html
Earlier quoted context omitted.
Let's be clear, I dislike slow apps, I think current behemoth web pages size is a monstrosity and every time I start an electron app (minus the excellent vscode), I scream in my head. Yet. Most electron app I tried have a ratio result/effort far better than any other solutions for the dev.
Why do we care so much about the dev? There are way more people who use a typical program than there are people who develop it, and these people often use the program more frequently than the developers make changes to it. For example, if a feature is used every day for a year by 10,000 people, speeding it up by 200ms is worth over a month of developer time (200ms for 10,000 people over a year is 203 hours of time wa…
Earlier quoted context omitted.
It's wasted only if it's not traded for something else. But it is. A lot of system would simply not exist if we would have waited for people doing it properly because there is a limited pool of very skilled experts and the demand for IT far exceed our ability to supply. Plus writing good code takes a lot of time and resources, but our society changes now so fast that it very well maybe rewritten next year. Hence, we…
> Because until now making a beautiful, powerful and modern app with a portable GUI was something only a few people would be able to do. Except it's none of these things: electron apps suffer the same presentation-before-content problems as most of the web, they inherit all of the state bugs of web apps, and they're painfully slow despite usually just being menus of nested lists and text boxes. It's passing a burden…
Earlier quoted context omitted.
Let's be clear, I dislike slow apps, I think current behemoth web pages size is a monstrosity and every time I start an electron app (minus the excellent vscode), I scream in my head. Yet. Most electron app I tried have a ratio result/effort far better than any other solutions for the dev.
Why do we care so much about the dev? There are way more people who use a typical program than there are people who develop it, and these people often use the program more frequently than the developers make changes to it. For example, if a feature is used every day for a year by 10,000 people, speeding it up by 200ms is worth over a month of developer time (200ms for 10,000 people over a year is 203 hours of time wa…
There are also lots and lots of products that take a "npm+glue" approach - they ship an initial version that leverages everything possible, and then run aground trying to make it to version 2, because the architecture is so reliant on the dependencies that it can neither be maintained nor support any additional features. This is a little bit different from the "Electron problem" in that it identifies a showstopper limitation to using developer-side easings, rather than a long-term paper cut issue.
Earlier quoted context omitted.
So is there any way to stop this treadmill, short of overthrowing capitalism itself? Edit: If that seems like a non-sequitur, I said it because the parent comment started by saying that the market is wasteful.
I don't think capitalism is to blame, as this is endemic even in free software. The way to stop this is to stop repeating dogmatic myths about optimisation, consider efficiency/optimisation as an integrated part of the design process and not something to be applied afterwards, and focus on " user time is expensive" instead of "developer time is expensive" --- and sometimes, those users may also be developers.
that's not always true, especially from the point of view of the dev.
Earlier quoted context omitted.
Way too much to cover in depth. In short, it's all terrible. We're mostly using tools from the 70s, and we're still to this day plagued by use-after-free and out-of-bounds errors, nullpointer exceptions, awful debuggers, race conditions, slow compilation times, bad primitives for multithreaded work, just to name a few. We've known for decades that we can do better and ways to do better have been studied in depth by a…
> We're mostly using tools from the 70s We're using the shittier tools from the 70s, because the better tools died off - which is sad, because we still didn't manage to recreate some of the features those tools offered. The success of UNIX and C seems to be caused by the same phenomenon that causes Electron to succeed and bloat to proliferate - what wins aren't good solutions, but those which get popular quickly.
but by the judgement of a majority, those tools are good! That's why it got popular. Any personal sense of aesthetics from you (or anyone) doesn't matter at all here, and most people who call tools that failed 'good' are only judging it by personal aesthetics.
Earlier quoted context omitted.
If slowness is the goal and if product managers insist on slowness, then you'd expect a lot of sleep() calls in commercial software (which has product managers) and no sleep() calls in open source software. This doesn't happen. What we see is that commercial software has better documentation, gets more long term maintenance and support, and supports more cumbersome enterprise features. Exactly what you'd expect when…
Actually, some software like facial recognition or OCR, does have sleep calls inserted because people don't believe it can be done as fast as it can be done. Thus, whenever I deposit checks at the ATM, I have to stand there and watch as some entirely unnecessary animation pretends to scan my check for ten seconds before I can have my card back.
When you do get to use it, using performant software is a really great experience, so how to we train users to appreciate this?