BYOJS (Bring your own JS) | Hacker News Reader

BYOJS (Bring your own JS)

byojs.dev

63 pointsfs_software83 comments

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!

Funny. I did a few years with Rails and won’t go back now that I use Typescript. I like the Rails and Ruby libraries. But I don’t like the Ruby language. You can always get better libraries for JS. But the languages are more or less fixed.

I would love better typesafety in Ruby, but really don’t like the Sorbet solution.

However, interestingly I don’t find I need libraries that much with Rails, which is part of what I love.

I started out hating the Ruby language but honestly I’ve begun to like it the more I use it.

I keep trying rails because I love Ruby so much but I've never been able to build anything in it because I find it's so heavily skewed towards an old-fashioned "traditional" stack and I tend to build SPAs with an API. Rails can certainly do that, but its tutorials and guides don't promote it at all so it feels like you're going against the flow from the start trying to do something that they don't seem to want you to do. I wish that wasn't the case, because the language is beautiful and the framework seems quite cool.

I always just end up using express instead...

Have you used it with Turbo/Hotwire/Stimulus?

The more I work with MVC page-based apps in Rails, the more I’m convinced it’s an incredible default that you should deviate from only when it really makes a lot of sense.

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.

I worked at an agency that did this (they were rather religious when it came to the "no frameworks" rule) and I can absolutely say that it is far less productive for complex UIs.

It's basically a home-spun version of backbone, and the reason people don't do that so much anymore is the same that backbone fell out of favor- you don't naturally get composable components without lots of manual management and excess paints and reflows.

It's certainly possible to build what 75% of websites actually need with this approach, but I wouldn't consider it for a moment for any UI that I actually consider to be complex.

It is far less productive for complex anything, not just UIs.

The only way to do home-spun stuff in JS/TS is to narrow the use-cases and components down religiously. The moment you'll require more than 2-3 bits of the website to interconnect... take one long hard look at the future and avoid the headache of writing your own JS boilerplate.

I love eschewing JS frameworks as much as the next man, but I also love my free time. Too much to waste it debugging problems coming from hundreds of different user stories and approaches. React's mature enough, as are most of the big libraries commonly leveraged on it.

I don't waste time doing that. Sounds like a skill issue :)

React is on like version 18, you guys can keep getting paid to upgrade frontend libraries every year, I'll watch.

> React's mature enough, as are most of the big libraries commonly leveraged on it.

Mature software doesn't break things every other year.

It really depends on what you mean by “complex UI.” In you mean a UI that needs to handle real-time user input, then it is extremely difficult to get React to be performant once the complexity reaches a certain scale.

As an illustration, try to make a website that has 1000 drag-and-drop elements that you can drag around the page. Getting it to render at 60-120 fps is hard and fragile.

"As an illustration, try to make a website that has 1000 drag-and-drop elements that you can drag around the page. Getting it to render at 60-120 fps is hard and fragile."

Glad I always avoided react then, despite all the hype.

React is nice for a lot of things, but when it's a pain it's really a pain. That's abstraction for you! :)

Yeah I wouldn't use backbone either. I use reusable components.

It really hasn't been a productivity issue for me... I wrote all of fastcomments (uis, backend), so... :P

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.

That's exactly what I'm doing too, after working with Lit for a few months (which is great) I felt that it would be easier to create a (even) smaller framework specific for my needs with only lit-html. I never been happier with Web Development in my life.

is this framework publicly available anywhere?

I've been thinking about making my own lit-html + honojs isomorphic "framework" and would love some inspiration.

I'm curious, if you're using lit-html, why not use LitElement as well if you're building web components?

I want to avoid another "not-a-framework" framework, like how React called itself "just a library" to semi-honestly offload the responsibility of state management. I don't know if LitElement is that, but I have some trauma.

On a positive note, it's a joy to compose my own framework.

Fair enough. For the record, I'm also planning to build my own very mini "framework" based on just lit-html.

