4 ms·

This is an amazing website. While it looks very minimalistc, every paragraph is in 11 nested divs and a final <p>, all with arcane IDs, classnames, and individu

by lqet 5y ago

This is an amazing website. While it looks very minimalistc, every paragraph is in 11 nested divs and a final <p>, all with arcane IDs, classnames, and individual styling. Nearly 5 MB of JavaScript are required. Google Lighthouse only reports preliminary scores because it times out. The one-line paragraph "Most of the time you're good! But you end up ruining 23.15% of your shakshukas. Whoops." requires no less than 3.1 kB of data, still 1.2 kB when gzipped. Also, selecting text is impossible, and I am not sure if that is intended or just the browser giving up.

phailhaus 5y ago
This is not a simple website, looks like it's served on a platform called Hex. While this particular page is light on content, the platform seems optimized for more complex usecases.
jwithington 5y ago
That's interesting. It's a data workspace platform called Hex. It's really something more like a Jupyter Notebook than a simple webpage. I wrote some python code that's generating those charts. You're right that's overkill for what it ended up being. I initially played around with giving the reader the ability to set their onion chopping time and see how it played out. It was getting a little complicated for the point I was trying to make I think. EDIT: I've added that in now, which helps make it a little more fun I think.
saurik 5y ago
FWIW on iOS 12.4 it doesn't do anything and just renders immediately as a white page. On iOS 13.5 it takes longer but then gives me an error message "something went wrong / try again" which I presume is from the page (not the browser). On iOS 14.0~b1 it took a while to think (showing an awkward loading progress indicator that I am used to only seeing from Google's ridiculous blogging platform) but then loaded the page! Only, I can't scroll... well, vertically :/ I awkwardly CAN scroll horizontally (though only by a bit). Reader view, "of course", doesn't work, because this website is too "awesome" to allow that. I am now waiting for an iOS 15+ device to charge in the hope I might be able to... actually, I don't remember what the article was supposed to be about anymore? Onions or something? (edit: OK, so iOS 15.1 was finally able to render the content, with vertical scrolling!)
jasonkillian 5y ago
Happened to see this thread on HN, (and disclaimer I'm an engineer at Hex) very cool project jwithington! Wanted to take a second to address your comment about performance, lqet. All your points are absolutely fair - I personally apologize for some of those layers of divs and some of that JS as they're definitely my fault! For context, Hex lets you write Python and SQL code in a notebook-esque format and then create apps from that to share across the web. So there's actually quite a breadth of functionality we need to support under the hood that adds to frontend complexity. We also revamped our whole app-building experience recently, so there's a couple straggling bugs (like the text selection one you mentioned, whoops!). But I totally agree with you - thinking about all that JS makes me wince a little haha as we definitely care and want to improve frontend performance. We plan to make better use of code-splitting and lazy-loading of JS so that the frontend code for more complex apps is only pulled in if/when necessary. (We also want to work on building better tooling to make analysis of code-splitting effectiveness easier - we've found that a lot of existing webpack bundle analyzer tools don't provide enough visibility for our use cases. Maybe an open source project for us one day!) And we want to decrease over-the-wire data size and reduce necessary network calls so you can get a faster initial load. We're a small team, so can't make promises when exactly this will all happen, but hopefully with these changes and other improvements things will feel a bit snappier someday soon

by lqet 5y ago

phailhaus 5y ago

This is not a simple website, looks like it's served on a platform called Hex. While this particular page is light on content, the platform seems optimized for more complex usecases.

jwithington 5y ago

That's interesting. It's a data workspace platform called Hex. It's really something more like a Jupyter Notebook than a simple webpage. I wrote some python code that's generating those charts. You're right that's overkill for what it ended up being. I initially played around with giving the reader the ability to set their onion chopping time and see how it played out. It was getting a little complicated for the point I was trying to make I think. EDIT: I've added that in now, which helps make it a little more fun I think.

saurik 5y ago

FWIW on iOS 12.4 it doesn't do anything and just renders immediately as a white page. On iOS 13.5 it takes longer but then gives me an error message "something went wrong / try again" which I presume is from the page (not the browser). On iOS 14.0~b1 it took a while to think (showing an awkward loading progress indicator that I am used to only seeing from Google's ridiculous blogging platform) but then loaded the page! Only, I can't scroll... well, vertically :/ I awkwardly CAN scroll horizontally (though only by a bit). Reader view, "of course", doesn't work, because this website is too "awesome" to allow that. I am now waiting for an iOS 15+ device to charge in the hope I might be able to... actually, I don't remember what the article was supposed to be about anymore? Onions or something? (edit: OK, so iOS 15.1 was finally able to render the content, with vertical scrolling!)

jasonkillian 5y ago

Happened to see this thread on HN, (and disclaimer I'm an engineer at Hex) very cool project jwithington! Wanted to take a second to address your comment about performance, lqet. All your points are absolutely fair - I personally apologize for some of those layers of divs and some of that JS as they're definitely my fault! For context, Hex lets you write Python and SQL code in a notebook-esque format and then create apps from that to share across the web. So there's actually quite a breadth of functionality we need to support under the hood that adds to frontend complexity. We also revamped our whole app-building experience recently, so there's a couple straggling bugs (like the text selection one you mentioned, whoops!). But I totally agree with you - thinking about all that JS makes me wince a little haha as we definitely care and want to improve frontend performance. We plan to make better use of code-splitting and lazy-loading of JS so that the frontend code for more complex apps is only pulled in if/when necessary. (We also want to work on building better tooling to make analysis of code-splitting effectiveness easier - we've found that a lot of existing webpack bundle analyzer tools don't provide enough visibility for our use cases. Maybe an open source project for us one day!) And we want to decrease over-the-wire data size and reduce necessary network calls so you can get a faster initial load. We're a small team, so can't make promises when exactly this will all happen, but hopefully with these changes and other improvements things will feel a bit snappier someday soon