Live data from Hacker News

Maybe we could tone down the JavaScript (2016)

eev.ee

111–120 of 237 posts

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

#111
post #17

I know this is likely to be controversial, but JS improves the user experience a lot, both in terms of interaction and speed, as well as making development more manageable (if used correctly), alas at the expense of annoying purists who would prefer to enagage in all sorts of CSS/HTML gymnastics just to avoid using JS (and other kinds that would prefer vanilla JS to frameworks). Do that in a large project and you'll…

[deleted]

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

#112
post #46

Earlier quoted context omitted.

Literally stepping off the shoulders of giants and wondering why you're less capable.

You and the parent are totally missing the point. Use the system tools. But make the look of the system tools customizable. System tool. Customizable look. That's what should be available. But even today you can't consistently change something as simple as a scroll bar or a checkbox. Which, even worse, are by default styled differently on different browsers.

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

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

#113
post #99

Earlier quoted context omitted.

I think that it's a bit of a cop-out to call your site static in instances like this. You've outsourced computation to a 3rd party as well as the user's browser, as opposed to doing it on your own server. It would be dynamic if you cobbled a comment system together with some CGI scripts and an SQLite database and some server-side includes, and it's still dynamic if you abstract that into a runtime dependency on the c…

Yup. I say down with comments on websites! Let the big boys of websites like this one take care of comments.

Removing comments on my website was a great idea. Instead, people email me and I don't have to moderate anything.

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

#114
post #11

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

I think there are a fair number of JavaScript devs who really don't appreciate being told that they are on the same ethical plane as, e.g. cigarette designers, which is pretty understandable even if one does think that JavaScript is basically cancer (a position I would not take myself: I think it's more akin to sugar: good or at least neutral in very small amounts). No-one wants to be told that the way he earns a living is fundamentally wrong.

Or, in the words of Upton Sinclair, 'It is difficult to get a man to understand something, when his salary depends on his not understanding it.'

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

#115
post #100
post #75

Earlier quoted context omitted.

> Are they using Javascript to improve experience and development speed? Some, yes. This was in the spec sheet for a large ecommerce website I helped rebuild with modern(er) technologies. > If a Twitter textbox is lagging while someone types That's an implementation issue. re Youtube, I haven't had the experience you describe, but having had to develop the framework side of SPA navigation into something robust and us…

But what’s the whole point of rewriting the URL and rerendering in JS the whole page? I’m fairly sure that browsers are really great at caching, so no additional HTML, JS should be downloaded and the change might very well be faster with better history and UX if we drop SPAs.

The overall experience feels (and is) faster as you only need to update the DOM, not recreate it from scratch, so you're not rerendering the whole page. There's also less processing required on the server as you're only requesting the piece of data you know will change and the response comes back faster. The history API makes going back and forth seamless, as if you were browsing the "classical" way. But this comes with additional complexity which is sometimes not dealt with correctly.

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

#116

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 we use on any given day. Server-side doesnt necessarily always mean full page reloads upon interaction. Websockets are pretty cool.

Hackernews is the only other website that feels approximately as fast to me.

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

#117
post #85
post #7

It's been thus, nigh on two decades now. Product Designer: "No system controls; we want our users to have the Full Brand Experience, therefore, custom controls." Also Product Designer: "Why don't our custom controls work as well as system controls?"

"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…

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

#118

This blog loads 2mb of scripts, and if you disable JS you can't leave a comment or even read any comments. Personally, I don't have a problem with this, but I'd have expected a blog hosting an anti-js essay to be less dependent on JS. The author notes in the noscript block that using disqus is part of hosting a static blog, but that definition of "static" is an implementation detail - i.e. a convenience for the devel…

[deleted]

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

#119
post #92

Earlier quoted context omitted.

yes, and no. You could have used the same argument with flash. It looked and ran the same everywhere, offered features totally unavailable with HTML/CSS and Js. The point being is that it might work fine on your machine, but its not fine for the rest of us. I am lucky that I have a 2013 retina with a GPU, but even still, there are more and more websites that are slow as shit, for no real reason. when I'm out and abou…

I've seen server-side rendered websites that took several seconds to return a page, while not being under any particular load. How is that different? Of course a static html file will load instantly and likely not cause any issues, but apples to apples would mean comparing dynamic server side rendered websites to dynamic client (or hybrid) websites. In both cases, inexperienced developers can make a mess of it, inclu…

Slow loading server rendered would also be a slow loading API. At least with a slow server rendered app I as a user (not a developer) knows something is happening. A fully formed client with a slow backend can give the wrong impression that the app is working (unless the developer reimplements "loading" feedback that the browser implements natively)

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

#120

I am not sure what Javascript buys you, but from a point of view of doing a server-side app and having to do the frontend... uh, it adds a lot of complexity. I am taking a look into htmx. It looks way closer to what html is and it is more than enough for my purpose at least.

> I am not sure what Javascript buys you

https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence

Post reply on HN