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

JavaScript growth and third parties

speedcurve.com

Post reply on HN
Print view View original

71–77 of 77 posts

Re: JavaScript growth and third parties

#71

Post by acdha »

z3t4 wrote: post #30
azeotropic wrote: post #7

I don't understand why JavaScript is so ubiquitous now. There seem to be very few cases where it is actually necessary and useful (e.g. a calculator form that does computations client side that would otherwise overwhelm the server). I am constantly surprised at the number of sites that should be totally static (e.g. a local restaurant's menu page) that display nothing at all when I visit with JavaScript disabled. Can…

Because of the explosive growth and fast paced advancement of the web, most developers are mostly copy/pasting and gluing modules together. When the customer asks for a "image slideshow" they are not going to write one from scratch, even though it's just 10 LOC, they are going to bring in a library/framework which already has that functionality.

Anyone who actually has written a slideshow from scratch knows that it's way more than 10 lines of code: you couldn't even do the CSS in that, let alone accessible HTML, responsiveness, etc. There's a lot of design and testing which goes into superficially simple-seeming components and it'd be irresponsible to take that on each time unless you have a really good business justification.

Re: JavaScript growth and third parties

#72

Post by ASalazarMX »

oraphalous wrote: post #39
ricardobeat wrote: post #15

Earlier quoted context omitted.

It is entirely possible to build rich web apps with very small size. As shown in the article, the main source of bloat are 3rd party scripts: ads, tracking, metrics, retargeting, security...

Everyone here is the choir... Now convince the client that they don't need to track every single possible click of the user - as they experience their "journey" through the site... ...convince the client that all those experience designers effusing about that "emotional layer" they added to that user journey didn't really result in 30% more engagement with the brand - as evidenced by exactly that same user tracking -…

There are these obscure files called "logs" which record every interaction with your server. They might be useful, IDK.

Re: JavaScript growth and third parties

#73

Post by zeman »

SCdF wrote: post #2

Ironically after 47 minutes on HN their site doesn't load at all. Here is a cached version that works: http://webcache.googleusercontent.com/search?q=cache:https:/...

Can I just check, do you use Edge browser? We've (SpeedCurve) been seeing some issues where Edge goes bonkers and makes thousands of requests to our CDN and fails to load CSS which would look like a broken site.

Re: JavaScript growth and third parties

#74

Post by franga2000 »

azangru wrote: post #58
franga2000 wrote: post #45

Earlier quoted context omitted.

I'm a web developer who avoids this sad trend wherever possible. I see two reasons for this: 1) the development experience for things like React is so 'smooth' that many developers use it even when it's not necessary at all (I'm referring to things like hot-reloading and custom components which are more complicated to set up with pre-processors) 2) some animations and advanced interactivity have become expected of us…

An unrelated question: how many `html` and `body` tags are allowed on a web page? I just looked at the page source of https://dev.to/liquid_chickens/three-qualities-of-failed-mic... , and to my surprise noticed they have about five `html` and `body` tags on that page. They aren't even in iframes either.

One and only one of each. And having more than 1 doctype declaration is ridiculous. Browsers are very resistent to garbage markup, so by looking at the parsed tree and not the raw text, I never actually noticed that.

I have no idea why they would do that. It looks like a misconfigurated preprocessor that thinks each fragment is a doc of its own. I vaguely recall something about them open-sourcing the frontend, so I might look into that...

Re: JavaScript growth and third parties

#75

Post by SCdF »

zeman wrote: post #73
SCdF wrote: post #2

Ironically after 47 minutes on HN their site doesn't load at all. Here is a cached version that works: http://webcache.googleusercontent.com/search?q=cache:https:/...

Can I just check, do you use Edge browser? We've (SpeedCurve) been seeing some issues where Edge goes bonkers and makes thousands of requests to our CDN and fails to load CSS which would look like a broken site.

Apologies, it wasn't down because of HN! I can't edit the original post now, but it was just my computer blocking your domain at the hosts level via https://github.com/StevenBlack/hosts

I should have realised, but it's the first time using that hosts list has ever stopped a website I've wanted to go to from loading, so I didn't think of it.

Re: JavaScript growth and third parties

#76

Post by azangru »

franga2000 wrote: post #74
azangru wrote: post #58

Earlier quoted context omitted.

An unrelated question: how many `html` and `body` tags are allowed on a web page? I just looked at the page source of https://dev.to/liquid_chickens/three-qualities-of-failed-mic... , and to my surprise noticed they have about five `html` and `body` tags on that page. They aren't even in iframes either.

One and only one of each. And having more than 1 doctype declaration is ridiculous. Browsers are very resistent to garbage markup, so by looking at the parsed tree and not the raw text, I never actually noticed that. I have no idea why they would do that. It looks like a misconfigurated preprocessor that thinks each fragment is a doc of its own. I vaguely recall something about them open-sourcing the frontend, so I m…

Yep, my guess would be that they are using a markdown parser that generates a complete html document out of submitted markdown, and then they just stitch those parsed htmls together, like here (the processed_html method on the article instance):

https://github.com/thepracticaldev/dev.to/blob/master/app/vi...

> Browsers are very resistent to garbage markup

Miraculously so! Anything I would have attempted to design would have crapped its pants at the look of this markup, but browsers heroically manage to display it as if nothing weird is happening. I take my hat off to their resilience.

Re: JavaScript growth and third parties

#77

Post by bhalp1 »

azangru wrote: post #76
franga2000 wrote: post #74

Earlier quoted context omitted.

One and only one of each. And having more than 1 doctype declaration is ridiculous. Browsers are very resistent to garbage markup, so by looking at the parsed tree and not the raw text, I never actually noticed that. I have no idea why they would do that. It looks like a misconfigurated preprocessor that thinks each fragment is a doc of its own. I vaguely recall something about them open-sourcing the frontend, so I m…

Yep, my guess would be that they are using a markdown parser that generates a complete html document out of submitted markdown, and then they just stitch those parsed htmls together, like here (the processed_html method on the article instance): https://github.com/thepracticaldev/dev.to/blob/master/app/vi... > Browsers are very resistent to garbage markup Miraculously so! Anything I would have attempted to design wou…

Yes. And actually, this is a mistake in our processing configuration. We don’t want separate body tags, but it hasn’t been a problem so we haven’t gotten around to fixing it.

PRs welcome. :)

Post reply on HN