Try writing a GUI with other toolkits. Hours of tweaking random XML to try and figure out why some constraint solving thing just isn't working...
Despite all the mess, I have an easier time getting buttons on a screen and doing things sanely (once all the fuss is set up) compared to trying to get the ball rolling in Qt/GTK/etc (especially if you're not using Java or C++)
Absolutely not true. Windows forms, WPF, JavaFX, Swing all are much more productive than the vanilla web. Like, how many lines of code does the most basic vbox/hbox thing requires in web technology? Many of them even have dragndrop ui creations, and this XML hatred is downright stupid at this point. How about criticizing the technology and not a random medium for that? Is writing something stupid in JSON inherently better?
HTML is simply a terrible GUI base, JS is quite great nowadays and CSS would be great, but has to provide way too much of what HTML should be doing. But the web ui frameworks are just barely getting at the level of where native frameworks have been in a decade.
That example you mentioned would be just a couple of lines of html with css (which you could inline if you wanted), and there are plenty of drag and drop tools for the web (WebFlow is a modern example, but they have been around for decades).
Why would it need any sort of CSS? Isn’t HTML supposed to be responsible for the structure of a webpage? And of course it can be done, but if we do something like hbox inside a vbox inside a vbox, the resulting code will be ugly as hell (perhaps Webcomponents will help a bit here?). Like, what is the point of HTML at that point? To spam divs (pun sort of intended)?
And there are plenty of other “layouting primitives”, all of which are quite cumbersome. And due to HTML encoding some form of semantic meaning only (though seldom used even for that), drag n drop tools can’t generate easy to read/modify output. Also, without js frameworks, you can’t really just embed another component into it trivially.
And I’m not trying to shit on web tech, JS has absolutely overcome its shitty past, and is quite a likable language nowadays, and CSS is an extremely powerful and expressive system (though this latter is due in part to how shitty html is). My only gripe is with HTML that is simply not fit for the task (as it was never meant for that).
Drag n drop UIs don't really help when you have too much dynamism (like "oh only have this button appear in these conditions", "do this here", etc). And I would say that box layout offered by CSS is much nicer than the constraint layout system _when you have a lot of dynamism_.
Like I wouldn't want to have to deal with an interfrace like facebook in native stuff. I don't think it's impossible, but I feel like it would require a lot more up-front design and correct engineering.
You're right about XML being a medium, just kinda my memories of working with this stuff.
Such a great point. HTML is a terrific way to write documents and TERRIBLE way to lay out applications - especially for lots of different screen sizes. It's not surprising at all to see Google embracing Canvas now to underpin Docs; basically they are admitting that it would have been better to write the whole program in a Java VM or in Flash than to rely on the browser for layout. This is patently obvious to anyone who builds large web applications. Ten years ago we had ASWing, JSwing and plenty of other actual frameworks where you didn't have to diddle around with tons of logic embedded in templates which were embedded in other logic; but thanks to Apple we're still saddled with this wretched Javascript/HTML paradigm that was never meant to do much more than inline some animated GIFs back in the 90s. Yes, it's gotten better (I've been doing this since the 90s, so I know). But it's so inelegant. To some degree this is just a problem with open web standards. It would be better if any one company actually had dominated to the point where they could write a closed standard, because at least it would be coherent and cross-platform. It was a lot easier to write a web app in 2010 than it is now, and it pains me to think how many hours I could have avoided reinventing the wheel if Flash had been allowed to stick around. Any app written entirely now on canvas is just replicating a VM that already existed a decade ago in what was by then a much more mature ecosystem - and was faster then than canvas or WebGL is now.
If I had to pick a stack to do a new web app entirely in canvas, I'd probably choose to port a ton of interface components from AS3 into PixiJS... but the point is, where have we gotten? Ten years from now we'll be writing apps the way they were written in 2010 -- inside a black box in a canvas or VM. The HTML5/JS revolution has been a sham from the start, just a way for one corporation to dismantle another with the side benefit of forcing all of us to rewrite our code from scratch in a crappier language.
I'm not sure I buy the idea that "efficient and easy tooling around a technology makes the technology". We all went through the same Dreamweaver pains.
How come the minuscule userbase of native frameworks have better tooling than the numero uno popular web? It may mean that there is a technical reason in the background.
They solve a simpler and more constrained problem which makes it easier to make tools. Something like Windows Forms are basically WYSIWYG - you drop some controls on a canvas and now you have a GUI. But the GUI will not gracefully adapt to different screen dimension from large monitors to mobile.
> I have an easier time getting buttons on a screen and doing things sanely (once all the fuss is set up) compared to trying to get the ball rolling in Qt/GTK/etc (especially if you're not using Java or C++)
I agree that it's pretty simple to get a button on screen in Qt, but your linked video presents it as horribly complicated. And requiring an IDE to do it is pre-admitting it's complicated.
By the way - Qt and GTK are super-outdated ways to do GUI in C++. Popular, but outdated.
> but your linked video presents it as horribly complicated.
... could you precise that more ? I'm literally just making "new project" > design view > search for the button component > drag'n'drop it ? How can it get more simple ?
(opening a text file and writing "Button {}" is definitely more complicated if we're talking about teaching to beginners)
Just that starting modal with 6 steps to choose various configuration stuff would probably throw a beginner into a loop for a while, even if you could just skip it all. Maybe if this IDE wanted to be beginner friendly, they ought to consider just having reasonable defaults and letting power users change them later - like how web tools tend to be designed these days.
There are visual editors for React. Pretending QT is easier than web technologies because it's easier to drag a component in a visual editor than type text in a code editor is comparing editors, not UI technologies.
Well, the question of what's "modern" in C++ is both deep and contentions. But I won't shirk the question...
You want to be utilizing the features C++11, C++14 and maybe even newer versions of the standard allow you to use, to avoid unnecessary boilerplate, repetition, and arcane-ness of syntax and semantics.
Similarly, the GUI toolkit should not be based on C-like or C++98-like design patterns, when newer versions of the standard allow replacing them with more convenient patterns.
Here's one example, from the Nana C++ GUI toolkit:
#include <nana/gui.hpp>
#include <nana/gui/widgets/label.hpp>
#include <nana/gui/widgets/button.hpp>
int main() {
nana::form form;
nana::label label{form, "Hello, <bold blue size=16>Nana C++ Library</>"};
label.format(true);
nana::button button{form, "Quit"};
button.events().click( [&form]{ form.close(); } );
form.div("vert <><<><weight=80% text><>><><weight=24<><button><>><>");
form["text"] << label;
form["button"] << button;
form.collocate();
form.show();
//Start to event loop process, it blocks until the form is closed.
nana::exec();
}
This is not perfect IMHO; for example, I don't really like the confusing div string with the many < and > signs. But you can put this in a text editor, build it with `g++ -I/path/to/nana/includes -L/path/to/nana/libs -lnana` - and it will just work, on various platforms. No secret sauce, no need for a bunch of IDE dialogs or any special configuration or action.
There is a wide world of applications and development that don't have anything to do with the web.
The films you watch on TV or at the cinema were not created (edited, VFX) using a web browser for a start, and the User Interfaces to those applications are pretty Graphical by anyone's definition...
As a counter point: plenty of desktop software embeds web technologies these days and even AAA games occasionally use them. I think Battlefield was a prominent example for React being used in AAA games for UIs. The Horizon TV streaming box also had a UI written in React (rendering to canvas for performance using their custom Chromium build I think, but they wrote it so the UI could also be rendered to the DOM so they could use it in their web version).
Not disagreeing with what you said, but "not having anything to do with the web" isn't as clear cut as it used to be and web technologies are increasingly showing up in unexpected places.
Having worked on both desktop and web UIs the problem you're describing occurs in both worlds. Usually with web you run into it when you're dealing with a more sizeable app, or fancier things you want to do with your framework.
Sounds like "developer productivity" could be increased by not having to create GUIs. As an end user, I will happpily accept and in fact prefer text-based, keyboard-driven interfaces.
There are different definitions of "simplicity". The entire stack top to bottom may not be simple, but if the developer experience is simple (which it can often be on the web- that's a major driver of the web's prevalence as a platform), that can be what matters.
I have a theory that the people who go on about how the web ecosystem is too complicated are either 1) web developers who are nostalgic for the jQuery days (and have selective memories about those days), or 2) non-GUI developers who enjoy the theoretical virtues of a QT or a GTK but have never actually had to work on a complex GUI, and so can't appreciate the incredible benefits the web has over those other platforms.
Maybe you are too young, but there was a time were we used RADs (Rapid Application Development) environments like Delphi, VisualBasic, Visual C++, etc. Those solutions which are from 1990s, are still years ahead in simplicity vs what you need to do to build a full web solution today (front-end and backend). Of course the web has many other benefits, like 0 install, runs everywhere, always updated, etc., but calling web development simple is just crazy in my humble opinion.
I have worked with both, including Widgets and Quick. I wonder why you think Qtcom is focusing development on Quick, which uses QML (JSON-like syntax) and JavaScript (ES6), while declaring Widgets "feature complete", mostly releasing minor fixes, in other words, keeping it stagnated. The obvious answer for me without getting into Mobile vs Desktop development is: it's easier to get new professionals to use technology as popular as JS (or any other web related stuff), and definitely cheaper for companies to hire said professionals, therefore making it a easier pick for new projects. To summarize the benefits: easier for junior devs to use and because of that overall cheaper/faster deliveries. Note that I'm not saying anything about quality.
Junior developer doesn't mean a developer who just knows JavaScript. Cheaper developers doesn't mean faster or cheaper delivery in the long run. And I don't think brundolf meant cheaper developers.
In my 20 years as a developer I’ve learned that the more polished something looks on the surface, the more complex the codebase under the hood becomes. Things are simple to the end user because of all that complexity.
That is my experience, too. I worked on a SPA with a more or less simple looking table that presented hierarchical data and made them editable with form elements. Under the hood there were hundred lines of very dense rxjs code and the whole thing was communicating with about 10 HTTP endpoints. But it looked simple.
There's preact/compat sub-module for the remaining react features, please inform yourself before inappropriately flaming someone. There some very slight differences https://preactjs.com/guide/v8/differences-to-react/#what-s-m... nothing blocking at all
Seriously. I’ve been doing web development professionally since 1998. I’d love to have OP write a blog post to teach the rest of us about this simplicity.
I've also been doing web development on essentially a daily basis since the 1990s.
I got pretty tired of chasing the fad explosion. Here's what I build everything with these days:
HTML, CSS, JavaScript, Go or PHP, Redis, MySQL or Postgres, Ubuntu & Nginx. Occasionally I'll make use of an ancient version of Sphinx for easy, fast search. I also sometimes mess with Vue for fun, as I happen to be fond of it, but I never find that I need it.
No frameworks. No containers. It's all mostly boring and ancient. I use DigitalOcean for about 95% of everything hosting wise (and rarely AWS). Works beautifully, everything is simple, blazing fast, light on bloat and rock solid.
The simplicity is still out there, if you don't have to care about what anybody else thinks, if you're not trying to earn a living doing web development (everything I work on is self-determined). That's a big if unfortunately. If you are trying to earn a living doing web development it's understood that chasing the latest thing isn't optional, as you can't afford to miss an inflection.
What sort of systems are you building ? I’m guessing some variation of CMS, shopping cart or simple crud backoffice reporting systems.
I’ve spent 14 years working for a small agency building these sorts of systems. I kept up with all the cool new stuff that’s come out and played with it but all we ever needed was 2 load balanced app servers with a single instance Postgres database and we ran some pretty chunky systems.
I’m now looking for a new position and this attitude has come up to bite me. I’ve always been dismissive of the new dangled complexity but turns out there are systems out there that churn through so much data that mongodb makes sense, and large teams of devs where splitting systems into separate services and writing reusable components is required which is where frameworks and inter process communication tools come in.
Most things exist because there is a need for them.
The last thing I built was a CMS structurally (a new non-commercial knowledge service), took about ~18 months to build. I plan to work on it for the rest of this decade approximately.
Currently working on a couple of trading systems (for physical objects, not financial). That's in the ecommerce sphere technically, although they're not monetary transaction based. The first one will hopefully launch in June. I might Show HN it.
Both work perfectly with the setup I described. I build in my wheelhouse though. I can build services like Stack Exchange, Quora, Wikipedia or Reddit (or most things in standard ecommerce, ecommerce platforms). I know what my stack is good at, and what it's not appropriate for. And at this point in my life I know well what I'm good at and what I enjoy, so I look for opportunities there.
MongoDB IMHO also has resource allocation issues, because for a simple two "node" distribution setup you have ~4 times the demand for resources than a "regular" clustered service like Postgre or Oracle. Added to that the actual promised efficiency relies heavy on the data model and has no real easy way to correct once deployed.
Taotau my aesthetic is similar to yours, but it's true that we are a minority. Devs are, as a group, perceived as technology maximalists that love new toys, and the truth of the perception is reflected in the software landscape. Libraries like Angular, RxJs, and Webpack are all packed to the gills with features! It's also reflected by all the "slightly better" options we get in our tooling (yarn v npm) and (scss v css) and (ts v js) and even (ts v es)lint. But without exception, all of those incremental improvements still require that you have total mastery of the browser's native runtime, html5 + css3 + ES6 + dom + async, and all the protocols it enables, HTTP, TCP/IP, DNS, and all the infrastructure that's grown around it all (CDNs and load balancers and hypervisors).
Devops is in a similar state! There is growing consensus that "Container orchestration" is something like the right problem to solve, and people seem to like Kubernetes, but tools like Puppet, Ansible, Salt are still in heavy usage, and are still very useful, but they solve a different problem. Even within k8s there is debate about the proper container runtime (Docker has fallen out of favor for containerd). But all of this assumes total mastery of linux, ssh, bash, systemd, vim, sudo, mount, ps, and all the distribution variations.
Java is in a similar state! Widely considered "boring technology", Java (lang) 8 introduced streams and lamdas, which is a very different way to code (and hence, to think), and emphasizes functional style over object-oriented programming. Then you get to pick which Java you want (Oracle, RedHat, ?), and how you want it installed (installer, brew, unzip, docker), and now your build tool (Maven, gradle, play, ?) Then if you're making a "typical" webapp you have to choose your VCS (git, mercurial, svn, cvs), code hosting provider (github, gitlab), your starting point - Spring, Spring Boot, Dropwizard - which assumes you want REST, when in fact you may want to try GraphQL, which may lead you to nodejs, and it's complexity.
Picking system dependencies is similarly complicated. Components we can choose from - message queues (rabbitmq, kafka, activemq, ?), caches, proxies (nginx, httpd), and here we have to balance many considerations, such as "is there a widely trusted image I can configure and use as is?", and your options, and the details used to deploy them, will depend on every other decision you've made. In fact, all of these choices are made in away that affects some or all of the others, in a way that is complex and difficult to articulate. This is certainly why certain combinations get acronyms (LAMP, Jamstack, etc[0]), and why its very hard to have an intuitive picture.
> Devs are, as a group, perceived as technology maximalists that love new toys,
Make that web devs, if at all. In many other places where software is written, it's closer to the opposite: Managers tend to be minimalists, and the more "adventurous" developers lobby for adopting newer libraries, or use a new language for some side-project.
The premise isn't that what I'm using will make it easy for somebody with zero knowledge to become good at web development in 24 hours or a week or a month, or any such pitch. It's certainly relative.
The relative simplicity is in that the stack is quite set and restricted, with no unnecessary pieces. I don't add to it just because the industry finds a new flavor of the week or something loses/gains popularity. Each part of the stack has a job to do and I don't add to it constantly or constantly turn over what's in it. That stack could remain entirely unchanged for five or more years easily. Where it can be avoided I don't use unnecessary incrementals that add dependencies or complexity (which will often resurface in the loss of reliability/predictability). I often don't use the latest versions of anything unless there's a very good reason to switch sooner than later. I might stick with Ubuntu 16.04 or 18.04 for the next decade if it were a safe thing to do from a security perspective. In that approach, I can place as much of my energy and focus on what I'm building as possible (since everything I build is mine, that's where my priority and interest is).
Web development was always a means to an end for me. It enables me to build things that I want to see exist. I don't love web development unto itself (I'm rather neutral on it), I love what it enables me to do. I grew up in the middle of nowhere Appalachia. An atheist, social liberal in a typical conservative region that was intellectually unfulfilling, uninspiring, non-ambitious, slow (it was also peaceful, green, and with very little crime). The Internet (and Web) showed up there around 1993-1994 and it was like something from another planet, my teenaged brain could see immediately what could be done with the open canvas and from then forward all I wanted to do was build on it. You're telling me there's this always expanding virtual space, seemingly infinite, and I can just build, and build, and build anything that I can think of? And it connects me up to millions (later billions) of other people? And it's not even very expensive to mess with? Holy shit, let's go.
So what I primarily care about is the thing being constructed, and I want my stack to be very reliable, fast and without many frills or unnecessary complexities. I don't want it to get in the way. I don't want to have to fight with it every time I begin a new project, I want to immediately get to building, with the stack being the 'ol reliable companion that just does its job.
If there's something far better nearby (that is reliable + low on complexity) with minimal learning curve, I'll consider it; I switched to PHP 7 very rapidly for example because the speed increase was such a considerable gain and it required very little time/effort to switch. I started utilizing Go because it was easy to learn, simple and fast (I worked with Java in the 1990s, and never wanted to go through that again); Redis is much the same story, I use it for all sorts of things (from caching to various throttling tasks) and it was pretty ridiculously easy to start using vs the enormous value I derive from it. I'd be happy to keep using my current version of Redis for the rest of this decade. I've been using Photoshop 7 since 2002 because it just works and handles ~95% of everything I need in that space (and they can't do anything to force me to upgrade).
It's also worth noting that I handle every aspect of building and operating a service in the beginning. So this adds emphasis on not shaking the stack unnecessarily, the time costs can become large fast.
I started building my own auth about 20 years ago and I've been learning and rolling (improving it) as I go. I've been using a structure that I've been iterating for about the past 6-8 years or so. Hardly a week has gone by that I haven't worked on something related to auth.
I've experimented with just about every approach. Lately I've dumped all forms of social auth (the past couple of years). I won't allow FB or Twitter login, none of them deserve to be trusted with that.
I'm a big fan of try (the service) before you have to sign up, but I always find that among the most challenging aspects to get right.
I know everyone has a different opinion on auth, but I find it routine to do after all this time. The part I find most annoying is probably throttling / controlling abuse attempts vs legitimate users (balancing it well), it's tedious.
I made a custom e-commerce from scratch with PHP and doing the auth system wasn’t hard at all and it is pretty secure. I feel people make auth seem scarier than it really is.
I seriously doubt you're going to do a better job at security than the AaaS systems out there. I couldn't, and no-one I know could. It's a ludicrously complex and subtle field.
How did you evaluate the auth implementations? In my experience it's about as hard to poke holes into something as it is to fix it. Besides, a custom auth implementation doesn't need to be best-in-class, it needs to just be good enough.
> the auth system wasn’t hard at all and it is pretty secure
If there ever was a red flag in what you're saying, this is it.
Auth isn't "scary". But it is hard. You need to know what you're doing in order to implement it from scratch. If you think it wasn't hard, odds are you did it wrong.
Definitely agree with this type of approach - and my experience as a freelancer (thankfully in charge of my tech stacks) is that clients are happy to pay for fast, reliable software built like this.
Web development, even single page apps, and progressive web apps, can be simple if you skip the web frameworks which solve non-problems and complicate things. The most difficult problem in web development is to make the user interface (UX) work on everything from smart-watches to 40 inch 4k monitors. CSS solves this problem, but it's not an easy problem by itself. The second most difficult thing in web development is automated testing across the stack, testing both back-end and front-end, with different user devices. It's complicated and time consuming to write the code that test every function automatically. Third most difficult thing in web development is optimizations, the browser dev tools doesn't say much about what is going on internally in the JavaScript engine.
I was able to create an original OS like GUI, including file system interaction, using vanilla JS (TypeScript) in about two weeks. I am still using it. The actual GUI is just a couple files each comprising about a dozen functions, nothing really complicated.
The nice part is that you can make web dev as simple or complex as you want. You can write your entire application in a single index.html file with no compilation or build step. You can also use various preprocessors, scaffolds, libraries and frameworks to achieve the same result. The choice is yours.
Despite all the mess, I have an easier time getting buttons on a screen and doing things sanely (once all the fuss is set up) compared to trying to get the ball rolling in Qt/GTK/etc (especially if you're not using Java or C++)