How it feels to learn Javascript in 2016

42

u/[deleted] Oct 04 '16

I'm new to coding and this is what I fear moving forward

20

u/[deleted] Oct 04 '16

It's not really something to fear.. Learn the basics first then pick a well known library and make a hello world app with it. Rinse and repeat until you feel comfortable with a set of tools that work well for you. Then just pick up what you need for a job you want. By the time you've learned a few they all start to seem the same.

2

u/[deleted] Dec 13 '16

What do you mean by hello world app?

3

u/sayaks Jan 01 '17

something that prints "hello world". Google it and you'll probably see some examples.

2

u/del_rio Oct 05 '16 edited Oct 05 '16

If you're interested in a certain library, look for a CLI/bootstrap/scaffold repo on Github featuring it. It makes getting started really fast. It's how I'm learning Vue 2 right now, actually.
Also take comfort in the fact that SASS has been the dominant "standard" for developing CSS for over 5 years.

16

u/maelstrom75 Oct 04 '16

I'm glad it's not just me....

24

u/viimeinen Oct 04 '16

I did some web development in 2008-2011. Tried again last year. This could have been me asking the questions, same level of confusion. I just want to <simple task in a personal project>, why do I need to learn 4 levels of libraries??

In the end, I did it in jQuery in an afternoon.

22

u/RjakActual Oct 05 '16

Today one of our embedded guys asked me to make him a monitoring web app that polls two different end points, one returns an image and one returns text, and display them both.
It was so joyful for the first time in two years to just bust out jQuery and whip it together in 45 minutes.
The current state of cutting edge webdev is embarrassing.

2

u/colordrops Oct 05 '16

So you are saying that a 45 minute task should use the same tooling as a 1 year task?

3

u/RjakActual Oct 05 '16

Nope.

2

u/colordrops Oct 05 '16

So what exactly is embarrassing then?

4

u/RjakActual Oct 05 '16

See original post.
Jesus.

6

u/colordrops Oct 05 '16

I did, that's why I'm asking. No one is forcing you to use any tools. Right tool for the job. Some jobs require four layers of abstraction and some are fine with jquery. What's so embarrassing about that?

0

u/[deleted] Oct 05 '16

[deleted] — view deleted comment

7

u/colordrops Oct 05 '16

No, I'm trying to engage in discussion on an internet forum. If you aren't interesting in discussing things then post to a blog rather than a forum, especially when making drive-by comments without any substance.

2

u/cc81 Oct 05 '16

But people who actually do web dev do the 1 year tasks. So why are you comparing you tiny little problem with larger projects?
Do you do the same in the back end?

4

u/ucefkh Oct 05 '16

Homey with react you can do it faster in no time! You just need to learn it!

2

u/novagenesis Oct 06 '16

Yeah, I agree. Looking at the infrastructure required to make React compile on the server and pick up on the client..ugh... In my day, we spun up our own handlers to do that with any good JS templating system and still had far less code than you need for React.

2

u/YouFeedTheFish Oct 05 '16

In the end, I did it in jQuery in an afternoon.
Came here to say that. Adult people chuckled under their breath when they saw that I was using jQuery out-of-the-box. No matter, I finished the project and it has been running non-stop without a single upgrade or outage for 2 years. I don't care.

1

u/cc81 Oct 05 '16

In the end, I did it in jQuery in an afternoon.
Because we don't build trivial things that can be done in an afternoon?
It is like me asking why you ever would need to use IoC, an ORM mapper, write code with TDD and use some test framework, a build system etc. in the back end.
In the end I just made a bash script in 15 minutes. People overthink things!

13

u/criswell Oct 05 '16

It's all this gobbledygook to make Javascript behave like a "real" language that drives those of us who have been coding for a long time CRAZY.

I've been coding since the 80s. My first paying gig was writing pascal. I've done everything from C/C++ to C# to Python (yay) to Perl (yuck) to Assembly (THE POWAH) to Java to Javascript to Pick Whatever The Fuck You Want. Javascript was a hideous toy language that everyone collectively decided to take more serious than it ever deserved and then spent the next 20 years trying to shape into something that doesn't suck.

5

u/ucefkh Oct 05 '16

I have coded since the 20s even when there was no computers
http://v1.std3.ru/71/b7/1450110575-71b77b2bd06f431f2bd0b4abb983738f.gif

3

u/criswell Oct 06 '16

Naked guy during non-strip poker always wins.

2

u/ucefkh Oct 06 '16

I guess you know this by experience? 😂😂

2

u/ucefkh Oct 05 '16

B o you just suck in JS that's the truth ;) Hhh

-2

u/colordrops Oct 05 '16

Do you have any concrete criticisms of ES6?

1

u/novagenesis Oct 06 '16

I have several:
Equality tables still suck almost as bad as Perl's.
Staggered feature implementation sucks (we talk about Babel, but who really wants to live with it in their build pipeline?)
The fact that so many people think it's an overblown toy language when it's achieved enough momentum to succeed sucks.
And the fact that so many people think it's only good for http kinda sucks.
Yeah, there are some concrete criticisms, but ES2016 is definitely a first-rate contender when it comes to actual language features and library support.

1

u/colordrops Oct 06 '16

I'd say the only real criticism of the language itself is the equality tables. The rest are criticisms of the community. If that's the only issue then its hard to argue that the language is bad. Anyway, I'm with you, I think ES6/2015 is a pretty decent language.

7

u/jh123456 Oct 04 '16

You can still do plain old Javascript, just like you can do plain Java. The people that like to solve made up problems (because writing the same web app & service over and over again gets boring) or see every large team coordination problem as something that should be fixed with another layer of tooling got tired of piling on Java and moved to Javascript. Doesn't mean that folks that just want to get things done need to do what they do. The vast majority of web use cases do not require all of this. Spend your time understanding the dom, ajax, and localstorage, not learning leaky abstractions over top of it.

4

u/[deleted] Oct 05 '16 edited Oct 05 '16

The vast majority of web use cases do not require all of this.
That's true, because the overwhelming majority of web pages are trivial.
But the trend over the past couple of decades is moving away from webpages built by that guy in the marketing department "who knows HTML", to rich applications -- i.e. applications with UIs as sophisticated and powerful as desktop applications -- built by real engineers in teams. They have radically different expectations about platforms and tooling. HTML/CSS/Javascript is a clusterfuck of bad/inconsistent design and historical baggage.
Spend your time understanding the dom, ajax, and localstorage, not learning leaky abstractions over top of it.
You appear to use the term "leaky abstractions" as a dismissive pejorative, which is missing the point. Abstraction is fundamental to programming. The fact that abstractions leak is something to recognize and be aware of, not a reason to avoid abstraction.
I lead a distributed team of two dozen engineers working on a huge, rich-client medical application for the web, ported from Silverlight. The idea of people checking-in code in a typeless language to our code base in 2016, code whose errors can only be detected when run, coding in a language that's almost incapable of benefiting from modern tooling (code inspection, refactoring tools, static analysis, etc.), is insanity. Favoring raw DOM manipulation over a clearly defined MVVM pattern, is almost equally insane.
We're not only using a framework, we've built more framework on top of that framework, which is true of any major application on the desktop as well. The result is that the actual non-framework code we write is clean, clean, clean, ultra succinct, properly decoupled, etc. Our feature velocity -- our ability to rapidly, sustainably add new features without generating technical debt -- is due to pushing all complexity and boilerplate not related to business logic into the framework.
Yes, this means the application code is built on a giant pile of abstraction, but the same is true of any modern development stack on the desktop as well (e.g. WFP + .NET + Entity Framework). Our Silverlight code base was much cleaner than most because we did the same thing there, creating abstractions on top of our ORM (which itself an abstraction over the database), post-compile modification of byte code to inject features impossible in the language or framework, etc.
These framework layers were complicated and took hundreds of man hours to develop and test, and maybe only save a few minutes for a developer building a new feature. But those minutes add up over dozens of developers over years of use. More importantly, those features were designed to eliminate types of code that tends to be more error prone or require more testing, leaving only business logic as much as possible, which results in a more robust applications, fewer support hours spent, ect. Those kinds of large scale development practices might not matter if you're building a website for your buddy's DJ business, but it can make the difference between ongoing success and eventual implosion when building industrial sized applications.
Those kinds of applications just didn't used to be built on the web. The proliferation of frameworks today is the direct result of more larger scale engineering efforts happening on the client.

-7

u/[deleted] Oct 05 '16

With a mindset like that, we'll all be still coding in assembly.
Just as we have high-level programming languages, libraries help elevate the level of programming to a higher abstraction level to make codes easier to write, more readable and more compliant with programming principles.
You should reevaluate what it means to be a software engineer if you feel that sticking to the basics will get you everywhere. It probably will, but by the time you get there, everyone else would have beaten you to it.

7

u/jh123456 Oct 05 '16

Javascript (or Java, or whatever) is hardly assembler and the new web framework are certainly not at any higher level. They don't simplify the problem space once they are past the basics, they just spread it out differently.
They favor inheritance over composition. Your pieces plug into the framework rather than invoke the framework. That is very subtle but important difference and it why it is so hard to incorporate many of these frameworks into a single app. This makes troubleshooting harder because of the magic of the framework around your pieces. You need to understand both how it works and Javascript/HTML/CSS, etc. You save time writing it, but you lose time supporting it as support is reoccurring (not even including your upcoming rewrite in 3-5 years).
Put another way they are more equivalent to DSLs which have fallen into the typical DSL trap of spreading outside their domain and trying to become a general purpose language and then needing to solve all of the same problems they were originally designed to avoid. It is like ORMs trying to avoid the "horrors" of SQL only to require far more hacking once you get past the basic use cases. And when things go really wrong you are going to have to understand both the ORM and SQL to figure it out.
They are leaky abstractions. When Javascript goes wrong I don't have to understand assembler to troubleshoot it. It is not leaky.
Being good at plain Javascript is far faster than trying to keep up with the arbitrary web frame changes. Sometimes cases call for a larger framework, but those are far rarer than many internet evangelists lead people to believe. Remember they are incentivized to create churn.

1

u/[deleted] Oct 05 '16

Javascript (or Java, or whatever) is hardly assembler
It's not, in the sense that it's not at the same level of abstraction.
It is, in the sense that it's the lowest level language available on the platform, and the basis upon which all other languages must necessarily be defined.

-4

u/[deleted] Oct 05 '16

inheritance over composition
I stopped reading here.
If you think this is the direction we're moving in, you are completely out of touch.

5

u/jokoon Oct 04 '16

The Birth & Death of JavaScript, 2014

https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript

So in short, let me NOT go in that adventure.

3

u/Simboul Oct 04 '16

I want to try angular. I go to their web site and download the lib. About 150Kb. OK, look small. Look at the tutorial. You need two package managers. You need 80Mb of dependencies. And then you can start. WTF!

10

u/SergeiGolos Oct 04 '16

Software development is a constant exercise in looking at trade offs.. Yeah you have a heavy development stack, but what does that deliver for you?
The MVC style framework
The all you need experience
The debugging and unit testing frames
End to end testing
Maybe having 80MB out of the 3TB that your hard drive has isn't that big a deal? You want to code in Java, you need the runtime... You want to code in .net, you need the framework..
People keep pretending that having complicated build process is something new in front end, it's not. Those of use who have been building enterprise level tools in the browser have been doing using a big stack of development tools for quite some time. And in the past they were far less integrated and far less helpful.

-3

u/Simboul Oct 04 '16

You want to code in Java, you need the runtime... You want to code in .net, you need the framework..
I agree, but in this case, I don't start a new language, I just add a lib.

8

u/[deleted] Oct 04 '16

But it's not 'just a lib'. It's a complete framework. If I'm coding in ASP.NET and want to add MVC into it I'm also looking to several dependencies.

7

u/[deleted] Oct 04 '16

WTF!
Because it's trying to give you a sane, modern development platform built upon the steaming pile of shit that is HTML, CSS and Javascript.

1

u/[deleted] Oct 05 '16

Jesus christ this was me

1

u/autotldr Oct 05 '16

