10

Web Tools #463 - JS Overkill, CSS Tools, Testing, Uncats

 2 years ago
source link: https://mailchi.mp/webtoolsweekly/web-tools-463
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

JS Overkill, CSS Tools, Testing, Uncats

Issue #463 • June 2, 2022

Advertisement
Stepsize: Fix Technical Debt and Ship 2x Faster Create and view code issues directly from your VSCode and JetBrains editors. Add technical issues to Jira, GitHub, Linear, and Azure DevOps. Link issues to code without context switching and make technical work visible in your codebase. Get a 50% discount for the first 3 months on the team plan using code "WebToolsWeekly". Sign Up with VS Code / Sign Up with JetBrains

Every once in a while I come across a social media thread, article, or forum post that's presenting some kind of polarizing view on JavaScript.

One that caught  my eye recently was on Hacker News where the user is asking the question: Why is the web lately all about JavaScript? In this instance, the user is questioning the use of heavy DOM manipulation libraries or even server-side JavaScript for rendering all content, and questioning why natural back-end languages aren't used more.

The responses to the post are quite mixed but generally in favour of the concerns the user is expressing. The top comment in part says:

"JS isn't bad, it just feels like people think it can solve anything while not seeing issues it adds."

This is true. Now that the DOM is the closest it's ever been to a cross-browser API, I agree that developers should first try to solve problems with vanilla JavaScript rather than assuming every project should use React, Vue, or similar libraries.

Another user answers quite strongly against JavaScript:

"I think JS has actively harmed software development in the past 10 years. It's a bad language, designed and patched hastily that does not work well with humans nor machines."

He goes on to use callbacks progressing to Promises as an example. I don't think I agree with that, but I understand the frustration.

Libraries that help the JavaScript Everywhere approach
Libraries that help avoid the "JavaScript everywhere" approach

Another user says:

"I think this is largely because people are writing JS on the frontend, and it's easier to do SSR with the code you've already got, i.e. render JS on the backend too."

This user and some others point out the shift towards libraries like htmx, Hotwire, Stimulus, etc. (all of which I've featured in this newsletter before) as part of an improved JavaScript landscape.

Personally, I agree with the user who says:

"Mostly, I see the modern crop of JS frameworks as a breath of fresh air compared to what precedes them, though the complexity of what is imported when running an `npm install` is enough to give me pause and a wish for something more minimal."

In other words, we're in a good state right now, but maybe lighter approaches to the problems need to be taken more seriously. I think when people choose a simpler library like Vue over React, that's definitely a step in that direction.

Now on to this week's tools!
 

report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK