DailyJS

I love how many people there are in this thread that somehow avoided the jQuery hell a lot of us battled against.

I was involved in that, mostly from when my paycheque involved throwing together websites in Drupal 6. Holding that architecture together was trouble enough without having to also care about the frontend, we were only scripting it. The idea of the HTML being considered an 'app' was utterly alien to me and my colleagues at that time.

I fondly remember the short period of time where we had post after post attempting to explain what a closure is, because for most of the authors back then the concept of a function pulling outside variables into its scope was utterly alien to us. Even now this practical meme persists[0].

Ten years later and I find closures more intuitive than half the stuff we've concocted in OOP land.

More than that, jQuery was a means to an end and to shove low-effort animation and UI into an app to make it look snazzy and 'Web 2.0' like (glass effect banners, drop shadows and all). If it wasn't jQuery it was script.aculo.us.

Then we got Backbone and Coffeescript at around the same time, by which time I was a Ruby dev. Backbone contributed to a fundamental shift in how we build a frontend, and we had Knockout, Sencha, ExtJS, etc. following along. And then the concept of 'comet' (keeping an HTTP connection alive for long polling) and MeteorJS.

The impact of React and its concept of the VDOM has been phenomenal. It may be overhead as the Svelte…

""On mobile, using menu to search in browser menus" -> This is not a sentence. " -> Sorry, I meant using the browser search feature by invoking it from the contextual menu of your browser, which is the only way to spawn the search toolbar on mobile.

" but the reality is that i HAVE to implement search because it is hitting on 730000 per year records;" -> True, there should be a search feature with a backend API.

"Again, you are too happy about your opinion that you spite it out like truth without even understanding specs."

Yes I want too far, your use case does require extra logic, because it's not good to send that much data to the user.
I'm not pushing a workflow, im not a front end dev, but i do maintain frontend apps sometimes, i'm simply angry at React, because it cause pain to me as an user.

It's noticably slower (https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1).

The virtual list may be required for your use case, but as a user, I often met virtual list:

- Used for less than 100 elements

- ctrl f is not hooked on the 'webapp search feature'

- the 'webapp search feature' is noticably slower than the browser.

Also, here some reading, from a framework I don't use, about the virtual dom:

https://svelte.dev/blog/virtual-dom-is-pure-overhead

Now, not as an user, but as a software engineer, my soul cry when I see the architecture principle of such a framework fixed with a workaround.

I enjoyed slightly more fine grained comparisons, like: https://youmightnotneedjquery.com/ (this hasn't been updated in a little bit, it seems)

Either way, I think you're right, just use whatever works for you.

I'd admittedly love to see a larger scale comparison of going vanilla JS vs recreating the same functionality in jQuery/Vue/Angular/React, for a real world apps and what the takeaways are from that, say, 50'000 SLoC instead of 100, that'd probably be more useful, but also is way more unlikely. Nobody will put in that much effort just for the sake of a comparison and so a lot will be up to opinion and comparing vaguely similar projects.

Closest I've seen was https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1 but still a fairly simplistic example, given the large amount of options that were compared. Still very cool, less about opinions and more about giving you metrics that you can weigh in yourself! Here's the repo: https://github.com/gothinkster/realworld

> I can't memorize all thousands of functions to manipulate lists and hashs in clojure (get-in, map-vals, conj, dissoc, select-keys, sorted-map-by, do you know what all those do?) which do a lot, I felt clojure was dense, the opposite of little cognitive load

In fact you need to memorize 10-20 functions to be productive in Clojure. Many of them are common across the other FP languages and some FP libraries for imperative languages and most of them cover common patterns for vector/map manipulation. Yes, the names could be confusing at first but there is good reasoning and logic behind them so it’s easy to learn.

> because in fact I love how productive I am with Elm

This is interesting because according to Real World App benchmarks Elm implementation has ~4x more lines of code then Clojurescript one [1]. How could it be more productive to write 4x code for the same result?

[1] https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1

Shameless Plug :)

I wrote recently a series of articles comparing most of those providers and explaining how to use them with JavaScript:

- Amazon S3: https://medium.com/@javidgon/amazon-s3-pros-cons-and-how-to-use-it-with-javascript-701fffc89154

- Google Cloud Storage: https://medium.com/@javidgon/google-cloud-storage-pros-cons-and-how-to-use-it-with-javascript-ea9ce60a94c0

- Microsoft Azure Blob Storage: https://medium.com/@javidgon/microsoft-azure-blob-storage-pros-cons-and-how-to-use-it-with-javascript-ca5aaf5d5ffd

- Backblaze B2: https://itnext.io/backblaze-b2-pros-cons-and-how-to-use-it-with-javascript-8c2d2a9a69d9

- DigitalOcean Spaces: https://medium.com/dailyjs/digital-ocean-spaces-pros-cons-and-how-to-use-it-with-javascript-1802559ce2bd

- Wasabi Hot Storage: https://medium.com/@javidgon/wasabi-pros-cons-and-how-to-use-with-javascript-fa528c3779a2

I'm using only Vysor and Postman Chrome Apps. So I can probably switch to their Electron variants.
But have mixed feeling about Chrome Apps discontinued.
On one hand it's good as Chrome Apps were tied just to Chrome/ChromeOS, while web apps should be platform agnostic. On other hand, Chrome apps were much smaller than Electron apps, as Election runtime has not to be included with every app (Chrome was the shared runtime). There is about 2 orders of magnitude size difference (megabytes vs. hundreds of MBs).

Wish we have system level support for Electron apps, so not every single one has to bundle Electron libraries separately.

Edit: There is already project that is targeting that. https://medium.com/dailyjs/put-your-electron-app-on-a-diet-with-electrino-c7ffdf1d6297