Chris Ferdinandi

I love seeing vanilla JS projects getting some love. I started one last year (https://github.com/CarlMungazi/aprender-js) and I feel it has made me a better programmer. If anyone wants to learn more vanilla JS stuff, you should check out https://gomakethings.com by Chris Ferdinandi.

Definitely, https://gomakethings.com is what I instantly thought of after reading the OP.

I was in the same boat with wanting to just learn plain HTML/CSS/JavaScript. Mozilla docs didn't quite do it for me but I swear by W3SCHOOLS website. I also found this guy's website helpful: https://gomakethings.com/ I think the author is on HN; he swears by plain JS. For me I just wanted to write a simple cross platform app, I decided Dart/Flutter was the way to go in the end.

>> He was just unable to follow and understand the trend, and thinks that therefore the whole industry made a MISTAKE :D That's not true, though. If you read [his next blog post](https://gomakethings.com/how-to-make-mpas-that-are-as-fast-as-spas/) you'll see he has lots of experience with architecting an advanced multi-page application which works and behaves much like an SPA. It makes his anti-SPA post kind of redundant and a bit hypocritical, but he clearly knows roughly what he's doing.

Great site! Love the idea. I would love to see the ability to alter the background color. I may also suggest you never default the background to pure black. https://gomakethings.com/design-tip-never-use-black/ You will now notice this on most websites you visit. You may also consider adding more sound effects and/or royalty free light background music that can be toggled on/off. Good luck!

Sure! :) But I think it's all just about few principles. Elaborated a bit more on them: 1. Tailwind CSS classes extracted with purge-css, all inlined. 2. Favicon inlined, small images (<4kb) inlined. Not sure what’s the best threshold. Here is all https://turboeshop.com/inlinedimages/ is all page in one requests. Meaning two big images that are https://turboeshop.com/fastestpageintheworld/ were inlined - results are way worse. So larger images - definitely excluded. 3. Gzip stuff(as one commenter below commented, not done in turboeshop.com/fastestpageintheworld/). 4. Everything from same domain and subdomain. If you want cloudinary or friends, I guess they are only allow subdomain. This is totally OKeish exemption. Or maybe there is a way to work around that cloudinary serves, Cloudflare caches. 5. JS - inlined. Cash.js maybe if you need jquery replacement, or just vanilla. Little content on vanilla js nowadays :), https://gomakethings.com/articles/ is something interesting. Don’t want to flame here, am not js expert, maybe someone can elaborate. 6. For compex components - svelte web components (or stencils or lithtml) - I’d prefer svelte but am not sure what’s best. 7. Google analytics a) - there is new google analytics (GA4) with measurement protocol2 and new server side google tag manager. Serve side gtm does two things a) serves gtag.js; b) accepts measurement protocol hits and sends to GA. Take a look how it’s done -…

It’s not ideal, but t it does exist in pure html… and the OP didn’t seem to note it. A bit of vanilla JavaScript with WebComponents is a few lines: https://gomakethings.com/html-includes-with-web-components/ Edit: “t” was supposed to be the object tag.

I've gone for tabs ever since I realized it helps with accessibility https://gomakethings.com/tabs-are-objectively-better-than-spaces/ Every developer can control how those tabs are rendered to their preference.

>My understanding is that the author is saying you could build google docs to go from one state to another by submitting a form and doing server side rendering [...] This is obviously much worse user experience and way less efficient, Your interpretation of "much worse user experience" is the opposite of the "work well!" that the author is claiming: >Every single core function of these apps could work—and work well!—without a single drop of JavaScript. https://gomakethings.com/the-web-is-mostly-links-and-forms/#:~:text=Ev…

>The only things people don't like about it is that you need some tooling and a build step. Wrong. Many people dislike many things about Typescript. https://levelup.gitconnected.com/the-inevitable-decline-of-typescript-… https://medium.com/codex/why-are-javascript-pros-saying-goodbye-to-typ… https://gomakethings.com/ditching-typescript-for-javascript/ https://www.reddit.com/r/sveltejs/comments/12cyady/are_you_leaving_sve… There are plenty more examples of why people tried typescript and went back to javascript. It's definitely not only because of a build step, but also "type gymnastics", and other code bloat.

> front ends independent of any of the existing frameworks that exist today, which I think is probably controversial Not sure controversial is the right word, in fact I think it is quite a common sentiment among developers, especially those that originally come from back-end. The only problem is finding a company that is willing to forgo the frameworks. They do exist though. Here's a short list of companies that use vanilla JavaScript, most notably GitHub and Netflix: https://gomakethings.com/companies-that-use-vanilla-js/

