Viqsi
"that chick from Ohio"
I'll stick with Puckpedia for the time being simply because it's accurate, even if it is sometimes a pain to navigate. I'm more willing to deal with annoying interfaces than being misled.
Capwages - the new Capgeek?
- Thread starter MHO
- Start date
VanillaCoke
Registered User
- Oct 30, 2013
- 26,324
- 13,025
I'm liking Capwages because the interface is so similar and easy to navigate like Capfriendly was. I just wish they would go all the way in copying Capfriendly completely because that really was the best layout with so much data on everything NHL related.
AzNightmare
Unregistered User
- May 11, 2011
- 1,816
- 1,553
Guess I'm late to the party. I only noticed this site when I googled, or maybe it finally made it to the top of the Google search results.
I'm glad they made a CF clone. The PuckPedia layout is so terrible, I would rather just not have the info than use it. lmao.
I'm glad they made a CF clone. The PuckPedia layout is so terrible, I would rather just not have the info than use it. lmao.
Viqsi
"that chick from Ohio"
The only folks who are going to understand this are fellow web geeks and developers, and virtually nobody's going to care about this other than me (and even that's limited), but I needed to rant somewhere.
If you've ever tried to make use of a browser's ability to add new sites' searches to their built-in search options, y'all may have noticed that CapWages' search doesn't work like that - along with several other hockey-related sites, but whatever. I tend to consider that to be a challenge that I've addressed before (you can see my horrible hacks here if you're morbidly curious) and needed a palette-cleanser from some work annoyances, so I decided to give making that work with CapWages a try. Surely it'd be a quick and easy win, right?
No. So very no. OMFG these people are blisteringly incompetent to a fault or being downright infuriating in their obfuscation attempts or both. Sure, they're following that same infuriating trend of making the client grab a Giant-Ass JSON Object Array Of Players and search it client-side, but I worked around that years ago with Sports Forecaster; that's old hat. But these pigf***ers don't even have a API endpoint to retrieve that list; they just have a giant-ass string hardcoded into their app bundle that gets on-the-fly JSON.parse()d and then Unicode normalized (because they store this string, not in UTF-8, but in WINDOWS-125f***ing2! IN 2024!). So you get to forcibly extract that string from Javascript code yourself (break out the regexes!). Only since it's part of a webpack bundle, our target naturally has a version hash embedded in its filename, so you'd have to do multiple fetch()es to first get their front page and then extract the filename for that part of the bundle and then fetch that file and then extract that Giant-Ass String and then JSON.parse() it yourself and then do your client-side search and...
...yeah, I went back to paying work and I'll consider coming back to this some other time. It's a solvable problem, but so is stabbing people.
So, yeah, now I have an additional reason to not be happy with CapWages and just stick to PuckPedia, which still at least does its actual search logic server-side (even tho it still returns JSON so I still have to parse the results to something navigable myself...).
If you've ever tried to make use of a browser's ability to add new sites' searches to their built-in search options, y'all may have noticed that CapWages' search doesn't work like that - along with several other hockey-related sites, but whatever. I tend to consider that to be a challenge that I've addressed before (you can see my horrible hacks here if you're morbidly curious) and needed a palette-cleanser from some work annoyances, so I decided to give making that work with CapWages a try. Surely it'd be a quick and easy win, right?
No. So very no. OMFG these people are blisteringly incompetent to a fault or being downright infuriating in their obfuscation attempts or both. Sure, they're following that same infuriating trend of making the client grab a Giant-Ass JSON Object Array Of Players and search it client-side, but I worked around that years ago with Sports Forecaster; that's old hat. But these pigf***ers don't even have a API endpoint to retrieve that list; they just have a giant-ass string hardcoded into their app bundle that gets on-the-fly JSON.parse()d and then Unicode normalized (because they store this string, not in UTF-8, but in WINDOWS-125f***ing2! IN 2024!). So you get to forcibly extract that string from Javascript code yourself (break out the regexes!). Only since it's part of a webpack bundle, our target naturally has a version hash embedded in its filename, so you'd have to do multiple fetch()es to first get their front page and then extract the filename for that part of the bundle and then fetch that file and then extract that Giant-Ass String and then JSON.parse() it yourself and then do your client-side search and...
...yeah, I went back to paying work and I'll consider coming back to this some other time. It's a solvable problem, but so is stabbing people.
So, yeah, now I have an additional reason to not be happy with CapWages and just stick to PuckPedia, which still at least does its actual search logic server-side (even tho it still returns JSON so I still have to parse the results to something navigable myself...).
The only folks who are going to understand this are fellow web geeks and developers, and virtually nobody's going to care about this other than me (and even that's limited), but I needed to rant somewhere.
If you've ever tried to make use of a browser's ability to add new sites' searches to their built-in search options, y'all may have noticed that CapWages' search doesn't work like that - along with several other hockey-related sites, but whatever. I tend to consider that to be a challenge that I've addressed before (you can see my horrible hacks here if you're morbidly curious) and needed a palette-cleanser from some work annoyances, so I decided to give making that work with CapWages a try. Surely it'd be a quick and easy win, right?
No. So very no. OMFG these people are blisteringly incompetent to a fault or being downright infuriating in their obfuscation attempts or both. Sure, they're following that same infuriating trend of making the client grab a Giant-Ass JSON Object Array Of Players and search it client-side, but I worked around that years ago with Sports Forecaster; that's old hat. But these pigf***ers don't even have a API endpoint to retrieve that list; they just have a giant-ass string hardcoded into their app bundle that gets on-the-fly JSON.parse()d and then Unicode normalized (because they store this string, not in UTF-8, but in WINDOWS-125f***ing2! IN 2024!). So you get to forcibly extract that string from Javascript code yourself (break out the regexes!). Only since it's part of a webpack bundle, our target naturally has a version hash embedded in its filename, so you'd have to do multiple fetch()es to first get their front page and then extract the filename for that part of the bundle and then fetch that file and then extract that Giant-Ass String and then JSON.parse() it yourself and then do your client-side search and...
...yeah, I went back to paying work and I'll consider coming back to this some other time. It's a solvable problem, but so is stabbing people.
So, yeah, now I have an additional reason to not be happy with CapWages and just stick to PuckPedia, which still at least does its actual search logic server-side (even tho it still returns JSON so I still have to parse the results to something navigable myself...).
