71–80 of 237 posts
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.
Surprised to see the top comments here so doom-and-gloom: "ah it was posted in 2016, I don't think anyone (but do wish) cares about limiting their JS usage anymore " The tools we have available today to optimize JS and build for progressive enhancement are light years ahead of 2016 because the smartest minds in the industry have optimized for it. The rise of batteries-included server-side-rendered React apps like Rem…
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.
Separating look&feel from functionality isn't that easy. In any kind of UX, they are bound to various degrees, depending on the use-case.
Earlier quoted context omitted.
The author already addresses this in the article: > I think the Web is great, I think interactive dynamic stuff is great, and I think the progress we’ve made in the last decade is great. I also think it’s great that the Web is and always has been inherently customizable by users, and that I can use an extension that lets me decide ahead of time what an arbitrary site can run on my computer. > What’s less great is a t…
Doesn't seem to be a JS specific criticism, testing application performance on typical user hardware is a key responsibility of QA regardless of the language or platform.
This is a really common problem in tech. Smaller companies adopt large company strategies that require more resources than the small company has to do correctly.
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…
Sure it can, but is that the way these companies are using it? Are they using Javascript to improve experience and development speed? If a Twitter textbox is lagging while someone types, then that's a degradation in user experience, and a pretty fundamental one. I like autocomplete too, but I also like my text box not to lag, and maybe there's a middle ground? I wouldn't say I'm a "purist" about this stuff, but I do…
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 useable, keeping the current page on screen after the a new url was history.push'ed while preloading the data necessary for the next render and managing the scroll position, I can confirm it is a pain. I expect Youtube has the right kind of resources for the task but it happens, probably at a higher rate of bug incidence than regular frontend button-broke-the-site issues.
Implementation issues are going to happen whether you use JS or not, but I find building with JS and with modern frameworks a joy (although a lot of things can be improved) compared to server side alternatives. As with everything though, this is a matter of preference.
Earlier quoted context omitted.
Since you mention autocomplete, dealing with forms is a lot better from both a development perspective and UX, ie complex forms being validated client side (as well as server side, of course) and getting instant feedback. Modals. Having slower things being loaded after the intial page load resulting in the page loading faster (moreso with session info being loaded less often in SPAs). Infinite scroll for search pages…
Good points. I'm still not convinced it is worth everything we lost: - Instant loading - Sane page sizes - Cross browser compatibility by default, including text based browsers - Every page is reasonably safe by default - CPU is idle after initial page load - Battery life is great by default and probably a few more. I guess a good middle road might exist but I wonder if the current situation doesn't mostly serve ad p…
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…
Sure it can, but is that the way these companies are using it? Are they using Javascript to improve experience and development speed? If a Twitter textbox is lagging while someone types, then that's a degradation in user experience, and a pretty fundamental one. I like autocomplete too, but I also like my text box not to lag, and maybe there's a middle ground? I wouldn't say I'm a "purist" about this stuff, but I do…
Since when do large companies do anything that isn't user-hostile and abusive? Of course FAANGs are trying to keep their walled garden more walled by reducing outgoing links, and Twitter's incompetence is legendary
The real question should be if this type of thing is improving the web at large or the capabilities we can develop "efficiently" on it, and while I would be willing to hear arguments either way, I can tell you I use JS/HTML/CSS in combination to introduce capabilities that would not be palatable without the JS component of that, putting aside whether I would be able to develop them as a bunch of standalone capabilities. Model editors, graph layouts, plugin architectures; we can leverage client machines to do more and more, and in a business setting delivering internal tools this is a great method of reducing costs across the stack - the laptops were already going to be purchased.
Earlier quoted context omitted.
Maybe it's a niche perspective, but as a blind person the obsession with JS forms is what makes the web borderline unusable for us. While it's not impossible to make an accessible experience with JS, people mess it up so often that it may as well be. I honestly think the problem with JS reimplementations is that develoeprs assume that they are their audience, or that people like them are the only people that matter.
While I understand the concern, I'm not really sure I buy the argument "JS makes accessibility bad". It is for sure easier to do things wrong, but if you check at most of the major libraries for front-end (drag-and-drop, routing, dropdowns...), accessibility is built-in, and a critical selling point (e.g react-router, downshift...). I think the proportion of front-end developers knowing about accessibility is just lo…