BYOJS (Bring your own JS)

https://byojs.dev/

by fs_software • 2 years ago

63 83 2 years ago

byojs.dev

handfuloflight4• 2 years ago

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

Why this alienation?

billyp-rva• 2 years ago

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

meiraleal8• 2 years ago

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?

handfuloflight4• 2 years ago

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

hitekker2• 2 years ago

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.

meiraleal8• 2 years ago

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.

nchmy3• 2 years ago

is this framework publicly available anywhere?

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

nchmy3• 2 years ago

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

hitekker2• 2 years ago

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.

fidotron6• 2 years ago

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.

o11c7• 2 years ago

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.

fidotron6• 2 years ago

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.

supermatt4• 2 years ago

Could you give some examples of these many missing basics?

MrJohz• 2 years ago

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.

zeta_• 2 years ago

Why don't you give us some examples?

ledauphin• 2 years ago

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

mplewis• 2 years ago

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.

fidotron6• 2 years ago

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.

STRiDEX2• 2 years ago

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

brrrrrm• 2 years ago

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

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

newusertoday• 2 years ago

excellent app.

threatofrain3• 2 years ago

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.

zoover2020• 2 years ago

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.

leptons5• 2 years ago

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

ervine3• 2 years ago

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

philippta• 2 years ago

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.

ervine3• 2 years ago

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

fidotron6• 2 years ago

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.

codegeek• 2 years ago

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 ?

winrid4• 2 years ago

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.

zdragnar• 2 years ago

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.

tinthedev2• 2 years ago

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.

in-pursuit• 2 years ago

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.

winrid4• 2 years ago

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

adamtaylor_133• 2 years ago

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!

teaearlgraycold• 2 years ago

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.

adamtaylor_133• 2 years ago

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.

windowshopping• 2 years ago

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

adamtaylor_133• 2 years ago

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.

tinthedev2• 2 years ago

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.

STRiDEX2• 2 years ago

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.

harel2• 2 years ago

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

AtlasBarfed2• 2 years ago

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.

harel2• 2 years ago

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.

z3t4• 2 years ago

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.

meiraleal8• 2 years ago

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

I plead guilty your honor

miffy900• 2 years ago

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

AtlasBarfed2• 2 years ago

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

gcau• 2 years ago

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.

BYOJS (Bring your own JS)

Related Stories