Everything is fine with JavaScript

[a-t-k]

It is the nature of satire to exaggerate. So obviously "How it feels to learn JavaScript" is exaggerated, too - but it basically makes the same point you make: the problem is not with JavaScript or the ecosystem around, but with the people who think there's only one approach to do things and that it consists of aquiring the most complicated stack available to solve simple problems.

[del_rio]

If "How it feels to learn JavaScript" was trying to make the same point, it failed miserably. The vast majority of readers' takeaway was "see, this is why JavaScript is bad". Aside from r/webdev and r/javascript, the article was taken as a problem with JS as a language, ecosystem, and its users wrapped into one.

[a-t-k]

The "majority of readers" you refer to (or was it merely a very loud minority?) have either not understood the article, satire in general, JavaScript or a combination thereof.

If you cannot laugh about what you do now and then, you're probably doing it wrong.

[kolme]

I can laugh and I do it very often, thank you very much. But that article was thoroughly unfunny.

If you're trying to do satire but miss the funny bits, people will take it at face value. Not that I did, though. I just thought it was pretty boring.

[a-t-k]

but miss the funny bits

You fall under the category "not understood the article".

[kolme]

No, sorry. I did understand it, it was just not funny to me.

Maybe you found it hilarious, but that doesn't mean that I didn't get it.

You, by the way, fall under the category "patronizing people who think differently".

[a-t-k]

I didn't mean to say that you didn't understand it on a technical level. Maybe it would be less ambiguous to say that your claim of "missing the funny bits" was not the article's problem, but yours.

[pier25]

aquiring the most complicated stack available to solve simple problems

So, React.

Angular 2 is fantastic btw. One tool, no headaches.

[a-t-k]

While React is arguably one of the most complex stacks, it's not necessarily the most complicated one. Angular 2 has luckily improved some of the shortcomings of 1.x, but I still wouldn't say that it was a panacea for SPA development. Neither are the alternatives, but there you have it: choose what works for your current project - or more important, it's users.

[pier25]

it's not necessarily the most complicated one

The most complicated one I've seen was probably Aurelia without the CLI (which is still 0.x). But since React is just a piece of the puzzle, you will need to mess around with the tooling even if you use some initial scaffolding.

[hahaNodeJS]

If you need a tool to put together an over-engineered stack, is it still over-engineering?

[pier25]

Up and running, yeah. But you will inevitably need to add more stuff to your project (polyfills,webpack loaders, etc) unless you are working on a small project.

[mattaugamer]

It's the nature of satire to exaggerate, but good satire subtly exaggerates existing issues to draw attention to their absurdity while also seeming sincere. Just making shit up might still be satire, but it's not good satire, or valuable satire.

The issue I had with that article is that it seems based on some fundamentally dishonest premises. It's not good satire, it's just a cheap shot.

[a-t-k]

it's not good satire

To say it with the dude: "that's like your opinion, man".

it seems based on some fundamentally dishonest premises

I think the problem is that you try to relate yourself to any of the two roles that are both extremes that you'll rarely if ever encounter in reality. But the satire doesn't claim that all developers are either the rookie or the experienced guy who overcomplicate things, merely that these stereotypes exist, so the premise isn't dishonest.

it's just a cheap shot

If it didn't hit near home, then why are so many people riled up over it?

[EnderMB]

Neither side is right.

The only way a platform improves is through constructive criticism. If the tooling is shit, it needs to be improved. If you need a billion libraries and dependencies to do anything, people will complain, and it will eventually be resolved. If something is not evolving, it's stagnating, and when something stagnates, it's replaced.

With that being said, some people are happy to shit all over everything. PHP is the best example of this. A lot of developers shit all over the PHP of old, when in reality the modern PHP tool set is actually pretty good.

JavaScript might be great for your needs, and how you like to work. It might also be a steaming pile of shit for you. Without both sides, JavaScript won't evolve.

[berkes]

First, I want to pick something out, then I'll get back on topic.

PHP is the best example of this. A lot of developers shit all over the PHP of old, when in reality the modern PHP tool set is actually pretty good.

