Complicated to create UIs? Win32 was complicated. MFC was complicated. GTK is hard
HTML and CSS aren't as complex as those. Not even close
HTML and CSS aren't as complex as those. Not even close
I'd say building Win32 GUIs in C++ was easier than current Web stack.
Same with Java AWT and Swing libraries.
Objective C / Cocoa is more complex - never really managed to learn it beyond basic stuff, maybe with Swift it's easier.
Elm is close to those desktop GUI frameworks, but functional instead of OO.
But Tcl/Tk is the most easiest GUI toolkit ever, too bad the resulting UI does not look professional.
I will have to vehemently disagree. I have no experience with Win32 GUIs, but I still have nightmares about wrangling nested LayoutManagers: comparing that to the current state of the web (especially after Flexbox) is downright absurd.
I am very happy with: Typescript + (Sass|LESS) + framework (Angular|Bootstrap|ReactJS). I think the 'hardcore' devs who would rather avoid using abstractions (frameworks/JS transpilers) will have a torrid time with the front-end.
My two main issues with doing UIs on the web are:
- web stack is terribly unpredicatable; you're trying to force an inherently document-layout-oriented model into a free-form 2D canvas, which leads to layouts exploding whenever user switches browser/OS/device/timezone/whatever.
- the code makes no sense; no matter how crappy the Java APIs were (due to deficiencies of the language mostly), the code you wrote at least did what it said, because it expressed the UI concepts explicitly. HTML/CSS is a huge mess of insanity when it comes to doing UI work. I mean, in what reasonable world should the idea "center this" be expressed as "set the left and right margin to 'auto'"? CSS is full of stuff like that.
(And then there are some silly philosophies like "separation of form and content" which everyone touts, but rarely anyone actually follows; see e.g. grid layouts.)
Not ignoring Flexbox, this is the crux of my problem with web development. There are 8,476 different frameworks, transpilers, toolkits, and what have you that all kinda-sorta do the same things. When first approaching this world you get confronted with alphabet soups of packages all combined to "make front end development sane". Everybody seems to have their own soup, though, and many claim that theirs is the way to do development. The flexibility that so many Node-style devs love leads directly to this impenetrability and fragility.
If they do the same thing, pick one and dig in. I really don't get this argument - walking down the cereal aisle will not generate this amount of antipathy despite the amount of choice available; why on earth should development different?
The optimal taste, texture and crunchiness is different for everyone, you can even default to the traditional oats or corn flakes if the newfangled cereals are too brightly-colored or too confusing for you[1].
I love the JS ecosystem and its Cambrian explosion - lots of ideas (good and bad) being tried out by other people[2] and the good ideas tend to be adopted by the more mainstream projects.
1. This is obviously a thinly veiled allusion
2. This is important - don't be the guinea pig and don't jump onto the latest and greatest.
If I don't like the cereal I've wasted a couple of bucks. Picking the wrong framework can be much more costly in terms of time/money. And with the amount of framework churn you can't even make a good decision because in two years time everyone's moved on to the next big thing.
How to pick the right one: age ("old" but not too old) x community x documentation
For the simplest developments I used jQuery (which is a thin layer over pure JS). If you need more complexity you could go for a higher level framework (but there were not so great things like JavascriptMVC)
PHP gets a lot of bad rap but Fb is built on it
There is no perfect solution. When I see people "praising" Win32 I can just laugh (no, really, anything is better than this: https://msdn.microsoft.com/en-us/library/bb384843.aspx) but I think the advantage of that is that there was only few alternatives so once the learning curve was gone that was it)
I know this was just a throwaway comment, but seriously, I love this site:
For the decades leading up to this stage cross system GUIs with a few simple library dependencies have been an unachieved "easy" task. Web remains as frustrating as ever because now we need it to work on all non portable browsers even on platforms that supports better ones. Then we want new features at an alarming pace that GTK could never normalize across *nixes.
Using the only non-browser that I think sort of got cross system portability working as an example.. I don't think things functioned reliably against the weird m$, Ibm and gcj Java implementations. But since they aren't really GUIs themselves with bookmarks, and familiar menus, no one gets upset when you tell them to replace an odd Java implementation before running a Java program.
1. Cross-platform across mac-win-linux-android-ios 2. Built for a compiled language such as pascal or C++ 3. Built to use native controls 4. Integrated to registered libraries through an interface like activex 5. Accompanied by a UI builder with design-time and runtime states and component builders. 6. Easily integrated to embedded and server-side SQL.
Sometimes we impose too many constraints on ourselves and never actually start anything. Fear of success?
- you could push one or the other
- you could try to support users on both side based on the editor variable
- you could go the new route where only users who care enough to invest do
- you could go the Jed simplicity route.
In the end, IDEs like jetbrains have the new route with plugins for the factions. Most lower investment cases do the Jed route which is more like web neutral. No one who pushed the unwanted editor on its opposing group seems to be still standing.
Applications with native UIs also tend to give a a better impression of responsiveness, and they reduce mental load for your users since they're don't have to relearn much (if anything). They can rest assured that every button and popup menu and text field (for example) functions identically to every other such control they've encountered on the system and in other native apps. This is worth way more than most people think.
One easy example of this is text fields in OS X. Native text fields there all have a form of emacs key bindings built into them to make powerful text navigation and manipulation a systemwide thing. Every application built with Cocoa gets this for free, but more often than not applications using non-native UIs don't implement this functionality at all. This is highly frustrating when you've worked said bindings into your workflow.
Not just an impression. They often are actually more responsive. Except when they hang, which does happen sometimes, but then so do web apps.
ttk does
The initial learning curve was higher, but once you had that knowledge it remained correct and relevant for years- sometimes decades.
And your application UX was faster and smoother. The minor lag between user interaction and UI action that we take as a given today in all but the most basic applications simply didn't exist if you wrote your UI to conform with the platform guidelines.
Even poor performing complex UIs typically did better than today's well written complex UIs - on hardware quite a bit less capable.
We've accepted he current hodgepodge because of portability, but if you've ever worked with the base platforms for any length of time , the difference is painfully clear.
This doesn't touch on how you could expect a consistent ui experience across all applications on an entire platform. It's hard to get that across even two web sites.
We are currently well into a full generation of developers and consumers who are unaware of what's being lost, because most of their interactions are with browser base applications and mobile phones. Waiting a few dozen to a few hundred extra ms for ui to respond is considered normal, if it's noticed at all.
However, displaying a modal window and handling messages in a local window-specific message loop is easy in Win32, and much more difficult in HTML/JS. In general, the browser makes it much more difficult to deal with synchronous operations like modal windows and server requests that require the application to wait on the response. This is how you end up with the overly-complicated mess that is callback-hell, which is then solved by another overly-complicated mess called promises.
So, presentation functionality = A+, foundational functionality for UIs = D.
The problem now is nobody can rationally understand the complexity. At least that was known before.
Perhaps the language may have been a barrier to some back in the day, but complexity vastly transcends that small issue.
Flip side: You can distribute/deploy the host HTML application with reach that will be impossible achieve with a WIN32 or MFC application.
With canvas, every browser has hardware accelerated immediate mode rendering that could be used to create UI toolkits. Looking around the web, there are some attempts to make this happen, but none of them seem to be hugely popular.
Last time I looked into this (years ago), a big blocker was that nothing inside a canvas element is visible to accessibility APIs, so UI rendered in a canvas would be invisible to people using assistive technologies like screen readers.