How it feels to learn JavaScript in 2016

Previous discussion: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=12628921" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=12628921</a> (19 hours ago, 108 comments)

In my experience, the developers who fall into this trap of despair almost always do so because they aren&#x27;t consciously choosing what tools to use; instead they are letting the tools choose them.<p>They see job descriptions demanding AngularJS or ReactJS and they think that they must learn it, or someone posts an article here and they don&#x27;t want to feel left behind.<p>Choose a library or tool because it improves your development process. If it doesn&#x27;t appear to improve it, don&#x27;t use it (at least not unless external forces compel you to). Especially don&#x27;t use it if it appears that it will retard your performance (<i>cough</i> Angular <i>cough</i>).<p>For example, after months (years?) of finding ever more efficient ways of enforcing object interfaces (or even basic types) at runtime, I eventually reached the limits of what JS and unit testing alone could acomplish and found myself researching Typescript, Flow, and the like.<p>That&#x27;s not to say I&#x27;m a user of either of those, but if I do choose to adopt one in a project, I will know exactly what performance gain I am expecting from it. I&#x27;m still very productive without them.<p>In fact, I&#x27;ve successfully avoided a lot of fads in the industry for most of my career. It turns out that being able to explain why I <i>don&#x27;t</i> use a tool makes me look like I know what I&#x27;m talking about and not just cargo culting. Employers quite like that.<p>Incidentally, this isn&#x27;t unique to the front-end. I&#x27;ve seen the same thing happen with the SQL-&gt;ORM-&gt;Mongo-&gt;Couch-&gt;SQL nonsense, or the myriad of templating engines written for PHP, a language that itself <i>is</i> a templating engine.

I&#x27;m a web dev, been doing this 11 years. But i totally feel past it, granted i code less and less nowadays so i havent kept up with new technologies.<p>I&#x27;ve hired people that are much better at web dev than me and let them accomplish a task with pretty much whatever tech they want to use, because i believe you shouldn&#x27;t constrict a developer if you dont have to. Even for a simple app that it&#x27;d take me 20 - 30 hours for me to create in basic jQuery, bootstrap and simple PHP&#x2F;MySQL, the tendency is to pull in Angular, Laravel, gulp or grunt, composer dependencies and a whole host of code for doing something really simple. It ends up becoming a frigging nightmare to maintain and deploy, i just want to do a git pull and thats it deployed, but instead i&#x27;ve gotta do artisan commands, migrations, grunt commands etc etc etc.<p>Anyway, i tell myself that what their doing is a better way of doing things and i&#x27;m just someone with outdated knowledge, because when i do it, i use basic tech and accomplish the same task in less time and with WAAAY less lines of code. While its maybe not the best practices, its simple.<p>I still feel like a bad coder because i&#x27;m not doing it their way. :(

It&#x27;s easy to show how complex those systems are. It&#x27;s easy because they <i>are</i> complex. And that&#x27;s pretty normal. Let someone talk about Java Enterprise development, the symptoms of your body and their diagnoses or just try to explain how to build a pencil (<a href="https:&#x2F;&#x2F;en.wikisource.org&#x2F;wiki&#x2F;I,_Pencil" rel="nofollow">https:&#x2F;&#x2F;en.wikisource.org&#x2F;wiki&#x2F;I,_Pencil</a>).<p>We&#x27;re professionals, after all, and TypeScript and React were not build by some teenage hackers.<p>I think the problem is that everybody remembers how they build that one website using jQuery in the early 2000s and now wonders why everything&#x27;s so complex now. The reason is that we started to build complex applications instead of enhancing grandma&#x27;s blog using jQuery.animate, get over it.<p>And if a software developer talks about all of this tools in the same manner you&#x27;ve described, he has poor social skills, nothing related to the tooling.<p>He could also talk about the intricacies of scaling web services using k8s and OpenStack and you&#x27;ll find another bunch of tools and concepts. If someone would actually talk like you&#x27;ve described it, he would play buzzword bingo in any domain of expertise like medicine students who want to sound smart using latin words.

