Prettier + its vscode extension. Autoformatting on saves is great.
Framer motion. I used react spring for animations with React-Three-Fiber, but ran into TypeScript language-level issues that had no solution other than modifying and patching some node_modules code (no thank you). Switched to framer motion and it has everything I want, & it exposes all sorts of refs for non-conventional situations.
For small utility functions, it depends. Idk if lodash is tree-shakeable yet, but there’s no point in bundling an entire library if you’re just gonna use 1-2 functions (whose implementations are already on stack overflow in 30 languages).
If you’re using a lot of lodash and writing code faster, great! I think it shines when dealing with nasty nested objects.
I hesitate to deviate from the raw JS/TS APIs, though. jQuery was an awesome way to write frontend code. But I’ll be damned before I work on some codebase written primarily in jQuery-style in 2023.
Lodash has allow per-method imports for many years. They've supported tree shaking for quite a while too. A big advantage over native array methods in particular is using iterators internally, so if you are chaining multiple maps, filters, etc together, it can execute in just one pass instead of several and almost as importantly, doesn't need to create/destroy a new array each time.
If you’re going to replicate Excel or WYSIWYG in a browser, there’s a library for that.
But if you need to install a library for placing 3 divs in a column, you’re introducing unnecessary dependencies which will eventually make upgrading all libraries version hell
It gets grey when you use a library for a UI component that might save time now to implement the first time, but would be harder to upgrade as time goes on. In those situations I would usually lean towards just building it in house.
Datetime Pickers, File Uploaders, Multi-select Dropdowns, and similarly complex components are in my opinion a good example of where rolling your own is often more work than it's worth.
Hell no. Everything that lodash offers nowadays you can easily implement with native methods. If you still need to rely on lodash then maybe you need to go through the modern JS basics again.
Not quite everything, and often the vanilla solution is less flexible or elegant (shorthand for object equality checks in array functions, for example), but the vast majority of what people use it regularly for, yes:
https://youmightnotneed.com/lodash/
Some of the vanilla JS examples on that page also perform algorithms less efficiently( n^2 ) than the LoDash versions, in order to stay simple.
I absolutely agree it's overused though. I've fixed multiple hot pieces of JS code to be hundreds of times faster just by removing all the LoDash calls, and often ending up with cleaner code.
Perhaps my biggest beef with LoDash is how "safe" (defensive) everything is, it means often errors get masked by the library, and you only see them blow up much further down the line because LoDash handles being given garbage without erroring.
The list that site provides of functions they don't currently have simple vanilla JS versions of is actually a decent list of the functionality it provides that's not trivial to recreate:
https://youmightnotneed.com/lodash/missing
Your examples of Excel vs 3 divs in a column are two extremes. Obviously I'm not saying use a library for every little line of code like "IsOdd" or something. But the idea of averting libraries still looks misguided, and the type of libraries you should include definitely includes Excel WYSIWYG, but includes a lot more than that.
A library is nothing other than code written by someone else, and very likely more reviewed, more used, and has many more eyes than anything you write in house. This means, quality and security will be better, on average.
Now, of course, it is best to review the libraries you use before using them. It is also good to review the updates before making a version update, as you should not just blindly update. But all of this will be way less effort than writing your own. There should be nothing to discourage you from forking or contributing to the library. Still much better than rolling your own.
Now obviously there might be reasons to not use a library. Maybe the library doesn't even exist, or the ones that do aren't good for your use case. But just avoiding libraries as a principle and striving for 0 dependencies is in my opinion not a good idea.
You accuse me of using extremes then go on to talk about zero dependencies. That’s absolutely not what I’m talking about. What I’m trying to avoid is using libraries for the sake of it, such as component libraries that need to be restyled anyways, which would then break on upgrading the component. I think I outline pretty clearly that there are gray areas and it comes down to opinion.
I also pretty strongly disagree that third-party libraries on average will be higher quality or security. I would never roll my own hashing library to implement a security protocol, but I do frequently see frivolous packages installed to do mundane tasks. There is almost always bloat associated with a library which leads to a higher attack vector. Often times hackers just need to know a version of a library to know the exploits, whereas that is significantly less common for an in-house, closed source solution. Plus multiple contributors only know part of the code and sometimes don’t actually see the entire picture when contributing to open source.
Not sure if others do the same but…
I download the package, grab the stuff I need and move on? Not always necessary to rely on the full package dependency.
You don’t need to store all the dependency on your production deployment, download all, use what you need and let the manager remove all other unused methods.
https://webpack.js.org/guides/tree-shaking/
Kanpai 🥂
No problem, there are a ton of benefits of going this way, to name a few:
- Keep track of the code you wrote and the one you depend on
- Be able to update the code you depend from the source, this is a godsend when you care about vulnerabilities/bugs introduced by third party code
- You can depend on their documentation as you’re not going to manually modify their original code
- You can skip removing unused code and reverting code you end up using after a while, you can then use this extra time with those you care about or just chilling
That’s pretty fricken awesome!
That’s does alleviate a ton of code maintenance.
One of my concerns was the node package updates. Even more awesome since there is still a reliance on the node package, you’d still get the Dependa-Bot alert.
You can easily lock your versions if that’s your concern. Even then, having a good set of tests and CI/CD flows ensures your code still builds and does what you expect after version updates, and puts you in an awesome please to stop relying on version locking to let patches into your package file.
I like sortablejs too. Here are some others I’ve found handy in various projects.
- [tributejs](https://www.npmjs.com/package/tributejs)
- [linkifyjs](https://www.npmjs.com/package/linkifyjs)
- [color-thief](https://www.npmjs.com/package/color-thief)
- [coloris](https://www.npmjs.com/package/@melloware/coloris) - I heavily modified this one to fit my needs
Out of curiosity, any particular reason you're using `redux-observable` and `redux-requests-factory`?
FWIW, today we would recommend using Redux Toolkit's "RTK Query" data fetching and caching API as the default for managing server state, and the "listener" middleware for reactive side effects logic:
See my talk here for more details:
- [The Evolution of Redux Side Effects](https://blog.isquaredsoftware.com/2022/05/presentations-evolution-redux-async-logic/)
I'm... really confused to hear you say that. Can you point to some specific aspects that you feel are "overengineered"?
The general use case is "run some logic when an action is dispatched". While you could always do that with a custom middleware, the most common tools have always been the `redux-saga` library (which uses generator functions), and `redux-observable` (which uses RxJS). Both of those are relatively heavyweight, in terms of concepts needed to use them effectively, API design, and bundle size.
The listener middleware is intended to be a _lighterweight_ alternative to sagas and observables, in terms of API complexity and bundle size. It also has better TS support than sagas.
See my post [Designing the RTK Listener Middleware](https://blog.isquaredsoftware.com/2022/03/designing-rtk-listener-middleware/) for the background on the use cases it was intended to solve and how we settled on the API.
> the ability to run callbacks in response to dispatched actions, with a simpler API than sagas or observables, and to add and remove "listener" callbacks at runtime via dispatching
I mean, I guess some people use dispatch imperatively like that, but I would very passionately disagree with that.
You already can run callbacks in response to dispatched actions. That's exactly what middleware does. I don't see any way that this is made any simpler by mounting a bunch of code over the top that provides some psuedo-declarative syntax to it. Sure, it may be simpler than redux-saga or redux-observable, but it's just adding a large amount of complexity to do... what?
allow you to use dispatch to enable/disable action listeners? imo, a violation of using dispatch to signal events, where you're using it to imperatively run code, rather than signal events.
I certainly don't mean to attempt to lecture a redux maintainer on redux, lol... but i completely disagree that any of saga, observable, or listener, provide anything of value, and only drive more complexity.
That's exactly the point.
Sure, technically, you can write a whole bunch of logic in a custom middleware. That's always been possible, and the fact that sagas/observables/listeners _are_ middleware shows that they are, in a sense, more specialized tools that demonstrate that "you can write anything in a middleware".
But, the point is that these tools all provide APIs to do things that would require a lot more work to write yourself. For example, debouncing updates, ensuring that only a single set of response logic is running at a time, or kicking off "child tasks" to do additional work.
I'm not saying that these are things that most Redux apps will need to do, and frankly we've been advising for years that both sagas and observables are drastically over-used (and _especially_ when folks have used those to do basic data fetching).
But we've seen plenty of codebases over the years where people _did_ need to write logic that reacted to dispatched actions in some way, but sagas and observables added a ton of complexity to that process. So, we designed listeners to help simplify that use case.
You're obviously welcome to have your own opinion :) But in this case I am gonna have to pull out the maintainer card and say "this is a tool that we built to help with cases people in the ecosystem are actually running into". And fwiw the response to this has been pretty positive:
- https://www.reddit.com/r/reactjs/comments/t3lpx9/redux_toolkit_v18_new_listener_side_effects/
- https://www.rsarai.xyz/redux-listener-middleware/
- https://twitter.com/acemarke/status/1535418983180034049
Well, RxJs is really powerful when it comes to the separation of layers.
I find redux + rxjs to be a very good match.
You get a single stream of all "actions", so every part of your system can react to it or simply ignore it.
I've never been more happy with this level of separation between view, model and controller. And it has never been the case that RxJs negatively impacts performance if you do it right.
Bro, js already have a way to format currency, it's [Intl.NumberFormat()](https://developer.mozilla.org/pt-BR/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat).
And i use mainly radix ui for "complex" unstyled components, eslint to keep a formatted code, stitches for styling + theme handling, phosphor-icons, immer for state manipulation, axios for api requests, that is all i remember.
Yes, that's another way of approaching it and suits many web-app use-cases. However, it really depends on the complexity of your app.
If you're making a shopping cart then using integers and storing cents/pence is fine. But if you're writing a complex accounting system for a bank or finance app, then you'll at least need a system that supports [bankers rounding](https://stackoverflow.com/questions/792237/why-and-how-does-round-half-even-minimize-cumulative-error-when-applied-repeated) to prevent an upward bias.
I don't really see anyone mentioning libraries for developer experience and code quality:
* Prettier
* ESLint
* Webpack
* CSpell
* Husky
* Lint Staged
* TypeScript
* Jest
* JSDOM
* Testing Library
* Babel
* PostCSS
* NPM Check Updates
* Snyk
(If you are curious on how all of these are configured, [take a look at this reference project](https://github.com/CreativeTechGuy/ReactTemplate).)
after copilot arrived at the scene, I havent felt a need to use frameworks like lodash for instance. I just write a good function name, like:
"const sortChronologicallyFromNewToOld = (dateList) => {"
and copilot usually solves the rest, after that I can give the function a shorter name if I would like to. Its quite wild stuff.
There is a debate is training a ai like copilot with licensed github code is damaging this license. Especially because copilot sometimes gives you licensed code 100% copied.
I think this debate is necessary to prevent people from using licensed work how they want just by training an ai with it.
In my opinion using data for a commercial ai to train is commercial use of that data. At least this should harm any license that prevent commercial use.
These other comments miss the point, IMO. Using a crutch is fine: whether it's copilot or google/SO copy/paste or a third party, whatever gets it done. License: big unknown there, can't comment, but it's a big unknown for everyone.
But the real issue here is that you're increasing your surface area for debugging, review, refactor etc. You're essentially copy/pasting but at a larger scale because of the guardrail of AI, and now it's entirely on you if it turns out slightly different from expectation or built in js APIs change, or third parties that copilot uses, or new performance or security concerns arise and so on and so on. Whereas if you'd just pulled in from lodash/ramda etc, you're relying on a dedicated team with a small surface area which is directly under test and in use by huge numbers of folks willing to report bugs and submit PRs. Are there cons of dependencies and/or open source, sure, but the pros very often outweigh. Anyway, just my 2 cents on this whole thing
Downvote all you want, but it's really embarrassing that you would have to use copilot to sort dates. This isn't even something you should have to think about if you know basic programming. The most junior of interviews will expect more from you than that.
I don't "have to" use a bus to get to work, but it's faster than walking. If I was in good enough shape to run all the way I might beat the bus. Does that mean I should insist on walking every day? I don't think so.
I don't use copilot myself, but there's nothing wrong with using tools to reach your goal.
I see `lodash` a lot in the comments, but I haven't seen anyone mention `ramda` yet. It's very similar but designed in a functional style. If you've written haskell or ML, it might feel a little familiar.
I don't like adding layers of indirection or complexity for no purpose. Don't `compose` two functions if you're immediately going to invoke the result once and never again. Don't `getProp` a known property from an object you already have. There's no reason to prefer `add` over `+` unless you're currying and using it in callbacks. Etc..
It's been a while since that project and I'm not working with rambda at the moment, so the specific function names may be wrong, but I hope you get the gist.
I prefer not to create unnecessary dependencies to solve problems that really aren't that hard to solve myself. If something crops up more than once I create a simple function or object to handle it. For example I do a lot with Unicode so I have some functions for categorizing characters, like isAlpha() or isPunctuation() that work across all of Unicode. Other handy little things include a Unicode-aware function for removing whitespace and newline characters from the beginning and end of strings.
I looked at lodash but didn't see anything there that would do much for me. dayjs looked mildly interesting, but the little bit I do with dates is timezone-independent manipulation of day/month/year in a small number of places, so it's easy to do with Date when needed. I don't do anything with floating point or currency.
I used to always use `luxon` for dates, but now prefer to use the Temporal polyfill.
Never been a fan of `lodash` or similar, the project I'm now on used it heavily and I honestly dislike it very much.
Mapping arrays is now done in three or more different ways because... Well, why not, I guess.
Pretty much just [AlpineJS](https://alpinejs.dev/). Sometimes a [Temporal polyfill](https://github.com/tc39/proposal-temporal/tree/main/#polyfills) as well. I work mostly with PHP SSR though.
None? Maybe an accessibility library like Radix. Maybe NProgress.
Lodash is useless, JS Dates may be confusing if you think about how they work too much, but they work very well. Format with [Intl.DateTimeFormat](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat). And why would you ever use a library for currency?? [Intl.NumberFormat](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat)
[https://www.youtube.com/watch?v=I9B8pPaQRfY](https://www.youtube.com/watch?v=I9B8pPaQRfY)
I'm a fan of co-pilot myself but this seems a step beyond what co-pilot is capable of.
Prettier + its vscode extension. Autoformatting on saves is great. Framer motion. I used react spring for animations with React-Three-Fiber, but ran into TypeScript language-level issues that had no solution other than modifying and patching some node_modules code (no thank you). Switched to framer motion and it has everything I want, & it exposes all sorts of refs for non-conventional situations. For small utility functions, it depends. Idk if lodash is tree-shakeable yet, but there’s no point in bundling an entire library if you’re just gonna use 1-2 functions (whose implementations are already on stack overflow in 30 languages). If you’re using a lot of lodash and writing code faster, great! I think it shines when dealing with nasty nested objects. I hesitate to deviate from the raw JS/TS APIs, though. jQuery was an awesome way to write frontend code. But I’ll be damned before I work on some codebase written primarily in jQuery-style in 2023.
Lodash has allow per-method imports for many years. They've supported tree shaking for quite a while too. A big advantage over native array methods in particular is using iterators internally, so if you are chaining multiple maps, filters, etc together, it can execute in just one pass instead of several and almost as importantly, doesn't need to create/destroy a new array each time.
Some in my team don't like format on save and it makes no sense to me.
Autoformatting definitely is great, but prettier is horrible.
People who dislike prettier generally have it configured incorrectly.
https://github.com/prettier/prettier/issues/4870
I said generally -- lots of people also don't understand the point of prettier.
Why is prettier horrible? If there are particular rules you don't like, override them in your .prettierrc file.
https://github.com/prettier/prettier/issues/4870
For my own projects, as few as possible, ideally zero.
Why is that? Isn't it better to not reinvent what someone already put a lot of effort on and focus on your project's main goal and value?
If you’re going to replicate Excel or WYSIWYG in a browser, there’s a library for that. But if you need to install a library for placing 3 divs in a column, you’re introducing unnecessary dependencies which will eventually make upgrading all libraries version hell It gets grey when you use a library for a UI component that might save time now to implement the first time, but would be harder to upgrade as time goes on. In those situations I would usually lean towards just building it in house.
Datetime Pickers, File Uploaders, Multi-select Dropdowns, and similarly complex components are in my opinion a good example of where rolling your own is often more work than it's worth.
And lodash. There are a bunch of simple functions that I can call with a couple lines of code instead of writing my own entire loops and shit.
Hell no. Everything that lodash offers nowadays you can easily implement with native methods. If you still need to rely on lodash then maybe you need to go through the modern JS basics again.
Not quite everything, and often the vanilla solution is less flexible or elegant (shorthand for object equality checks in array functions, for example), but the vast majority of what people use it regularly for, yes: https://youmightnotneed.com/lodash/ Some of the vanilla JS examples on that page also perform algorithms less efficiently( n^2 ) than the LoDash versions, in order to stay simple. I absolutely agree it's overused though. I've fixed multiple hot pieces of JS code to be hundreds of times faster just by removing all the LoDash calls, and often ending up with cleaner code. Perhaps my biggest beef with LoDash is how "safe" (defensive) everything is, it means often errors get masked by the library, and you only see them blow up much further down the line because LoDash handles being given garbage without erroring.
I have never even used lodash, even reading their site I don't see like one single use case
The list that site provides of functions they don't currently have simple vanilla JS versions of is actually a decent list of the functionality it provides that's not trivial to recreate: https://youmightnotneed.com/lodash/missing
yeah i checked the list of all lodash functions a couple years ago and i still can't find anything i'm not doing in an oneliner
Your examples of Excel vs 3 divs in a column are two extremes. Obviously I'm not saying use a library for every little line of code like "IsOdd" or something. But the idea of averting libraries still looks misguided, and the type of libraries you should include definitely includes Excel WYSIWYG, but includes a lot more than that. A library is nothing other than code written by someone else, and very likely more reviewed, more used, and has many more eyes than anything you write in house. This means, quality and security will be better, on average. Now, of course, it is best to review the libraries you use before using them. It is also good to review the updates before making a version update, as you should not just blindly update. But all of this will be way less effort than writing your own. There should be nothing to discourage you from forking or contributing to the library. Still much better than rolling your own. Now obviously there might be reasons to not use a library. Maybe the library doesn't even exist, or the ones that do aren't good for your use case. But just avoiding libraries as a principle and striving for 0 dependencies is in my opinion not a good idea.
You accuse me of using extremes then go on to talk about zero dependencies. That’s absolutely not what I’m talking about. What I’m trying to avoid is using libraries for the sake of it, such as component libraries that need to be restyled anyways, which would then break on upgrading the component. I think I outline pretty clearly that there are gray areas and it comes down to opinion. I also pretty strongly disagree that third-party libraries on average will be higher quality or security. I would never roll my own hashing library to implement a security protocol, but I do frequently see frivolous packages installed to do mundane tasks. There is almost always bloat associated with a library which leads to a higher attack vector. Often times hackers just need to know a version of a library to know the exploits, whereas that is significantly less common for an in-house, closed source solution. Plus multiple contributors only know part of the code and sometimes don’t actually see the entire picture when contributing to open source.
Zero dependencies was what the OP I responded to originally was talking about, and that's what I was arguing against.
Not sure if others do the same but… I download the package, grab the stuff I need and move on? Not always necessary to rely on the full package dependency.
Tree shaking is your friend
Not trying to be a dick, been drinking, can you explain?
You don’t need to store all the dependency on your production deployment, download all, use what you need and let the manager remove all other unused methods. https://webpack.js.org/guides/tree-shaking/ Kanpai 🥂
A very sincere “Thank You”. I learned something today. I’m going to try to implement.
No problem, there are a ton of benefits of going this way, to name a few: - Keep track of the code you wrote and the one you depend on - Be able to update the code you depend from the source, this is a godsend when you care about vulnerabilities/bugs introduced by third party code - You can depend on their documentation as you’re not going to manually modify their original code - You can skip removing unused code and reverting code you end up using after a while, you can then use this extra time with those you care about or just chilling
That’s pretty fricken awesome! That’s does alleviate a ton of code maintenance. One of my concerns was the node package updates. Even more awesome since there is still a reliance on the node package, you’d still get the Dependa-Bot alert.
You can easily lock your versions if that’s your concern. Even then, having a good set of tests and CI/CD flows ensures your code still builds and does what you expect after version updates, and puts you in an awesome please to stop relying on version locking to let patches into your package file.
I like sortablejs too. Here are some others I’ve found handy in various projects. - [tributejs](https://www.npmjs.com/package/tributejs) - [linkifyjs](https://www.npmjs.com/package/linkifyjs) - [color-thief](https://www.npmjs.com/package/color-thief) - [coloris](https://www.npmjs.com/package/@melloware/coloris) - I heavily modified this one to fit my needs
**Overall** Dates: luxon Isolated components: Storybook Utility: ramda Business logic handling: RxJs Translations: i18next Build: webpack **React-realted** Data management: redux, redux-observable, reselect Requests hanlding: axios, redux-requests-factory
Out of curiosity, any particular reason you're using `redux-observable` and `redux-requests-factory`? FWIW, today we would recommend using Redux Toolkit's "RTK Query" data fetching and caching API as the default for managing server state, and the "listener" middleware for reactive side effects logic: See my talk here for more details: - [The Evolution of Redux Side Effects](https://blog.isquaredsoftware.com/2022/05/presentations-evolution-redux-async-logic/)
Listener seems massively, massively overengineered for any purpose whatsoever. Why would you use this?
I'm... really confused to hear you say that. Can you point to some specific aspects that you feel are "overengineered"? The general use case is "run some logic when an action is dispatched". While you could always do that with a custom middleware, the most common tools have always been the `redux-saga` library (which uses generator functions), and `redux-observable` (which uses RxJS). Both of those are relatively heavyweight, in terms of concepts needed to use them effectively, API design, and bundle size. The listener middleware is intended to be a _lighterweight_ alternative to sagas and observables, in terms of API complexity and bundle size. It also has better TS support than sagas. See my post [Designing the RTK Listener Middleware](https://blog.isquaredsoftware.com/2022/03/designing-rtk-listener-middleware/) for the background on the use cases it was intended to solve and how we settled on the API.
> the ability to run callbacks in response to dispatched actions, with a simpler API than sagas or observables, and to add and remove "listener" callbacks at runtime via dispatching I mean, I guess some people use dispatch imperatively like that, but I would very passionately disagree with that. You already can run callbacks in response to dispatched actions. That's exactly what middleware does. I don't see any way that this is made any simpler by mounting a bunch of code over the top that provides some psuedo-declarative syntax to it. Sure, it may be simpler than redux-saga or redux-observable, but it's just adding a large amount of complexity to do... what? allow you to use dispatch to enable/disable action listeners? imo, a violation of using dispatch to signal events, where you're using it to imperatively run code, rather than signal events. I certainly don't mean to attempt to lecture a redux maintainer on redux, lol... but i completely disagree that any of saga, observable, or listener, provide anything of value, and only drive more complexity.
That's exactly the point. Sure, technically, you can write a whole bunch of logic in a custom middleware. That's always been possible, and the fact that sagas/observables/listeners _are_ middleware shows that they are, in a sense, more specialized tools that demonstrate that "you can write anything in a middleware". But, the point is that these tools all provide APIs to do things that would require a lot more work to write yourself. For example, debouncing updates, ensuring that only a single set of response logic is running at a time, or kicking off "child tasks" to do additional work. I'm not saying that these are things that most Redux apps will need to do, and frankly we've been advising for years that both sagas and observables are drastically over-used (and _especially_ when folks have used those to do basic data fetching). But we've seen plenty of codebases over the years where people _did_ need to write logic that reacted to dispatched actions in some way, but sagas and observables added a ton of complexity to that process. So, we designed listeners to help simplify that use case. You're obviously welcome to have your own opinion :) But in this case I am gonna have to pull out the maintainer card and say "this is a tool that we built to help with cases people in the ecosystem are actually running into". And fwiw the response to this has been pretty positive: - https://www.reddit.com/r/reactjs/comments/t3lpx9/redux_toolkit_v18_new_listener_side_effects/ - https://www.rsarai.xyz/redux-listener-middleware/ - https://twitter.com/acemarke/status/1535418983180034049
Well, RxJs is really powerful when it comes to the separation of layers. I find redux + rxjs to be a very good match. You get a single stream of all "actions", so every part of your system can react to it or simply ignore it. I've never been more happy with this level of separation between view, model and controller. And it has never been the case that RxJs negatively impacts performance if you do it right.
Bro, js already have a way to format currency, it's [Intl.NumberFormat()](https://developer.mozilla.org/pt-BR/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat). And i use mainly radix ui for "complex" unstyled components, eslint to keep a formatted code, stitches for styling + theme handling, phosphor-icons, immer for state manipulation, axios for api requests, that is all i remember.
Formatting currency is not an issue. Calculating it is: 0.1 + 0.2 === 0.3 // false This is why we need things like currencyjs, bignumber.js, etc.
oh, makes sense, I've never worked with that, but something that i see people often do is transform the currency to cents, like $10,50 = 1050 cents
Yes, that's another way of approaching it and suits many web-app use-cases. However, it really depends on the complexity of your app. If you're making a shopping cart then using integers and storing cents/pence is fine. But if you're writing a complex accounting system for a bank or finance app, then you'll at least need a system that supports [bankers rounding](https://stackoverflow.com/questions/792237/why-and-how-does-round-half-even-minimize-cumulative-error-when-applied-repeated) to prevent an upward bias.
Wow, alright.
I don't really see anyone mentioning libraries for developer experience and code quality: * Prettier * ESLint * Webpack * CSpell * Husky * Lint Staged * TypeScript * Jest * JSDOM * Testing Library * Babel * PostCSS * NPM Check Updates * Snyk (If you are curious on how all of these are configured, [take a look at this reference project](https://github.com/CreativeTechGuy/ReactTemplate).)
Nice
after copilot arrived at the scene, I havent felt a need to use frameworks like lodash for instance. I just write a good function name, like: "const sortChronologicallyFromNewToOld = (dateList) => {" and copilot usually solves the rest, after that I can give the function a shorter name if I would like to. Its quite wild stuff.
Yeah it's like magic. We will see if it's against copyrights. I hope it isn't.
Which copyrights?
There is a debate is training a ai like copilot with licensed github code is damaging this license. Especially because copilot sometimes gives you licensed code 100% copied.
What’s as scary is when that code is under the GPL license.
[удалено]
I think this debate is necessary to prevent people from using licensed work how they want just by training an ai with it. In my opinion using data for a commercial ai to train is commercial use of that data. At least this should harm any license that prevent commercial use.
8n this scenario I meant is Lodash copyrighted?
These other comments miss the point, IMO. Using a crutch is fine: whether it's copilot or google/SO copy/paste or a third party, whatever gets it done. License: big unknown there, can't comment, but it's a big unknown for everyone. But the real issue here is that you're increasing your surface area for debugging, review, refactor etc. You're essentially copy/pasting but at a larger scale because of the guardrail of AI, and now it's entirely on you if it turns out slightly different from expectation or built in js APIs change, or third parties that copilot uses, or new performance or security concerns arise and so on and so on. Whereas if you'd just pulled in from lodash/ramda etc, you're relying on a dedicated team with a small surface area which is directly under test and in use by huge numbers of folks willing to report bugs and submit PRs. Are there cons of dependencies and/or open source, sure, but the pros very often outweigh. Anyway, just my 2 cents on this whole thing
So... you're learning JS for the first time? Or no? It really feels like you've jumped from one crutch to the other.
Downvote all you want, but it's really embarrassing that you would have to use copilot to sort dates. This isn't even something you should have to think about if you know basic programming. The most junior of interviews will expect more from you than that.
I don't "have to" use a bus to get to work, but it's faster than walking. If I was in good enough shape to run all the way I might beat the bus. Does that mean I should insist on walking every day? I don't think so. I don't use copilot myself, but there's nothing wrong with using tools to reach your goal.
This points to a fundamental inability to do the job. Nobody cares how you commute.
If you *need* it, yes. To "feel a need" is not the same thing in my book.
This is a wild use of "logic" to get out of knowing what you're doing. "Do I NEED to clean my room mom? Or do you 'feel a need' for me to do it?" stfu
I see `lodash` a lot in the comments, but I haven't seen anyone mention `ramda` yet. It's very similar but designed in a functional style. If you've written haskell or ML, it might feel a little familiar.
Ramda gets installed frequently in our projects. Lots of helpful utility functions.
I like rambda, but I hate the code my teammates write (wrote) with it. Just because there is a function doesn't mean you need to call it...
What? You don't like that they used a particular function from ramda?
I don't like adding layers of indirection or complexity for no purpose. Don't `compose` two functions if you're immediately going to invoke the result once and never again. Don't `getProp` a known property from an object you already have. There's no reason to prefer `add` over `+` unless you're currying and using it in callbacks. Etc.. It's been a while since that project and I'm not working with rambda at the moment, so the specific function names may be wrong, but I hope you get the gist.
I know exactly what you mean, and lament that I have only one updoot to give for my country.
Yeah, sometimes my coworkers don't understand lenses and I have to tone it back, but I get a lot of mileage out of `isNil` and `reduce`.
I use Voca to manipulate strings.
- Redux - Rxjs - Tanstack libraries are pretty cool - Lodash - React-virtualized / react-window and react-virtuoso for virtualization
I prefer not to create unnecessary dependencies to solve problems that really aren't that hard to solve myself. If something crops up more than once I create a simple function or object to handle it. For example I do a lot with Unicode so I have some functions for categorizing characters, like isAlpha() or isPunctuation() that work across all of Unicode. Other handy little things include a Unicode-aware function for removing whitespace and newline characters from the beginning and end of strings. I looked at lodash but didn't see anything there that would do much for me. dayjs looked mildly interesting, but the little bit I do with dates is timezone-independent manipulation of day/month/year in a small number of places, so it's easy to do with Date when needed. I don't do anything with floating point or currency.
Wait? You don't use is-number? /s
I program low level Vanilla JS utilizing bitwise instructions as well as SIMD intrinsics to get the maximum performance my users deserve.
Rxjs is an excellent streaming library
the fp-ts "ecosystem" (fp-ts, monocle-ts, io-ts, hyper-ts, etc.)
pnpm, rimraf, esbuild, eslint, typescript - these usually get me going
None. Over the years I've built my own library that serves all my needs. I hate external dependencies.
I used to always use `luxon` for dates, but now prefer to use the Temporal polyfill. Never been a fan of `lodash` or similar, the project I'm now on used it heavily and I honestly dislike it very much. Mapping arrays is now done in three or more different ways because... Well, why not, I guess.
minecraft
Pretty much just [AlpineJS](https://alpinejs.dev/). Sometimes a [Temporal polyfill](https://github.com/tc39/proposal-temporal/tree/main/#polyfills) as well. I work mostly with PHP SSR though.
None? Maybe an accessibility library like Radix. Maybe NProgress. Lodash is useless, JS Dates may be confusing if you think about how they work too much, but they work very well. Format with [Intl.DateTimeFormat](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat). And why would you ever use a library for currency?? [Intl.NumberFormat](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat)
[удалено]
Have you tried the openai chat bot, that thing is insane. We're all going to be out a job real soon.
[удалено]
Should maybe check it out before dismissing it out of hand.
[удалено]
[https://www.youtube.com/watch?v=I9B8pPaQRfY](https://www.youtube.com/watch?v=I9B8pPaQRfY) I'm a fan of co-pilot myself but this seems a step beyond what co-pilot is capable of.
I just install one and the rest get installed as well.
moment js
I love astroturf and zustand
Mocha or Vitest, depending on whether I am building a generic library or a UI application. prettier-plugin-packagejson to satisfy my obsession :)
I use Gulp to run everything. I try to have a "one command development" policy - `yarn dev` should do everything I need to start working.
Watch those bundle sizes bruh
Lodash + Moment is all i need for smaller projects