Echo JS 0.11.0

At this point the only cookies I *might* have set these days is an http only refresh token... for all others I'll use sessionStorage or localStorage for.

Do not use this in a web server unless run inside a worker thread.

Probably an okay guide for a total newbie... I absolutely recommend Visual Studio Code (VS Code), it's hands down one of the best editor options imo.

VS Code Killer features:

 - directory tree view
 - integrated terminal
 - remote coding (WSL2 and SSH)
 - good git integration (not great)
 - okay merge tooling (not great)

If you are on Windows, install WSL2 (I prefer Ubuntu, but other options work well too, kind of a pain to get setup, but great after that).  WSL2 gives you a full linux envornment to work in.  With VS Code remoting, you can launch code from inside your WSL2 prompt and all is right with the world.

Also for windows, the new Terminal (both terminal and wsl2 require windows 10 version 2004 or neewer).  It's just a better experience in general.

Next up, nvm... having nvm installed is a must when you work with JS and web applications, may also want a script to download/update Deno in addition to nvm/node.  Deno is quickly becoming a really nice option designed for future projects, still some rough edges though.

Git.  You need to get used to git, most modern source control is using it either hosted or locally.  From Github, Gitlab and Azure you will see it in a career as a developer.  When you install git for windows, be sure to use the option to make git tools available for windows cmd and unix.  Select checkout-asis commit as unix, this will keep you in-line with the rest.

Configure git in your WSL2 to use the git credential manager in windows.

Last and certainly not least, Docker.  For any services you work against locally, there's likely a dockerized version you should target.  Microsoft SQL Server, check.  PostgreSQL, check.  RabbitMQ, redis, mysql, etc, check.  Also, get used to making a docker-compose file for any project with backend services, and script everything... updates, schema changes... even if you're deploying to bare hardware you'll thank yourself.  This also lets new developers onboard super quickly.  By using Docker and scripting all the things, you can setup/teardown between projects at ease.  If in windows, try to stick to your WSL2 environment and ensure Docker is setup and configured for WSL2 environment.  Do not bother with "Windows Containers" it's a dead end.

Other than general entertainment stuff (spotify, etc), Email, Teams/Slack... the above is pretty much all I need to be productive.  I also install the starship prompt and a few other bits, but the above goes a long way to being productive.  I tend to prefer npm and node scripts only because my peers on Windows can also use them, and even though I do edit in wsl2, most of the docker target stuff works from windows without issue, ymmv.

Generally, if you're passing properties from above to components below more than a layer or two, you're better off using Context and/or Redux (more advanced context).

I tend to find it's worth getting used to Redux's flow for *most* applications. There are alternatives (like MobX) but Redux works REALLY well in most applications.  There are some configuration utilities that are Redux with enhanced configurations in the box as well.  In the end, the pattern is a bit harder to get used to, but allows for feature scaling without linear growth of complexity.

GraphQL or Apollo are also good and can work well when the backend supports it especially on larger applications or development environments.

For small apps, you can go a long way with contexts and custom action hooks, but I'm inclined to just jump to Redux pretty early on.

It's the end of the year and time again for the biggest JS survey online.

while there's still need for optimizations (reduced deno runtime for merged executable) as well as an improved binary module story, it's a pretty big feature to get in the box.

Been following Deno with great interest since it was announced, and the goodness keeps on coming.

Would suggest taking a look at Steve Souders' books[1] on website performance. While they're a bit old at this point, there's a lot to gain from them.  As always, if you're really concerned about performance, write test cases for your assertions, as you may be surprised that your "optimization" does more harm than good.

As always, premature optimization is often a waste of time... optimize when you experience issues as writing more obtuse or difficult to understand code/structures will often work against you if you aren't writing apps for 100m+ user sites.

When in doubt, test.

[1] https://www.amazon.com/Steve-Souders/e/B001I9TVJS

You aren't doing meaningful checks or adding additional TS context, so why even bother with adding a tsconfig?  Most IDEs will apply those checks with the jsdoc alone and it isn't actually checked at runtime.

Tried with about 10 different websites and not getting any results.

You don't need to do this... JSDoc comments work without TS configured at all.  Assuming all you are really after is the code usage hint/dialog.