DEV Community

Josh Chernoff
Josh Chernoff

Posted on

Did the JS community forget clever is not smart?

I'd like to start by saying some words of appreciation for the community. Without the efforts of the few who contribute to the tools and scripts that they share with the world almost none of this could be possible.

With that said I personally feel that their same efforts now maybe the very thing that is undoing / undermining everything.

Clever is bad for the community and thats ok.

Everyone at some point has found a difficult problem to solve that required a difficult solution. You could say that today the problems are growing faster than there are solutions to solve them. I'm also a firm believer that sometimes you just have to make it work and thats ok. With that you should always strive to except things the way they are even if they are "bad" and thats ok. Clearly perfection is the enemy of good. So now that we agree that clever things sometimes happen and we shouldn't feel bad if and when they do lets move on.

Why clever is not smart?

Smart should not be difficult. Smart is simple, smart is easy and it just makes sense to all who perceive it. The whole reason its smart is because its effective, reproducible and easy. All of which tends to be at direct odds with clever.

Why is the JS community trying to be so clever?

First, I'm not an expert js dev. Hell I'm not even really all that much of a mid level dev. Though, I bet you I represent a great portion of the community who feel like they have been completely left out of the industry as a result of the large wave of clever devs from the last 5 years. Thats not to say all the new things are clever and not smart. For example the "destructuring assignment syntax" is amazing and really smart. Most everyone gets it right away and it just works. Sadly that can't be said for the other major advancements in our community. Let's look at Webpack for a moment. Its everywhere everyone is using it though, I bet you not everyone got it right away. I bet you many still don't get it. Yet here it is, quite possibly in at least one project you are working on right now. Ok, let's not blame Webpack, its just a reflection of what everyone is trying to do. It's trying to solve difficult problems and so naturally it sometimes has difficult solutions and we all agree thats ok.

So whats really happening here? Well for starters everyone has been upping their standards, and thats good right? You all know what I'm talking about.

  • "You don't need jQuery for everything"
  • "You should use ES6 today (babel)"
  • "imperative vs declarative"
  • ect..

So naturally the problems are changing and are generally getting harder and thus so are the solutions.

let's look at another example via a popular library. is arguably the best option out there for photo galleries. Naturally that means the majority of new devs are gonna find it on google when they look up how to add a photo gallery in js as I did. Since it favors pure js it will naturally win over lightbox who I think still uses jQuery because this is what we are telling the community to avoid.

So when that new dev goes and reads the example code to see how they can integrate this lib as their own photo gallery and they come across something like this.

var closest = function closest(el, fn) {
    return el && ( fn(el) ? el : closest(el.parentNode, fn) );

What message are we sending to the community when we insist you should be comfortable enough with this code to even start to use this library?

This is a part of the example for just trying to initialize that library!

Sure they noted their was gonna be a learning curve to this library in the read me but, is this what they meant?

I'm begging you all to observe what you believe to be smart and really ask yourself are you just being clever? If so thats ok but, let's do more to not push that as the standard since that is hurting our over all community.

<!-- end rant -->

Thank you. - Josh Chernoff.

Top comments (4)

rhymes profile image

Hi Josh, I agree with you that frontend development has become more and more complicated lately. It will get better and complexity will be hidden behind abstraction. In the case of webpack for example, most JS frameworks are hiding it behind their own configuration, for example like webpacker does for Rails or @vue/cli does for Vue.

I didn't know about PhotoSwipe, I feel there are so many tools out there one can get overwhelmed sometimes. Your issue with it seems to be unrelated with the complexity of the JS tooling, famously known as JavaScript fatigue.

I'm a little surprised too at how complex is the initialization of this library. They want you to install it, paste a giant blob of code, pass a ton of configuration and so on. The example you referred to definitely shouldn't be in the "getting started" page.

Regarding the function, the comment above it in the page has a clue, it's the JS implementation of a function to find the nearest parent. It has to use recursion because the DOM is a tree and you want to start from the current element and go upwards through the branches. It's a vanilla JS implementation of this jQuery function:

I think you can greatly simplify that code (as in skip all of that) because that's the section about building a dynamic gallery from a static list of links (hence the need to navigate the DOM upstream).

This is all you need to initialize (copying from the getting started):

var gallery = new PhotoSwipe( pswpElement, PhotoSwipeUI_Default, items, options);

First argument is the container, third argument is the array of images and then the options.

Good luck!

polymorphicprod profile image
Josh Chernoff • Edited

Don't get me wrong I knew the method was recursive. I was just making a general observation as it how it would be likely difficult for any new dev and that it was not pleasant to read. It also feels like this is becoming common and not just because of the complexity of the problems but almost rather because of complacency. I'm also not saying that is was the wrong way to solve that problem but, rather a clever way to solve that problem. Its the its not what we are saying but rather how we are saying it argument.

rhymes profile image

Regardless of photoswipe, which needs better and updated docs, I'm not pessimistic, I think things will get better in the future.

It's just that at least two things happened all at once which overwhelmed frontend programmers:

  • JavaScript stopped being used by the masses as a byproduct of jQuery scripts and its being a full programming language was recognized and expanded a lot in just a few years

  • People recognized they could optimize and speed up the user experience by using SPAs and PWAs. The main frameworks all encourage you to develop these two types of apps.

The programming language evolution was accelerated on one side and on the other suddenly you have to write complete applications which bring with them patterns, best practices and unique ways to solve problems that are not always the same as backend programming.

Tooling, complexity and the fatigue are byproducts of this.

I'm not sure it's just programmers trying to be clever, in part maybe, it's also that things have gotten way more complicated than before.

Suddenly you have to deal with functional programming (which you were already using in jQuery), with reactive programming (a little hyped imho), with promises everywhere, with state management, with schemas, with graphql instead of just RESTy Ajax, with transpilers and linters, with new paradigms, with new frameworks and libraries, with JavaScript on the server, and more. All of this without decades of established practices.

It's going to take time, even just to weed out clever tricks or to hide them behind nicely thought interfaces.

Thread Thread
polymorphicprod profile image
Josh Chernoff

I appreciate and respect your positivity. I didn't write this to shame people or dog on the community as much as I wrote this to hopefully just make people aware of what its like currently and to hopefully inspire change. All of which is not easy to highlight without calling out the current short comings that I'm seeing being trends. For the same reasons I think the destructuring assignment syntax is amazing is what I think the JS community needs more of. That is we need to make things readable again. I agree that will inevitably happen as we progress but, that is not an excuse as to why we can't start today. For as much as we push on the community to embrace new ecmascript standards and to avoid old trends for X reasons we almost never hear people say to follow some of the very basics of any program language.

…the ratio of time spent reading versus writing is well over 10 to 1.
We are constantly reading old code as part of the effort to write new
code. Because this ratio is so high, we want the reading of code
to be easy even if it makes the writing harder.”
β€” Robert C. Martin
Clean Code: A Handbook of Agile Software Craftsmanship

It's like we put so much energy into the new X thing thinking its gonna make our day that much better when in reality the truth was in plain sight hidden by our own doing.

Your worst enemy will hide in the last place you think to look.