7 ms·

> I absolutely 100% do not want web workers (service workers?) enabled in any way shape or form. Any website which uses one is, in my opinion, not only extremel

> I absolutely 100% do not want web workers (service workers?) enabled in any way shape or form. Any website which uses one is, in my opinion, not only extremely poorly designed but uses anti-patterns. that's kind of an unfair statement. web workers are extremely useful for moving computation away from the (single) gui thread, allowing the page to load and process large amounts of data without locking the main browser thread. what you're saying is equivalent to saying "any program that uses threads is poorly designed and uses anti-patterns". while, like threads, there can be bad uses for them, they can be used extremely effectively for good.

inetknght 8y ago
> what you're saying is equivalent to saying "any program that uses threads is poorly designed and uses anti-patterns". No, what I'm saying is that I want my web browser to have a light footprint. The browser from 10 years ago works perfectly fine: it rendered and displayed text and images and didn't require hundreds of megabytes or even gigabytes of disk space. The anti-pattern is the idea that so many new things are "needed".
- jerrysievert 8y ago
  > No, what I'm saying is that I want my web browser to have a light footprint. but that's not what you said (I'm not trying to be antagonistic) - you called using a specific part of the browser an anti-pattern and poorly designed. > The browser from 10 years ago works perfectly fine: it rendered and displayed text and images and didn't require hundreds of megabytes or even gigabytes of disk space. and alternately, the ed editor also works perfectly fine: it edited files, and is 57k (likely more than it needs to be). but for some reason most people don't use it very often, instead opting for vim, emacs, atom, or even eclipse. needing new things isn't an anti-pattern, it's simply the growth of the environment.
  - inetknght 8y ago
    > but that's not what you said (I'm not trying to be antagonistic) - you called using a specific part of the browser an anti-pattern and poorly designed. You're right. Where do you think the statements contradict each other? I don't think they do. > and alternately, the ed editor also works perfectly fine: it edited files, and is 57k (likely more than it needs to be). but for some reason most people don't use it very often, instead opting for vim, emacs, atom, or even eclipse. As a matter of fact, I use vim a lot. > needing new things isn't an anti-pattern, it's simply the growth of the environment. From what problem did this need arise?
    - jerrysievert 8y ago
      > As a matter of fact, I use vim a lot. which is miles ahead of ed (and vi for that matter), adding a ton of extra features when ed works perfectly well for editing files. so why use vim? > From what problem did this need arise? from the same problem that threads in general arose - some part of the program blocking another part of the program, making for a bad experience. javascript runs in a single thread for the whole page - so anything that is blocking in any way, due to processing data, dealing with loading data, rendering any sort of 3d for you, mixing audio, really anything that would give you any sort of interactive experience could block the whole page from being responsive. you might as well as from what problem threads arose - same answer. it's true that we had fairly primitive cooperative multi-threading in c using lngjmp and setjmp, but it's still a lot better to fire up another thread when doing tasks like the above, especially when dealing with a gui is also involved, such as with the web. I'm happy to provide concrete examples, if you want.
      - inetknght 8y ago
        > so why use vim? vim is lightweight and miles ahead of ed. It's easier for me, as a user, to use vim than to use ed. It's simpler and loads faster than Notepad++ or Code. > from the same problem that threads in general arose - some part of the program blocking another part of the program, making for a bad experience. While I concur that a web site not loading makes for a bad experience, I do diverge on the solution. > javascript runs in a single thread for the whole page - so anything that is blocking in any way, due to processing data, dealing with loading data, rendering any sort of 3d for you, mixing audio, really anything that would give you any sort of interactive experience could block the whole page from being responsive. Solution: don't use javascript. > you might as well as from what problem threads arose - same answer. it's true that we had fairly primitive cooperative multi-threading in c using lngjmp and setjmp, but it's still a lot better to fire up another thread when doing tasks like the above, especially when dealing with a gui is also involved, such as with the web Honestly I don't see where the problem is a user problem. It's a problem, for sure, but I believe it rests solely in the hands of the developer and web site's servers. > I'm happy to provide concrete examples, if you want. I would like that, if you're willing to also learn how I think some of the examples might be done differently.
- erinaceousjones 8y ago
  Website != Web application. The "anti-patterns" are super useful to those of us who are using all of them to create functional cross-platform applications ;) I feel that there's a disconnect between website devs and webapp devs, and that the latter win when it comes to adding new functionality. The people who want to use the web as a generic platform are the ones that are turning it into an operating system by itself, which by nature is going to cause bloat, but people still think of it as "hey, it's 'just' a web browser!" when in reality they're becoming almost another whole layer of abstraction that allows arbitrary programs to run on any OS. I agree that the adoption of new unnecessary technologies by websites that don't need them makes for a frustrating experience. Like, when I go to a small-town newspaper's website to read an article, I have to wait seconds for the custom font to load, elements pop in and out of existence as third party advertiser code loads, a video somewhere starts autoplaying, I have to click through a GDPR consent form, a cookies-ok form, a "subscribe with your email" screenjacker, social media buttons appearing reflow the text, ......... yeah it's BAD. I think the issues we encounter come from the wheel-reinvention and the fact that web counterparts of existing technology tend to eschew things like security and scheduling in order to quickly catch up.
