We have all, at one time or another, looked at some horrid wall of JavaScript code cursing silently within ourselves, knowing pretty well that ther...
For further actions, you may consider blocking this person and/or reporting abuse
A lot of these one liners are just bad coding standards in general. Each line should have 1 function/operation.
Take for example your "Debounce Event Handling" example. If you need to debug that with a breakpoint, you really can't without formatting it. And the "trad" way is more readable.
Also just looking at this
),ms);};};That's seriously bad readability there.Code IS READ more than it is WRITTEN make things easier on your readers
This. Just because it can be written in one line doesn't mean it should 😊. White space is free. Write elegant readable code and let the bundler do its job. No need to write like a bundler. The article could be better named as "using modern JavaScript"
For object cloning, just use the built in
structuredClonefunctionSome of these are things where you're better off using a library or core function.
For example, the CSV parsing will explode if you escape or quote commas.
Id also add that it didnt take into account the hidden Byte Order Marker (BOM) that .xlsx files tend to have.
Remember we write code for colleagues and future selves.
@peboycodes some of us here are probably a senior dev, or been developing for quite some time. The common theme is that just because we could we shouldn't. While you demonstrated a quite a few APIs in JS, to us, one liners are usually pain to read and debug. To an up and coming developer, these may look cool, and I'm afraid it is just that, nothing more. A good code reduces cognitive overload, reduces complexity, increases maintainability and performance. One liners like
.flatare great, however, fitting a map, reduce and other logic, with minified variables is no so good. You are showing a lot of efficiencies in your examples, and I don't want all of our comments to diminish the value of that. Great work ✨. I wish you good luck in your long journey as a developer. I strongly believe you'll write another article talking about things we commented on, because we have been there in this phase as well 😅In addition to what @jonrandy said,
JSON.parse(JSON.stringify(item))is not a true deep clone of an object - if before doing that, you had the same reference repeated in multiple objects or arrays, then after you have multiple copies of that reference. There are times when stringify/parse work out - but you should pick structuredClone by default.Well, putting everything on one line sure does make it a 'one-liner' ;)
Still, thanks for pointing to some usefull API's.
The key takeaway people should get from this article is: just because you can do something in one line, doesn't mean that it should be done in one line.
Debugging is harder, readability is sacrificed, and one-liners often sacrifice error checking and edge cases to reasonably fit on one line.
And of course, use
structuredClone, not parse(stringify()).In the frontend i would debounce with requestAnimationFrame...
With
.flat(Infinity)you should be prepared for circular references to throw an error.It may be unlikely in most cases, recognize that using
Infinity– or even numbers like 10000 –.flat()can throw a RangeError.If you use something called JavaScript minifier along with bundler (if code is split across multiple files) you can not just replace more lines of code into one.
Here's a dijkstra algorithm one liner that I never use.
The
JSONtechnique is not only slow because of the double-pass processing, it is also fraught with hazards. Check the exceptions that can be thrown:the NodeList returned by
querySelectorAllhas aforEachmethod, so there is no need to convert it to an array. (developer.mozilla.org/en-US/docs/W...)Regardless, great article. Thx :)
I think one liners can be useful if they are easily read and understood.
I tend to have two-three liners more often than not.
You do need to keep in mind what the potential consequences are, as well as the cost.
In general, if you can write a short function that is easy to follow and be understand that also, by its name, is more clearly understood as to what it does, then generally, yeah, go for it.
You may find that you need better security or performance in some areas and this may require adding or rewriting functions so that they better meet the needs, but usually readability is my number one priority.
I noticed in some of your examples, the "one line" is extremely long.
If the line is over 80-100 characters long, particularly if there are multiple branches on a single line, then I usually prefer not to make that into a single line function.
As others have mentioned, just because you can make something shorter, that doesn't necessarily mean you should. However, if you can make the code shorter and simultaneously easier to read, follow and understand then that's the way to go.
Succinct code is beautiful and useful.
But, “short” code is useful to me “only” when it allows me to load more into my mind at once without sacrifices.
If so, it’s not a choice, but an obligation.
If it doesn’t meet the prior criteria, you shouldn’t be doing it.
It’s great to see how powerful and concise JavaScript can be with the right techniques. By using modern features, we can dramatically improve the readability and efficiency of our code. Whether you’re cleaning up an existing project or starting a new one, these one-liners will help you tackle common problems in a sleek, maintainable way. If you're looking for a place to explore more practical examples, you might find helpful resources like Arrestss-va, which can provide further insights on optimizing your web development practices.
Less # of characters != Better source code
If that were true, we would be learning how to write minified code.
😂you just write the functions in one line without the spaces in the denounce function
Ohh to be back in time.