Is yours shared publicly anywhere? I'd love to check it out for inspiration.

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.

I really don't understand why people are still using an inferior tool chain to build JavaScript in 2024. The type checking alone has the potential to save countless of bugs.

I wish we could get rid of "vanilla js must imply going back in time 10 years" ideology because it's so unnecessary. Using typescript doesn't mean you have to go react or other libraries.

eh... so far Typescript hasn't saved us from any bugs, but YMMV.

Ditto. If anything, trying to add it into an existing codebase via JSDoc has only really been a detriment via being a massive time sink. It might have caught maybe 4-5 bugs in the code but none that presented a large enough issue to warrant the time investment. If you're starting from scratch with TS instead of JSDoc, it might be worth it, but even on the best of days trying to figure out typing oddities from library typings being wrong and such have only really added headache. As always YMMV

Even if that's true (maybe your team is really careful about documentation and data structures even when they don't have types?) - the majority of the "bugs" TS catches are those that would be caught manually anyway, during development.

It's just that instead of measuring those bugs in hours, they don't even exist to be measured.

> It's just that instead of measuring those bugs in hours, they don't even exist to be measured.

hours beautifully wasted configuring, updating, getting beaten by a myriad of build tools, configs, breaking changes, wrong/any types all everywhere. No, thanks.

The eternal question of spending "x hours upfront" vs "x/2 hours every single day"...

I have a feeling you made up "x/2 hours every single day".

Yes, I did. What's the correct denominator that makes the daily effort worthwhile for you? Would you do x/5? x/10? x/50? After 50 days of continuously spending more effort than necessary, do you make the trade or just accept the ever-increasing loss of productivity? Fortunately for us all, the real number for "configure Typescript" is a lot closer to 1 than to 50.

Typescript is not saving me x/2 of the usual time I spend coding, not even close, not even in the ballpark. It's more like costing me 10% of my time due to missing types in libraries, hassle of extra tooling, more complexity, compilation step, etc, etc. Yes, I made that up that 10% figure, but I wouldn't be surprised if it's close to that.

If you're prone to making easy to avoid errors in your code, then maybe Typescript will save you time. For me, that is not the case. YMMV.

If you're a library author doing non-trivial type stuff, it's believable you might be slowed down by more than 10% because TS can get really really tricky for libraries.

But it's worth it because you're about to get a massive multiplier effect based on the scale of your user base.

>If you're a library author doing non-trivial type stuff

So what if I'm not a "library author", what I do could still be non-trivial, and I could still do it without typescript like people have been doing for decades before. Typescript is not the only strong-typing game in javascript town.

>But it's worth it because you're about to get a massive multiplier effect based on the scale of your user base.

Using typescript is not a causal factor for this. What the library does, and what people need is.

And honestly I don't care who is using a library I make, life isn't all about likes and it isn't a popularity contest.

You don't think a tool saving 10% of your time is worth learning to use?!

Anyway, this gets off-track. The metric is (time wasted on problems that only exist without typing) / (time it takes to configure TypeScript). Regardless of what your 10% figure is, learning TypeScript and configuring it for a project takes less time.

> If you're prone to making easy to avoid errors in your code, then maybe Typescript will save you time. For me, that is not the case. YMMV.

Putting aside the dig, it sounds like you're working alone, so use whatever you want. It matters a lot less when you control the data structures and hold the entire program in your own head.

How special can your needs be that low-config setups that satisfy most people won't work for you? Is this a polyglot monorepo? If so then you're going to have a build and deploy story that's even more complicated than what TS people are used to.

Moderately sized polyglot orgs will have a specialist for this position.

Are you using strict mode?

Just knowing wtf an API response shape the app is expecting, or what the shape of a function argument object is... I can't imagine arguing against TypeScript (or whatever thing documents the shape of your data as it moves through your app).

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/

excellent app.

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.

> And don't write your own tooling because its very addicting.

