10 ms·

You both do realize that similar arguments could have been made back in the day when moving from, say, command-line DOS applications to Windows API applications

by cr0sh 10y ago

You both do realize that similar arguments could have been made back in the day when moving from, say, command-line DOS applications to Windows API applications - right? Ultimately, computing has always been one of abstraction from the lower "layers". Taken far enough, one could spuriously argue that if you aren't soldering together the flip-flops that make up your logic and memory, you just aren't being efficient...

thechao 10y ago
Except that the abstraction layer for the user has remained the same. The extra abstraction layers you're talking about are invisible to the user... while our GUIs are slower, and our processors faster. It feels like, after 30 years, we should be able to have our GUI cake and eat it, too.
- JustSomeNobody 10y ago
  Where are the Michael Abrash's of today teaching people how to write tight, fast code? Seems a lost art... Yes, I know, he's still around...
  - deleted 10y ago
    [deleted]
  - desertrider 10y ago
    Luckily there are a few people that still care, just look at the response Handmade Hero has gotten.
    - swah 10y ago
      Those videos on data oriented design were also very interesting: https://github.com/taylor001/data-oriented-design https://github.com/taylor001/data-oriented-design The thing is, using C++ instead of React for mobile development of a simple application would probably make me miss deadlines... So we just stick to whats popular.
      - flukus 10y ago
        Building UI's in something like Qt, GTK or swing was never really that time consuming, especially given the limited amount of controls one screen in a mobile app.
  - criddell 10y ago
    Except today's machine language is javascript.
- stickfigure 10y ago
  Except that the abstraction layer for the user has remained the same. This is absolutely not true. Going to windowing GUIs from character-mode DOS was a massive usability improvement. No more exotic ctl-alt-function key combos (or control-control sequences for WordStar users like me). Going from desktop apps to webapps changed the abstraction layer of how we access and share documents. No more installing software on the desktop. Docs are available on every computer we log into. Multiple people can edit the same document. Maybe you don't care about document sharing and would be happy installing old school word processors and spreadsheets? That's a fair statement to make, but the market appears to be voting otherwise.
  - wongarsu 10y ago
    >No more installing software on the desktop At least VS Code has to be installed. It is a plus for Google Docs & Co, but not universal. And in most cases, instead of installing you now have to create an account. >Docs are available on every computer we log into. Multiple people can edit the same document. Those features are completely independent from the platform the application uses. Those features are commonly implemented in web apps because for a long time they had no other choice, but cloud storage and collaborative editing can be equally well implemented in a destop application.
  - deleted 10y ago
    [deleted]
  - dheera 10y ago
    > Going to windowing GUIs from character-mode DOS was a massive usability improvement. No more exotic ctl-alt-function key combos cough Blender ...
    - paulmd 10y ago
      Unfortunately - the OSS world has a shortage of good UX people, and the engineers tend to be the ones steering the ship. I would point to Eclipse as another classic example of "obviously designed by an engineer". There's tons of functionality under the hood and it's a fantastic jumping-off point for further customization... but its layout is intensely non-intuitive in so many ways compared to a purpose-built IDE. Everything is locked away in menus and "perspectives". If you're writing a Java web app - do you want the Java perspective, the Java EE perspective, the Web perspective, or the Debug perspective? I hear GIMP's no picnic to work with either but can't confirm personally.
