Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript: Search and Don’t Replace (2008)

johnresig.com

Post reply on HN
Print view View original

31–40 of 46 posts

Re: JavaScript: Search and Don’t Replace (2008)

#31

Post by chmod775 »

He missed an opportunity to make that even shorter and even more of a clusterfuck.

I present to you:

    function compress(data){
        var s = {}, q = [];
        data.replace(/([^=&]+)=([^&]*)/g, function(m, k, v) {
            s[k] ? q[s[k] - 1] += "," + v : s[k] = q.push(m);
        });
        return q.join("&");
    }

Re: JavaScript: Search and Don’t Replace (2008)

#32

Post by throwanem »

lucasmullens wrote: post #24

We probably should be cautious reading anything about JS optimization that's 12 years old. It might have been true at the time, but now with the highly-optimized V8 engine, and a set of native methods that didn't exist back then, there's a pretty good chance there's another way to do this that's even faster.

It can certainly be done at least as fast and much more legibly. Probably not in 2008 - which predates even ES5 by a year! - but these days, most certainly.

Re: JavaScript: Search and Don’t Replace (2008)

#33

Post by Stratoscope »

lucasmullens wrote: post #24

We probably should be cautious reading anything about JS optimization that's 12 years old. It might have been true at the time, but now with the highly-optimized V8 engine, and a set of native methods that didn't exist back then, there's a pretty good chance there's another way to do this that's even faster.

That is very true. I wrote a polygon drawing library the same year of this blog post, and I pulled out all the stops to make it as fast as possible on the browsers of the day - including IE6!

Now of course many of the tricks I used backfire in modern engines, and simple straightforward code is faster.

Perhaps a more important point is that this particular problem does not need to be optimized, and shouldn't be optimized! It should use the simplest and most understandable code possible. Even in the era of slow browsers from 10-15 years ago.

It's a query string, not a million-row database.

Re: JavaScript: Search and Don’t Replace (2008)

#34

Post by [deleted] »

lucasmullens wrote: post #24

We probably should be cautious reading anything about JS optimization that's 12 years old. It might have been true at the time, but now with the highly-optimized V8 engine, and a set of native methods that didn't exist back then, there's a pretty good chance there's another way to do this that's even faster.

[deleted]

Re: JavaScript: Search and Don’t Replace (2008)

#36

Post by Stratoscope »

chrisrhoden wrote: post #17
urvader wrote: post #12

Just use match instead? Why use replace and hack into an array? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

This was a time when there was widespread belief that iterating over an array was best done with a library. I know it's weird, but that's what $.each existed for. for ... of did not exist.

There was a bit more to $.each than that.

Originally, a jQuery object that you got from calls like $(foo) was not an array-like object as it is today. The jQuery object had an internal array of the matching DOM elements, but you were supposed to ignore it and instead use $(foo).each(...) to iterate through the elements, or $(foo).get(n) to access a specific element.

I thought it would be more convenient if you could just treat the jQuery object itself as an array, which turned out to be a simple change. So that's why you can now do $(foo)[n]. The .get(n) method was kept for compatibility with very old code.

At that point, $(foo).each(...) was not as useful as it had been, but it was also kept for compatibility. And $.each(...) was also kept around, as it was the helper function for $(foo).each(...) and related methods.

Another fun fact on the first version of the jQuery code: all of the methods on a jQuery object like $().each, $().html, $().css, etc. were not on a prototype object. Whenever you called $(foo) to create a jQuery object, it ran a loop to copy references to all those methods into the jQuery object.

Needless to say, that was a bit slow, and got slower as you added plugins. So my other minor architectural contribution was to use a prototype instead of copying all the methods.

We were all learning as we went along in those days! :-)

Re: JavaScript: Search and Don’t Replace (2008)

#37

Post by fataliss »

chmod775 wrote: post #31

He missed an opportunity to make that even shorter and even more of a clusterfuck. I present to you: function compress(data){ var s = {}, q = []; data.replace(/([^=&]+)=([^&]*)/g, function(m, k, v) { s[k] ? q[s[k] - 1] += "," + v : s[k] = q.push(m); }); return q.join("&"); }

I think he avoided the array + join on purpose and went directly for final string concatenation :)

Re: JavaScript: Search and Don’t Replace (2008)

#38

Post by tyingq »

This is the sort of thing that's cited when people say they hate Perl. I'd consider a more readable version if performance isn't really a 1st class requirement. It doesn't appear to be in this case. A temporary array solution would be much more readable.

Re: JavaScript: Search and Don’t Replace (2008)

#39

Post by diegof79 »

urvader wrote: post #23
augusto-moura wrote: post #14

Earlier quoted context omitted.

To not create a intermediate array I think

This works fine: [...paragraph.matchAll(regex)].reduce((q,[kv, key, value]) => { q[key] = (q[key] ? q[key] + `,`: ``) + value return q }, {}) https://pastebin.com/yb5QBCm6

In this case you can use for..of. The Array [... ] restructuring is converting the iterator to array so you can use reduce... but then you are using reduce in an imperative way. With for...of you skip the intermediate array and is more readable.

For...of has a bad rep because eslint usually is configured to show a warning, because the Babel transpile creates less optimal code if it targets old browsers; but is better here.

Re: JavaScript: Search and Don’t Replace (2008)

#40

Post by recursive »

chmod775 wrote: post #31

He missed an opportunity to make that even shorter and even more of a clusterfuck. I present to you: function compress(data){ var s = {}, q = []; data.replace(/([^=&]+)=([^&]*)/g, function(m, k, v) { s[k] ? q[s[k] - 1] += "," + v : s[k] = q.push(m); }); return q.join("&"); }

Further fucked:

        function compress(data){
            return data.replace(/(?
I say: do replace after all!

(Javascript didn't have zero-width look-behinds at the time)

Post reply on HN