I plead guilty your honor

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?).

Optional typing is one of my favorite features of groovy.

Explicit typing also helps show where code needs to be explicitly performant and of course where type strictness is valuable.

I'm assuming of course that types in js flavors has performance advantages a la asm.js, but admittedly I haven't tracked JavaScript evolution that closely.

If it isn't typed then that helps clue the programmer that looser dynamic techniques being used.

I'm not arguing against types. I'm arguing against an extremely convoluted type system that is so complex it's practically a language on it's own. And it's sole existence is to make a dynamic language not dynamic.

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.

I've found tsc --noEmit with esbuild is the magic combination.

This way you can split the type checking from the actual bundling, as esbuild only does the latter.

esbuild can bundle typescript files directly, you don't need tsc to strip types

edit: nevermind i get what you're saying. check types with tsc and dev work with esbuild

> "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.

It's the eternal infinite loop of " lightweight" replacing "heavyweight", then needing more features/support/testing/management/,tooling, becoming "heavyweight".

To reacts credit, they started out heavyweight, but they knew it needed to be to address the problem in the manner they desired

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.

I see lot of frontend people say this (since their baseline is "nothing"), but as someone who's used to compiled languages, all JS-ecosystem tooling is quite atrocious. It's still missing many of the useful basics that other ecosystems take for granted.

The way around this is to build your own tools. For instance, I used esbuild as a library to write a custom obfuscator that links the hand written JS and GLSL together. (This is why the shader link symbols are also obfuscated).

I came from many years of compiled languages in the games industry. I would not assume the current state of React and TypeScript is bad, far from it. There are reasons this stuff has eaten away at more native approaches, or inspired things like SwiftUI.

Edit to add: To also add that in my time I've seen more WebKit added to games in order to do the UI. For instance, that Sim City which was always connected to the cloud, or big bits of the PS4 interface.

"build your own tools" is also known as "the ecosystem is lacking"

One tool does not necessarily fit all the things. And that would be true of any "ecosystem" that has as many diverse uses as Javascript does.

Versatility is one of Javascript's strengths, not a weakness. And with that versatility you get what seems like too many frameworks.

I have never met an existing ecosystem where building your tools did not make your life easier, at least in the short term. The trick is knowing when to abandon them in favour of a standard solution.

To put this in perspective one team I was on built their own Android NDK, until the normal one caught up.

True, but I've never met an ecosystem where building your own tools is required.

Could you give some examples of these many missing basics?

Two blatant ones: 1. conditional compilation (typecheck and use these apis only in some environments), and 2. being able to compile "hello world" in under 1 second. I know I keep finding more but these ones I can't even write trivial programs without running into.

I've been trying to emulate conditional compilation using multiple directories, but that runs into problems with each tool using different path lookup logic.

This sounds more like lack of knowledge/experience of the tooling rather than problems with the tooling itself.

Many build tools will “tree-shake” unused code and support conditionals when compiling their bundles.

Build time varies considerably depending on the tooling you use and the size/complexity of the project, and is definitely much slower than many other languages, but while developing people will use incremental builds which can complete faster than you can type a new statement.

What other basics are “missing”?

Ignoring the massive vtable problem for a moment ...

If tree shaking is so good, show me how to write something like this:

* when targeting browser, use dom

* when targeting node, use process/fs

* typescript should bail out if a mixture of APIs is used. That is, the type-checking must be done twice - once for browser-only, once for node-only.

