Hacker News Reader

I was with you until "... so is writing a React frontend".

No. No it's not. Making a functional UI in visual basic is childs play compared to the absolute cesspit of NIH and feature treadmill that frontend web development has become.

You are gatekeeping with strawmen.

I was trying to compare like for like on features. Slapping together a few fields and a button in react and posting the results to an unauthorized endpoint doesn't feel any more difficult to me than the same in VB.

However, it's certainly an order of magnitude more complex to use react with all the features expected of modern development with design systems, auth/z, logging, monitoring, etc.

I'm deploying react to a CDN for a living, and I would have no idea how to instruct someone to "slap together a few fields and a button" and put it somewhere meaningful. As a kid, I remember making full blown D&D character sheets based on an easy Access backend. You could even print them out.

I want to, but I just can't back any claim that things have gotten easier for pretty much anything. With a ton of extra power on the compute side, parts of the machine have gotten attainable. But nothing about the process is easier along the way.

    I want to, but I just can't back any claim that 
    things have gotten easier for pretty much anything.

I think it's easier for a seasoned developer to spin up and deploy a "real" Djanjo/Rails/whatever app with decent table-stakes features like secure auth.

But everything else is harder.

I have zero idea how to tell a new developer to get started in the hobby/industry these days.

The real problem IMO is the absolute churning shitstorm that is front-end development. I don't know how it got so bad, so quickly, and stayed that way for so long. We as an industry are not going to be happy until it takes at least 50 toolchain steps to produce a simple "hello world."

Getting a rails app up and running used to be somewhat easy. You did have to ssh into a machine, but that wasn't that complicated, all told. Comparable to standing up a BBS way back in the day. Restated, if you could have a machine that was dedicated to the serving of something, it wasn't that hard back in the day.

To that end, I suspect telling people to just stand up a node server is where to start hobbyists off? Still very complicated with the division between front and backend that is difficult to see for new folks.

And I fully agree on the ridiculous churn. Having zero stability in documentation and how to do things has been terrible for our industry. What we have gained in better ways seems to mostly be lost in all of the previous ways that used to work.

A-fucking-men!

On the other hand, I never understood how to build anything with Access despite having a book on it as a teen.

Web tech, even in its early forms, was much more obvious to me and I could run code in the browser's web console. I could find JS snippets online, paste them into index.html, and open the page. I found VB/Access far more confusing than that.

These days I help beginners pick up web dev and I think HNers overestimate (if not circlejerk over) how hard it is just because create-react-app does a lot of things. Client development always had a bunch of specific knowledge you had to learn, and the fat stack of supporting software you generally use (IDEs, Xcode, node_modules, SDK APIs, browser APIs, etc) was always a behemoth.

Access was the hard part of those things. Using a form builder to get a basic form up and build some interactions, though, was trivial back in the day.

Were there complications? Of course there were. Would I recommend some of those practices to build something? Not necessarily. But I can't get behind any claims that we made any progress on making things easier for hobby programs.

Closest we have to that, would be the scratch programs my kids have been making.

Hilariously, the best thing for making games and similar ideas that my kids would have, is going to be Mario Maker. By a long shot.

And where would you meaningfully deploy a VB form other than your personal computer? Likewise, you don't need to deploy react at all if you are running it locally, just npm start. You can even print to PDF from the browser. You can use LocalStorage for persistence. Feature for feature, it approaches a local VB and Access project for about the same effort. I've taught many beginner students with this technique.

My point was not that modern deployment is easy. Nor that modern react with all the trimmings is easy. My point was that the nostalgic view of VB is reductive and skips all the things we now consider essentials. And for the effort involved, we get much more done now than ever before, albeit at a much greater complexity cost and steeper learning curve.

I'm mostly with you on this, in that running `npm run start` or whatever feels close. However, it doesn't give you the state management in near the same way. Nor does it have anything close to the form builders that you could use back when. Things can feel similar, if you ignore all of the other tooling that we had back then.

Dreamweaver was surprisingly close for building a form or similar. We tossed a lot out the window when we decided to focus on the HTML side of that equation. I swear it is like a lot of the older assembly versus C that existed years ago. Only, we decided that we did, in fact, care about the assembly.

I wonder how doable it would be to make a drag drop interface for building react complete with double click to add click handler and focus on that new code kinda stuff.

A better comparison is with VB’a spiritual successor: Power Apps.

Not sure, but I think VB is still responsible for most of MS’s security threats even now. It makes sense for MS to try to EOL

I saw a talk on Power Apps at ATL DEV CON this weekend and was blown away. The only downside is it can only be used internally, with AD M365 logins. It won't work with B2Clogin, and it won't work without authentication.

But, that's the only way I used VB6 - for internal software.

> You are gatekeeping with strawmen.

Love the image. "Hey you! No visual aids go into this town! One more step, and my strawmen will React!" But the accountant with the abacus continued towards the east gate. He squeezed between two strawmen, who didn't React as much as the gatekeeper was implying.

What does NIH stand for?

Don't forget that most of those VB apps you've seen were hacked together by amateurs, engineers, business and finance people, not professional programmers. It was great for their productivity. They automated their work, and they couldn't have done it in C.

BASIC = Beginners' All-purpose Symbolic Instruction Code

You should think about what the alternative was at the time: Mostly C/C++

VB6 you would have connected to the db by the end of the day. C/C++ you're still trying to handle WM_ERASEBKGND

Well you'd probably be using MFC which handled most of the windows messages.

Or wasting time figuring out whether you should switch to ATL

Borland was the alternative. You could throw together a C++ database application in a day. And if you used Delphi you even could not justify a coffee break by the long compile time.

Exactly! The little Visual Basic I saw was always and entangled, manually tested, spaghetti code mess. Devs were productive only at the start of the project and slowed down to a crawl as things got more complex.

    Devs were productive only at the start of the 
    project and slowed down to a crawl as things got 
    more complex.

...and as your productivity declined, your manager thought you were a dolt or perhaps had some kind of drug problem that was interfering with your work.

Because he saw how easy productivity was at the start ("look! you just draw a button with your mouse!") and couldn't understand why it quickly became a nightmare.

My favorite VB6 moment was as an intern. I opened a project that lived on a shared drive that wasn't in source control. Visual Studio popped up a dialog warning that I didn't have the proper license on my PC for the parts of the app that interfaced with Excel. Then it cheerfully deleted the offending project files and sections of code and saved it. On the shared drive.

Big oof right there. Thankfully, I've never had that happen on the job. The lack of meaningful version control in most VB projects is dangerous. It's like trying to operate a chainsaw without a handle. Whenever I get a new VB project to rewrite I always have to stop and remember "don't touch _anything!_". Then I sneak around like Indiana Jones in a lost temple filled with traps.

I make a good living turning VB+Access messes into something modern and stable. After a point it's such a huge mess that it's either rewrite or leave it untouched forever. Sometimes it's important enough to pay someone to untangle the whole snarl of cables and turn it into a modern project that can be handed off to a dev team. Thankfully it's usually pretty straightforward to get all the data out into a modern SQL database and whip up a bunch of CRUD forms in react. The hard part is what to do with all the bad data that is inevitably in the Access database. That often takes the most time, just getting them to clean up all the bad data.

Maybe not all apps need the complexity but portability.

Most of those were built by non programmers for "free" (no extra pay).