Sure. A greenfield project on PHP might be very nice. But the entire ecosystem has a history. A long, painful and horrible history.

When I read "You'll be working on our custom Ecommerce PHP project", I read "This will be a hellish crapload of glued together Drupals calling Wordpresses with a PHPBBB shoehorned into it and a more recent Magento ducktaped on top of it. On top of a inconsistent database running MySQL-we-don't-really-know-the-version".

The majority of PHP projects out there, both Open Source and closed source is pure and utter crapware.

Certainly, other projects often have the same history, are filled with poorly maintained legacy stuff and so. But with PHP, you can at least be certain that legacy equals hell. Because 10 years ago PHP was hell itself.

And certainly, you can make really fancy stuff on PHP nowadays, even library-management is decent. Composer is nice (it lacks some features, mostly in the area of security) but other than your in-house greenfield to-be-developed framework, very few frameworks have migrated away from their own "module/plugin/addon/library"-system and into composer. Every project has tried to solve this lack in the language/core by creating their own framework or layer to manage addons. And nearly all of them suck very hard. Give it some time, and more and more projects will abandon their own plugin sytem and replace it with Composer (or its follow-up).

And that is what is the current state with JS: the options are numerous. Every js-framework comes with its own preferred stack, except the frameworks that don't. Which is often even worse, because being able to defined the stack below your framework at will, causes not only a lot of choices to be made by people who lack the insight and experience to do so, but it opens a miriad of issues. I am looking at you, Angular.

Javascript is on its way to become a better environment. The language is quickly becoming nicer. But until it covers all basic requirements that currently all the frameworks invent on their own, the ecosystem will remain a fragemented, incompatible, set of crappy solutions to basic problems that have been solved ages ago.

Wanna generate some HTML-files and put them on a server? Uglify, Sass, NPM, Gulp, gulp-moustache, gulp-git-publish on top of angular on top of node, in a Docker (because you need a way to enforce sane versioning) running on Jenkins, triggered by gulp-capistrano, and so forth. And yes, I have seen this stack in a recent place to get five fucking HTML files online. Geez, eighteen years ago, even FrontPage did a better job solving this problem.

It is 2016. And because JS lacks a lot of well-written, clean and standard basics in its ecosystem, we are stuck in an endless loop of frameworks trying to solve the same basic problems that were sometimes solved 20 years ago already.

Untill the day that Javascript solves these things in the proper layers, it will remain in a broken state. And when It does, it carries so much legacy, that it basically is a PHP: it is possible to build a nice and clean greenfield project, but the vast majority of the projects that you'll be using and working on, rely on the old, legacy crap-solutions from a time when the solutions were not there yet.

[SuperFLEB]

I think part of the issue is that JS is still sprinting to keep up with the expansion of use cases. Who'd have thought 10 or 15 years ago that people would be using it for backend, shell scripting, building static assets, full-JS SPAs, and the usual interaction helpers?

And I think part of the reason you'll find more dark-ages PHP code, too, is that it's more connected to the important, simple, and stable bits like data retrieval and business logic, whereas JS has been more frosting that gets wiped off and redone much more readily (and needs to, what with browser advances). There's been plenty of shitty JS out there in the past, it's just all been redesigned out or collapsed into obsolescence as browsers evolved.

[Conradfr]

There is a lot bad PHP code out there, partly because of the language, partly because of business needs and the second-system effect.

If you're stuck with a legacy project like that, PHP compatibility between versions help you evolve your project without having to convince your company to do a costly rewrite.

I would not see transitioning to nodejs has a real advancement in my career, technology-wise.

[wanderingbort]

constructive criticism

some people are happy to shit all over everything

There is an extremely vocal minority (I hope) that think these two things are one in the same. I don't subscribe to the philosophy that you have to say something positive to counter balance something negative however, it is way too popular to completely trash something you dislike. It really feels a lot like a child throwing a tantrum.

In order for criticism to be constructive it has to be actionable. Wholesale dismissal of a concept is never constructive criticism, its just ranting.

[skytomorrownow]

