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.
GDI was originally designed to run on printers as well as screens, where the DPI values are completely different.
The declarative model of CSS has nothing to do with it. You can specify pixel values in CSS if you like.
And many (most?) do... leading to the reinterpretation of what "pixel" means in the CSS spec. Yes, CSS pixel does not mean a physical pixel on the screen.
Integer pixel coordinates are right there in the most fundamental functions:
HWND WINAPI CreateWindow(LPCTSTR lpClassName,
LPCTSTR lpWindowName,
DWORD dwStyle,
int x,
int y,
int nWidth,
int nHeight,
HWND hWndParent,
HMENU hMenu,
HINSTANCE hInstance,
LPVOID lpParam);CSS people still think a grid is a choice of "small" "medium" and "large" columns/rows. Haha.
> CSS people still think a grid is a choice of "small" "medium" and "large" columns/rows. Haha.
CSS Grid is literally Microsoft taking the WPF grid layout and porting it to the Web!
And even now it's still not mature and supported in all browsers.
> we don't need the new stuff
> how about we throw both away to shut everyone up, would that make either side happy?
There's nothing special about javascript the language. The nice thing about web development is that the really fast framework iteration cycles. And everyone complains about them, but as a result we have some fantastic APIs for UI development in javascript land now. (Eg, react.)
What I want to see is someone port those lovely abstractions across to native languages. For example, a port of choo[1] to swift on top of uikit would be gloriously fast, efficient, small and easy to work with.
Edit: I'll add, I frequently see people say that Windows XP was the best OS ever made. Why the rose-tinted glasses? It was the tail end of the era when hardware was getting faster, faster than software was getting slower.
Yes, I know, he's still around...
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.
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.
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.
cough Blender ...
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.
It used to be that OSS was developed by people that actually used it. Maybe it wasn't pretty, it had a steep learning curve, but it got things done and was efficient once you learned how. Often you got fresh perspectives on how an interface could be done, since people got fed up with existing solutions.
Nowadays you get UX experts preaching how an interface is supposed to look like, which mostly means copying Apple or Google. You get tons shiny whitespace. Burger menus, because that's what "everybody is used to".
GIMP with "good UX people" would turn into a bad copy of Photoshop.
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.