4 ms·

> But with the advent of 8-16+ GB of ram in consumer computers can we really say 2-3GB for windows rendering is heavy? This attitude is why we have phones wit

by k00pa 12y ago

> But with the advent of 8-16+ GB of ram in consumer computers can we really say 2-3GB for windows rendering is heavy? This attitude is why we have phones with 1G of memory and 1Ghz+ CPU's lagging when just trying to read email. Yes, there is more memory available than before, but that doesn't mean we should just waste it for useless stuff. For example if we eat 2-3GB of memory on a system with 8GB of memory, thats over 25% of the usage. Then some applications that are actually used. (Let me use my own process mem counts here...) 1.3Gb for Firefox, 0.6Gb for Android emulator, 0.5Gb for Visual studio.... And there would have gone over half of the 8GB of ram! I am sure my current memory usage would be half of what its now if developers would actually give some shit about memory usage... Not just allocate too much memory because "there is so much memory it doesn't matter"

joev_ 12y ago
> Yes, there is more memory available than before, but that doesn't mean we should just waste it for useless stuff. I disagree. I think the point is that it's not useless, by its own existence. It saves dev time (which allows more - and better! - programs to be built), it allows richer features and interactions, it lowers the barrier to entry for maintenance work, and most of all prevents constant re-inventing/implementing the wheel, which is reflected to the user in a lack of many common types of bugs, annoyances, and accessibility issues.
- com2kid 12y ago
  I'd argue against it saving dev time. See my above comment, HTML+CSS is not the fastest way to design an app. If it is all you know then yes, it is faster, but inherently it is not a /good/ system. It gets worse even faster if you add JS to the mix!
  - kristiandupont 12y ago
    I think it's a great system. It's surely the fastest way for me personally, in spite of it not being "all I know". With Bootstrap or Foundation, you need very little code to make something look nice, there is great documentation and lots of online resources.
    - com2kid 12y ago
      If I want to make a UI in C#, I can pull up WinForms and use one language. If I want to have nice separation of style from code, I can use XAML (which is purpose designed for making layouts easy) and be using 2 purposefully technologies. There is a lot more mental overhead to HTML + CSS + JS (and then the DOM somewhere) than to just type in Button accept = new Button("Accept!", new size(100, 45)); form.Add(button, 300, 50); If I want to style my button, I set some properties on the button. (And if I want to use XAML, I send a file off to a designer who pops it into a purpose built XAML editor who can play around with the styling and layout to their heart's content!) The thing is, web tech was designed for a non-interactive page based model, and then interactivity was added. Then someone wanted curved boarders, and what had to be done to make curved borders was rather nasty. So after a good long time web standards caught up with fashion and an ability to add curved borders was added to CSS. And damn you to the neither regions of hell if you want squiggly borders (Back to nasty scaling PNGs, or a few thousand 1 pixel DIVs!) However, I'm sure if those do come into style and enough people complain, that squiggly borders will also be added to the spec. In comparison, a real UI framework lets you override the Paint function and do whatever you want. On that note, about 2 quarters of freshman Java will have students be able to create custom UI widgets that do whatever is desired. For someone who already knows programming? Point them at OnPaint, "here override it, draw whatever you want, have fun!" The set of concepts needed to modern UI development on the desktop is tiny. This is a problem space that has had three decades of effort put into making it simple and easy. Again, want separation of concerns? About 2 hours of XAML will have someone making custom widgets, in fact that is the entire way XAML works! (It was sort of a mind twist for me that the easiest way to make an image button in XAML was not to override an OnPaint method and draw an icon, but rather place the XML nodes for an Icon and a Button together!) But take someone that knows programming, well first you have to introduce them to CSS, which is a bunch of fields that you have to memorize (or rather just keep looking up) with a number of different types of units supported (none of which do exactly what you want, but I'll grant that is the case for all resolution independent UIs). Then of course they get to learn the newest flavor of HTML (semantic everything, don't you dare use <bold>). Then you get to show them JavaScript (Packages? Namespaces? A language in which imports can silently override my variables causing havoc and dismay? Wow, C's #DEFINE is considered harmful, but this is a whole new level.) But hey thankfully CSS3 makes 3 box layouts no longer an exercise in pain! So that is a good thing. (I've been using flexible layouts that auto adjust the positioning and sizing of elements since the late 90s, it is nice that the web finally caught up by introducing yet another boxing model!) Of course the final lesson is "oh and by the way this all sucks so you really want to use a third party JavaScript UI framework. Also CSS is sort of painful so you may want to use a preprocessor. Yeah just shove your content in the middle of your client side generated DIVs. Well yes generating the exact same page on every visitors PC is sort of silly and a huge thermodynamic waste, but it is currently in style so stop complaining about it. Yes I know the comments section takes 10 seconds to load. What do you mean BBSs on a 9600 baud modem responded faster?" (Edit: Of course the last bit about responsiveness isn't relevant to using a web stack for client side apps, it is just me complaining about the poor state of the web in general)
