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

Maybe we could tone down the JavaScript (2016)

eev.ee

Post reply on HN
Print view View original

121–130 of 237 posts

Re: Maybe we could tone down the JavaScript (2016)

#121

Post by bdcravens »

jenscow wrote: post #39
newshorts wrote: post #24

Earlier quoted context omitted.

Vanilla JS is more rare these days. I interview 2-3 devs per week and always ask basic vanilla JS questions since it’s vital for our workflow that you don’t rely on frameworks we may or may not be using. Knowing react/vue is a bonus, but knowing how to do basic tasks like adding event listeners and manipulating the DOM in vanilla JS is required. It’s anecdotal but I just wanted to say there are a few places that stil…

And this is why we need technical tests during interviews. There are people who call themselves "web developers", apparently been writing websites for 5+ years, but don't know about addEventListener.

Even better, make their direct supervisor take the same test. If they outscore them, they get their job and the supervisor then is demoted to the job being hired for.

Re: Maybe we could tone down the JavaScript (2016)

#122

Post by alphabet9000 »

corobo wrote: post #11
alphabet9000 wrote: post #9

Earlier quoted context omitted.

i care, plenty of other people care.

Well then I dunno where they hang out cause it doesn't appear to be on HN anymore

10 other people upvoted my 'i care' comment; they are here on HN, lurking

Re: Maybe we could tone down the JavaScript (2016)

#123

Post by root_axis »

rauhl wrote: post #110
root_axis wrote: post #103

Earlier quoted context omitted.

> As you have observed, disabling JavaScript does not make the site stop working entirely for no reason. Such is the case for most JS sites, the site typically doesn't break "entirely", but I consider being unable to post or even read comments to be a major functional breakdown. Comments are non-interactive text, there's no justifiable reason why I should need JS to read them.

> I consider being unable to post or even read comments to be a major functional breakdown. For a blog? I disagree, because the point of a blog is to read the author’s comments, not those of third parties. > Comments are non-interactive text, there's no justifiable reason why I should need JS to read them. I kinda agree. The issue is that it is very rare to find a static site generator which can interface with a dyna…

> For a blog? I disagree, because the point of a blog is to read the author’s comments, not those of third parties.

The author has posted several comments in the comment section, so even by your definition the blog fails to meet functional standards. However, IMO, the distinction between the author's comments and user comments is arbitrary, both are text meant to be read by readers, and those readers without JS are missing a ton of discussion that's happening in the comments, including discussion with the author. There's actually more to read in the comment section than in the blog post itself.

> All that being written, it would be awesome to have a static site generator which were called by a hook in a dynamic comment server. I actually would like to write one someday!

I have actually seen a system like this implemented at company I used to work for. A posted comment would be stored in a sqlite database before a request to rebuild the comment section is fired (as a partial, to avoid re-rendering the whole page/site), subsequently dumping the new build into the CDN (with some debounce logic to throttle high comment traffic). The rebuild was typically sub-second and performed very well.

Re: Maybe we could tone down the JavaScript (2016)

#124

Post by Devasta »

No one asks if Excel or Hearthstone or Git or other desktop applications have progressive enhancement, it's unfortunate but these days no one should be asking it about web pages either.

The web is an application platform, it stopped being about documents years ago. Whatever you may feel about Xforms, its spec was published nearly 20 years ago and even now HTML forms still cannot do something as basic as a PUT request without JS or workarounds.

It's clear that browser vendors expect you to use JS for basic functionality, and for document distribution you'll be using PDF anyway so why try to pigeonhole the web onto something it is not? What's to be gained by pretending otherwise?

Re: Maybe we could tone down the JavaScript (2016)

#125

Post by crabmusket »

rauhl wrote: post #110
root_axis wrote: post #103

Earlier quoted context omitted.

> As you have observed, disabling JavaScript does not make the site stop working entirely for no reason. Such is the case for most JS sites, the site typically doesn't break "entirely", but I consider being unable to post or even read comments to be a major functional breakdown. Comments are non-interactive text, there's no justifiable reason why I should need JS to read them.

> I consider being unable to post or even read comments to be a major functional breakdown. For a blog? I disagree, because the point of a blog is to read the author’s comments, not those of third parties. > Comments are non-interactive text, there's no justifiable reason why I should need JS to read them. I kinda agree. The issue is that it is very rare to find a static site generator which can interface with a dyna…

This seems to be exactly how Gatsby et al work, by pulling in "dynamic" content over an API at build time. I've never seen this being used to re-render a site based on third-party changes like comments, but it's popular to pull data from a first-party system like a CMS containing e.g. the blog posts.

Though I wonder if the prevalence of programmable edge networks will leapfrog that before it becomes really mainstream, and allow site owners to add a small bit of edge dynamism to pull dynamic content in without client-side JS.

Re: Maybe we could tone down the JavaScript (2016)

#126

Post by crabmusket »

Devasta wrote: post #124

No one asks if Excel or Hearthstone or Git or other desktop applications have progressive enhancement, it's unfortunate but these days no one should be asking it about web pages either. The web is an application platform, it stopped being about documents years ago. Whatever you may feel about Xforms, its spec was published nearly 20 years ago and even now HTML forms still cannot do something as basic as a PUT request…

> for document distribution you'll be using PDF anyway

This is true and it makes me really sad. HTML in particular, and the web broadly, is really good at document presentation and distribution. I see PDFs every single workday that should have been a tiny, readable, mobile-friendly-by-default HTML file.

Re: Maybe we could tone down the JavaScript (2016)

#127

Post by bo1024 »

Devasta wrote: post #124

No one asks if Excel or Hearthstone or Git or other desktop applications have progressive enhancement, it's unfortunate but these days no one should be asking it about web pages either. The web is an application platform, it stopped being about documents years ago. Whatever you may feel about Xforms, its spec was published nearly 20 years ago and even now HTML forms still cannot do something as basic as a PUT request…

> The web is an application platform, it stopped being about documents years ago.

No, it's both. The problem is people not knowing which type of site they're creating and making an app when all they need is a page.

Re: Maybe we could tone down the JavaScript (2016)

#128

Post by goatlover »

laurent92 wrote: post #117
timeon wrote: post #85

Earlier quoted context omitted.

"a good rule of thumb to follow when designing your own controls: Don't." -- https://web.archive.org/web/20021009021738/http://www.iarchi...

And then, everyone has their custom buttons, sliders, switches, input fields, and everyone is happier for that…

Except for when those custom controls fail to implement all the features of the built-in ones, as the article details from various popular sites, at least back on 2016. But maybe at the end of 2021, all custom stuff is fully accessible and reimplements everything.

Re: Maybe we could tone down the JavaScript (2016)

#130

Post by marcos100 »

bob1029 wrote: post #116
adreamingsoul wrote: post #78

Lately I’ve been limiting my JS usage only been use vanilla JavaScript for tertiary functionality and server-side rendering for everything else.

Server-side rendering is something that has been tragically overlooked by a lot of teams. With no amount of client-side javascript could you ever hope to build something that brings fresh business data to a customer's eyeballs faster than if the server simply delivers the final DOM on the initial page request. Our Blazor web apps are running in server-side mode, and they are some of the fastest web applications that…

Is it scaling well? Do you have a lot of concurrent users?

I'm thinking o using blazor server in a production app, but the latency and higher costs may be a problem. Wasm is not ideal for me because of the high initial payload.

Post reply on HN