(nodejs is also rather abominable for implementing APIs that really, really only make sense in browsers, like `navigator`, breaking everybody's runtime detection, but all non-browser environments require evil hacks anyway)

The obvious way is to use separate configs for each target - most bundlers support running these builds in parallel.

It seems like you are trying to do something in a specific way instead of using the available tooling correctly. That’s not a problem with the tool. You just need to RTFM

As for the “massive vtable problem”, that’s not even a tooling issue. Why are you even using JavaScript if that’s a problem for you.

For your case 1 my extended obfuscator does do preprocessor style stuff, but that is a giant hack.

For case 2 you can use esbuild, not something like webpack. Sub second builds are completely normal if you pick the right bundler. Tbh esbuild is the killer thing that moved this mode of js development into being acceptable from a total mess.

The problem with `esbuild` is that it silently does the wrong thing whenever there are type errors. The main job of a compiler is producing error messages; actually producing an output file is secondary.

`tsc` is so slow that it seems the least bad approach in use is "automatically run it asynchronously in the background", which is not confidence-inspiring.

You can separate type checking and building. Have tsc to check types and esbuild to build. These can run in parallel, or at different stages of your pipeline.

The background asynchronous incremental typechecking is how most typescript devs are working anyway, as issues are immediately highlighted or otherwise output in your dev environment of choice (whether that be inline, or as output in the console).

Can you describe some of those basics? In my experience, the JS ecosystem is surprisingly good, and most of the issues tend to be due to a lack of experience rather than directly tooling issues. For example, NPM is one of the better package managers out there, but like all package managers, if you haphazardly chuck dependencies at it, and don't pay attention to what you're going, you're going to have issues. A lot of people run into those sorts of issues and assume that this is a general NPM problem, but it doesn't have to be that way.

I've replied more in the other tree, but I'm not even touching NPM yet. The stuff I'm writing is simple enough not to need any dependencies.

Why don't you give us some examples?

do you use React capabilities exclusively for state management? I have found that they inevitably fall apart when things get sufficiently complex, which has me reaching for one of the many MANY 'other' state management libraries.... which then sometimes has me reaching for other related things, which then....

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

Why this alienation?

The author is Kyle Simpson of "You don't know JS" fame. He was, at least initially, very much against Typescript as a concept.

Isn't alienation exactly what you are doing here?

9 out of 10 JS posts here are talk positively about typescript.

Let the 1 of 10 talk freely, could you?

Odd way to respond to my question. No where was I espousing censorship.

It is not censorship for those who like JS-looking languages like TypeScript. The idea that focusing on JS is alienation is at least hilarious for someone that doesn't follow the typescript religion.

So it's not alienation? What exactly are you arguing? Why are you arguing?

How has TypeScript hurt you to this extent?

alienation is to want that people should always choose TypeScript, which is what you were initially complaining in favor of, just because this specific post mention not using Typescript.

No. That's your interpretation of what my post meant. I was not complaining about anything. Neither did I indicate anywhere that everyone should always choose Typescript.

Typescript is obviously so related to Javascript that I wanted to understand more—technical reasons—why the author was excluding Typescript in such a way from any sort of treatment, even passing remarks that explains his stance. I may not have explicitly asked for a technical discussion, but this is Hacker News and I know better what my intentions and meanings are than you do.

You're the one who brought the complaints, and made it into a religious dispute.

Go into my comment history and find any discussions from me about Typescript or Javascript. You're superimposing a debate on me that I'm not part of. I did not know that debate was so omnipresent in the community that you deem it rational to extract such intent from my question, but I see that now.

Perhaps I was not privy to such a debate because Typescript has so obviously won.

> No. That's your interpretation of what my post meant.

Ok, that's what I understood from your post. Sorry if I got you wrong.

But the reason to exist of this thread is to talk about JavaScript, pure old JS.

Unfortunately, the mention of TypeScript got more attention than anything else.

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.

I would feel cool doing this until any sizeable DOM manipulation and then immediately remember why react was such a godsend.

The underappreciated part of React today is it helps you to be more secure by default. Once you are handling user generated content, even of the simplest kind, it's far safer.

I would love to do this. However, if you are building a heavily interactive application, wouldn't it be easier to manage with a framework instead of jquery ? Wouldn't you want to manipulate DOM more easily than with jquery ? Unless the web app is not that complex. Thoughts ?

Reply on news.ycombinator.com