- welly 12y ago
  Isn't inefficient coding, which is what we're discussing really, possibly needlessly forcing the specifications of hardware to be more and more powerful rather than getting the best out of the hardware we have now by better coding?
  - RyanMcGreal 12y ago
    I rather expect causality flows the other way: coding is getting less efficient because hardware is getting faster. Or as the old saying goes, "Intel giveth, and Microsoft taketh away."
- k00pa 12y ago
  Adding HTML to the GUI coding is re-inveting the wheel. There are native toolkits for UI, there are crossplatform UI libraries for a reason. They work, they are fast. No need to add extra layers on top of those.
  - yAnonymous 12y ago
    Most desktop applications have a terrible interface compared to modern websites. That wouldn't be the case if the UI libraries were half as good as some people here claim.
    - Moru 12y ago
      Most new desktop applications have a really crappy interface. Mostly because they are trying to copy some new homepage layout and instead is missing lots of information and buttons and fading in/out text and buttons instead of letting me click them directly. Not to mention taking several seconds to load a form that on my 8MHz Atari would have loaded instantly. Yes I'm old, get off my lawn!
      - Napoleon1963 12y ago
        Desktop apps from the late 1980s to around 2004 or so were very usable. There were clear UI standards in place for most platforms, and thus a high degree of consistency between applications, even from different vendors. Even Java's AWT, which came at the tail end of this and pretty much only targeted UI functionality that was common between different UI systems, could create desktop apps that were and are much more usable than the inconsistent web-inspired desktop apps we deal with today.
    - normloman 12y ago
      Let me add myself to the chorus of people standing up for native desktop applications. Sure, there are bad and good examples of both desktop and web UIs. But whats so horrendous about the original Mac OS interface? What was so bad about Gnome 2?
  - eurleif 12y ago

by k00pa 12y ago

joev_ 12y ago

> Yes, there is more memory available than before, but that doesn't mean we should just waste it for useless stuff. I disagree. I think the point is that it's not useless, by its own existence. It saves dev time (which allows more - and better! - programs to be built), it allows richer features and interactions, it lowers the barrier to entry for maintenance work, and most of all prevents constant re-inventing/implementing the wheel, which is reflected to the user in a lack of many common types of bugs, annoyances, and accessibility issues.

