Hacker News Reader

>If frontend was bicycle science then I must have missed that in my 10+yrs writing frontends with JS+CSS.

What you've said directly proves OPs point - you've missed the central message: UIs used to be bicycle science before everyone started using JS to make them.

They mentioned VB as in visual basic. GUIs with VB/Delphi are a case of dragging controls to where you want, pixel perfect every time on every desktop.

Web technologies are not designed for desktops but for building on top of HTML, so everything is an abstraction to get back to something that used to be possible with zero experience and sometimes even zero programming. For example, a simple notepad clone can be made in Delphi without a single line of code.

Now you need to 'full stack' to even know what's going on under all the layers just to place a control at an x,y and even then it can't be guaranteed because of all the different browsers, css edge cases, and other caveats.

> For example, a simple notepad clone can be made in Delphi without a single line of code.

Sure then I agree, making simple toy apps with VBasic and similar tools was easier. It was also easier to make websites in Dreamweaver back in the day than really learning HTML+CSS.

That doesn't really solve any serious problems, nor the reasons why we've adopted such extensive frameworks.

What I disagree with is that it's getting harder or messier or worse to build frontends. I've seen significant improvements in the last few years and I've told many people that I'm actually liking making JS-driven apps for the first time in my career (Typescript has played a big role in this as well, not just React/Vue). I'm no longer scared of deploying large-scale browser apps since it became clean component/redux driven stuff instead of a tangle of JQuery + other crap shoot combinations.

I'm sure the pace of change to outsiders can make it seem like a long series of failures and flailing about, but to those who have been following it there has been a relatively consistent evolution of ideas. One that more recently has gotten us the closest to desktop quality software than ever before - even though 'desktop widgets' was a dirty word in the frontend world for a long time - IMO largely because early attempts were too bold and complicated for the capability of the browsers at the time.

> That doesn't really solve any serious problems

Yes it does. It meant that less-experienced developers could make nice programs that near-zero-experience users could immediately take advantage of, with the same look and feel as every other program they already used.

It went far past "simple toy apps"; maybe not suitable for making a distributed network app, but for making something useful for an accountant or an administrative professional, it was perfect.

> I'm sure the pace of change to outsiders can make it seem like a long series of failures and flailing about, but to those who have been following it there has been a relatively consistent evolution of ideas.

I've been following this since the 90s and it went from "a nice way to publish documents to everyone" to "a bastard environment with a shitty language that is inconsistently implemented" to "overburdened with frameworks to paper over the fact that this system was never designed for this at all".

Great, 20 years later we have some huge massive framework that takes ages to learn even for someone who used to know JS competently, just to draw some basic widgets and data tables that we used to be able to drag-and-drop into place in the 90s.

> What I disagree with is that it's getting harder or messier or worse to build frontends.

Maybe it's slowly improving in the browser now, but until we have things on the level of Flash as far as interactive design for non-developers goes, it's still massive steps backwards for no real gain besides the self-gratification of JS devs.