- gvb 10y ago
  The abstraction layer has only remained the same visually, and only for a loose definition of "visually." In the "good old days" the user interface was 640px x 480px (original VGA[1], skipping past the original MDA, CGA, and Hercules graphics cards[2] since they predated "modern" GUIs). Then it was expanded to 800x600, etc. The programs of those days were hard-coded to the graphics adapter resolution. If a program did not support the graphics adapter you had, you had to run your GUI in lower resolution compatibility mode. Sometimes it didn't work at all. In lower resolution compatibility mode, the program's display got uglier and uglier as the screen resolution went up. The abstraction layer today is adaptive and high DPI. Since the abstraction layer abstracts away the actual display resolution, programs (generally) can take advantage of the resolution that is available on a given display without change, allowing a program to run on small hardware displays (phone/tablet form factor) up to mega 4K++ displays, looking better and better as the screen resolution goes up. [1] https://en.wikipedia.org/wiki/Vga https://en.wikipedia.org/wiki/Vga [2] https://en.wikipedia.org/wiki/Hercules_Graphics_Card https://en.wikipedia.org/wiki/Hercules_Graphics_Card
  - pcwalton 10y ago
    Precisely. And even Win32, which is being touted in this thread as somehow far superior to the Web stack, was never designed for high DPI apps. It's far worse than the Web stack, with exact pixel hardcoding everywhere. That's why the HiDPI situation on Windows is such an inconsistent mess. Meanwhile, the Web scaled up to HiDPI so seamlessly that most people never even noticed any friction. This is the benefit of the declarative model of CSS.
    - smitherfield 10y ago
      Isn't this a false dichotomy? Why not create more modern, declarative native APIs and libraries, or use them where they already exist?
      - pcwalton 10y ago
        Because it's less effort and more likely to be successful to just improve Web implementations.