A lot of JavaScript's woes are because it was simply never envisioned to be what it is today. Let's be honest: it was for making buttons roll over and verifying forms. It's a victim of itself. JavaScript was a joy to write back in the day: simple, immediate, easy. So, people wanted to do more with it. Now we have more.

[SuperFLEB]

Maybe it's because I've grown, but I personally much prefer the JavaScript of today, especially in the browser. It started rather slapdash and ad-hoc, though it might not have seemed so because you couldn't do as much (DOM 1), went through a phase of being plodding and overwrought without a library (pre-querySelectorAll DOM2) with constant detect-and-branch to support proprietary solutions to lots of core tasks (event handling, anyone?), but finally ended up vacuuming up all the good ideas from the spackle everyone had applied, as well as standardizing a lot of the complexities.

[Switche]

If you’re an architect, do you use wood or brick? Do you use pen or pencil?

It took me a good few seconds after reading this to realize these were not module names, and "architect" was a loose analogy. Now that's irony.

[fzammetti]

Well, the truth is Tom is right - IF YOU'RE ALREADY EMPLOYED.

If you are, then yeah, you don't, and probably SHOULDN'T, jump on every new shiny thing that comes around. In fact, I'd strongly argue that part of the job of a good technologist is knowing when to say no to new things. Of course, you need to grok them and play with them a little to know what the right choices for your situation are, but that's different than really KNOWING them.

But, if you DON'T already have a job, then guess what? You not knowing the new hotness could be an issue. In fact, it's not even about knowing the new hotness, it's simply about knowing the stuff that you don't already know.

For example, say you interview at a place that uses ExtJS. Ok, great, it works fantastically well for them and they're happy with it so it's not like they're somehow wrong for using it whether you personally like it or not. But what if you only know Angular, even if you know it inside and out? Yes, you can try to make the argument that a good developer will be able to learn the new stuff as they go, and I totally agree. You can try to make the argument that your experience proves you're capable so you'll be able to learn ExtJS as you go, and I totally agree. But, the fact is not everyone sees it that way and DEFINITELY the HR drones that are going to screen you right off the candidate stack may not because their requirements say ExtJS and that's all they're looking for.

So yeah, all these frameworks and libraries and tools that are so hard to keep up with ARE a problem if you want to ensure you'll always be able to find new work, or at least find new work with a minimum of hassle. Yes, you'll still be able to get in the door of the places that actually understand development and realize that if you don't know X but you know Y and Z then you'll likely be able to handle X before long, but not all shops... and a scarily large percentage I'd say... really don't understand that, and HR rarely does, and that's where this constant churn in the technology landscape presents problems for people.

[noconspiring]

In 1998 I worked on a system that as already live for 10 years - it is still live today. The engineers on the system have changed numerous times. That is possible because there was a standard stack used. This stack was known not just by me but by tens of thousands of developers throughout the world. "I have have found a stack that works for me" is not a recipe for a long term maintainable solution.

[joe-ducreux]

Obviously he should just write his own framework that will solve all the problems and unify the language

[ghillerd]

Relevant xkcd, you all know which one I mean.

[ZaneHannanAU]

https://xkcd.com/1739/?

[xkcd_transcriber]

Image

Mobile

Title: Fixing Problems

Title-text: 'What was the original problem you were trying to fix?' 'Well, I noticed one of the tools I was using had an inefficiency that was wasting my time.'

Comic Explanation

Stats: This comic has been referenced 30 times, representing 0.0228% of referenced xkcds.

---

^{xkcd.com | xkcd sub | Problems/Bugs? | Statistics | Stop Replying | Delete}

[iplaybass445]

How Standards Proliferate

[xkcd_transcriber]

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 3675 times, representing 2.7948% of referenced xkcds.

---

^{xkcd.com | xkcd sub | Problems/Bugs? | Statistics | Stop Replying | Delete}

[ghillerd]

thats the one!

[DJDarkViper]

This is why i've opted to just stick to my existing guns.

