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: api.jquery.com/closest/
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):
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.
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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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: api.jquery.com/closest/
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):
First argument is the container, third argument is the array of images and then the options.
Good luck!
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.
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.
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.
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.