Thank god we have all these libraries. I mean remember the days when the back button worked, pages rendered quickly without 3-second ajax spinning animations, the browser remembered where you were when you clicked back, your phone didn’t randomly jump around the page when you’re trying to read something, and a syntactical fuckup didn’t prevent your entire site from being rendered? Oh, and you could scroll normally too. And crawlers other than Google could index your content, and blind people could listen to it. But right, javascript is awesome, I probably just don’t understand enough yet.

I feel like knowing which tools are useful, which ones are currently dominating, and which ones are going to continue being supported in the future is the best place to start learning JavaScript. This is difficult because the ecosystem is so wildly fragmented and insane. You&#x27;ll get a lot of different opinions if you go searching for them, so here are mine.<p>ES2015 is the place to start, it is a finished stable release of the latest version of JavaScript. It represents the single largest update to the language in a long time and includes many features that make development easier. It is being phased into web browsers natively and is the future of the language.<p>For maximum browser support you need a transpiler, this would be a matter of preference because it isn&#x27;t for you, it&#x27;s for the computer. TypeScript however is a very very clean transpiler and it offers optional features which are for you, should you choose to use them.<p>Once you have that setup, you really don&#x27;t need anything else. You don&#x27;t need jQuery unless you&#x27;re trying to support IE8, which is a tiny proportion of the browser market and that will gum up your code significantly.<p>Speaking of gumming up your code, nearly every single library out there is bloat and can or should be avoided. React is very popular but it suits one very specific use case, it should be used almost nowhere else. Particularly since it is still new and evolving, it is going to cause more headaches than it will resolve. Webpack is an enormous bloated nightmare for example, it messes with even static html for little or no perceivable benefit and honestly just avoid all of it if you&#x27;re trying to learn JavaScript.<p>If you want the full-stack experience, Node.js is rapidly becoming the largest JavaScript community on the net. You&#x27;ll have your questions answered quickly and there are modules for everything you want to do. Choose a markup tool for html and css, such as pug and less.<p>There you go. State of the art front end JavaScript with two tools. Full stack with five. If it wasn&#x27;t for the whirlwind massive chaos of the JavaScript community currently, fewer new developers would feel discouraged from becoming involved.

I have no trouble at all &quot;keeping up&quot; with the &quot;insanity&quot; that is front-end development. If you&#x27;re confused learning new things, it means you&#x27;re learning.<p>At my company, we have moved a lot of our front-end code to eslint-checked ES6 with some plugins, writing react&#x2F;redux powered interfaces. New hires generally learn the codebase fast, you&#x27;re well protected from shooting yourself in the foot thanks to type checking and linting and the absence of globals. Our team is many times more productive with this stack than with the es5 + knockoutjs code we built with before.<p>If you&#x27;re building a hobby project, just start with a &lt;html&gt; tag with inline ES5 and css, and refactor and iterate from there. Use server-side templates. &quot;keep it simple&quot;. But when building client-side interfaces at a higher complexity level, React is king.

JavaScript is a very special language, I think.<p>When I learned it in 2011 it was already strange to me, coming from years of work with PHP. Also, Java and C in university.<p>It was nerver meant to build big applications and had a few issues that many people tried to assert.<p>Old implementations which needed stuff like jQuery to normalize the APIs, no native module system so everyone implemented their own stuff (ExtJS, CommonJS, AMD, etc.), strange scoping rules forcing variable aliases and wrapper functions all over the place, functions as first class objects intruducing people to a new world of possibilities with ideas from FP, prototype based OO which comes with a different set of problems than class based OO.<p>The whole &quot;we want new stuff now&quot; movement forced many tools onto us to build our software, which before could simply be run in a browser without compilation. So we got rid of a few problems with a whole set of new problems.

I know it&#x27;s super fashionable to hate on javascript, but I&#x27;d be very interested to see a similar rant on another area of software. I&#x27;m pretty convinced this is just how the industry works.

Occasionally designers seem to seek credit merely for possessing a new technology, rather than using it to make better designs. Computers and their affiliated apparatus can do powerful things graphically, in part by turning out the hundreds of plots necessary for good data analysis. But at least a few computer graphics only evoke the response &quot;Isn’t it remarkable that the computer can be programmed to draw like that?&quot; instead of &quot;My, what interesting data&quot;.<p>- Edward Tufte

