6 ms·

> 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 us

> 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.
  - jerrysievert 8y ago
    (we're too many levels deep on hn, so replying to myself - this may end up going beyond what would be a good discussion on hn though) > vim is lightweight and miles ahead of ed. and modern browsers are miles ahead of where they were 10 years ago, giving us better text rendering, better image rendering, much better layout, and better interactivity. > Solution: don't use javascript. for some things, this is acceptable, but for some applications this simply does not make sense. loading a static page, probably shouldn't be any javascript. viewing a map, where you can zoom in and out, as well as pan around should probably use javascript. I'd be interested in hearing how you would solve that use case without using javascript. > 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. here's an example of something that I did real-world with web workers: a city's building footprints, loaded from a feature service (~150mb as JSON), processed by a user-specific variable (such as age of building, square feet, building usage: store, warehouse, residential) where each building is rendered on an interactive map in different colors based on the visualization type. this can be done server-side, with 150mb of data rendered onto either vector or raster images, each processing tiles for any location, or it can be rendered in browser. without using web workers, expect a 5 minute freeze while everything loads, gets processed, and rendered into the dom, with the experience repeating every time criteria is changed or the map is moved. with web workers, it is near real-time, with no freeze. if this were rendered on the server, it would be quite a lot of server cpu usage to render on the fly, or a huge amount of image space to render ahead of time, plus very large amounts of data. add another layer on top of it, and you're looking at doubling that, along with huge data transfer, which would not make for a very good user experience. I'd be interested in hearing an alternate way to provide this, while keeping the data usage, server disk usage, and cpu usage (server and client) to a minimum, while still providing a compelling user experience to the user.

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.
- jerrysievert 8y ago
  (we're too many levels deep on hn, so replying to myself - this may end up going beyond what would be a good discussion on hn though) > vim is lightweight and miles ahead of ed. and modern browsers are miles ahead of where they were 10 years ago, giving us better text rendering, better image rendering, much better layout, and better interactivity. > Solution: don't use javascript. for some things, this is acceptable, but for some applications this simply does not make sense. loading a static page, probably shouldn't be any javascript. viewing a map, where you can zoom in and out, as well as pan around should probably use javascript. I'd be interested in hearing how you would solve that use case without using javascript. > 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. here's an example of something that I did real-world with web workers: a city's building footprints, loaded from a feature service (~150mb as JSON), processed by a user-specific variable (such as age of building, square feet, building usage: store, warehouse, residential) where each building is rendered on an interactive map in different colors based on the visualization type. this can be done server-side, with 150mb of data rendered onto either vector or raster images, each processing tiles for any location, or it can be rendered in browser. without using web workers, expect a 5 minute freeze while everything loads, gets processed, and rendered into the dom, with the experience repeating every time criteria is changed or the map is moved. with web workers, it is near real-time, with no freeze. if this were rendered on the server, it would be quite a lot of server cpu usage to render on the fly, or a huge amount of image space to render ahead of time, plus very large amounts of data. add another layer on top of it, and you're looking at doubling that, along with huge data transfer, which would not make for a very good user experience. I'd be interested in hearing an alternate way to provide this, while keeping the data usage, server disk usage, and cpu usage (server and client) to a minimum, while still providing a compelling user experience to the user.