masswerk 8y ago
Maybe, this is exactly what a user doesn't want. Maybe, we should have a confirmation banner (including an estimate of the CPU load), like for getMedia, autoplay, etc?

inetknght 8y ago

> what you're saying is equivalent to saying "any program that uses threads is poorly designed and uses anti-patterns". No, what I'm saying is that I want my web browser to have a light footprint. The browser from 10 years ago works perfectly fine: it rendered and displayed text and images and didn't require hundreds of megabytes or even gigabytes of disk space. The anti-pattern is the idea that so many new things are "needed".

jerrysievert 8y ago
> No, what I'm saying is that I want my web browser to have a light footprint. but that's not what you said (I'm not trying to be antagonistic) - you called using a specific part of the browser an anti-pattern and poorly designed. > The browser from 10 years ago works perfectly fine: it rendered and displayed text and images and didn't require hundreds of megabytes or even gigabytes of disk space. and alternately, the ed editor also works perfectly fine: it edited files, and is 57k (likely more than it needs to be). but for some reason most people don't use it very often, instead opting for vim, emacs, atom, or even eclipse. needing new things isn't an anti-pattern, it's simply the growth of the environment.
- inetknght 8y ago
  > but that's not what you said (I'm not trying to be antagonistic) - you called using a specific part of the browser an anti-pattern and poorly designed. You're right. Where do you think the statements contradict each other? I don't think they do. > and alternately, the ed editor also works perfectly fine: it edited files, and is 57k (likely more than it needs to be). but for some reason most people don't use it very often, instead opting for vim, emacs, atom, or even eclipse. As a matter of fact, I use vim a lot. > needing new things isn't an anti-pattern, it's simply the growth of the environment. From what problem did this need arise?
  - jerrysievert 8y ago
    > As a matter of fact, I use vim a lot. which is miles ahead of ed (and vi for that matter), adding a ton of extra features when ed works perfectly well for editing files. so why use vim? > From what problem did this need arise? from the same problem that threads in general arose - some part of the program blocking another part of the program, making for a bad experience. javascript runs in a single thread for the whole page - so anything that is blocking in any way, due to processing data, dealing with loading data, rendering any sort of 3d for you, mixing audio, really anything that would give you any sort of interactive experience could block the whole page from being responsive. you might as well as from what problem threads arose - same answer. it's true that we had fairly primitive cooperative multi-threading in c using lngjmp and setjmp, but it's still a lot better to fire up another thread when doing tasks like the above, especially when dealing with a gui is also involved, such as with the web. I'm happy to provide concrete examples, if you want.
    - inetknght 8y ago
      > so why use vim? vim is lightweight and miles ahead of ed. It's easier for me, as a user, to use vim than to use ed. It's simpler and loads faster than Notepad++ or Code. > from the same problem that threads in general arose - some part of the program blocking another part of the program, making for a bad experience. While I concur that a web site not loading makes for a bad experience, I do diverge on the solution. > javascript runs in a single thread for the whole page - so anything that is blocking in any way, due to processing data, dealing with loading data, rendering any sort of 3d for you, mixing audio, really anything that would give you any sort of interactive experience could block the whole page from being responsive. Solution: don't use javascript. > you might as well as from what problem threads arose - same answer. it's true that we had fairly primitive cooperative multi-threading in c using lngjmp and setjmp, but it's still a lot better to fire up another thread when doing tasks like the above, especially when dealing with a gui is also involved, such as with the web Honestly I don't see where the problem is a user problem. It's a problem, for sure, but I believe it rests solely in the hands of the developer and web site's servers. > I'm happy to provide concrete examples, if you want. I would like that, if you're willing to also learn how I think some of the examples might be done differently.
erinaceousjones 8y ago
Website != Web application. The "anti-patterns" are super useful to those of us who are using all of them to create functional cross-platform applications ;) I feel that there's a disconnect between website devs and webapp devs, and that the latter win when it comes to adding new functionality. The people who want to use the web as a generic platform are the ones that are turning it into an operating system by itself, which by nature is going to cause bloat, but people still think of it as "hey, it's 'just' a web browser!" when in reality they're becoming almost another whole layer of abstraction that allows arbitrary programs to run on any OS. I agree that the adoption of new unnecessary technologies by websites that don't need them makes for a frustrating experience. Like, when I go to a small-town newspaper's website to read an article, I have to wait seconds for the custom font to load, elements pop in and out of existence as third party advertiser code loads, a video somewhere starts autoplaying, I have to click through a GDPR consent form, a cookies-ok form, a "subscribe with your email" screenjacker, social media buttons appearing reflow the text, ......... yeah it's BAD. I think the issues we encounter come from the wheel-reinvention and the fact that web counterparts of existing technology tend to eschew things like security and scheduling in order to quickly catch up.

masswerk 8y ago

Maybe, this is exactly what a user doesn't want. Maybe, we should have a confirmation banner (including an estimate of the CPU load), like for getMedia, autoplay, etc?