People writing these kind of articles are really not looking at their current stack objectively.<p>If I&#x27;m doing backend, I have to pick from various languages, I often will still need build tools (often more complicated) for various reason), you need to spin up a server (or make an AWS account....maybe use S3, maybe not!), you still have dependency management, etc etc.<p>Remember when Maven picked up, the bitchfests that surrounded it?<p>And debugging a server side app in production by picking at memory dumps, profilers, etc? Its not exactly easy.<p>The difference is that those problems are understood, and everyone knows the barrier for entry is higher.<p>The web platform used to feel like it had a low barrier for entry because it was so limited and there was only so much you could do. Those barriers were removed, so now its just as hard as anything else, except its not quite as understood (the barriers were removed recently). So all of the peanut gallery goes in thinking they can change the world in JavaScript, then realize they actually need to learn to engineer.<p>A good example of that problem is all of the big companies and startups hiring &quot;full stack&quot; engineers, which is code name for &quot;pure backend engineer who has 10+ years of experience doing backend...and has heard of HTML&quot;.<p>Of course, that kind of people won&#x27;t go far.

The worst is, if you don&#x27;t keep up with this, good luck getting a web job five years from now, you&#x27;ll be the equivalent of a Cobol programmer. Can&#x27;t get off the train.

I do feel that the javascript people have made C++ look simple. Not so much the language perhaps, but making programs in it..

I spend my time in C++ and Python land the majority of the time. I have had to jump in to fix front end bugs a few times... This page reflects my experience fairly well. I spend hours trying to find the magic incantation of bower, grunt, less, npm and&#x2F;or make, shell, versions to make one line of JS change. And I sincerely hope it gets better. I <i>want</i> to develop web sometimes, but every time I approach a new code base, I feel like I am starting from ground zero.

Very accurate<p>And if you go for X instead of Y you&#x27;re obviously a non-hipster loser that hasn&#x27;t been up to this week&#x27;s fad

As these rehashed JavaScript versions of <a href="http:&#x2F;&#x2F;harmful.cat-v.org&#x2F;software&#x2F;xml&#x2F;soap&#x2F;simple" rel="nofollow">http:&#x2F;&#x2F;harmful.cat-v.org&#x2F;software&#x2F;xml&#x2F;soap&#x2F;simple</a> are on front page of Hacker News every other day, I can&#x27;t even begin to imagine what kinds of rants we will see in the next 15 years or so.

In defense of JavaScript, there is an article that appeared here not long ago:<p><a href="http:&#x2F;&#x2F;mrmrs.io&#x2F;writing&#x2F;2015&#x2F;07&#x2F;27&#x2F;too-many-tools&#x2F;" rel="nofollow">http:&#x2F;&#x2F;mrmrs.io&#x2F;writing&#x2F;2015&#x2F;07&#x2F;27&#x2F;too-many-tools&#x2F;</a><p>Basically all these new terms come out because people are constantly trying to improve the ecosystem and make it better according to their own standards, be it more modular, more robust, or more scalable.<p>Eventually winners will emerge and the losers will die out. Give it a few more years and it will stabilize.

I&#x27;ve always been of the mentality to use a tool only when the efficiency gains outweigh the learning curve. This is, of course, impossible to judge without spending a lot of time understanding exactly where your efficiency bottlenecks are.<p>The truth is, a complex application is going to be complicated no matter what tool you use. I look at application programming like this: the more complicated it is, the more likely it is that you&#x27;ve missed key requirements early in the process. This means you will likely need to refactor, rearrange, add&#x2F;remove features, etc. Choose tools that make this inevitable process as quick and painless as possible. For me that&#x27;s the number one goal.<p>I reject tools that make picking a project back up a week or two difficult because of dependencies or weird hacks, syntaxes, or configurations that worked fine when they were fresh in your mind but required an hour of your life to retrace how you got there using the tool.<p>For example, I chose to use a library that used generators to eliminate callback hell in a screen scraping project of mine. I did this for no other reason than it was too hard to modify the scrapper when everything was nested 8 levels deep. I didn&#x27;t know what generators or coroutines were before that, but I had spent enough time with my problem to know that I was going to hit a serious maintainability wall unless I found a more clear syntax to write my app. In that case, it was worth the inital overhead of learning new parts of ES6 and programming language concepts.

Unfortunately this is pretty accurate..

