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…
Maybe we could tone down the JavaScript (2016)
111–120 of 237 posts
Re: Maybe we could tone down the JavaScript (2016)
#112Earlier 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.
Re: Maybe we could tone down the JavaScript (2016)
#113Earlier 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.
Re: Maybe we could tone down the JavaScript (2016)
#114Earlier 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
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)
#115Earlier 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.
Re: Maybe we could tone down the JavaScript (2016)
#116Lately I’ve been limiting my JS usage only been use vanilla JavaScript for tertiary functionality and server-side rendering for everything else.
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)
#117It'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...
Re: Maybe we could tone down the JavaScript (2016)
#118This 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…
Re: Maybe we could tone down the JavaScript (2016)
#119Earlier 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…
Re: Maybe we could tone down the JavaScript (2016)
#120I 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.
https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence