November 16th, 2024

JavaScript dos and donts Mu-An Chiou

Mu-An Chiou emphasizes a balanced use of JavaScript in web development, advocating for HTML enhancement, accessibility considerations, avoidance of unnecessary dependencies, and a focus on core skills for newcomers.

Read original articleLink Icon
JavaScript dos and donts Mu-An Chiou

Mu-An Chiou discusses the best practices for using JavaScript in web development, emphasizing a balanced approach between HTML and JavaScript. The article outlines scenarios where JavaScript is necessary, such as when core functionality cannot be achieved with HTML alone or when HTML lacks essential user interface patterns. Chiou advocates for starting with HTML and progressively enhancing it with JavaScript, ensuring that a non-JavaScript fallback is available whenever possible. Accessibility is highlighted as a critical consideration, particularly when using ARIA attributes. Conversely, Chiou warns against using JavaScript in situations where it is not needed, suggesting that many modern practices have unnecessarily complicated web development. The author reflects on the evolution of JavaScript practices, criticizing the industry's shift towards dependency-heavy frameworks and the increased barriers for newcomers to web development. Chiou encourages developers to assess their JavaScript usage critically and to focus on understanding the fundamentals of web technologies rather than relying solely on frameworks.

- JavaScript should enhance HTML, not replace it; always consider a non-JavaScript fallback.

- Accessibility is crucial; use ARIA attributes when necessary.

- Avoid unnecessary JavaScript dependencies to simplify web development.

- Newcomers should focus on core web development skills rather than being overwhelmed by frameworks.

- Regularly evaluate JavaScript usage to ensure it serves the intended purpose effectively.

Related

New Web Development: Or, why Copilots and chatbots are bad for modern web dev

New Web Development: Or, why Copilots and chatbots are bad for modern web dev

The analysis critiques Copilots, chatbots, and React for web development, citing slow sites, complex code, and high costs. It advocates for a shift to browser APIs, CSS, and HTML for better performance and lower expenses. Transition challenges include finding developers skilled in vanilla JavaScript. Organizations are urged to prioritize simplicity, efficiency, and core web technology training.

Show HN: Plain Vanilla – a tutorial website for vanilla web development

Show HN: Plain Vanilla – a tutorial website for vanilla web development

The article discusses web development using only HTML, CSS, and JavaScript, emphasizing Web Components and modern CSS. It encourages experienced developers to explore this simpler, standards-based approach for building applications.

The Gift of Code

The Gift of Code

The article outlines the evolution of web technologies during Web 2.0, highlighting HTML5's creation, JavaScript's stagnation, Mozilla's rise with Firefox, and the impact of Adobe's Project Tamarin on development.

Do not build your Gov.uk service as a single-page application

Do not build your Gov.uk service as a single-page application

The GOV.UK Service Manual promotes progressive enhancement for government services, emphasizing HTML first, followed by CSS and JavaScript, to ensure accessibility and functionality across devices and browsers.

React on the server is not PHP

React on the server is not PHP

The article highlights the evolution from PHP to full-stack JavaScript frameworks, emphasizing improved collaboration, product cohesion, and developer efficiency through modern tools like Next.js and Remix in web development.

Link Icon 10 comments
By @Waterluvian - 5 months
On the topic of tables and JavaScript and using vanilla HTML:

Lately I’ve felt especially frustrated that I’m wasting so much time dealing with performance for data tables, a concept that has been so thoroughly solved for decades in desktop applications. Feels like there should be a vanilla html option for a table that:

- supports massive collections (“virtual tables”)

- sortable, filterable by header

- overflowable cells

- user resizable column widths

- user show/hide columns

- freeze columns/rows

- performance!

- no strong opinions on style

I struggle to find one solid option that fits all of that. Usually I have to make a sacrifice and then wrestle with the library of choice for that missing feature.

By @esperent - 5 months
> If you are a user of github.com, consider how it has changed since 2020.

I've been a GitHub user since around 2016. My overall impression is that it's gotten slightly better over the last couple of years but not really changed that much.

By @jitl - 5 months
I use an alternative Github front-end called Graphite that is faster and more reliable than GitHub.com, and it’s a React single-page app.

I’ve always thought of GitHub’s turbolink repo tabs as flaky and their full-page navigations as slow. It’s much better as an app (Graphite) than as a series of websites. The UX of GitHub.com has evolved at a glacial pace :-/

By @haburka - 5 months
Ironic that this person claims GitHub UI was something to be proud of when it’s far from good UX when it comes to browsing code.

I do think it was very impressive in terms of functionality especially without relying on JS, possibly the most powerful and well crafted UI on the web, but still it was deeply flawed from a UX standpoint.

They lacked many critical features for viewing source code, like linking function definitions, or expanding directories without relying on a load.

I’m sure that the GitHub front end team was of the opinion that users should just clone every repo they interact with and use their own editors instead of the GitHub website. However this has always been a bit of a hassle compared to using the website, so I very rarely find myself doing this.

By @yashasolutions - 5 months
While I have learn web development when blink was still trending, I have had my period where I tried to force every frontend into becoming a react app. I have since then wisen up, and tend to agree that for frontend - best to start with as simple as possible and increase complexity and add dependancies as it is needed. "Write JavaScript like it’s 2005" is good advice.
By @wruza - 5 months
a sortable table needs only a dash of JavaScript

On the wall of naive sentences, this one deserves to be framed.

By @yakshaving_jgt - 5 months
I mostly share the author’s position, but to be fair, GitHub’s UI did massively improve over the past decade. So much so that the rest of my company — even non-developers — were happy to drop Jira and do all product management in GitHub.

That’s not going to strictly be down to how the JavaScript is written, but even as someone also in the anti-JS camp, I don’t think I would want to write a file explorer and code editor without something like React (or in my case, Elm).

By @sellmesoap - 5 months
I notice the website now redirects to the path /no-yc apparently our presence has been felt. It's using a redirect based off the referrer, you can strip the path off the URL and browse to the article. I agree that JavaScript should be used sparingly, but you can't deny there are amazing things done in JavaScript and the list keeps getting larger.
By @peutetre - 5 months
Increasingly you can avoid JavaScript altogether with WebAssembly if you're making an application more than a set of hyperlinked documents.

Here's a demo of Dart and Flutter in WebAssembly: https://flutterweb-wasm.web.app/