I can not emphasize this enough. Keep it simple. I see to many software written through solutions just because they are a hype. Pick the right tools for the job.

In my experience the whole complex JavaScript comes when you try to build the entire thing using JavaScript.<p>If you are developing a web app, restrict JS to the client side only, get something like react to do it.<p>On the server side I stick with Go(lang). This separation helps me and my team think of these two separate problems, well.. separately. Isomorphic this isomorphic that is when things start to go all in sane.<p>tldr; JS for front-end. Go for back-end.

And that&#x27;s way I feel much more comfortable in Dart ecosystem:<p>- sane SDK and sane - not surprising - lang without <i>this</i> hell<p>- jquery like functionality built in<p>- one package manager and package repository<p>- can be used on server as well<p>- nice tooling (WebStorm-IntelliJ, VisualStudio Code)

Funny, but it&#x27;s not quite that complex.<p>How about &quot;Here&#x27;s a link to a CLI utility or git repo which will give you a working project in 2-3 hours&quot;?<p>I took a break from web dev for some years and had barely used any JS frameworks besides jQuery, until June, when I began working on an ambitious project and quickly got up to speed with the state of JS.<p>I&#x27;m using React&#x2F;Redux&#x2F;Sagas&#x2F;Webpack&#x2F;etc. for the client, and Express (with ES6 and what have you) for the API.<p>Developing with these new technologies has been a delight, especially compared to hacking bits of jQuery together.<p>Sure I&#x27;ve had to learn a lot of new concepts, particularly after being away from this world for so long, but this has always felt like a continual learning process to me.<p>We are the early adopters, the cutting-edge types. If you want to work with aging technologies there are plenty of companies invested in them.<p>Otherwise you can learn React in a few hours. What&#x27;s the big deal?

Sometimes jQuery is all you need. Sometimes you don&#x27;t even need that.

Lucky for him he didn&#x27;t ask about tests :)

&quot;I need to display data on a page, not perform Sub Zero’s original MK fatality.&quot;<p>This sums up my opinion of the whole React+Redux+Webpack+SatansSeventhCircleOfHellLib combination.

I think people that don&#x27;t like to constantly learn new stuff shouldn&#x27;t be developers in the first place ... personally this is the part about web development I like most. I love to write prototypes and experiment with new stuff.<p>Second JS is not changing so fast imho and there are not so many frameworks that stand out of the crowd. Yeah there are lots of frameworks and libraries on github and even this is a good thing because it shows JS has a vibrant community that loves to create stuff. But it&#x27;s not like you need know all of them, if you are really lost and don&#x27;t know what to choose, just ask other developers around you or check out websites like <a href="http:&#x2F;&#x2F;stateofjs.com&#x2F;" rel="nofollow">http:&#x2F;&#x2F;stateofjs.com&#x2F;</a> and you will notice that there are not that many frameworks that get used by a lot of devs.

A common problem when I try to switch to platform that I haven&#x27;t been paying close attention to. It is very difficult to quickly figure out what is the current stack of libraries and tools you should use if you are starting now. For example jump to the .NET and it is not so obvious should go for Core, Asp.net Core, how to do data access, which version of EF to use and so on.<p>Usually it is very difficult to find this information from anywhere. Articles and blog posts get outdated fast. Material produced by vendors is usually a bit biased. You get to see all the good things, but they might forget to mention stuff that is still under development. If you are new to the field, you don&#x27;t know the right people and right blogs.

There&#x27;s no need to jump straight into the deep end of tooling.<p>An iterative approach works really well here - do a brief survey of what tools there are and what problems they solve. Then, when that problem starts soaking up a lot of time, you can read up on the available tooling in greater detail.<p>There _are_ a vast amount of libraries in the js ecosystem, and it&#x27;ll take time to fully understand all the different pieces. It took me nearly 2 years to achieve an understanding of most of the buzzwords in that article (and even then, there are some I still haven&#x27;t worked with directly).<p>In my personal experience, learning JS is very much a BFS process.

Very accurate. The web is still highly immature and the rate of change is proof of that. Very much looking forward to WebAssembly (and its full adoption by web browsers) so then we can end this madness once and for all.

