Hacker News new | ask | show | jobs
by nightski 2214 days ago
I laugh because you'd think the distributed part would be the toughest one. But nope, it's pretty easy. In fact the client/server model was pretty well understood even in the 90s (or well before that even).

In my opinion what has exploded the complexity is the proliferation of environments. The execution environment of our software provides very few guarantees on what is available (no standard library) or even what language is supported (many JavaScript features and versions with varying support). That, combined with the explosion of devices including input modes, screen sizes, and resolutions has just made it extraordinarily difficult.

We don't even have standard ui primitives like we did in the past. Every major website is expected to have a team of world class designers and reinvent the wheel.

It doesn't need to be this way. But it's the way we have chosen. It has advantages, but I'd imagine the economic cost is enormous.

3 comments

I can't agree more with your "we don't have standard UI primitives" and "every major website is expected to have a team of world class designers" comments. I have been migrating a site from an old to a new shop system and the amount of work for simply displaying product data, options and choosing something to buy is insane. I really believe we've lost something from the RAD era.
Lol - 90s is the era that gave birth to PHP, I'd wager to say very few things were "well understood".

People writing apps with 100s of global variables was the norm.

If you worked with WPF you'll see angular 2 is very similar in spirit - complexity is on par. I don't really see the difference between native development and JS once you start dealing with the same level of complexity.

Client/server models existed before the web and HTML/JavaScript.

WPF is backed by the .NET framework. While the UI framework itself might not be easier than say "React", you have a stable language (C#) with a huge, stable, standard library for all kinds of things from Date manipulation to File IO. There are so many advantages to that ecosystem over JavaScript currently.

For example, I've been using numeraljs for number formatting in JavaScript. This is now un-maintained and contains a bug where if the number is below 1e-6 it shows up as NaN. So now I have to go source a new package for number formatting. This is so simple and core it's amazing I am searching for packages for it.

There is now Intl.NumberFormat but it has quirks also. But this is the crap you have to deal with on a daily basis with JavaScript.

Single machine local apps and apps using direct database connections over a trusted network were the norm - these are much easier to write since they didn't have to deal with client/server separation of logic.

You won't hear me arguing that JavaScript is a great environment to work with - but people argue that JS frameworks are overcomplicating things - when in reality desktop frameworks arrive at the same design decisions.

ExtJS was pretty close, but its license model was never good enough for mass adoption.
There's a free edition for small business and personal use and a perpetual "enterprise" license for $1,895. Not so bad for a commercial product. But yes, no free software.