Early in my career, having mastered Visual Basic I decided it was beneath me and I'd move on to more sophisticated tools like J2EE. When Ruby was born, Java's IDEs and static tooling became stupid, because Real Developers(TM) use raw editors like vim and emacs. Years have passed, I develop less and manage more, but I still use vim and I've moved on to yet other languages.
And now, 15 years into my career, I face the painful realization that VB remains the most productive environment I ever worked in. Yes, it was narrow. If Microsoft hadn't implemented an API for a feature, you waited for the next version.
Therefore, this question does give me pause: Why has the web failed to produce an experience as productive as several (Visual Delphi, anyone?) options over a decade ago? Competition is the web's strength. But it's also its undoing. Personally I think this article is Quixotic—and I prefer a decentralized, ineffecient (JS), sort-of secure (HTTP), competitive web to whatever top-down integration visionaries might push—but I think he—and many older developers—are asking the same question: What happened?
People often make this complaint with flash rather than with VB (although VB is also a nice example - thank you).
The web platform aims to solve a _very broad_ problem. I don't know if you've used VB for big projects - but as someone with lots of nostalgia for VB6 (and winforms) it got very painful around the 20K LoC mark and didn't really support complex UIs in a very efficient way.
There certainly _are_ visual builders for web design (literally hundreds - google "React UI builder" or "Angular UI builder" for some examples). They just haven't received adoption. I think it's because people always get weird UI requirements and the tools break. How many UI designers worked with you when you built UIs with VB? For me that number was 0.
In general, UI is designed today in sketch/photoshop and then a tool like Zeplin is used to export the design's properties to code automatically.
I would say this is dancing around the issue. The fact is, you need a unique UX, or your app will lose its identity in a sea of competitors. You can't build something interesting by using a library of off-the-shelf sameness.
Tools like VB and UI builders really shine with internal, corporate-only apps that put functionality way ahead of form. You can crank out requirements all day long, and the internal users really don't care much. It's just a tool to get their job done.
As a user, internal or not, I strongly wish that your app WOULD lose its identity. I don't want your app to have a separate identity; I want it to look and feel exactly like everything else I already know how to use, so I don't have to waste any additional time getting familiar with it. I don't want "something interesting", I want "a tool to get my job done", and the more you try to push a brand and make your app distinctive, the harder it is for me to plow past all that and get to what I really want to do.
I disagree. I don't know about Flash and I just assume that VB was more or less like an underpowered Delphi. The problem was not tooling at all... at least with Delphi, please see my other comment.
Same here, except replace VB with AS3/Flex. I've since moved on to learn ES5/6/7, rails, and react; react as concept is approaching flex in terms of productivity, but tooling is still not quite there. In terms of raw programming joy, I've not seen an editor as clean as FlashDevelop in years, and I say this as an avid Sublime Text 3 user. Sigh.
Your career seems very similar to mine, I've somewhat recanted on visual designers too, having recently been maintaining some old desktop winforms/c# apps. I think you're being somewhat rose tinted though, those designers could and did shit all over your code from time to time, merging could be a huge headache too.
I still find the middle ground of hand typed code + a decent UI library (Qt, Gtk, maybe swing, etc) to be the best middle ground for productivity. I find it both productive enough in the short term and productive in the long term because it encourages componentization and doesn't encourage spaghetti code in click handlers.
Unfortunately we've mostly seen a transition form visual designers to xml/html and that is a step backwards.
I worked a lot with Delphi ("Visual" was not in the name, BTW) and I predicted more than 15 years ago in a mail list that web programming was going to completely eat most of the GUI programming.
What happened? Short version: 1) Everybody talks about productivity but nobody really cares 2) "Some" people care a lot about the price of programming tools 3) Web architecture provides for free a handful of requirements that were increasingly being demanded and were difficult to fulfill with desktop programming tools.
Well, let me tell you my story. The first company I worked in was developing and selling a ERP to several middle-sized companies- we had about 30/ 40 clients, with maybe half of them requesting customizations and new procedures to be added on a regular basis. We were just three developers, and the ERP was written in C. Not even a SQL database, the access to the DB was based on cursors. Sounds like a nightmare, right? And yet, that has definitely been the most productive environment I've ever worked in.
The secret was a well tested and never changing base library and hyper-specialized developers but especially no deviation whatsoever from the standards ("can we have that string in blue?" "no, not possible, sorry"), a very controlled environment to run on and strictly defined use cases.
And now, 15 years into my career, I face the painful realization that VB remains the most productive environment I ever worked in. Yes, it was narrow. If Microsoft hadn't implemented an API for a feature, you waited for the next version.
Therefore, this question does give me pause: Why has the web failed to produce an experience as productive as several (Visual Delphi, anyone?) options over a decade ago? Competition is the web's strength. But it's also its undoing. Personally I think this article is Quixotic—and I prefer a decentralized, ineffecient (JS), sort-of secure (HTTP), competitive web to whatever top-down integration visionaries might push—but I think he—and many older developers—are asking the same question: What happened?