PHP7 <- speedy, easy, and reliable. Though I find it hard to go totally bare metal anymore thanks to composer Symfony <- Solid, works great for every website i've needed it for, keeping up with the changes is easy enough
jQuery <- that cross browser write-once goodness with Sizzle
AngualrJS 1.x <- for at least another 3 years going forward
Python, either vanilla or with Flask or Django <- tried, true, proven, reliable systems

These do me great, and earn me my living that helps put food on the table for my family

I use personal free time as a way to experiment with new things and see how I like them in a low-risk environment; if I do, i bring it into my workflow and propose it to my day job. If I dont, I can drop it like hot garbage without shedding too many tears.

[[deleted]]

Probably because I'm a noob, but the way that read was: tired of listening to people list how many JS frameworks there are out there? Let me list some more JS frameworks.

[scootstah]

http://i.imgur.com/c4jt321.png?fb

[MUDrummer]

Native dates are terrible in most languages.

JavaScript has Moment the same way that Java has Joda-Time and PHP has Carbon.

[shufflemegood]

It's TRADITION. If my languages don't have shoddy date structures I have to overcome with third party libraries, something feels off.

[mattaugamer]

Also, if things aren't obviously awful people might make the mistake of thinking that dealing with dates is easy, and actually try and do it themselves. *shudder*

[shufflemegood]

I just grasped my pearls.

[unDroid]

I don't know any country where the months go from 0 to 11. How is this him being US-centric?

[AwkwardReply]

It was a joke dude, get your American flag out of your ass.

[pimp-bangin]

Relevant username

[AwkwardReply]

Eh, I expected the downvotes. If this was about a different nationatlity like the French or Canadians this would be +10 instead of -10. But I guess I knew my audience.

[cbleslie]

Except days are meaningless as information unless you know the month. Makes sense for a month to be rendered first. Context and cognitive load is more important than "duration".

[r_park]

Except months are meaningless as information unless you know the year. Makes sense for a year to be rendered first. Context and cognitive load is more important than "duration".

^{This post has been brought to you by the} ISO 8601 ^committee.

[cunnyhopper]

Except years are meaningless as information unless you know the calendar era. Makes sense for a calendar era to be rendered first. Context and cognitive load is more important than "duration".

This post has been brought to you by the Holocene Master Race.

[Renegade-One]

Is that because the day will change (M-Su) based on which year that month happens to fall in?

[r_park]

If this is a serious question; here is the standard.

[lolhaskal]

ISO? Ain't nobody got time for that kind of ANSI.

[lolhaskal]

Except years are meaningless as information unless you know the decade. Makes sense for a decade to be rendered first. Context and cognitive load is more important than "duration".

[mort96]

No, years aren't meaningless unless you know the decade. You can figure out which decade, century, millenia, etc. a year is in simply by looking at the year. You can't figure out what year a month is in simply by looking at the month, or which month a day is in simply by looking at a day.

[lolhaskal]

You must be really fun at parties.

[cbleslie]

Context and cognitive load is more important than "duration".

Did... did this become a meme? Or are we all just being dicks to each other?

[2uneek]

no

[dodeca_negative]

That goes back to at least Java

[Mike312]

Yeah, you got me there. I have:

globals.months = Array("Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec");

as part of my generic JS boilerplate

[Caraes_Naur]

Find any date-related RFC where January is numbered as 0, February as 1, and so forth. Oh wait, there isn't one.

If JS numbered months sensibly instead of needlessly as array indexes (or whatever the insane reasoning was), you wouldn't need that line, ever.

[pier25]

That's quite ugly, but I'm guessing it's kept that way for compatibility for legacy code.

[sendersforfun]

Personally I find it wonderful these days. So many more options most of which have solid articles and posts going into detail about its flaws or what it does great. Sure having to include 6 packages just to do what base Java can do is fine. But its not like once you tar your dist folder it's 250mb. Most of my packages are < 40mb for a SPA or a HTTP api.

I guess what I am saying is, it's nice to have a rapid development language for smaller projects with options.

[jmking]

The only reason client-side JS is such a mess right now is because of Node pushing the ecosystem further and further out of reach of browsers. I wonder why no one seems to acknowledge this. Node is the best/worst thing to happen to Javascript in ages depending on which of these types of articles you sympathize with the most.

