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

221–230 of 237 posts

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

#221

Post by corobo »

WesolyKubeczek wrote: post #218
corobo wrote: post #11

Earlier quoted context omitted.

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

They kind of are hanging out on HN, given that a story in such a spirit is being upvoted into the front page once a week or two, but they also seem a bit bipolar in that they swing between wanting to use the internet ascetically and defending the "web is your new OS and TV and it's a good thing!" attitude because they do it for a living, and that 150k is a 150k after all.

Different people have different opinions, let's make 2022 the year we move away from grouping vaguely related people then calling the group inconsistent

I've also not seen any recently aside from the one we're in (published 2016), what was the most recent one you recall seeing outside this?

E: just realising this comes off a bit snarky after the group quip, apologies. Asking out of legitimate interest not as a gotcha or anything.

At this point I've just given up worrying about it thinking it's an outdated opinion and I've not seen much recently to inform it in any direction other than towards JS support being expected

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

#222

Post by ahartmetz »

bzzzt wrote: post #210
matheusmoreira wrote: post #202

Earlier quoted context omitted.

Are there details about this? I've read that nvidia drivers would actually patch game code by replacing functions at runtime.

Both ATI/AMD and nVidia use all kinds of tricks to outcompete each other since gamers only look at the fps count. That means driver optimization for specific games, even dropping fidelity a bit when that means more fps. Also, nVidia has teams that take over engine code to 'help' software devs making the most of their hardware which gives them an opportunity to push specific approaches that don't work as well on their…

"Nvidia Gimpworks" - it isn't said in the video, but: while these techniques are slow on nVidia, they are even slower on AMD. Especially gratuitous tessellation. https://youtu.be/AUO3LEjWsw0

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

#223

Post by oversocialized »

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…

Desktop GUIs were making great inroads until the push to put everything on the web arrived. HTML/CSS/Javascript was never meant to build these types of apps. That's why it is all popsicle sticks and glue. Javascript was almost toast until Google brought it back from the dead.

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

#224

Post by innocentoldguy »

corobo wrote: post #4

I honestly thought this attitude had died out with everything being Vue and React and all that I used Huel's site earlier and it even had a splash overlay saying what it was loading, it was one reticulating splines away from being The Sims Edit: ah it was posted in 2016, I don't think anyone (but do wish) cares about limiting their JS usage anymore

We’ve been migrating our React front end code to Phoenix’s LiveView for any client-side code that requires server interactions, and use AlpineJS for client code that doesn’t. So far, we’ve been really happy with it.

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

#225

Post by WesolyKubeczek »

corobo wrote: post #221
WesolyKubeczek wrote: post #218

Earlier quoted context omitted.

They kind of are hanging out on HN, given that a story in such a spirit is being upvoted into the front page once a week or two, but they also seem a bit bipolar in that they swing between wanting to use the internet ascetically and defending the "web is your new OS and TV and it's a good thing!" attitude because they do it for a living, and that 150k is a 150k after all.

Different people have different opinions, let's make 2022 the year we move away from grouping vaguely related people then calling the group inconsistent I've also not seen any recently aside from the one we're in (published 2016), what was the most recent one you recall seeing outside this? E: just realising this comes off a bit snarky after the group quip, apologies. Asking out of legitimate interest not as a gotcha…

All those yearnings for "the old web", I can amend it to "once every couple weeks". Here's a recent one:

https://news.ycombinator.com/item?id=29661935 (This page is designed to last, 5 days ago)

HN is also my procrastination tool of choice, so it might be I can see articles and manifestos urging for the return to the glory of blogosphere and web 1.0 before they sink down into oblivion.

It's like you may grow an impression that on HN, there are always endless debates about notetaking in software and paper. Sure they are there. There's good stuff, too, at least every other day.

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

#226

Post by bmeski »

Shacklz wrote: post #135
ninkendo wrote: post #112

Earlier quoted context omitted.

Customizable look and feel means lack of consistency, and confusion as to why things look different without good reason.

This purist talk about how everyone should stick to some system standard or whatever really needs to die. It's not working. Nobody is doing it. Everyone, literally everyone is running their own thing. Name me big company that doesn't roll their own design system. Preaching purism really doesn't help anyone, let's just accept reality as it is, and stop chasing some utopian dreams that just won't ever materialize (and…

I’ll keep complaining about it as my parents age and struggle to use their tv apps to watch shows because every product manager needs to prove that they can reinvent the search interface.

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

#227

Post by bmeski »

Spivak wrote: post #67
Shacklz wrote: post #51

Earlier quoted context omitted.

> they're making the wrong choice. If what feels like the vast majority of them are making the same "wrong" choice, we should probably think about ways to make that choice more "right", because clearly, the current approach isn't working

This is my approach. To me the ask for custom components from designers is extremely reasonable. The fact that it’s so hard to get all the edge cases right on the web is a failing of the tooling not the ask. At some point we have to climb out of the trenches and introspect why the most treaded path in web design is the one with the rickety bridge and spike pits when we the software engineers are the ones who lay the…

It’s not a failing of the tooling. It’s a failing of designers and product to understand what a web page is and what an application is.

If youve only designed/“Ideated” for iOS or Android, you have no business designing for web. Entirely different platform with different capabilities.

Embrace reality and build simple effective products. Literally no one gives a shit about the arrows on your carousel or the border radius animation on a button. I just want to scroll and click and open new tabs.

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

#228

Post by bmeski »

spc476 wrote: post #181
Spivak wrote: post #14

Earlier quoted context omitted.

I mean the product manager isn’t wrong, there is no good reason we shouldn’t be able to make custom components with the behavior of “native” widgets. The fact that the dev story is “build a widget from scratch out of divs” and not “extend the fully functional component with new styling and hooks and slight behavior modifications.” We created this problem ourselves by not having the tools to meet designer needs while…

I recently came across a web site that allows one to zoom into the content (it's a mapping site). Only the designers just assumed that everyone would have either a mouse with a scroll wheel, or a touch pad. Well, I have neither. And the developers of the site suggested "oh, just install this piece of software that allows you to bind some keyboard shortcuts to simulate a scroll wheel" instead of, you know, providing t…

Bingo

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

#229

Post by bmeski »

johnisgood wrote: post #149
tommek4077 wrote: post #144

Earlier quoted context omitted.

Only if you use 8k$ Macs. Not for normal people.

Perhaps it is just poorly written, or maybe it is the animations that are making it look like it is slower than it should be. I created a simple website where I update parts of the DOM, and it is super fast. I have the opposite experience on known websites.

Totally agree. I implemented a page with tons of posts on it that will hide the posts before the provided cursor in the url and I simply show hide them with display: none. Even if it’s 100 posts hidden, the images are lazy and clicking “show” unhides all of them immediately. If new posts come in we simply append to the top of the parent container with basic DOM apis.

The app were replacing with this page is heavy react and there’s a long visual stutter during the show hide because it has to render them all. Not simply show/hide. They actually load more bits to lazy load the posts in JS than to simply send the html and hide/show.

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

#230

Post by joe_guy »

toastal wrote: post #212
joe_guy wrote: post #193

Earlier quoted context omitted.

You're not going to delete a dll or not install DirectX then get annoyed when the software fails.

I'm not familiar with Windows but I'm going to assume the OS will at least give you an error. A lot of websites are just blank and/or swallowing errors without giving feedback.

Oh this is true. Rereading your point that an error should be present is something I agree with.

It feels more domain to the browser. Have some sort of required flag.

Post reply on HN