The frontend frameworks wars are pathological. It&#x27;s useful, to me, to remember _why_ that&#x27;s the case: because web sites&#x2F;apps have to support every browser make and model out there. But how do we know that? Presumably from testing. So its funny that there&#x27;s isn&#x27;t any mention in the article about browser testing, or harnesses, or what-not. So now there needs to be another iteration of this series where we step through PhantomJS, Selenium, AWS Device Farm, etc. etc. (and shout-out to Quirksmode and Caniuse).

Loved the Trump-ism buried in the middle of the dialog.

JavaScript devs have an embarrassment of riches when it comes to tools&#x2F;frameworks. It is overwhelming yes, but this anecdotal ranting is counterproductive. JQuery still works excellently, and so does ReactJS if you have the patience and time to learn it. One just needs discretion when distinguishing the tools of the avant-guard from the tools of the pragmatic workhorses.

Why I Hate Frameworks (2005) is climbing back up the charts, probably because of this very news thread. Here&#x27;s the link to that: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=12635142" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=12635142</a>

No seriously it&#x27;s crazy. I tried doing some MEAN stuff for a while(I&#x27;m backend and can do some WPF UI MVVM ). Anyway it was insane I&#x27;m not doing any javascript development. Why would I ? Come to .NET we have cookies.

To me, this topic highlights the difference between a developer&#x2F;programmer and a software engineer. As a small business owner, If I&#x27;m hiring a developer&#x2F;programmer, I&#x27;m looking for specific skill sets in a given language&#x2F;framework. I don&#x27;t expect to hire a PHP programmer and throw them into React&#x2F;Mobx&#x2F;Webpack&#x2F;Gulp&#x2F;Babel&#x2F;Websockets without a tremendous amount of training. Frankly, I don&#x27;t even expect them to know SQL in any sort of advanced way. I&#x27;m paying less for that person and getting less in return. I&#x27;m taking on the challenge of &quot;growing&quot; them into what I want them to be in the future or letting them go if our project pivots<p>When I hire a software engineer, however, I&#x27;m paying more and getting more (hopefully). I expect software engineers to understand engineering principles and be able to work in almost any language. At a foundational level, they understand the basics of compiled vs interpreted languages, OOP vs functional programming, client vs server, optimization, testing, databases, networking, software release life cycle...and how to employ all of those. I expect to give them a business problem and have them develop an entire technical solution using whatever tools are best suited for that job.<p>In most cases, projects are a good mix of both software engineers and developers&#x2F;programmers. The two can balance each other out and produce amazing things.<p>Lastly, everyone should be looking to improve their knowledge of their own industry. If you are a developer&#x2F;programmer&#x2F;software engineer, you should be looking at what is new&#x2F;upcoming in the industry. You need to remain fresh or you become obsolete. In a very small example, the move from Python 2 to Python 3 has been a long road. If you are not aware of the improvements in Python 3 over Python 2, how can you actually determine if Python 3 is a good choice for your project? How can you take advantage of the improvements? What about Go vs Python 3? How does Erlang&#x2F;Elixir fit in to the equation?

I feel like everyone needs to be reminded that this post is probably more of a joke than anything. Not criticizing JS so much as a buzzword-iness surrounding it

Holy shit these articles are truly tiresome.<p>I am learning Javascript in 2016. I also learned it in 1998. It was a simpler time back then, sure, BECAUSE YOU COULDN&#x27;T DO MUCH. Rollovers, alerts, scroll some annoying text in the status bar of a browser. This was about the extent of it.<p>I can do SO MUCH COOL STUFF with 2016 Javascript. Much of it comes with a complexity cost, but of course I&#x27;m free to code &quot;raw&quot; Javascript in the browser just like I used to. Instead, I choose to learn some new tooling, because the leverage it gives me to execute my ideas is worth the effort.

Damn I feel so far away from reality..I am still using vanilla JS (plain old JS not the framework) &amp; JQuery....yet I have no problem.

&quot;-Ever heard of Python 3?&quot; (go to top)

My favorite line from the article:<p>&quot;I need to display data on a page, not perform Sub Zero’s original MK fatality.&quot;

The picture on the top sums it up.