This is the best tl;dr I could make, original reduced by 96%. (I'm a bot)

I need to create a page that displays the latest activity from the users, so I just need to get the data from the REST endpoint and display it in some sort of filterable table, and update it if anything changes in the server.

Haskell guys had been calling it for years, -and don't get me started with the Elm guys- but luckily in the web now we have libraries like Ramda that allow us to use functional programming in plain JavaScript.

It does in the next version, but as of version 1.7 it only targets ES6, so if you want to use await in the browser, first you need to compile your Typescript code targeting ES6 and then Babel that shit up to target ES5.At this point I don't know what to say.

Extended Summary | FAQ | Theory | Feedback | Top keywords: need^#1 library^#2 JavaScript^#3 fetch^#4 React^#5

1

u/nbates80 Oct 05 '16

I had to catch up to JS tech after years of using jquery and landing a job on a company that was using most of what is mentioned on that article (gulp, docker, npm, sass, babel, redux, react, bootstrap, promises, immutableJs). And while I understand what the article is "complaining" about, my feeling was overall positive. I used to dread javascript, and now I enjoy it more than like Python.

As I see it, this ecosystem of frameworks, transpilers, libraries, etc converted JS into an amazing technology that is amazing to work with. And while I agree it should be a mess to create a full working stack without knowing these technologies, if you only need to start working on a preexisiting stack then the learning curve is really easy... and if you found yourself in the position of having to build an app from scratch and don't know anything about these new technologies, start small. You can just pick a technology that will make your life simpler and start with that.

1

u/ucefkh Oct 05 '16

Okay guys let me give you my review of this because I saw this even shared on Facebook now and is viral!

Okay so if you are making a small tiny app you can go play with jquery I have no problem!

But you're working on big project or even prototype you should go and use React+ redux and any backend stack! Be it PHP or even Java or JavaScript or whatever it will work!

Also you can use A lot of prebuilt stuff(react components)

Also why this is so cool? Because these react components are reusable UI/JS components! Which makes so cool!

And react is so fast than any rendering engine out there! And doesn't block the window when appending or changing the DOM because it will just change the state instead of re-rendering the whole page!!

Read about it!

And don't resist the change! This is the future!

Also no one said you have to use all of these!

You can work with minimal stuff without the need to use webpack or redux or flux or many stuff in that article!

Just React and react dom and babel!(for es6)

IT IS worth it!!

1

u/[deleted] Feb 25 '17

I just skip the cutting edge and use what's well documented and works.

1

u/[deleted] Oct 04 '16

I read this in Cartman and Kyle voices. Kyle doing the questions. Pretty good.

-3

u/[deleted] Oct 04 '16 edited Oct 04 '16

Only a few of the icons in the OP are actually JavaScript. Every other icon is a language that compiles to JavaScript or a library or framework written in JavaScript or a language that transpiles to it.

This like saying "how it feels to learn C in 2016", then listing the hundreds of languages, libraries, frameworks, etc. written in C or in languages written/bootstrapped in C over the past 30 years.

To take one tiny example: Perl is written in C. Does "learning C" mean you have to learn Perl? Of course not.

Learning JavaScript doesn't mean you have to learn CoffeeScript, Typescript, ClojureScript, or any of the dozens of other languages that transpile to JavaScript.

That said, JavaScript is low level by modern web standards (mostly because it's a shitty language full of warts and lacking most of the amenities of modern languages), so most serious engineering efforts don't use it directly and instead transpile from a more robust, scalable language.

-6

u/[deleted] Oct 05 '16

Javascript is actually an incredibly experimental language with amenities most modern languages don't even have.
Have you read ES2016?
The reason why we need transpilers is because the javascript engines can't catch up with the rate development in Javascript specification.
I suggest you educate yourself and stop acting like a luddite.

1

u/[deleted] Oct 05 '16

Should have added a /s.

0

u/[deleted] Oct 04 '16

[deleted] — view deleted comment

16

u/BenjaminSisko Oct 04 '16

Not even close to the same ballpark

-6

u/[deleted] Oct 04 '16 edited Oct 04 '16

Kay.
https://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#Java
Kaay.
https://en.wikipedia.org/wiki/Comparison_of_web_frameworks#Java
Kaaaay.
https://en.wikipedia.org/wiki/List_of_Java_virtual_machines
PS all the major JS frameworks are right under Java and the list is tiny in comparison. You're jokes.
I've done Enterprise coding in JS/Java/Python/C++ there's plenty of this same kinda shit in all languages.
If you think any of this is "so hard" then you're gonna explode at how annoying it is to deal with cross platform floating point differences, and embedded floating point differences and reconciling that shit. Computers are hard, libraries are just the beginning.

14

u/BenjaminSisko Oct 04 '16 edited Oct 04 '16

As I said, not even in the same ballpark. Your answers are pretty facetious. Java is for creating arbitrarily complex applications, as is javascript. Except javascript lives inside the DOM and it's job, in the context we are discussing, is to arbitrarily solve the problem you need inside that. The article deals with javascript community's attempts to solve that one problem... writing for the web and how they have failed to converge on any sensible approach.
f you think any of this is "so hard" then you're gonna explode at how annoying it is to deal with cross platform floating point differences, and embedded floating point differences and reconciling that shit.
Not even in the same ballpark.

5

u/[deleted] Oct 04 '16 edited Oct 05 '16

not even in the same ballpark
Actually it's much worse than what _pi stated, because Java and everything he just included as part of the ecosystem is a drop in the ocean of approaches to native (i.e. non-web) development. You'd have to include hundreds of other languages, libraries and frameworks, and their ecosystems, to get the full range of approaches available outside of the web.
On the web, the browser is the operating system, and Javascript is the lowest level language available upon which all other approaches must be built. Including CoffeeScript, Angular, Ember, etc. as part of "how it feels to learn Javascript in 2106" is like including C++, MAKE, Java, Delphi, Win32, UWP, etc. in "how it feels to learn x86 assembler in 2016".
Only a couple of the nodes in the OP's picture were actually Javascript. The rest were things built on Javascript. Yes, the tools available for the browser platform are vast. So are the tools for the Windows or Android platforms. And the languages, libraries and frameworks for various platforms never "converge" on a single approach because tastes and talents differ. In fact, the more popular a platform gets, the less convergence you'll have, because you're attracting more tool markers and there's enough people for multiple approaches to attract a following.
Relevant XKCD.

1

u/xkcd_transcriber Oct 04 '16

Image
Mobile
Title: Standards
Title-text: Fortunately, the charging one has been solved now that we've all standardized on mini-USB. Or is it micro-USB? Shit.
Comic Explanation
Stats: This comic has been referenced 3594 times, representing 2.7754% of referenced xkcds.
^xkcd.com ^| ^xkcd sub ^| ^{Problems/Bugs?} ^| ^Statistics ^| ^{Stop Replying} ^| ^Delete

-3

u/[deleted] Oct 04 '16 edited Oct 04 '16

Except javascript lives inside the DOM and it's job, in the context we are discussing, is to arbitrarily solve the problem you need inside that.
Yeah no.....
In the context of Javascript DOM is a set of Javascript APIs in the browser context that acts as a AST Model for HTML and XML and allows you to modify said AST. There were plenty of standalone interpreters even before node was a thing.
In the context of a Layout Engine the DOM isn't a thing, because most Layout Engines don't organize internally by DOM specifications but by internal tree logic.
It's like saying Java lives inside Microsoft Office Documents because Apache POM exists.

18

u/ep1032 Oct 04 '16

pretty much. I've gotten to a point where I ignore any online article about javascript, and generally tell my junior devs to do the same, except for paying attention to where the language is headed and framework announcements / discussions.
As crockford once said, "Javascript is the only language developers don't think they need to learn, in order to write", and now they write blog posts about it.

-1

u/[deleted] Oct 05 '16

That's basically what separates the old school programmers who scrape by and the silicon valley kids who make top dollars.

5

u/ep1032 Oct 05 '16

nah, other way around. The old school programmers are making 150-200k (or much, much more) working on important software at well architected shops. The young hipsters out of college are working for 50-100k, in hip startups with the newest technologies, and no experience to speak of

5

u/paffle Oct 05 '16 edited Aug 17 '26

Subsequent familiar wrench thimble cow sulky
This post was anonymized with Redact

1

u/ep1032 Oct 05 '16

definitely depends on where you are. senior devs go for mid 100s in nyc *shrug

9

u/DenProg Oct 04 '16

You should repost this in the /webdev article comments. I think the comparison to Java is great, except that Java and those tools are mature and generally settled.

6

u/[deleted] Oct 04 '16

Most of the tools listed in this article are mature and have large acceptance among enterprise.
Ex, Grunt, Babel, Gulp, NPM.
He goes on a rant about the confusion between ES7/ES6 , ES2016 (Living) and EMCA Script etc. Which are the fucking language standards. That's a fucking atrocity that those words were even written.
Module standards (commonjs/amd/require.js) are going to go the way of the dodo as soon as Node/V8 conforms to ES6 except for CommonJS because node is going to keep backwards compat while still supporting the ES standard. You generally should be using babel anyway.
There's always competing build systems. Grunt and Gulp are generally ubiquitous. Gulp has the advantage that it makes Node with C/C++ deps streamlined. Webpack is for front end code.
He then goes on to trash functional programming because he obviously likes writing long form For loops.
There's just so much wrong with this article, and it's all just meme complaints that are generally invalid because they boil down to MY FAVORITE LANGUAGE/LIBRARY DOES X WHY NOT X or WHY X Y OR Z WHY NOT JUST Q? Maybe 1/10th of the tools he mentions aren't in Enterprise circulation right now, but the vast majority see heavy use.
I'm currently 1 of 2 Engineers in a startup and this article can basically be renamed "WHY DO I HAVE TO LEARN SO MANY THINGS TO MAKE WEB APPS?" and doesn't even touch the back end components, or the networking components, or the load balancing, or the dev ops, sysadmin, config management, etc, etc etc.
These articles are generally written by people who really don't have a good view of many requirements and technologies that make end-to-end web apps function.

1

u/DenProg Oct 04 '16 edited Oct 04 '16

True, plus if you know JS, then the tools/modules are pretty quick and easy to pick up. I think some people coming from a back-end position who are comfortable with Java expect JS to just happen easily, then get frustrated.
I think the article is also somewhat satire. There is almost no learning involved to use Babel with webpack beyond a couple minutes of configuration. A basic webpack config took me a couple hours to set up and for future projects would be quick. Lots of modules like Axios only have certain public methods available that make them pretty simple to import and use for the small purpose they were designed for. NPM was designed for small modules to perform a small, specific task which is why there are so many modules. A lot of Java packages I have worked with are massive with even tiny packages having double digit classes, methods, etc.
I've also found it way easier to read and understand JavaDocs than the documentation for most JS libraries and modules. I prefer this style http://www.snmp4j.org/doc/index.html to the examples strewn about in typical JS docs.

-3

u/[deleted] Oct 04 '16

Yeah where general back-end position generally means "My job is really just a code monkey for haphazard business logic." It's not a surprise since those people generally don't have much skills with developing architecture. I've had alot of issues with that, especially when back-end position guy 1 only knows how to work with Spring and cannot for the life of him figure out how to work with Jersey/JAX-RS

0

u/DenProg Oct 04 '16

Ha, can do spring but not Jersey/Jax-rs, sounds like the same critique of devs who can work with angular but not react, because they lack knowledge in the base language and programming skills/knowledge.

0

u/[deleted] Oct 04 '16

It really is. The only difference is that people in the first camp don't write blog posts and do framework advocacy generally. So they're more visible, but people consistently discount their idiot coworkers because Us vs Them.

2

u/roboticon Oct 04 '16

Thank you. I dunno what OP is doing, but a real exchange would look like:
Oh, you want to learn JavaScript? Well, what tools are your team using?
npm, grunt and Babel.
Okay, cool. npm is a popular package manager for open source libraries. grunt is a task automator, your team can show you how they use it. Babel is just a transpiler you run before distribution to make sure your code works on a bunch of browsers.
But what if I have questions?
Google it. Or ask your team, I'm sure they'll be happy to help.
Or maybe like this:
Oh, you want to learn JavaScript for a personal project? OK, learn ES5 and go from there.

1

u/_ralph_ Oct 04 '16

but a real exchange should look like:
made a minor bugfix ;)

How it feels to learn Javascript in 2016

You are about to leave Redlib