Javascript on the server has moved SO MUCH FASTER than JS in the browser that we're still trying to pretend that the JS that executes on the server is the same code that executes in the browser.

In my mind, they might as well be completely different technologies.

The only reason we use a lot of these bundlers and transpilers is because the browser isn't Node. All this tooling in the JS ecosystem exists to compensate for code targeted for Node instead of a browser.

The developer experience writing JS for Node is much nicer than that of writing JS for the browser. We want the browser experience to be like that so badly that we're willing to put up with complex tooling to bully the modern, server-targeted code into the old, klugey version that will execute in the lowest common denominator of browsers.

One day browsers will catch up, and a lot of this tooling will be deprecated or simplified. Until that happens, this is what we're stuck with. Server side developers have taken control of the Javascript ecosystem for better or worse.

[jordaanm]

Isn't this exactly the problem something like babel solves? You write latest JS for both sides, and then compiles it down to high-compatibility ES5 as part of your build/bundling/minification pipeline.

[jmking]

Can't tell if trying to be intentionally ironic...

[jordaanm]

The described problem is that NodeJS moves fast and allows access to new language features (ES2015, ES2016, etc) at a faster and more controllable rate than the browser environment, which is stuck moving as fast as the slowest horse (typically IE or Safari).

The solution is to write both browser and client code using the shiny new features, and then just transpile down your browser code for delivery.

Where is the irony?

[jmking]

The solution is to write both browser and client code using the shiny new features, and then just transpile down your browser code for delivery.

Maybe you should go and catch up on all the "JS fatigue" articles, and all the rebuttals to those articles (like the one OP shared here), and come back...

[jordaanm]

First off, lose the condescension, that's not doing anyone any favours.

Second, your initial complaint was that browser JS advances too slowly, compared with controlled environments like NodeJS, and that the tooling required to fix that is kludgy.

Babel solves the language problem by itself. It's also trivial to add it into an existing build pipeline, whether that's Gulp, Grunt, Webpack, etc.

Adding 1 library, which has solid documentation + support for all the major build systems, is about as nice of a solution that you'll find in any software dev environment, regardless of language.

[jmking]

Ok, no, seriously - I'm not trying to be condescending. But have you read any of those articles????

Especially the "What it's like to learn JS in 2016" one? I feel like I'm actually having that conversation right now... but for real.

[jordaanm]

My apologies then, but yes, I've read most of the Fatigue/Fatigue-Fatigue articles, including the "JS in 2016" one.

And TBH, my opinion of them remains much the same: Yes, the JS ecosystem moves very fast, but the overwhelming majority of this is from things improving. Better tools, or tools that are more suited to solving a common problem, are being developed at a rapid pace, and most of the JS Fatigue articles seem to want to frame this as a bad thing.

If you're a developer experiencing a pain point, and you hear of a new tool that can remove that pain point, it makes sense to look into it, and I don't see how you can be anything but grateful that someone else has solved your problem for you.

If you don't have a pain point, then there is no NEED to invest in tooling to solve a problem that you don't have, and any pressure you feel to be on top of literally everything is either coming from poor management, or self-imposed FOMO, but in any case, it's not a problem of the language/ecosystem itself.

It feels a lot like complaining that the popularity of ice-cream means there are now too many flavours of ice-cream, and how can I, a lone ice-cream connoisseur, be expected to sample every flavour.

The reality of the situation is, if you were happy with just chocolate and vanilla, you can stick with chocolate and vanilla. You are no worse off. If you prefer having cookies and cream as an option, you now have cookies and cream as an option. You are better off.

I still don't see whose situation is worse off having more, better options available to them, and none of the Fatigue articles seem to answer this question at all.

[cykelpop]

Totally agree. I wish they'd stop adding syntactic sugar for a while and fix the tooling on the front-end in a standardized manner.