Re: [That doesn't really solve any serious problems] "Yes it does. It meant that less-experienced developers could make nice programs that near-zero-experience users could immediately take advantage of, with the same look and feel as every other program they already used."

Let me clarify. I am or used to be what's now called a "full stack developer". I am not really an intense "coding wizard", but can do ALL parts of the development cycle reasonably well, including talking to the customer to understand what they need and why they need it. Those good with code details tend not to be so good at the analyst and communication side of things. There are exceptions, but I'd say this is about 85% true. These tools made full-stack-developers possible and relatively cheap.

This also means each department (group within an org) can have its own programmer/analyst who can focus on and learn the domain, now it has to be more centralized in order to have specialists.

Tools like VB-classic, Delphi, PowerBuilder etc. meant I didn't have to micromanage a lot of UI details that either take a lot of time or require hiring UI coding specialists now. I could do both the analyst/people side and the technical side at a good clip.

Current web stacks mostly killed all that, requiring either layer specialists or spending a lot of trial-and-error time fiddling with browser UI's trying to get the friggen UI to match the sketch. Before if the customer asked, "can you move that button to the right just half an inch", it was 5 minute job. Now such can take 2 days if it goes against the grain of the UI framework. It's ridiculous. Sure, an expert at the UI framework may instantly know the magic CSS trick, but it's only obvious to a UI framework expert, NOT to generalists like me.

It now often requires rocket science or a manual genetic algorithm (mass trial & error) to move that damned button half an inch on the customer's screen.

> PowerBuilder

I used this tool at the State of [redacted] Dept of Taxation to develop the whole system. The database was Oracle (I think) and we would write the backend code as such:

1. Copy the 2019 code function "VERIFY_TAX_RULE_147B_2019()" to "VERIFY_TAX_RULE_147B_2020()"

2. Follow this list of rule changes for this rule to change the function

3. If there are any 2019 functions in this function, make a ticket to copy+paste those in a similar fashion for some other developer

4. Close ticket

5. Get another ticket

The front end for the forward-facing revenue agents would also get updated in a similar fashion, one Power Builder form for each year and window they needed, so if you opened 2020 taxes you would get "WIN_FORM_PAGE_A317_2020" and if you opened 2019 or 2018... you get the idea.

It was a horror from the usual "software engineering practices" standpoint on stuff like code re-use, but it was super easy to do and based on the risk analysis it was the best/easiest/cheapest solution to be able to test, review, and ensure the accuracy of EVERY tax rule we implemented with iron-clad certainty.

Someone in QA would just go to each function, make sure it calculated things correctly based on the requirements, and do a few other checks. We had a big QA department that would do test driven development on each pull request (if it failed, you went back to fix it again, so since we used Visual Source Safe we ENSURED it worked the first time; you know what I mean if you used VSS) and sit down with the developer for each function and go through it in a heavy review. I can't imagine trying something like that in React or whatever, you could never ensure the software would always behave the same way each time with the network latency and huge underlying security concerns for the framework and a bunch of other issues we would have had to overcome to prove it worked correctly every time. Backend frameworks would be even WORSE for our risk profile.

Most importantly: no one cared what the damn UI looked like as long as all the buttons and text boxes were there in the designated configuration. They were all Windows 95-style UI boxes and I doubt that the front desk agents would have been happier to use some Reactified "pretty" stuff.

The story is just to say that I agree with you wholeheartedly that the UI/UX space has exploded with useless garbage you don't need in a simple, boring business tool and 95% of software is just that, simple and boring.

Each such VB-influenced tool all had their weak points. But overall they seemed moving in the right direction as each vendor learned from each other's mistakes. Power-Builder's difficulty in code share-ability was a specific design flaw of the product, not of the general concept, and perhaps fixable on a later version.

As far as most business software being "simple and boring", I wouldn't necessarily call it "simple", for the domain rules can get intricate. But it doesn't need buzzwords like blockchain web-scale AI or what not.

Desktop GUI's reached a pinnical around the late 90's and web UI's still cannot compete on simplicity and functionality. DOM-based emulators tend to break on browser version updates. We need a dynamic GUI-over-HTTP standard to allow us real GUI's on a browser or browser-like interface. Something like YAML, but more interactive. #MakeGuisGreatAgain!

I agree with the central thrust of what you're saying here; its definitely easier now than it has ever been, and things are now moving towards the simplicity of how it used to be when creating desktop apps using web tech with the advantage that they're cross platform.

However this improvement is in spite of using a tool designed for a different medium, rather than because of it, and the years and abstractions its taken to get here express this.

Having said that, cross platform is better going from web to desktop than the other way round.

Re: and things are now moving towards the simplicity of how it used to be when creating desktop apps using web tech with the advantage that they're cross platform.

I suspect we'll need a new web standard that's GUI-friendly. For one, have the option of sending raw coordinates to the browser and have the (optional) layout/flow engine be on the server. That way you only have ONE layout engine instead of a different one for each browser version/brand, which is what we are really dealing with.

     A. app -> server layout engine -> coordinates -> client -> screen

     B. app -> markup/JS -> client -> DOM -> coordinates -> Screen

The problem with "B" is that each DOM is slightly different: different browser brands and versions. You have to test with about 50 variations to be sufficiently thorough. And as time goes on, they break more code. A more accurate diagram would fan out after "client" and have DOM1, DOM2, DOM3, DOM4, etc. Since the browser is dealing with raw coordinates in A, there fewer things to go wrong. Thin client = thin errors.

Another advantage of A is that you can choose different layout engines not bound to DOM standards and quirks. Or even have none and go WYSIWYG. (Web browsers don't really do WYSIWYG well in practice, partly because font-to-widget-size-ratios are not standardized.)

"A" is more stable. It's better factoring, period.

The GP was saying VB-classic, implying that he's talking about windows desktop apps. I think that's what he's saying about layout engine stuff; layout engine is only a thing on web apps. Everything you're talking about is re: web apps, just older style web apps with JS+CSS in the past 10 years. For old school windows desktop apps you don't have to worry about client rendering, client's browser size, responsive (mobile vs desktop), etc. I believe GP is making an argument that most of these business-use web apps could've been windows desktop apps where the frontend takes half the time and team to build.

As I mentioned in my comment, JS frameworks by adopting a reactive model are getting closer to how desktops apps function. That has always been the goal, making interactivity as capable and flexible as 'native' desktop software while still remaining consistent, accessible, and cross-platform in the browser.

One of the biggest motivations of these JS frameworks early on was due to the adoption of smartphones becoming the primary computer interactions. The other was the SaaS model, creating far greater demands on what needs to be done in a web form.

I've developed VB and cross-platform stuff like Qt and wxWidgets, and that stuff is no easier than the stuff I'm building with JS every day. HTML templates + automatic reactive bindings via Vue and a Redux/Vuex 'backend' are very simple.

What's more complicated and still shitty with JS frontends is the wider frameworks with Webpack, that come with a hundred packages that break often. That is the most painful thing I have to deal with day-to-day. The learning curve once you add in Babel, PostCSS, the various code optimizers and linters, TypeScript, etc can be quite intimidating.

But that has more to do with the tooling than the general approach being taken in modern frontend development.

Re: As I mentioned in my comment, JS frameworks by adopting a reactive model are getting closer to how desktops apps function. That has always been the goal

And they keep failing because they throw layers at the problem: chicken-wire is used to fix problems caused by the duct-tape on the prior layer, etc.

It's becoming pretty obvious that Yet-More-Layers only exacerbates the problem. It may get "solved" by having fewer browser choices, but then the evil of oligopolies will kick in and we'll be back to the IE-esque problems, one of the most hated browsers.

Re: I've developed VB and cross-platform stuff like Qt and wxWidgets, and that stuff is no easier than the stuff I'm building with JS every day. HTML templates + automatic reactive bindings via Vue and a Redux/Vuex 'backend' are very simple.

My experience is different, and I observe similar bottlenecks at various orgs. Those JS-centric frameworks are harder to trouble-shoot when things go wrong, and different browser brands/versions render them different and/or wrong. With the VB/Delphi-esque tools, things show up exactly on the screen where I tell them to go: there is no if, ands, and buts. They follow my exact commands like dutiful robots. The technology is MY slave instead of the other way around: Thou Shalt Go At X=37 and Y=200. My Will Be Done! (Cue thunder clap.) React/Vue et. al. often go, "Sorry Dave, I cannot do that, but I'll do it my way anyhow." (I recommend GUI's use vectors instead of pixels these days, by the way. They are potentially equivalent when needed.)

Further, the quirks in pre-web GUI tools were getting ironed out over time: they got better with age. The web seems to get messier with age because of the layer-to-fix-layer problem above.

> For old school windows desktop apps you don't have to worry about client rendering, client's browser size, responsive (mobile vs desktop), etc.

Is this just a matter of there being less ways to interact with the apps back then? Everyone had the same platform, same hardware, same screen resolution... etc. Plus, accessibility was an afterthought. Now, users have bigger and more varied expectations.

> JQuery was the standard before JS frameworks took off

jQuery was never a standard any more than it is now. It was popular even driving a bizarre fundamentalist cult of personality worship, but that by no means makes it a standard. In technology a standard requires wholesale adoption opposed to mere frequent consumption, even if not enshrined by a document (de jure). For example there was never a time that jQuery was required in any commercial capacity either to seek employment, perform work, or deliver a finished product. Claiming that I hated jQuery during its prime didn't stop me from closing a job interview, but it did turn a few heads.

* https://en.wikipedia.org/wiki/Technical_standard

* https://en.wikipedia.org/wiki/De_facto_standard

* https://en.wikipedia.org/wiki/De_jure