Agreed - the perceived tone of the post is not very convincing. The sibling post ( https://gomakethings.com/theres-no-such-thing-as-a-website-or-web-app-… ) is also really light on facts. "In many countries around the world, accessibility is a legal requirement." Would have been nice to name a few. AFAIK it's not that clear cut in the US for example. It depends on your industry, your physical presence (judges seem to apply the rule of thumb of "if you have accessible buildings to do business, your website must be too", etc).

timeouts/intervals are slowed down when in inactive tabs https://gomakethings.com/the-delay-on-settimeout-and-setinterval-is-ju…

Or, alternatively, not ideal. For example: https://www.programming-idioms.org/idiom/174/make-http-post-request On Fetch: https://gomakethings.com/why-i-still-use-xhr-instead-of-the-fetch-api/

While others may agree with them [1], Google are the ones immediately springing into action [2]. They only started collecting feedback on which sites may break after they already pushed "Intention to remove" and prepared a PR to remove it from Chromium. The main guy pushing it didn't even know RSS sites as used by podcasts until after people flooded the issue with examples and requests not to remove. E.g. https://github.com/whatwg/html/issues/11523#issuecomment-3152359096 [1] Reaction was "cautiously agree" btw. In that same issue, https://github.com/whatwg/html/issues/11523#issuecomment-3149280766 and https://github.com/whatwg/html/issues/11523#issuecomment-3149788558 [2] Same as with alert/prompt. While all browsers would want to remove them, Chrome not only immediately decided to remove them with very short notice, but literally refused to even engage with people pointing out issues until a very large public outcry: https://gomakethings.com/google-vs.-the-web/#the-chrome-team-has-handl… There's a difference between "we agree on principle" and "we don't care, remove/ship/change YOLO"

https://gomakethings.com/react-is-slow-at-its-very-core/ What's your point? If you disable all remote and interactive stuff you get a fast page render? That's exactly what i criticize here. The page should be considered loaded when all is fetched and usable. And not "loaded" when the main parts from his server are transferred. But yes, the Disqus takes the longest loading time starting at 4s. Scripts start at around 1 second to load. So yeah, you COULD argue the page is loaded after 1 second, but the point is, that it is not _RENDERED_ and functional and not all parts have been fetched yet. Ofc your mileage may vary, i don't block disqus but use uBlock and the page is most likely hosted on another continent which makes latency another issue. To make things fair i took to https://tools.pingdom.com/ and selected american and german servers respectively, which show 140ms for my page (Frankfurt) and still 800ms for his (from NA) which i think is mostly due to the use of http1.1. and ignores all remotely added scripts and tracking.

I personally like the separation of concerns that HTML/CSS/JS evangelizes and I feel like it lines up well with how the old school MVC frameworks want you to think about things. I think a good middle ground here is that HTML web components article that was shared here a few weeks ago: https://gomakethings.com/html-web-components/ I like this because it's still fairly low-code but you get cool stuff out of the box like attributeChangedCallback. You don't have to mess with build tools, which is what I like the most about this strategy. I can just drop these components into my Rails views like any other element, and their custom functionality gets mounted up as soon as they get folded into the DOM. No more document.querySelectorAll(".foo-bar").forEach(foo => bar()). Much cleaner, and the intent is more clear too. With <foo-bar>, it's much more obvious that the element has scripting attached to it than <div class=”foo-bar">.

I graduated graphic design in 2009, I worked from 2009-2011 building Joomla and WordPress websites for companies, then went freelance and I’ve been doing responsive front-end web stuff for about five years now. Here’s how I got from where you’re at to where I am now. The web is built using three technologies: HTML, CSS, and JavaScript. Literally every other technology that gets used with the web has to interface to one or more of these three, so focus your learning on the foundational technologies. If you try to learn React and Bootstrap and Flux and Grunt and Parse and Node and SASS and everything else you’ll get worn out just trying to get started. By learning the foundational technologies you can quickly adopt any tool you truly need to use, but you could never keep up with all the tools available out there. Here are some simple rules and attitude changes I adopted in my own discipline that resulted in rapid learning in CSS, then HTML, then JavaScript: - when building new projects, don’t automatically include bootstrap, or other libraries. Only include what you need AS you need it - don’t look at other people’s code before trying to write your own solution first, this helps you clarify your needs! - when you do look at other people’s code, NEVER copy/paste it, read and earn and rewrite what you need - only ever copy/paste code you have personally written in the past - don’t be afraid to rewrite code at any time - code is expendable, and the more code you write the…