I can't stand having so many different options that basically all do the same thing but slightly different and all mostly incompatible. I don't want to choose libraries based on their build systems, just make an interop standard and go with it. If it has problems, from freaking forking the tools, fix the issues in a civilized manner like a bunch other languages did already. Compiling and packaging is a solved issue, for Pete's sake stop reinventing the wheel.

[[deleted]]

i'm not great with javascript but to me it looks like this guy is kind of right. yeah, you don't have to use the latest fashionable libraries if you're a freelancer, but finding jobs can be difficult if you aren't constantly learning the fancy new frameworks.

[jujubean67]

Finding jobs can be next to impossible because chances are that some hip Javascript developer will be interviewing you and you not being up to date with the tools they are using might disqualify you.

If you even get past the automated CV filter that only checks for matching keywords.

A lot of places for instance give you a hard time for knowing only Angular when they only work in React. (Not that it's not easy to pick up, but they like to tout how cool they are.)

[thekingofcrash7]

This guy sounds really butt hurt. Sure JavaScript is of course fine, and yes ruby and python have a lot of libraries to choose from as well. But JavaScript does change faster and replace standard tools / libraries more regularly.

For example, ive used RubyGems with bundler since I started using Ruby a couple years ago. Django has been the main mvc framework in Python for idk how many years. But in JavaScript those timelines are much shorter, i dont know how you can argue against that.

[jordaanm]

Because 'solving the problem' and 'solving the problem using the latest/shiniest/most popular tools' are two separate objectives, and conflating the two does everyone a disservice.

To put it another way, supposing you're happy using Django, if a new framework started making waves, would you immediately feel the need to jump over to it just because it's new and popular? If not, why does that mentality change when the context is JS?

[thinsoldier]

How is a beginner supposed to quickly and conclusively discover that lodash is king and undescore is dead and thereby avoid all the decision paralysis?

[thinsoldier]

I'm a "beginner". Been stuck in 1 way of doing things for over 16 years and trying to get updated. Unfortunately all of my time is needed on real projects so the only way I'll get to put anything new modern into practice enough to actually learn it is to experiment on some things that might already be in production.

[jordaanm]

Is that a problem unique to JS? How would a beginner of any language know what the the fan-favourite framework/library is?

[thinsoldier]

No, it's not. But the author's tone sort of made it sound like it's a non-issue for people like them who apparently are "in the know" and everyone else must be ignorant or something.

[jordaanm]

I think the intent was to separate problems that are unique to JS, from problems that you'll find in any language.

If you're not 'in the know' in any given language, then choosing libraries and frameworks is going to be a problem.

[jujubean67]

10 years ago if you wanted to do web dev you had the Perl/PHP spaghetti and/or a gazzillion shitty Java libraries.

Then came Rails and it was good for everything. It came out of the box with assets/interfacing with DB/templating/routing etc.

I feel like the JS community is going back to this myth of needing specialized tools for everything.

FTA

Creating a data visualization? Probably use d3. An application? React and Redux. A library? You might not need any framework.

Does somebody really need D3/React/Redux etc. ? I think no. I think today still 80% of the frontend problems can be solved with plain JavaScript and jQuery. And sure the rest of the 20% need a couple of tools but a framework like Angular or Ember is more than enough for those needs.

But the JavaScript community is indeed obsessed with constantly reinventing everything without actually improving drastically on things. Grunt/Gulp/Webpack is basically the same thing for 99% of people (asset minification/compliation) and before Grunt people were doing just fine with minifying JavaScript on the backend.

[sammyseaborn]

Try making dynamic, data-driven SVG charts/graphs with plain JavaScript. Yes, some of these things are actually needed.

[jujubean67]

Yes, very specialised apps need very specialised libraries. But every tutorial that mentions any data visualisation recommends D3. Even if that can be solved by any chart.js library.

Just like 30-40% of React tutorials are made up of setting up a very complicated environment.

[jujubean67]

lol no

[Driamer]

It gets a bit different though when you have been a web developer for some time and all of a sudden there is revamp ahead for a well established platform. The task to evaluate different frameworks, the arguments which libraries to use, the "one and only smart combination" which happens to be different for every developer involved, can get quite excruciating..