com2kid 12y ago
I'd argue against it saving dev time. See my above comment, HTML+CSS is not the fastest way to design an app. If it is all you know then yes, it is faster, but inherently it is not a /good/ system. It gets worse even faster if you add JS to the mix!
- kristiandupont 12y ago
  I think it's a great system. It's surely the fastest way for me personally, in spite of it not being "all I know". With Bootstrap or Foundation, you need very little code to make something look nice, there is great documentation and lots of online resources.
  - com2kid 12y ago
    If I want to make a UI in C#, I can pull up WinForms and use one language. If I want to have nice separation of style from code, I can use XAML (which is purpose designed for making layouts easy) and be using 2 purposefully technologies. There is a lot more mental overhead to HTML + CSS + JS (and then the DOM somewhere) than to just type in Button accept = new Button("Accept!", new size(100, 45)); form.Add(button, 300, 50); If I want to style my button, I set some properties on the button. (And if I want to use XAML, I send a file off to a designer who pops it into a purpose built XAML editor who can play around with the styling and layout to their heart's content!) The thing is, web tech was designed for a non-interactive page based model, and then interactivity was added. Then someone wanted curved boarders, and what had to be done to make curved borders was rather nasty. So after a good long time web standards caught up with fashion and an ability to add curved borders was added to CSS. And damn you to the neither regions of hell if you want squiggly borders (Back to nasty scaling PNGs, or a few thousand 1 pixel DIVs!) However, I'm sure if those do come into style and enough people complain, that squiggly borders will also be added to the spec. In comparison, a real UI framework lets you override the Paint function and do whatever you want. On that note, about 2 quarters of freshman Java will have students be able to create custom UI widgets that do whatever is desired. For someone who already knows programming? Point them at OnPaint, "here override it, draw whatever you want, have fun!" The set of concepts needed to modern UI development on the desktop is tiny. This is a problem space that has had three decades of effort put into making it simple and easy. Again, want separation of concerns? About 2 hours of XAML will have someone making custom widgets, in fact that is the entire way XAML works! (It was sort of a mind twist for me that the easiest way to make an image button in XAML was not to override an OnPaint method and draw an icon, but rather place the XML nodes for an Icon and a Button together!) But take someone that knows programming, well first you have to introduce them to CSS, which is a bunch of fields that you have to memorize (or rather just keep looking up) with a number of different types of units supported (none of which do exactly what you want, but I'll grant that is the case for all resolution independent UIs). Then of course they get to learn the newest flavor of HTML (semantic everything, don't you dare use <bold>). Then you get to show them JavaScript (Packages? Namespaces? A language in which imports can silently override my variables causing havoc and dismay? Wow, C's #DEFINE is considered harmful, but this is a whole new level.) But hey thankfully CSS3 makes 3 box layouts no longer an exercise in pain! So that is a good thing. (I've been using flexible layouts that auto adjust the positioning and sizing of elements since the late 90s, it is nice that the web finally caught up by introducing yet another boxing model!) Of course the final lesson is "oh and by the way this all sucks so you really want to use a third party JavaScript UI framework. Also CSS is sort of painful so you may want to use a preprocessor. Yeah just shove your content in the middle of your client side generated DIVs. Well yes generating the exact same page on every visitors PC is sort of silly and a huge thermodynamic waste, but it is currently in style so stop complaining about it. Yes I know the comments section takes 10 seconds to load. What do you mean BBSs on a 9600 baud modem responded faster?" (Edit: Of course the last bit about responsiveness isn't relevant to using a web stack for client side apps, it is just me complaining about the poor state of the web in general)
welly 12y ago
Isn't inefficient coding, which is what we're discussing really, possibly needlessly forcing the specifications of hardware to be more and more powerful rather than getting the best out of the hardware we have now by better coding?
- RyanMcGreal 12y ago
  I rather expect causality flows the other way: coding is getting less efficient because hardware is getting faster. Or as the old saying goes, "Intel giveth, and Microsoft taketh away."
k00pa 12y ago
Adding HTML to the GUI coding is re-inveting the wheel. There are native toolkits for UI, there are crossplatform UI libraries for a reason. They work, they are fast. No need to add extra layers on top of those.
- yAnonymous 12y ago
  Most desktop applications have a terrible interface compared to modern websites. That wouldn't be the case if the UI libraries were half as good as some people here claim.
  - Moru 12y ago
    Most new desktop applications have a really crappy interface. Mostly because they are trying to copy some new homepage layout and instead is missing lots of information and buttons and fading in/out text and buttons instead of letting me click them directly. Not to mention taking several seconds to load a form that on my 8MHz Atari would have loaded instantly. Yes I'm old, get off my lawn!
    - Napoleon1963 12y ago
      Desktop apps from the late 1980s to around 2004 or so were very usable. There were clear UI standards in place for most platforms, and thus a high degree of consistency between applications, even from different vendors. Even Java's AWT, which came at the tail end of this and pretty much only targeted UI functionality that was common between different UI systems, could create desktop apps that were and are much more usable than the inconsistent web-inspired desktop apps we deal with today.
  - normloman 12y ago
    Let me add myself to the chorus of people standing up for native desktop applications. Sure, there are bad and good examples of both desktop and web UIs. But whats so horrendous about the original Mac OS interface? What was so bad about Gnome 2?
- eurleif 12y ago