BYOJS (Bring your own JS)

I find it ironic that as JS/TS begins to pick up more and more steam (and market share) that I find myself loving Rails more and more each day.

I have never felt as powerful or productive with JS (as much as I love it) as I have with Ruby on Rails.

I’ve “almost built” countless projects that never actually shipped with Node. Whereas with Rails I have shipped so much I feel like I was cheated out of the first few years of my career not knowing Rails.

All that to say. I love JS (and especially TS), but they’ve got to find their “Rails” before I can truly come all the way back.

There’s a few contenders (Redwood, Adonis), but none of them have been battle tested the way Rails has—yet!

FastComments is a couple hundred thousand lines of JS now (backend and frontend, with a couple small backend java services)

I hope to move to TS in 2025

But, we still don't use a frontend framework, we just write components as classes. Each component takes a root node that the parent is supposed to "own", and that's kinda it. React is more productive short term, but I find this easier long term with complex UIs, keeping memory usage low, and less work keeping stuff upgraded.

This comes off as very naive and contrarian, and like the author just wanted a reason to create some more javascript libraries. The lack of types in your library makes it harder to use, more likely there will be bugs where its being used, and the library itself is probably buggy. The author commonly champions bad practices, that you should "just know" how js works and then none of this matters.

There's very strong reasons a vast amount of people are switching to typescript. It can very easily compile to clean javascript, you can commit that to git, and you are much better off.

I've found it especially useful, in recent years, to eschew a lot of JS and go back to the "stone age" so to say, when developing non-public components.

I'd still not go without React (or something similar) to manage DOM in the user-land, but there's something blessed about using barely any to no JS at all in an admin/moderator UI, or in dev tooling. Don't have to consider any of the compatibility/update headaches outside of the user space.

That rant aside, I feel that the best approach to JS is a static one. Build your code and your artifacts, package them long-term... serve them when needed and you're done. It's somewhat retro, SPA style, but it works like a charm and doesn't require building all the time, nor babying all the dependencies and build steps.

Off-topic, feel free to ignore: I'm enjoying lit-html with web components (and no LitElement). Feels pretty native and down-to-DOM, kind of like building my own framework while building my own app. The aspects I need to control are mostly in my control and the aspect I don't care about are handled for me well.

Paired with Claude Sonnet 3.5 and I'm more productive than I've been in years.

Mmm as a library author, even if your users don't use TS they can still benefit from the typings you provide as an author.

there's existing libraries in this space that are quite good. not sure why you would use this instead.

storage for example:

https://github.com/unjs/unstorage vs byojs storage https://github.com/byojs/storage

most users are going to prefer autocomplete and types regardless of if they also use typescript.

probably my biggest pure JS app is this one: https://github.com/bwasti/mebm

you can try it here https://bwasti.github.io/mebm/

Being able to develop with instant feedback and without any tooling is pure joy. Just open a simple text editor and within minutes you have something up and running on your own computer without having to install anything. Then when you want to publish it you just upload it as is to a web server. And if you need to write a server all you need is a single program called NodeJS where you also get instant feedback and it comes with a standard library that lets you do just about anything. The only negative about vanilla JS is that writing async code is difficult, but no tooling can solve that problem. Try vanilla JS for one year and your productivity will go up one or two orders of magnitude, because development is now fun, fast and simple. Just don't write too big of a project because when you start to bring in tools its a slippery slope. And don't write your own tooling because its very addicting.

I really truly hope that one day optional types are introduced to the EcmaScript/JavaScript spec. My only reason for saying that, and I know it's the unpopular view, is that I actually LIKE JavaScript and think TypeScript is a mess of over complicated concepts, trying to do too much and feels sometimes it's in competition with itself for how verbose and complex it can be. So I'm hoping that the introduction of types to JavaScipt will be the same death spiral seen with the likes of CoffeeScript (remember that?).

These days, I would not write a pure JS app if I could help it. JS is so dynamic that TS is a mandatory step for safety whenever it’s possible to use the TSC compiler.

> "but it feels like a lost art to build effective web applications using the core JS language."

Yeah it is getting lost, more and more lost each year - you know why? The core JS language is bad. Note how the author uses the word 'core' instead of what they really mean: 'subset'. Use a subset or a small portion of the language, because if you use the whole breadth of language features, you will litter your application with so many landmines that you will eventually scrap it and re-write due to how awful most of the 'features' in JS are. Even using a subset you have no choice to resort to syntactical verbosity to get around bad language design, like === over ==, or const & let over var.

I wonder what the ultimate point of posts like these are; it's like someone trying to light a fire during a flood; and to what end? To pointlessly champion a bygone era of when people didn't know better? Let's be clear here, JS is popular because it is the only language shipped by default in browsers, since 1996. That's it; it's not popular because it's good; we're not using it in 2024 because it won out in a contest of merit. It's design phase was rushed and even its name betrays how stupidly conceived it was; 'JavaScript' - as if superficial association with an already trendy tech during the 90's was somehow enough to paper over it's obvious flaws as a language. Just laughable.

Seriously, it's 2024, we know better now - use TypeScript. It's actually kind of amazing how Microsoft released TypeScript only in 2012 and not years earlier.

Honestly, TypeScript and React are in such a good space now that adopting those two is a near no brainer. You need discipline to not bring in millions of other dependencies.

I've done the whole "I'll write it all in JS by hand" to a ludicrous degree: https://luduxia.com/whichwayround (and the rest) and while there were advantages when this started I am now looking to port the useful bits over to saner ways for future maintenance.

> and also no disrespect for those who like JS-looking languages like TypeScript...

Why this alienation?

I‘ve started building a new web app (not website) using Go and jQuery, all loaded from a CDN without any build step. Writing JavaScript the imperative way (rather than declarative like react) feels very refreshing.