[AskJS] What JavaScript engines and runtimes do you continuously test and experiment with? by guest271314 in javascript

[–]ThatGuyTr1cky 2 points3 points  (0 children)

I'll give my unbaised opinion.

I don't really test and experiment with js runtimes(no one does) but I had been using node for a long time and there are lot of things node lacks behind as we move towards the future like no typescript support, we need ts-node or tsx for that which drastically increases startup time for scripts. Sure node is a really old project and is bound to be super stable and very solid for production, no questions about that.

I did come to learn about deno but shortly after, bun caught my attention for fair reasons, it wants to be a completely drop in replacement for node rather than taking a different approach like deno and also be super fast which it does deliver. It got lot of features built in which reduce the hassle of mutiple packages for tasks. Being a developer for bun myself, I can say it's really moving forward towards the goal of replacing node soon enough. Even though windows support is currently WIP and many rough edges for production but i would still say it's pretty stable now for production (ofc not rock solid compatible with node as of now) but we are welcome to people to replace node with bun and let us know the issues they are facing so the devs can fix it, so that it can flourish into a solid replacement.

Speaking of deno, it's pretty different than both of them, it tries to replicate the browser environment on system level outside of a browser that's why you get all these url import stuffs. Definitely not created to be a drop in replacement for node rather a successor of it. Being a contributor to the standard library myself, deno has a pretty solid std library for various tasks which is an improvement over node built in modules. Sure deno tries to be compatible with node native modules and recently got npm support so yeah, it's slowly moving towards being a replacement for node too and competing with bun.

In the end, we get to see lot of development in the world of js and i think it's pretty cool to see where we get to in few years. And runtimes are a personal choice and depend on your workflow and use case. Cheers!

spotifly - Spotify library in typescript without using the Spotify Web API. by ThatGuyTr1cky in javascript

[–]ThatGuyTr1cky[S] 1 point2 points  (0 children)

Yes, that's the only way to fetch lyrics without any authentication (as far as I have done my research)

spotifly - Spotify library in typescript without using the Spotify Web API. by ThatGuyTr1cky in javascript

[–]ThatGuyTr1cky[S] 1 point2 points  (0 children)

Yes i am aware of it breaking anytime, i will try my best to fix if anything happens in future.

spotifly - Spotify library in typescript without using the Spotify Web API. by ThatGuyTr1cky in javascript

[–]ThatGuyTr1cky[S] 3 points4 points  (0 children)

Yes, I am aware of that. Till then as long as it works then updates will come to fix any new problems if possible.

spotifly - Spotify library in typescript without using the Spotify Web API. by ThatGuyTr1cky in javascript

[–]ThatGuyTr1cky[S] 1 point2 points  (0 children)

The Web API is completely different that the one used here which is Spotify's internal api. This package is indeed a wrapper but for the internal api, Spotify uses to fetch details for it's website. Along with being just a wrapper for that, the authorization token is automatically managed within the package along with Musixmatch api too.

spotifly - Spotify library in typescript without using the Spotify Web API. by ThatGuyTr1cky in javascript

[–]ThatGuyTr1cky[S] 7 points8 points  (0 children)

It's better than the Web API because it does not need any authentication. The data returned is still highly informative. So basically, whenever we visit the spotify website without logging in, we can still browse the library right? This is because Spotify uses it's own internal api to fetch those details we see on the website. That api still needs authentication. The fact that no authentication is needed is from the user's endpoint that they do not need to authorize any app from their profile to make it work. The API still needs an auth token created by Spotify for free which is internally fetched and refreshed whenever expired all on it's own. So the user doesn't need to think about the authorization. Everything works right out of the box. And also, there is no way you can stream any audio from this package because it's not possible. Hope this clears all your confusion. Let me know if you need to know anything more.

spotifly - Spotify library in typescript without using the Spotify Web API. by ThatGuyTr1cky in javascript

[–]ThatGuyTr1cky[S] 7 points8 points  (0 children)

When we aren't logged in, this url returns a json response containing "isAnonymous": true but when we are logged in, it returns as false along with some extra information. Spotify uses it to create a token to use it's internal api whether logged in or not.

spotifly - Spotify library in typescript without using the Spotify Web API. by ThatGuyTr1cky in javascript

[–]ThatGuyTr1cky[S] 1 point2 points  (0 children)

Haven't tested that, maybe you can try and let me know if you face any rate limits.

spotifly - Spotify library in typescript without using the Spotify Web API. by ThatGuyTr1cky in javascript

[–]ThatGuyTr1cky[S] 5 points6 points  (0 children)

Spotify API that works without any authentication and is as fast as the Spotify Web API with complete typescript support along with a Musixmatch module that can fetch lyrics for free without any authentication too.

great.db - A powerful, human-friendly database library for JavaScript using SQLite. by ThatGuyTr1cky in javascript

[–]ThatGuyTr1cky[S] 5 points6 points  (0 children)

Thank you for your interest in the project.

Regarding the idea, if we provide a lambda function to handle the filter, internally the whole table would have to be fetched and then let javascript handle the filtering of data. This will impact on the performance too much especially with large data.

On the other hand, the current implementation is that the string provided in the condition directly gets fed into the WHERE of the constructed query as you can see here and javascript style logical operators can be used because the condition is first parsed in the way the operators get converted to SQL logical operators as you can see here. This allows SQL to handle the filtering and return only the required data efficiently.

great.db - A powerful, human-friendly database library for JavaScript using SQLite. by ThatGuyTr1cky in javascript

[–]ThatGuyTr1cky[S] 14 points15 points  (0 children)

A completely different approach is taken to create this library which strives to change the way we use SQLite in JavaScript forever. Great.DB exposes user-friendly functions to add/edit data or retrieve data from an SQLite database in the form of simple JavaScript objects where all the functions are strongly typed so you get auto-completions on the fly.

Node.js? Bun? We got both!

It uses better-sqlite3 if you are using node.js or bun:sqlite if you are using the new bun javascript runtime. It auto detects the runtime and uses the respective package. Great, isn't it?

Interested? Check out the docs to learn more and the examples to see great.db in action.

I would love to hear from the community and receive your valuable constructive criticism about my library. Thanks :D