How it feels to learn parallel parking in 2016<p>&quot;I want to parallel park in that parking space.&quot;<p>You&#x27;ll need a car first.<p>&quot;When I was a kid I just walked into the parking spaces.&quot;<p>Yeah, but that&#x27;s not really parallel parking, you were just walking into a parking space.<p>&quot;Oh ok. So I&#x27;ll get a car then.&quot;<p>Well, it&#x27;s not that simple, you have to actually get inside the car in order to parallel park.<p>&quot;What? Can&#x27;t I just push the car?&quot;<p>No way! First you have to unlock the car, start it and put it in gear.<p>&quot;Oh. OK, how do I do that?&quot;<p>First take out your key.<p>&quot;What&#x27;s that?&quot;<p>It&#x27;s a small attachment that should have come with your car. Then press the unlock button.<p>&quot;I unlocked it and am sitting in the seat. Ready to park?<p>&quot;Not quite. first, you need to put the key in the ignition&quot;<p>What is an ignition?<p>&quot;It&#x27;s the small hole on the side of the steering wheel. Now turn it. No, the other way.<p>&quot;OK, let&#x27;s parallel park!&quot;<p>Hold on now, you need to adjust your seat, rearview mirrors and side view mirrors to ensure that you can drive safely.<p>&quot;But I don&#x27;t want to drive, I just want to parallel park!&quot;<p>It doesn&#x27;t work like that.<p>&quot;Fine. How do I get these side view mirrors to adjust?&quot;<p>Well, first you have to select which mirror you want using the switch to your left, then push the directional arrows until it&#x27;s at the correct angle.<p>&quot;How do I know what the correct angle is?&quot;<p>There are lots of opinions about this, just search Stack Overflow.<p>&quot;This seems like a good angle. Let&#x27;s park!&quot;<p>Hold your horses, first you have to put the car in Drive...<p>...<p>Some things that we take for granted as simple really aren&#x27;t and never have been. Within a generation the above will be completely outdated knowledge and you&#x27;ll get a car from point A to point B using an app, with its own complexities and absurdities at which we can poke fun in blog posts.

This article looks like some dialogue taken from Fallout 1. :)

JS should have stayed where it was, in the browser ;D

Still laughing but if you want to know what:<p>1. people use<p>2. people are happy with<p>Try the results of this survey:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=12627693" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=12627693</a>

i miss the days of Borland where the IDE would just run darn the thing.

This misses the point.<p>It&#x27;s about the unit test.<p>jQuery is easy to develop with but difficult to unit test.<p>React is slow to develop with but easier to unit test.<p>For small projects, jQuery is better.<p>For large projects where the all the persons writing it tomorrow might not be here today, pick the testable one so they have a chance of future refactoring.

It&#x27;s so interesting to me that so many people complain and no one does anything.<p>If Javascript is so bad just make any other JIT compiler run in browsers. Defeat the argument with action.<p>I&#x27;m comfortable with my build process. I have a package.json and a gulpfile.js. I run npm i, then gulp dev. For every new project this is automatic.<p>Don&#x27;t follow trends if you don&#x27;t want to, but I don&#x27;t believe anything in the OP was difficult if you understand why you&#x27;re doing it and learn it properly.

&gt; What&#x27;s wrong with HTML?<p>Its impossible to share data between JS and HTML without reimplementing parts of JS in HTML from scratch, or rather, implementing a HTML-like template engine from scratch in JS. The model just isn&#x27;t designed to do what we want it to.<p>Web components are working on this, except they&#x27;re reimplementing every modularity feature that JS already provides (HTML imports, shadow dom) from scratch, and then they&#x27;re implementing every feature that React gives you (custom elements) from scratch. But its still too early, and most tutorials don&#x27;t show how it works beyond the simplest examples (I would be convinced if I see a data grid component demo with custom item rendering per column which supports passing table data from JS)

I&#x27;m getting tired of these pointless non-specific rants. You could write an article about &quot;How it feels to learn C++ in 2016&quot; and make it all about the complexities of operating systems, linking, compilation, text editors and the QWERTY keyboard layout, and you&#x27;d still be as accurate.<p>All you need to &quot;JavaScript in 2016&quot; (as a beginner) is a config file and one or two commands. That&#x27;s it. If that&#x27;s too information or too hipstery for your taste, then follow the footsteps of other programming languages and use an IDE with a button that can hide that complexity for you.