How can I push/inspire myself to learn JavaScript and Node?
I'm a full stack dev and my current use of JavaScript language is limited to making the best (read trivial) use of jquery for DOM manipulation in my web apps which primarily use PHP or Python (Flask/Django) as backend.
Now, have you watched that popular thriller movie called Inception which is based on a radical sci-fi concept that an idea or thought can be implanted into someone remotely?
Just like that, I often find myself facing this strange idea that JavaScript is supposed to be just a toy running inside the web browser. No idea where exactly this idea came from! Each time I try to learn JS or think of getting deeper with things like npm, react, etc., this idea just pops up and kinda stops me from doing anything!
Is there any way to get rid of this idea somehow?
You have a very strange, yet I suspect not uncommon issue.
If you were one of my students, I would have you learn Typescript instead, and remove you from the idea that it's JS at all. Divorce yourself from the web ecosystem. Write a typescript hello world app using Deno, and once you have played with that, then try to port that to the web.
I suspect it will help you understand that the web is just a compile target, as x64 and x86 are compile targets for the C family.
I mean, I don't know how helpful this is, but.....does it matter even if that was 100% true?
It's very clear that a lot of smart and talented people are using it, toy or not, to build very interesting applications inside a browser. Javascript is a cobbled together Frankenstein('s monster) of a programming language and framework(s) and environment, but that hasn't stopped people from using it. Every ecosystem has its warts and cobbled togetherness (I mean just look at PHP and all of its history), and that hasn't stopped anyone, won't stop people again, and is going to happen to every ecosystem that comes along.
Figure out something cool you'd want to build, in a browser, with interactiveness that you'd need JS to achieve (in a browser at least), and set to work on building it. Come up with an idea and a vision of the end product, with a URL you can give to people and say "hey look at this cool thing I made", and get started on building it. Knock off a little piece of it every day, no matter how crappy or how much it hurts your sense of good taste, until it's done.
The completion of work is seen through by the motivation to achieve an end result, not the inner workings of it. Perfection is the enemy here.
The idea of JavaScript being a “toy” is simply out of date. Back in the IE6 days, JavaScript implementations had some severe limitations that took some pretty bad hacks to work around. Happily this is no longer the case. Modern JavaScript has more language features than many other languages, has reliable implementations that run pretty fast, and has good developer tools.
It also has a fair number of misfeatures that are kept around for backward compatibility. Beginners will stumble on them, but you can learn to avoid them.
My advice as someone who prototypes all my systems level code (for robotics, IoT, etc) in JS before writing it in $[Rust|C|C++|Elixir] — don't mess with any of the frameworks. In fact, don't mess with any of the UI aspects of Javascript. Since you're a developer already, write some scripts, backend scripts, for small utilities. It's fast, doesn't take long to do, and in javascript there is no 'right' way to write it, there's a million possible ways of doing it, just write it in your style and get your expected result, blemishes and all.
Leaf through NPM and use some packages for no other reason than to try, that could be one for a headless browser, or for doing some basic file formatting, or even write your own version of curl using fetch() or something like axios(). Just write some command line scripts, and when you want to get into the UI side of things (maybe build a GUI for one of those scripts) it will feel natural. Javascript isn't just a browser language any more.
Edit: Javascript is a toy, but it's a fun one, and more like a game than a toy. You can write anything in a million different ways and have the same result, it's what programming was originally supposed to be like when we all started. There is no 'right' way, and that's what makes it fun. Sure, there's always better ways, but none of them are 'right'. As long as it works, as long as its enjoyable, it's the right way to do it.
I would try to get to the bottom of this and why it stops you from doing anything. Is the idea that there won't be any depth to the language and its ecosystem that's worth learning? Or is the idea that you shouldn't spend time learning a toy language? Do other languages invoke the same idea?
Npm and React make me want to binge eat.
...Jokes aside, React is great in theory but I keep running into all sorts of cases in which I have to make stupid workarounds for the unintended side-effects of its paradigm. I want to like it but I'm not sure how to get there.
There are free-ish basics courses on react around the internet, like on codecademy.
How comfortable are you with the node brande of asynchronicity right now (promises)?
If you run into "having to make stupid workarounds", chances are you are not thinking of your problem correctly. I am happy to assist if you can give some examples.
Enjoying React fully comes when you embrace the functional paradigm from start to finish. It's an unparalleled experience when you get there, but I will admit that for a less experienced programmer who has mainly touched imperative code, it can be very unintuitive in the beginning.
That's the problem with modern webdev: being gaslit into thinking the unintuitive reasoning behind React and Typescript and NPM is "correct" in any way. If you have a library that's supposed to check everything for you, and yet it's you who have to tell it "it's fine, this works, trust me", it's not a good library.
(Can you tell I'm hot off the heels of debugging some TS code?)
They're just libraries. People design them, much like they design other tools. Sometimes, elements of these designs are unfortunate compromises: either no better solution is available at the time, or the designer is limited by the medium. Sometimes, they're mistakes.
Just because a design exists, doesn't mean it's good, even if it's employed by millions of workers around the world. A good tool is supposed to guide your process seamlessly. When you have to bend over backwards for the tool, you're using the wrong tool.
(Yes, yes, consistency of experience and a certain degree of reliability are good things. Being able to jump right into the project because it uses the tools a lot of devs are familiar with offers a fair degree of productivity. I just can't stand the inextinguishible certainty some devs have about how things ought to be done.)
Thank you. I'm going to steal and modify your quote in the future. "That's the problem with modern webdev: being gaslit into thinking the unintuitive reasoning behind [latest popular thing] is "correct" in any way."
I rarely contribute to conversations online about web development, despite having over 30 years of development experience and over 20 on the web, because you can't win arguing against whatever the latest hyped framework is.
My advice is to learn how the web works. HTTP. Learn HTML, CSS, and JavaScript (as it applies to browser interaction). The rest is just today's fashion.
Those frameworks all make the easy stuff easier and the hard stuff harder. There will always be workarounds using them. They are all compromises. If you're doing the same easy stuff all the time, fine, learn them and use them daily. Next week, learn the next one. But you'll never go wrong learning the basics in depth.
My boss can do some amazing shit with code. It's clean, clever but not too clever, and it goes the mile in terms of functionality.
But I know the actual JS, and the actual CSS, and the actual HTML. I've been working with the barebones webdev for most of my let's call it "career". I know when not to
npm install left-padbecause evergreen browsers all have support forstring.padStart()these days. (Incidentally, even the author of the infamousleft-padhas deprecated the package with the following message:use String.prototype.padStart(). The package still has about 2 million weekly downloads.)The problem is, I can't sell it if I had to. "I ship with minimum final code" is not sexy when most of the industry wants to publish an app that can handle two million active users, with MVD (minimum viable design) that's cookie-cutter enough to not make the user feel slightly uncomfortable yet relay the brand's identity, and make a splash on ProductHunt and Hacker News yesterday. It seems intuitive to me to use a tool of least power to achieve my goal, and yet React etc. win out because they allow to develop things at scale.
None of it is "correct". Everything is a tool for a job. If the two fit? Fantastic. If not, you better keep searching. Mental health is an underappreciated part of a life of the developer. Can't waste it on what someone considers an axiom when it is, in fact, just a paradigm.
There's a bit of a "if a tree falls in the forest" to that. If you make something useful but nobody uses it, then who are you performing this for?
Personally, I value the ability to "ship with minimum final code". Not specifically that, but I think in general what you're trying to describe is the ability to understand not just the code you're writing now, but what it will become once it goes through the compiler. This is a skill that is useful everywhere, from C++'s deadly abstraction to SCSS's endless nesting.
I have no idea how to help you "sell it". i have no idea how to sell that myself; it's often been useful to me, but it's always to solve problems others never knew they had. That's one of the reasons I just lead my own projects now: I wanted to be able to hire differently from how most people normally do.
I think it's ultimately what Google tried to do. The interview process does try to look for certain less obvious skills regular job interviews do not. But it's also become a farce and a meme in the industry, and now people "train leetcode" before going through tech giant interviews (all of which copied google, and the whole thing became a xerox of a xerox). I went through the Google interview process ten years ago, it was not pleasant, and it confirmed for me I don't belong in an office.
The craft? The sense of pride in making something beautiful (for a given definition of beauty)?
This one seems kinda obvious to me too: to make things that are good because that's how good work is done. I don't expect an award for it or a salary hike as a result: I just want to have written something I'm not ashamed to put out in the world.
For all things pragmatic, I have you to work things out for me. :P
I can very much see where you and @ThatFanficGuy are coming from; there's a lot of trend-following out there, and it can often veer into cargo culting (insert Rust package manager joke here), but I also feel like there are important, fundamental concepts implemented in libraries just as much as there are in the language core itself. New can just mean fashionable, but it can also be the result of genuine progress in the field.
Learning the fundamentals in order to fully understand what's built on top is hugely important - I'd never advocate someone learning only the way to do something in a specific library at the expense of deeper foundational knowledge, and I know a lot of people still end up doing exactly that - I just think there's equally valuable conceptual understanding to be found in the ways that major libraries with thousands of incredibly smart contributors solve difficult problems.
I happen to like React, for example, but I recognise it's a specific implementation with certain strengths and weaknesses. I think that declarative, component-based UI is a fundamental development, of which React happens to be one example - I compared it to automated memory management in terms of significance and I stand by that. Neither of those things are 100% perfect all of the time, but both moved the general field of software development in a way that lets most developers get more done, more efficiently, with broadly fewer bugs.
Everything is a tool, no tool is perfect, and "better" will always be subjective - I just think that applies as much to languages themselves as to the major tools built on top of them.
The functional paradigm is not modern. And it was always the case that mixing functional and imperative makes things weird. React adds on top of that, because it's tied to a render loop, so now when you "make things weird", you make them weird every time the render happens. And it gets even weirder when you take render optimizations into account (how react only rerenders "when it's needed"), and now you're asking yourself "Why is shit going haywire but only-sometimes?" - The answer is always "you made things weird further up".
React is a great framework because overall it's not full of compromises. People compromise, and the code "becomes a mess" when they build on top of their own shaky foundations. I've seen this a lot.
Typescript is a weirder one; it compromises, because JS compromises; and the TS team wants to rigidly adhere to the ES specs. It's not great (they could have fixed ==/=== for example!), but tbh, the ability to pull in any JS code and have it "be valid typescript*" is invaluable enough.
Or you're using the tool wrong ;)
That's why nobody wants to argue the case before someone who's been head-first in the industry for a while. Victim-blaming the user for someone else's insufficient design is peak "I am the very model of a modern web developer". It's no fun to listen to.
It’s got nothing to do with the modern web and everything to do with tools in general having a learning curve. Web dev is very accessible however, and training tends to be shit, so a lot of people are improperly equipped.
I say this having myself gone through the self teaching process; I don’t think it’s wrong, but it’s extremely difficult especially when you don’t know what resources are available and which ones are high quality. It took me a very long time to build a correct intuition for when my tool is bad, versus I don’t have an adequate understanding.
We are quick to blame some of our tools and forget the immense amount of thought that has gone into them, because we’ve often been burned by 5-minute-designed things; so instead of putting ourselves into question we blame the author. But React is absolutely not like this; you are free to think otherwise but I’d say it’s the most elegant piece of code the web has access to on such a wide scale.
Functional React gets a little wild sometimes. I remember building something with
useCallbackand needing to understand that at some level the mechanisms were doing a function pointer comparison to evaluate if the cached closure was stale. One hell of a leaky abstraction.For sure; but then again in … eight years of react now, I’ve never had to use useCallback once. (I have used it, it was never necessary)
I have gotten into WEIRD leaky states with react, just as you have here. But honestly it’s always ultimately a problem elsewhere in my code. In how I’ve structured things until there.
Code can always live outside of the react lifecycle if it has to exist.
I don’t have access to the code anymore but it was for a hook that would let you interrupt page changes with a modal. The API was really nice in the end - you would pass in an async function returning a Boolean. If true the page change would occur, if false it was interrupted. I also had built an async modal into the app so using the hook required a one line closure.
Thank you! Next time I give it a try I'll remember the offer.
To be clear: I'm a Javascript developer, I have plenty of node experience, and I'm comfortable with promises/async.
100% of my react attempts have been with the functions/hooks paradigm (not classes).
Verbalizing your feelings or ideas is a good first step to reinforcing or getting rid of them. I suggest you give it a shot.
A couple years ago, I switched from writing networked applications in C++ to writing user interfaces for network devices (very much a quality of life move). These devices have low enough resources that the server just handles serving application files, authenticating users, and forwarding SNMP messages to and from the browser, meaning the client application has to do everything else. Browser JS is definitely capable of doing real work. (Use TypeScript, the type system hides 99% of JS’s infamous warts)
Quit your job and work somewhere with a full stack typescript app.