pyre 10y ago
There is a point to be made here though that is more valid than the argument against moving away from command-line DOS applications to Windows API applications. Moving from text-based to graphical is a much different shift than what we are talking about here. The idea here is that we are creating many abstractions to get the same basic result. I can't rewrite Atom.io for DOS, but I could rewrite Atom.io to use the Windows API directly rather than being Electron-based. We're talking about VS Code using 13% of the CPU while idle to render a blinking cursor. What benefit does the user get from this? We could render a blinking cursor with less then 13% of a much less powerful CPU years ago.
- jug 10y ago
  Or, as a better example - rewriting from Electron to Qt rather than Win32. Obviously Electron was chosen to be cross platform. But I still don't get the web renderer obsession. We already have high perf cross platform solutions. Use them.
  - smitherfield 10y ago
    On a related note, it seems crazy to me that for actively maintained, cross-platform, native widget GUI libraries, your options are… Qt. (Not that Qt is a bad library, but it's bizarre that such an important area is so neglected by our industry).
    - TillE 10y ago
      It's a huge undertaking with a questionable business model, especially as most things have moved to the web and/or mobile. But it is amusing that there are way more free, cross-platform, high-quality game engines than GUI toolkits.
    - usrusr 10y ago
      An interesting observation. But isn't the explanation rather obvious? Writing desktop applications to sell for money, that has quietly disappeared. It still exists, somewhere, but so does horseshoe-fitting (the few experts are probably making decent money, but it's a zombie business nonetheless). Between a few established offerings that won't be looking for a new framework any time soon, desktop-packaged web and all the gratis stuff, where would new GUI toolkits find their footing? Desktop means potentially offline and offline means almost all monetization schemes don't apply. (including those that don't work except for instilling hope in investors)
cuckcuckspruce 10y ago
It depends on what efficiency buys you, and what you trade efficiency for. When Windows was developed, we had enough CPU power to do the basic tasks people wanted done with a computer at a reasonable speed - the idea was that spare capacity was being traded for user friendliness. For some applications, even today, when maximum efficiency is necessary, purpose built machines ('soldering together the flip-flops that make up your logic and memory') are still used - it's just that it's often an ASIC that is fabricated.
- jacquesm 10y ago
  > When Windows was developed, we had enough CPU power to do the basic tasks people wanted done with a computer at a reasonable speed - the idea was that spare capacity was being traded for user friendliness. And in many cases that led to an instant drop in productivity. Those old green-screen systems were not pretty but they were quite efficient to use.
  - braveo 10y ago
    I've actually witnessed a very large oil & gas company switch over from those old dos programs to a new win32 program, and to a man, every person who had any experience on the old system bitched about how much slower it was to get anything done. Having worked on the system myself, they were right (this was as a noobie to both systems). There is something to be said for a small, tight system.
    - digi_owl 10y ago
      Some time ago HN linked to a blog from a Norwegian tasked with mailing 3.5" floppies to doctors. This because the doctors insisted on using a DOS based patient journal, as they could operate it completely by keyboard while maintaining a conversation with the patient. I speculate that one reason for this is that DOS allowed each program to have full keyboard access, while Windows and other GUI has to reserve certain keys for managing the UI (switching between windows etc). Thus what was earlier a series of single key presses now involves holding down a modifier for the duration. And that is if the developer even remembered to put in a hotkey for said action.
coldtea 10y ago
>You both do realize that similar arguments could have been made back in the day when moving from, say, command-line DOS applications to Windows API applications - right? No, we don't. With Windows API there's no sandbox and extra embedded language overhead (it's still native code like in DOS, and even optimized better, able to use more available memory than DOS would allow, etc.). Oh, and you also got the benefit of a FULL graphical interface over DOS. Here you have slower performance, extra cruft, bad apis AND the same final output (as a GUI app). Not to mention that the Windows API UI toolkit, while bad, is sane compared to the web stack.
- CJefferson 10y ago
  There was a big new overhead -- in DOS you could write directly to video memory, and control the graphics cards registers directly. In windows you had to go through libraries. Until DirectX came along, it was basically impossible to write even reasonable performance animations in windows, hence the lack of games in windows 2 and 3.
  - pjmlp 10y ago
    That is not true, before DirectX there was WinG and there were quite a few good games done in WinG. The lack of games was mostly due to reluctance of game developers to abandon Assembly and using directly PC hardware, specially because C and C++ compilers were "too slow".
    - kayamon 10y ago
      WinG didn't come around until 1994 though. If you wanted to ship a game in 1990, you had a choice of using GDI or using MS-DOS. And the "assembly" argument doesn't make any sense. You can program Windows games in assembly if you want.
      - pjmlp 10y ago
        Windows only became relevant for home users after version 3.0, actually the 3.1, which was released in 1992, so of course no one was shipping Windows games in 1990! Sure you can use Assembly on Windows and there were a few books teaching exactly that, but you weren't allowed to touch the graphics hardware any more, unless you were doing a graphics driver, and do all those graphic card tricks, specially mode X.
na85 10y ago
>You both do realize that similar arguments could have been made back in the day when moving from, say, command-line DOS applications to Windows API applications - right? Ugh, reddit's standard, snarky response: "you do realize... right?" There's simply no way to get around the fact that by and large, many in-browser apps are poorly performant by any modern standard. To me, it seems like there's a faction within the web development community whose goal is to take things that worked perfectly fine as native apps and re-implement them with poorer performance in the browser, with seemingly no benefit. I wish these people all the success in the world, if that's what they enjoy doing. But for the most part I simply cannot tolerate the work they produce.
- digi_owl 10y ago
  The benefit is to their paymasters, as they get to extract rent (either directly or via ads) without having to contend with software pirates because the actual software logic is sitting pretty in a server cluster somewhere. Effectively we are back to the world of time-share terminals.
  - pjmlp 10y ago
    And they get to use open source libraries without having to share any single piece of their changes.
  - yourapostasy 10y ago
    Ironically, we may yet see a renaissance in native code as more investors realize that the US broadband situation (especially wireless) is not getting better anytime soon. This leads to the realization that always-on, high-speed, low-latency broadband is not a safe assumption. Disconnected operation will become more important as the product space for always-on solutions becomes ever-more crowded. This realization that always-connected apps might be joined by disconnected apps is emphasized when looking to markets across the world. There are more disconnected people in the world than always-on, high-speed, low-latency connected. There is a burgeoning middle class characterized by sporadic, low-speed, high-latency connections, who are willing to spend some money online, for those times they make it online. They might spend pennies each today, but whoever captures those markets is addressing billions of underserved online customers. I'd take a billion $0.01 payments a day any day.
jdonaldson 10y ago
Except we're using divs, markup elements originally intended for research documentation, and using them to emulate modern UI techniques. I don't mind abstractions, but we should at least be using something built to task.
- bananaboy 10y ago
  The most egregious example of abuse of technology for me is the browser version of Wolf3d, where they used divs to essentially replicate the vertical column drawing of a raycasting engine: http://3d.wolfenstein.com/ http://3d.wolfenstein.com/
  - kuschku 10y ago
    That game only works in the US, as it seems. But if you set the cookies document.cookie = "age_checker=pass; expires=Thu, 18 Dec 2037 12:00:00 UTC; path=/"; document.cookie = "is_legal=yes; expires=Thu, 18 Dec 2037 12:00:00 UTC; path=/"; It does work elsewhere, too. (Otherwise it just redirects to your local wolfenstein info site)
throwaway91111 10y ago
Yea, but that came with other benefits, like mandatory accessibility and unified look (at least on the mac). Where are they on the web? Does anyone proactively consider ARIA? Consistency of user interface is just a laughable dream. But hey, thank god we finally have a framework we can inject ads in at will.
sedachv 10y ago
Abstraction is about coming up with general designs from many specific implementations. You can layer abstractions but layering is not fundamental to abstractions. Just because a design introduces extra indirection into a system does not mean that the design is providing any abstraction. Likewise just because a design changes from one implementation to another does not mean anything has been abstracted. Your example of moving from DOS to Windows is really good for illustrating this. DOS had almost no hardware abstraction support, you had to include drivers for a lot of hardware into your application. Moving from DOS to Windows 3.1 only provided abstractions over the video drivers, for example when it came to network cards you still had to use DOS drivers. Moving a text editor from DOS to Windows does not provide you with any abstractions for things like the cursor. It is only changing the API for the sake of having your text editor run on a different platform. Guess what? This is the same with trying to get your cursor and text rendering working on a web browser. There is absolutely no abstraction here, you are just changing your code to work with the very awkward DOM API.

by cr0sh 10y ago

thechao 10y ago

Except that the abstraction layer for the user has remained the same. The extra abstraction layers you're talking about are invisible to the user... while our GUIs are slower, and our processors faster. It feels like, after 30 years, we should be able to have our GUI cake and eat it, too.

JustSomeNobody 10y ago
Where are the Michael Abrash's of today teaching people how to write tight, fast code? Seems a lost art... Yes, I know, he's still around...
- deleted 10y ago
  [deleted]
- desertrider 10y ago
  Luckily there are a few people that still care, just look at the response Handmade Hero has gotten.
  - swah 10y ago
    Those videos on data oriented design were also very interesting: https://github.com/taylor001/data-oriented-design https://github.com/taylor001/data-oriented-design The thing is, using C++ instead of React for mobile development of a simple application would probably make me miss deadlines... So we just stick to whats popular.
    - flukus 10y ago
      Building UI's in something like Qt, GTK or swing was never really that time consuming, especially given the limited amount of controls one screen in a mobile app.
- criddell 10y ago
  Except today's machine language is javascript.
stickfigure 10y ago
Except that the abstraction layer for the user has remained the same. This is absolutely not true. Going to windowing GUIs from character-mode DOS was a massive usability improvement. No more exotic ctl-alt-function key combos (or control-control sequences for WordStar users like me). Going from desktop apps to webapps changed the abstraction layer of how we access and share documents. No more installing software on the desktop. Docs are available on every computer we log into. Multiple people can edit the same document. Maybe you don't care about document sharing and would be happy installing old school word processors and spreadsheets? That's a fair statement to make, but the market appears to be voting otherwise.
- wongarsu 10y ago
  >No more installing software on the desktop At least VS Code has to be installed. It is a plus for Google Docs & Co, but not universal. And in most cases, instead of installing you now have to create an account. >Docs are available on every computer we log into. Multiple people can edit the same document. Those features are completely independent from the platform the application uses. Those features are commonly implemented in web apps because for a long time they had no other choice, but cloud storage and collaborative editing can be equally well implemented in a destop application.
- deleted 10y ago
  [deleted]
- dheera 10y ago
  > Going to windowing GUIs from character-mode DOS was a massive usability improvement. No more exotic ctl-alt-function key combos cough Blender ...
  - paulmd 10y ago
    Unfortunately - the OSS world has a shortage of good UX people, and the engineers tend to be the ones steering the ship. I would point to Eclipse as another classic example of "obviously designed by an engineer". There's tons of functionality under the hood and it's a fantastic jumping-off point for further customization... but its layout is intensely non-intuitive in so many ways compared to a purpose-built IDE. Everything is locked away in menus and "perspectives". If you're writing a Java web app - do you want the Java perspective, the Java EE perspective, the Web perspective, or the Debug perspective? I hear GIMP's no picnic to work with either but can't confirm personally.
gvb 10y ago
The abstraction layer has only remained the same visually, and only for a loose definition of "visually." In the "good old days" the user interface was 640px x 480px (original VGA[1], skipping past the original MDA, CGA, and Hercules graphics cards[2] since they predated "modern" GUIs). Then it was expanded to 800x600, etc. The programs of those days were hard-coded to the graphics adapter resolution. If a program did not support the graphics adapter you had, you had to run your GUI in lower resolution compatibility mode. Sometimes it didn't work at all. In lower resolution compatibility mode, the program's display got uglier and uglier as the screen resolution went up. The abstraction layer today is adaptive and high DPI. Since the abstraction layer abstracts away the actual display resolution, programs (generally) can take advantage of the resolution that is available on a given display without change, allowing a program to run on small hardware displays (phone/tablet form factor) up to mega 4K++ displays, looking better and better as the screen resolution goes up. [1] https://en.wikipedia.org/wiki/Vga https://en.wikipedia.org/wiki/Vga [2] https://en.wikipedia.org/wiki/Hercules_Graphics_Card https://en.wikipedia.org/wiki/Hercules_Graphics_Card
- pcwalton 10y ago
  Precisely. And even Win32, which is being touted in this thread as somehow far superior to the Web stack, was never designed for high DPI apps. It's far worse than the Web stack, with exact pixel hardcoding everywhere. That's why the HiDPI situation on Windows is such an inconsistent mess. Meanwhile, the Web scaled up to HiDPI so seamlessly that most people never even noticed any friction. This is the benefit of the declarative model of CSS.
  - smitherfield 10y ago
    Isn't this a false dichotomy? Why not create more modern, declarative native APIs and libraries, or use them where they already exist?
    - pcwalton 10y ago
      Because it's less effort and more likely to be successful to just improve Web implementations.

pyre 10y ago

There is a point to be made here though that is more valid than the argument against moving away from command-line DOS applications to Windows API applications. Moving from text-based to graphical is a much different shift than what we are talking about here. The idea here is that we are creating many abstractions to get the same basic result. I can't rewrite Atom.io for DOS, but I could rewrite Atom.io to use the Windows API directly rather than being Electron-based. We're talking about VS Code using 13% of the CPU while idle to render a blinking cursor. What benefit does the user get from this? We could render a blinking cursor with less then 13% of a much less powerful CPU years ago.

jug 10y ago
Or, as a better example - rewriting from Electron to Qt rather than Win32. Obviously Electron was chosen to be cross platform. But I still don't get the web renderer obsession. We already have high perf cross platform solutions. Use them.
- smitherfield 10y ago
  On a related note, it seems crazy to me that for actively maintained, cross-platform, native widget GUI libraries, your options are… Qt. (Not that Qt is a bad library, but it's bizarre that such an important area is so neglected by our industry).
  - TillE 10y ago
    It's a huge undertaking with a questionable business model, especially as most things have moved to the web and/or mobile. But it is amusing that there are way more free, cross-platform, high-quality game engines than GUI toolkits.
  - usrusr 10y ago
    An interesting observation. But isn't the explanation rather obvious? Writing desktop applications to sell for money, that has quietly disappeared. It still exists, somewhere, but so does horseshoe-fitting (the few experts are probably making decent money, but it's a zombie business nonetheless). Between a few established offerings that won't be looking for a new framework any time soon, desktop-packaged web and all the gratis stuff, where would new GUI toolkits find their footing? Desktop means potentially offline and offline means almost all monetization schemes don't apply. (including those that don't work except for instilling hope in investors)

cuckcuckspruce 10y ago

It depends on what efficiency buys you, and what you trade efficiency for. When Windows was developed, we had enough CPU power to do the basic tasks people wanted done with a computer at a reasonable speed - the idea was that spare capacity was being traded for user friendliness. For some applications, even today, when maximum efficiency is necessary, purpose built machines ('soldering together the flip-flops that make up your logic and memory') are still used - it's just that it's often an ASIC that is fabricated.

jacquesm 10y ago
> When Windows was developed, we had enough CPU power to do the basic tasks people wanted done with a computer at a reasonable speed - the idea was that spare capacity was being traded for user friendliness. And in many cases that led to an instant drop in productivity. Those old green-screen systems were not pretty but they were quite efficient to use.
- braveo 10y ago
  I've actually witnessed a very large oil & gas company switch over from those old dos programs to a new win32 program, and to a man, every person who had any experience on the old system bitched about how much slower it was to get anything done. Having worked on the system myself, they were right (this was as a noobie to both systems). There is something to be said for a small, tight system.
  - digi_owl 10y ago
    Some time ago HN linked to a blog from a Norwegian tasked with mailing 3.5" floppies to doctors. This because the doctors insisted on using a DOS based patient journal, as they could operate it completely by keyboard while maintaining a conversation with the patient. I speculate that one reason for this is that DOS allowed each program to have full keyboard access, while Windows and other GUI has to reserve certain keys for managing the UI (switching between windows etc). Thus what was earlier a series of single key presses now involves holding down a modifier for the duration. And that is if the developer even remembered to put in a hotkey for said action.

coldtea 10y ago

>You both do realize that similar arguments could have been made back in the day when moving from, say, command-line DOS applications to Windows API applications - right? No, we don't. With Windows API there's no sandbox and extra embedded language overhead (it's still native code like in DOS, and even optimized better, able to use more available memory than DOS would allow, etc.). Oh, and you also got the benefit of a FULL graphical interface over DOS. Here you have slower performance, extra cruft, bad apis AND the same final output (as a GUI app). Not to mention that the Windows API UI toolkit, while bad, is sane compared to the web stack.

CJefferson 10y ago
There was a big new overhead -- in DOS you could write directly to video memory, and control the graphics cards registers directly. In windows you had to go through libraries. Until DirectX came along, it was basically impossible to write even reasonable performance animations in windows, hence the lack of games in windows 2 and 3.
- pjmlp 10y ago
  That is not true, before DirectX there was WinG and there were quite a few good games done in WinG. The lack of games was mostly due to reluctance of game developers to abandon Assembly and using directly PC hardware, specially because C and C++ compilers were "too slow".
  - kayamon 10y ago
    WinG didn't come around until 1994 though. If you wanted to ship a game in 1990, you had a choice of using GDI or using MS-DOS. And the "assembly" argument doesn't make any sense. You can program Windows games in assembly if you want.
    - pjmlp 10y ago
      Windows only became relevant for home users after version 3.0, actually the 3.1, which was released in 1992, so of course no one was shipping Windows games in 1990! Sure you can use Assembly on Windows and there were a few books teaching exactly that, but you weren't allowed to touch the graphics hardware any more, unless you were doing a graphics driver, and do all those graphic card tricks, specially mode X.

na85 10y ago

>You both do realize that similar arguments could have been made back in the day when moving from, say, command-line DOS applications to Windows API applications - right? Ugh, reddit's standard, snarky response: "you do realize... right?" There's simply no way to get around the fact that by and large, many in-browser apps are poorly performant by any modern standard. To me, it seems like there's a faction within the web development community whose goal is to take things that worked perfectly fine as native apps and re-implement them with poorer performance in the browser, with seemingly no benefit. I wish these people all the success in the world, if that's what they enjoy doing. But for the most part I simply cannot tolerate the work they produce.

digi_owl 10y ago
The benefit is to their paymasters, as they get to extract rent (either directly or via ads) without having to contend with software pirates because the actual software logic is sitting pretty in a server cluster somewhere. Effectively we are back to the world of time-share terminals.
- pjmlp 10y ago
  And they get to use open source libraries without having to share any single piece of their changes.
- yourapostasy 10y ago
  Ironically, we may yet see a renaissance in native code as more investors realize that the US broadband situation (especially wireless) is not getting better anytime soon. This leads to the realization that always-on, high-speed, low-latency broadband is not a safe assumption. Disconnected operation will become more important as the product space for always-on solutions becomes ever-more crowded. This realization that always-connected apps might be joined by disconnected apps is emphasized when looking to markets across the world. There are more disconnected people in the world than always-on, high-speed, low-latency connected. There is a burgeoning middle class characterized by sporadic, low-speed, high-latency connections, who are willing to spend some money online, for those times they make it online. They might spend pennies each today, but whoever captures those markets is addressing billions of underserved online customers. I'd take a billion $0.01 payments a day any day.

jdonaldson 10y ago

Except we're using divs, markup elements originally intended for research documentation, and using them to emulate modern UI techniques. I don't mind abstractions, but we should at least be using something built to task.

bananaboy 10y ago
The most egregious example of abuse of technology for me is the browser version of Wolf3d, where they used divs to essentially replicate the vertical column drawing of a raycasting engine: http://3d.wolfenstein.com/ http://3d.wolfenstein.com/
- kuschku 10y ago
  That game only works in the US, as it seems. But if you set the cookies document.cookie = "age_checker=pass; expires=Thu, 18 Dec 2037 12:00:00 UTC; path=/"; document.cookie = "is_legal=yes; expires=Thu, 18 Dec 2037 12:00:00 UTC; path=/"; It does work elsewhere, too. (Otherwise it just redirects to your local wolfenstein info site)

throwaway91111 10y ago

Yea, but that came with other benefits, like mandatory accessibility and unified look (at least on the mac). Where are they on the web? Does anyone proactively consider ARIA? Consistency of user interface is just a laughable dream. But hey, thank god we finally have a framework we can inject ads in at will.

sedachv 10y ago

Abstraction is about coming up with general designs from many specific implementations. You can layer abstractions but layering is not fundamental to abstractions. Just because a design introduces extra indirection into a system does not mean that the design is providing any abstraction. Likewise just because a design changes from one implementation to another does not mean anything has been abstracted. Your example of moving from DOS to Windows is really good for illustrating this. DOS had almost no hardware abstraction support, you had to include drivers for a lot of hardware into your application. Moving from DOS to Windows 3.1 only provided abstractions over the video drivers, for example when it came to network cards you still had to use DOS drivers. Moving a text editor from DOS to Windows does not provide you with any abstractions for things like the cursor. It is only changing the API for the sake of having your text editor run on a different platform. Guess what? This is the same with trying to get your cursor and text rendering working on a web browser. There is absolutely no abstraction here, you are just changing your code to work with the very awkward DOM API.