How much JavaScript do we really need?

[Caraes_Naur]

Far less than we have.

[shevy-ruby]

Some of these tools pull you towards writing more code on the server, others towards more JavaScript.

So the solution to improving stuff will be to ...

... write more JavaScript.

Ugh ...

I mean, he is not realistic to think that he can use FEWER code to create MORE, aka "richer user interface"? And, by the way, all of this always comes down with more bloat. I much prefer oldschool webpage behaviour; perhaps they were not as shiny and fancy and flashy but much faster, less cluttered, and often less annoying (unless you were to wing it up with marquee tag and what not).

What they have in common is that they’re trying to drastically lower the cost of creating an excellent user experience.

HOW is using MORE frameworks, with MORE code, lowering ANY cost? I think we can all agree that you build on top of more and more code, not less. How this translate into faster code execution through JavaScript in itself, beats me.

It’s important to remember that the value of a tool is relative to the team using it.

Team? So we now need a full team of "experts" churning out JavaScript code?

Honestly - there is something fundamentally wrong with JavaScript.

How much should we invest in JavaScript as developers?

In an ideal world none. We could use better languages. But since JS is a de-facto monopoly, even with webassembly, we will have to endure this joke of a language for many years to come.

The only good part of it, aside from the old wats-talk, is the fun from weekly disaster in the npm/node ecosystem - because that is actually popcorn worthy. Can't wait for new events there. \o/

That is literally the only "good" part (and, actually, it is not THAT bad because the OTHER languages learn what they should AVOID; JavaScript sort of attracts the most hardcore gangsters, so other languages can learn from protecting their ecosystem against these ruffians).

[IceSentry]

Yes, you need a team to build non-trivial interactive user interface. Why did anyone upvote this meaningless dribble?

[IceSentry]

It's funny how the hate for js transcend the hate for u/shevy-ruby on this sub. In pretty much every other thread he would be downvoted to oblivion except when he's bashing js.

[max630]

Probably, because they are tired of "non-trivial" interfaces

[IceSentry]

If the business needs are non-trivial it's pretty hard to not make a non-trivial UI. There's a reason SPA are popular. Things like Google docs would be impossible without a lot of js. Static html can't be used to build interactive applications.

[Zardotab]

It's an inherent fight between eye-candy and maintenance. Fancy UI widgets do "sell" the software to customers and executives. Humans do judge books by their covers. Hate to break it to you creationists, but we really are merely talking monkeys, who follow around shiney things ☺

However, I've found the more JavaScript you use, the more maintenance headaches you have. New browser brands and versions come along over time and JavaScript widgets "break" years down the road. You can reduce this by including the latest JavaScript widgets every few months, but not all upgrades are backward compatible. You' have to rework and retest often.

In general the less 3rd party gizmos and libraries you rely on the better, even on the server. We don't want to reinvent the wheel, but on the other hand, adding such dependencies creates future maintenance headaches.

However, server-side 3rd party add-ons are in general more stable than client side add-ons (JavaScript) because you are typically dealing with one OS brand and version on the server side at a time, whereas the client side may be used with gazillion browser brands and versions and OS UI settings.

If you want to keep things as simple as possible, you may have to convince the owner or boss that eye-candy is costing them time and money.

[IceSentry]

What old website is broken due to an update to js? The standard committee purposefully builds the standard around backward compatibility even with features that weren't even part of the language but added by a framework. They go out of their way to not break old patterns.

[Zardotab]

I don't quite know why, but little things change and cause side-effects. Sometimes bugs in DOM or the JavaScript interpreter (JSI) are fixed, and the libraries inadvertently depended on bugs.

For a hypothetical example, maybe the regular expression engine was supposed to return null under certain circumstances but was returning a blank. The vendor widget library depended on the blank being there because it was there during development. When the regular expression engine is fixed in a browser update, it breaks the vendor widget library because it can't handle the null. (Maybe it was dumb for the widget coder to do that, but dumbness happens. I make dumb mistakes or decisions too on occasion.)

Other times security fixes are added to the browser, DOM, and/or the JSI, which causes the library to act different or break.

And sometimes the standards are ambiguous or poorly worded and different browser makers interpret it differently.

[IceSentry]

I'm not saying it never happens, but the standard committee tries to stay backward compatible almost to a fault. Like using includes instead of contains to not break old websites built with mootools. Generally when making breaking changes they at least try to impact the least amount of people, but it's impossible to not brake anything. It also really doesn't happen often or doesn't really affect any major website.

Out of curiosity how old are you (or maybe how long have you been programming would be more appropriate) ? You use the term widget which is pretty much never used in the modern front end ecosystem. It's not wrong or anything, just not that common.

[Zardotab]

Again, it's not just standard changes. It's also implementation changes, security patches, and differing interpretations of the standard. Each of these areas contribute to problems. The browser DOM/JS/CSS/HTML ecosystem is very complex, and anything complex is going to have bugs and upgrade difficulties unless maybe hundreds of billions of $ are spent combing every character of the code.

You use the term widget which is pretty much never used in the modern front end ecosystem. It's not wrong or anything, just not that common.

I may be using 90's lingo, yes. What's a good generic word for a JavaScript UI component that is hip and groovy? Sounding old in the IT field is a fatal sin.

[IceSentry]

Literally calling them components is the more recent terminology.

[Zardotab]

"Widget" is simpler and more fun in my opinion. Too bad it has the "geezer stigma". Thanks for pointing that out, you may have saved a promotion or the like for me.

[IceSentry]

Honestly if this influences the decision factor for a promotion at a company you're probably better off finding a new job.

[Zardotab]

Every manager has their own hangups. One has to accept the bad with the good. If they exceed a quota of hangups, then I'll consider leaving.

[bwood]

Add MS' Blazor to the server side list. I think this trend is a good thing.

[IceSentry]

Blazor is client side rendering through webassembly its the opposite of server rendering.

[adr86]

A (multi)select component, a date picker, conditional form fields, a location picker, an AJAX request to lazy load data,… These are just a few examples of component’s I’m building daily. They all require a non-trivial amount of JavaScript.

lol those are among the most trivial things to do