How it feels to learn JavaScript in 2016 | Hacker News Reader

How it feels to learn JavaScript in 2016

hackernoon.com

499 pointsobjectiveariel230 comments

Previous discussion: https://news.ycombinator.com/item?id=12628921 (19 hours ago, 108 comments)

In my experience, the developers who fall into this trap of despair almost always do so because they aren't consciously choosing what tools to use; instead they are letting the tools choose them.

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't want to feel left behind.

Choose a library or tool because it improves your development process. If it doesn't appear to improve it, don't use it (at least not unless external forces compel you to). Especially don't use it if it appears that it will retard your performance (cough Angular cough).

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.

That's not to say I'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'm still very productive without them.

In fact, I'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 don't use a tool makes me look like I know what I'm talking about and not just cargo culting. Employers quite like that.

Incidentally, this isn't unique to the front-end. I've seen the same thing happen with the SQL->ORM->Mongo->Couch->SQL nonsense, or the myriad of templating engines written for PHP, a language that itself is a templating engine.

So what do you do about jobs asking for Angular/React experience? Just tell them you have none because you haven't needed to use them yet? Or avoid those jobs? (There are a lot)

I'm not the person you replied to, but I'd recommend learning them well enough to know their strengths, and then telling the interviewer that's what you did.

If you have any experience in other front end frameworks, that'll usually be enough to get you through that part of the interview anyhow.

Also, after learning a few frameworks, it simply isn't hard.

I mean, if you get the right mind-set of wanting to understand "what is the intention of the framework devs" you can pretty much learn any framework.

Problems mostly come if you try to force your React/Ember/Backbone knowledge into another framework.

I got all my jobs without prior knowledge of the used frameworks.

That's if you get the interview. This is my problem with most of this kind of advice. All the learning in the world won't help if they ignore your resume because your last job didn't us the same technologies they do.

You're presuming that's why they ignored your resume; it might not be. A good recruiter will help you improve your CV and will also ask the employer why you were rejected. It is also worth while including a covering letter that you can use to make some statements up front. Make it relevant to the job description and keep it to the point.

Finally, you may not be ready for the skill level you are targeting and you may need to work out what areas you need to improve in order to be able to progress.

I've hired multiple people onto team using React when they have no prior React experience.

The learning curve for React is pretty smooth, so I'd mostly check if they had experience of building the types of apps we were doing with other approaches - and whether they'd seen any ill effects from those choices.

Demonstrate you know fundamental javascript. I hire "I know javascript" over "I know angular".

Unfortunately for OP, you're in a very small minority.

I don't really agree. I think people make a lot of assumptions on the "losing" side of the interview table. If you don't get the position and feel like you aced the interview, you search for some justification that has nothing to do with your performance. The fact is, there are 10 people vying for a single position. All else equal, If we use angular, I'll take the angular person over the jQuery person (emphasis on all else equal). That person will likely chalk it up to jQuery instead of the simple fact that there was an equally qualified candidate with a more specific skill set.

Just tell them you have none because you haven't needed to use them yet, and tell them why you haven't needed them yet. It may be because you haven't built complex apps or it may be because you have found your own way of dealing with that complexity that didn't require those libraries. Use it as an opportunity to discuss what you can do. If they ask you for an interview anyway then you know that it's not a deal breaker.

Also realise that a lot of the time the requirements are really just a wish list. I was recently sent a job spec that "required" a year of Angular 2 experience. Rather unlikely, given that Angular 2 is still in beta.

As someone who learned Unity well enough to do game jams, then tried to switch to Unreal Engine 4 and failed to get traction for a year, I absolutely agree.

I was choosing UE4 for technical reasons and completely ignoring my comfort with the system. I was completely unable to get motivated and it absolutely brought my mood down for that year.

Then I recently picked Unity back up (and had to learn a year or more of what I'd missed, including the new UI stuff) and it feels so much better. I'm getting things made and my mood has improved quite a bit.

I haven't completely given up on UE4, but I'm no longer trying to shoe-horn it into my development. I'll wait until it really is the right tool for the job this time.

True story, same issue.

We were building on Unity 4 and kept getting awful looking details and figured 'game engine swap' and went Cryengine. Holy shit, what a bad one. Cryengine and Unreal Engine have well-thought pipelines for asset management and they work great with professional studios that use the complete professional Adobe pipeline. Remember that Unreal Engine is a professional product being shoe-horned for indies where as Unity is an indy product now being shoe-horned for professionals.

How would you suggest developers actually figure out what tools to use? It is next to impossible to make an informed decision without digesting a good portion of what the OP is talking about. You need to start somewhere.

Where the OP falls off is with stuff like "OMG don't use jQuery" or "no one uses HTML anymore". There's nothing wrong with using those -- and frankly using plain old javascript and HTML is fine. Remember we reached for jQuery in the first place because the browser lacked features we wanted, and because it handled cross browser stuff for us. That is, it simplified things we were already doing manually. So the trap is bad advice like "use these 58 libraries" combined with an inexperienced person making the architecture choices. I'd say instead (if you're the inexperienced person) just start building stuff. Then every time you said "this is repetitive, I wish there was a library that did this for me" -- there will be. Go out and get it, and you'll then understand why it exists.

I've been to more than one interview where I defaulted to jQuery and was immediately disqualified, based on the looks on the interviewers' faces. As a ruby developer, it certainly feels like keeping up-to-date on JS takes more work than the other 90% of languages that I'm familiar with.

Yeah, it's true, but I've also been in interviews where I told them I was using a tool that I think they thought was too hipster and ended up just being ahead of the curve (Babel or TypeScript, don't remember which one, both were just picking up popularity) while still being looked down on because of jQuery.

These interviews usually end and then when I look up the company 3 months later they don't exist anymore or have pivoted.

Interview question: "iterate over an array":

  angular.forEach([1,2,3] ...

  $.each([ 1, 2, 3 ], ...

  [1,2,3].forEach(...

One of these things is not like the other. I hire people that know javascript, not ones that only know the tool we use. The tool we use today may not be the tool we use 6 months from now. I've never asked a javascript question that required framework knowledge unless it was explicitly about concepts of the framework. Someone taking the time to include jQuery is instantly out the door. Walking through people's code demonstrates whether or not they default to other people's solutions than their own.

This isn't to say your experience didn't happen, I'm just pointing out that there is a lot more that goes into it than just which framework the cool kids are using nowadays.

@cloverich I think this comment is showing exactly how the author of the article wasn't exaggerating

I don't follow. Are you saying _I_ demonstrate why the article isn't exaggerating, or that some of the people I've interviewed are?

I am saying that you demonstrate why the article wasnt exaggerating. Cloverich stated that using jQuery was fine and the article was exaggerating how far it has fallen out of favor, but you have stated that anyone using jQuery is out the door when interviewing with you. Therefore theres at least a group of people that article is accurately describing

> Cloverich stated that using jQuery was fine and the article was exaggerating how far it has fallen out of favor, but you have stated that anyone using jQuery is out the door when interviewing with you

That isn't what I said in the slightest. My criticism had nothing to do with jQuery. Go back and replace jQuery with underscore, lodash, ramda... I'm not saying that I would turn away a jQuery developer when interviewing for an angular position. I said that a negative defaulting to a framework/library to solve a vanilla problem is a problem in and of itself. "One of these things is not like the other" is the native Array.prototype.forEach(). It's literally built into the language, and the person added a script tag to include an 85kb file just to run a loop over 3 elements. THAT'S the problem.

> Go back and replace jQuery with underscore, lodash, ramda... It's literally built into the language, and the person added a script tag to include an 85kb file just to run a loop over 3 elements. THAT'S the problem.

Well, jQuery in particular is somewhat of an exception. It achieved such a high level of ubiquity, and solved such a vast array of cross browser issues, it was not unreasonable for a front-end dev to add jQuery as the first step in any project. Similarly, while its "literally built into the language" that's only true in cases where you can drop IE8 support. I would personally be very surprised if there weren't still more quality developers who knew the jQuery or underscore api's better than the native javascript ones.

I think the more general sentiment here is: If you use map / reduce / forEach / etc with jQuery / underscore very well, you can very easily transition into dropping or changing those libraries. But your comment made it sound like you were less interested in how well they could code and more interested in which API's they knew (and knocking them for defaulting to the most widely known ones).

To add onto this, this was not an attack or criticism against your methods lloyd-christmas. This was more the fact that I was pointing out that the front end dev world is so fragmented that almost any view point is something you'll come across while interviewing. Your point that this is a simple task to solve without a library is a valid one, but you'd also be as likely to find a team who expects you to default to a library because any non trivial project would require it. The main problem that I think is at the heart of this conversation is that the expectations of what you know and how you work is far too fragmented for most people to keep up with

I have to say, this strikes me as an odd way of filtering out bad developers. jQuery is a time-saving library.

It seems like you're presuming that they must lack proficiency in the DOM if they're choosing to use jQuery. Perhaps you're trying to say you want to see them demonstrate that they're not just copy/paste coders.

Given your code example above, I wouldn't want a candidate to know the difference between each `forEach` method, but I would expect them to know that each provides a means of iterating over a set of values.

> I have to say, this strikes me as an odd way of filtering out bad developers.

I don't use this in my interviews, and I'm surprised everyone took this literally given that we have a weekly blog article about the villainy of technical interviews and how they destroy the very fabric of software development. I'm using a hyperbolic example to demonstrate what I perceive as a negative trait; A reach for unnecessary tooling to solve simple problems. My hiring experiences have pointed towards it being indicative of a comfortable one-trick-pony.

> Given your code example above, I wouldn't want a candidate to know the difference between each `forEach` method, but I would expect them to know that each provides a means of iterating over a set of values.

Likewise. However, if I'm hiring someone for a back end role, I'd expect them to be able to know basic SQL and not just their language's ORM. I'd expect them to be able to type `cd` and not just navigate through their IDE. I don't think there is anything different between that and the relationship of jQuery/angular and vanilla js. jQuery isn't written in jQuery. Debugging rarely stops at the script tag/require statement.

My original comment was actually in the opposite direction: the interviewers were looking for comfort with a framework other than jQuery that showed that I knew more than vanilla JS. That was the frustrating part.

> Interview question: "iterate over an array":

  for(let thing of things) {...}

forEach only obfuscates the imperative nature of your loop.

Good, but that's more modern

for in, on the other hand is wrong

https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...

https://stackoverflow.com/questions/500504/why-is-using-for-...

> Walking through people's code demonstrates whether or not they default to other people's solutions than their own.

Sorry, what does this even mean? When we consider it bad to use an external solution we call it Introducing Unnecessary Dependencies, when we consider it good to use an external solution we call it Not Reinventing The Wheel.

What you're doing here is fetishizing some arbitrary knowledge that you've set up as a litmus test. I've hired probably close to a hundred engineers by this point in my career, and I have to say, unless you are hiring for specialists to fill a very specific purpose, the only test that matters is Joel Spolsky's smart-and-gets-things-done test. There are plenty of web developers out there who only ever used jQuery and thus never learned javascript properly—that says nothing about their talent. There is a good portion of them who, upon being told, "we don't use jQuery here, just raw javascript" will learn and be better at it than you in a couple months. Even more importantly, any good engineer is going to have a lot experience which you don't have, and which to you is an unknown unknown. The best team is made up of diverse backgrounds and experience, not a bunch of people who managed to pass through a series of arbitrary knowledge gates.

> I've been to more than one interview where I defaulted to jQuery and was immediately disqualified

Was the role more biased to front end development? Speaking as someone who has been on the other side of the interviewing table, you won't believe the number of people who can use jQuery but are otherwise unfamiliar with vanilla Javascript. I suspect the question itself could have been solved by via plain JS, and you did the equivalent of $('#id') instead of document.getElementByID('id')

Oh I'm sure that's not what they mean. 100% sure

While knowing how to use vanilla js is important, nobody uses getElementByID anymore, unless you're doing something very, very simple (or building a library yourself)

You sound like the article

> Was the role more biased to front end development?

These were Rails positions, which in my experience almost always equates to the same skillset expectations as a front-end engineer.

That probably depends. If the company is really small then you may end up doing quite some frontend work but there can still be significant backend logic going on in Rails.

As was said earlier, finding the right tool is essential. jQuery can still be used if the problem you are solving is limited and confined in scope. We had a website where angular is almost everywhere, we created a new page where there is just a list of check boxes, and another dev did that with Backend code. I just added a small jQuery event listener as the page needed nothing more than to disable a certain set of buttons when one from a set is selected. I could have re-written the entire stuff making angular get the model from server and then using angular in the view. But no, it was just not worth it. If you see that your jQuery component is building up (adding more functionality) then it gets messy/spaghetti etc. But if the interviewer straight away dismissed you at the sound of jQuery you are better off not working there.

> using plain old javascript and HTML is fine.

It's fine if it's a single-person's decision. If two or more people are involved in any sort of standardization process, you're going to go back and forth until you land on the most complicated possible approach like in the article.

that depends a lot on how well they can work together. This is also where good team leaders add a lot of their value.

This is where OP lost me as well. "Oh my god no, no one uses jQuery anymore. You should try learning React, it’s 2016."

The appropriate response is "Yeah, your problem seems simple enough. jQuery should do just fine."

But that article would be boring and not on the front page of HN.

> "Oh my god no, no one uses jQuery anymore..."

I've been told that within the last month, almost in those exact words, here on HN.

I asked what one should use instead and the answer was React. It felt like one of those "no one goes there anymore, it's too crowded" kind of moments.

The official react tutorial uses jquery for $.ajax[1].

I'm really not well versed in any of these technologies (but came up with a fun personal project that might end up using them) so I'm assuming that using both together is tame, and that the venn diagram for the two projects doesn't overlap too much.

[1]: https://facebook.github.io/react/docs/tutorial.html

Effectively React replaces (in many cases, simplifying) the base DOM manipulation aspects of jQuery -- but of course it does not replace the other useful utilities jQuery provides, nor the many DOM manipulation plugins in the jQuery community. When I first started with React I was able to use those libraries without issue -- you do have to learn how (when) React allows you to access the DOM and when it expects you to clean it up but for an experienced dev, its a short learning curve. Over time, I've seen many libraries similar to those jQuery plugins arise (or transition) into React components and its been fine to slowly phase in / out as I please. Lastly, its been mostly straight forward to encapsulate jQuery (or other) DOM manipulation libs within a React component, such that consumers need not even know its being used internally.

After a local tech demo with some CSS3 stuff included, I was amazed by how much could be left out of javascript entirely. My goal with my next project is to learn when to use React vs. jQuery vs. CSS3 for various events that will occur on screen.

I'm excited about it, and I appreciate your explanation. I've never been a front end guy (all devops/scripts and some crud type stuff), so this helps me greatly.

I'm lead to believe that either jquery isn't useful for dealing with virtual DOMs, or that it does screwy things when working together with a virtual DOM system (like react) or both.

I've also heard claims that React's theory of slow DOMs is wrong. Which doesn't make it a 'bad' framework to make use of, just optimized on the wrong thing. I haven't had time to suss this out. I spend a lot of time in "good enough for now" mode because I'm not a dedicated front-end person.

"I want to study oncology" - On the biological side? Go learn biology. On the ML research side? Go learn basic python syntax before trying to train a neural network.

I usually see 3 categories:

- I want to learn Web Development.

- I want to learn Web Development, but in all actuality I'm going to quit in 3 days.

- I want to learn Web Development, but in all actuality I just want something working with no effort.

None of these need an informed decision. The latter 2 don't matter anyway, and the first one is better off starting with a vanilla ajax request[0], and they likely know it. When it comes down to it, "I'm going to make an app today" means your decision likely doesn't have long-term consequences and an informed decision isn't all that important. Pick up jquery like the other 80% of the living internet[1].

[0] https://webdesign.tutsplus.com/tutorials/an-example-of-ajax-...

[1] http://trends.builtwith.com/javascript/jQuery

This is kind of a cop-out, but I am constantly surprising coworkers with the (I thought simple!) things that I do with relatively old-school JS. I think if you're just starting out on a project -- any project, any skill level -- then your biggest obstacle is your own inertia, your tendency to evaluate options for how you might solve the problem, rather than just plunging right in and saying "I am going to code something, it may not be the right thing, but I am going to try to write this little function which does this little thing." (I once heard some conference speaker say something to the effect of "I found it very hard to floss until my dentist said 'hey, if you don't have time to floss between all of your teeth, please still try to floss just one.' Suddenly I'm at the mirror like, 'I don't wanna take that time to floss all my teeth... oh well, I'll floss just one to make my dentist happy... oh, and I might as well do another, and another..."). The hardest thing is to get started, which paradoxically can begin just about anywhere you want. You just have to choose something and do it. So a lot of this "what framework am I going to learn and use?" stuff gets in the way of this and slows you down from tackling this hardest-problem-that-should-be-a-non-issue. Just start with low-level JS and begin building, then let your pain in doing so guide your further choices.

Because low-level JS sucks, of course. It sucks that the DOM specifies that each node in HTML has a property .childNodes but the object that resides in that property is not an array with a .forEach() method so you find yourself either doing `Array.prototype.slice.call(x.childNodes, 0)` (in ES5, for compatibility), or `[... x.childNodes]` (in ES6 because it's prettier and more obvious what you're going for). And it sucks that HTML tables don't come with any built-in sorting mechanisms, and it sucks to be dealing with XMLHttpRequests directly. That's why these frameworks build on top of those things.

But I really think that if you're starting out, you should start out with this sucky stuff and then choose your framework based on what you learn about your pain points, rather than the other way around. If you find yourself needing to support older browsers then you will learn these cross-compilation tools; if you find yourself eventually turning it into a RESTful API written Node.js then you'll probably be OK with just ES6. Or if you find yourself writing similar sortable table widgets for the third time, you start googling "has some framework already solved this stuff?" and you eventually stumble upon the search "grid component" which will get you checking out either Vue.js, React (though you'll quickly realize that it's not native to React, there are several options there), and Ext.js, all of which have fine grid components that you might start using. Now you're doing a short research project to incorporate those things into your present workflow, which is much better than doing a long research project to decide which one of these things will be your Firm Foundation For All Things To Be Built Here.

The other huge thing about knowing plain JS is that you can start by messing with other peoples' web sites; just Ctrl-Shift-J on whatever page you happen to be on, "how would I add a little button that would replace all instances of the name 'Paul Graham' on this comments thread with the phrase 'my little pony'...? I think it would be hilarious if all these techies were talking about ponies instead."

100% agree with the point "start out with this sucky stuff and then choose your framework based on what you learn about your pain points, rather than the other way around."

For Javascript I'd start from a project template (e.g. https://github.com/sahat/hackathon-starter). This approach teaches you learn some useful defaults and how the pieces fit together, as well as where the defaults break down.

I've found that settling on a fairly narrow set of tools that will cover most use cases is a good start. "Best tools for the job" is not a good advice in the JS app development... Rather, "Good-enough tools for most situation" has been what I've been telling myself. (The caveat is that I am the only developer in this case, or I am in a position to determine the technology stack for the rest of the team.)

Personal anecdote: I chose React as a starting point as its component model and lifecycle API just clicked better with my mind. I tried Angular 1.x and, while I liked that it defined application structure more, I couldn't motivate myself to study its component model and lifecycle. Things might have changed since Angular 2.x, but I don't want to go through a technology churn again trying it out. Then I noticed React Native plus other spinoffs like React Native for Desktop. Those projects seem fairly active and appeared to be offering mostly consistent APIs (React, JSX) for a somewhat narrower but still large set of use cases for cross-platform application development. So at that point, I decided to freeze the searches and build out the rest of the choice around it, partly based on the React community's support of the libraries and tools (Redux, Webpack, etc.)

I do catch myself getting distracted here and there checking out other libraries and tools, and they might genuinely be superior in the context of an objective, head-to-head comparison. But having built up some familiarity and skills using the current choices, I can't justify the time and attention span lost switching to another set of libraries. Afterall, by then, something even better will have come along. :)

EDIT: I wanted to just add, "The fewer APIs I have to look up in the docs to use, the better" also has been a guiding principle as well. For example, I just use Webpack for build as well as bundling, as I don't want another API in the project for the builds (like Gulp, even though devs seems to like it).

A good place to start is by writing productive code. As part of the development process, look back on what parts of the code are holding you back the most. Perhaps bugs keep appearing in this dialogue, or that list renders very slowly, or setting up the unit tests takes a lot of boilerplate. Something on the project will be impacting your delivery the most. Work out what it is if it isn't already obvious, then fix it. You might do this by using a pre-existing library, or you might write your own solution.

Either way, by going through the problem solving process, you will develop some of the skills needed to recognise the motivation behind the solutions provided by 3rd party libraries and you will be in a better position to evaluate them.

When I had no experience I was asked to define the next few years for my company's single page app.

I researched all the major tools and committed to django, react, fluxxor, leaflet. As the major parts. All but leaflet (now OpenLayers) are still around and growing well.

The most important thing is that I got to pick which tools felt most resilient to rapid development and lots of rookie mistakes. Even if they may have been overkill or not ideal or some thing I cant possibly know as a newcomer.

In the past I did chase the dream of the one toolset to end them all and it had me never committing for any meaningful duration.

I think that someone coming to the field cold is going to be sucked into the vortex of enthusiasm surrounding one or more frameworks and, eventually either become a die-hard fan of some specific stack or jaded by the phenomenon.

I'm a member of the second group since, like 1995.

Right now we're on the nth cycle of lemming like enthusiasm which is currently favoring React because it just tried Angular two years ago and writing a new site with React sounds a whole lot more awesome than fixing the incomprehensible pile of crap you wrote in Angular which, guess what, seemed like a great idea at the time because of the mess you made with jquery UI.

You sound like you have not often worked with legacy code or software architecture teams who choose the "right" tools for you. In large companies you rarely choose the tools you use.

Also, when you feel that you need to learn technologies simply to avoid using them something is very, very wrong. I think that is sort of the point of the article.

In my experience, it's not the developers who fall into this trap, it's the culture--nobody wants to learn some random technology that will probably be obsolete in a year (and I'm not even joking when I say this, this really is the reality)

The only situation where you are not affected is if you're a freelancer and you don't need to worry about what's going on around you.

I'm not going to mention where, but I worked at a well known company which you've heard of (you probably would know it as an innovative company), and everyone who worked there was very talented, there is absolutely no doubt about that. But I got sick of what's happening around me and quit recently.

Here's what happened: In the last couple of years a few people started talking about all this "cool new javascript testing/packaging/templating/single page app building" frameworks. Since it is indeed a "cool thing" to talk about these, and since they believe that potential new hires would be excited to learn that we use these hip new technologies to power our company, they started implementing EVERYTHING that the OP mentioned in the article. Of course, I'm sure it looks really cool from a recently graduated college kid's point of view when they interview. But anyway, suddenly the company culture started revolving around these hip technology advocates. I can understand why but at the same time it's really stupid because they keep switching out their stack and spend their money on useless crap instead of actually spending it on building the actual product. For example, they've transitioned from browserify to grunt to webpack in just last two years.

So when I read this article I totally sympathized with the guy.

If you're a web developer who works at a large company that wants to be seen as "innovative" (especially the ones that are already seen as being technically innovative), this is exactly what's going on. And you only have two choices: You either jump on the bandwagon and become one of the "in" crowd, or complain like the rest and be left behind and seen as a "laggard". When I saw these otherwise intelligent programmers moving like bunch of lemmings to adopt the latest new technology I couldn't help but feel pity for them. They grow old day by day thinking they're becoming a better programmer but all they're doing is learning some library that's designed so that the code monkeys can be managed better. They should be spending less time on those meta things and spend more time on building what a user wants instead. At least that's why I became a programmer.

This is very true and cool shiny new things are hard to counter, mostly because ones instinct is to point out the deficiency in the "innovation", which is often only obvious to you.

The best way I've found to counter this is to give your own demonstration showing how you achieved the same (or better) coolness with existing technology, and you did it faster, and it can be integrated into the code base today.

This gives your argument real substance and people have to at least now argue against facts and data rather than hand-wavy speculation.

I'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.

I'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't constrict a developer if you dont have to. Even for a simple app that it'd take me 20 - 30 hours for me to create in basic jQuery, bootstrap and simple PHP/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've gotta do artisan commands, migrations, grunt commands etc etc etc.

Anyway, i tell myself that what their doing is a better way of doing things and i'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.

I still feel like a bad coder because i'm not doing it their way. :(

> I still feel like a bad coder because i'm not doing it their way. :(

Well, in some ways yes. But experience has a value

Today people use an Arduino to flash a led, "in my time" it could be done with 2 transistors (you can do it with one + one "funny" component I guess - like a transformer)

The point of flashing an LED with an Arduino is not to flash the LED, it's to get the tools setup and workflow working while learning the basics. It's the "hello world" of microcontroller programming.

I've heard this process called "flow flushing". With things like FPGAs it can take days to go from nothing to flashing an LED. Because the toolchain is large, complicated and opaque.

It sounds like the Javascript world have built large toolchains for large projects and have then cargo-culted into using the same toolchains for tiny projects when they don't have to.

"Pipecleaning" is another term I've heard for that "get the tool workflow sorted" step, I think.

i am have programming in js for decade, these days i go with react unless the item requires few lines then its jquery.

Even for a simple app that it'd take me 20 - 30 hours

If your entire job is doing small apps that take a week of work, these tools are not much better than the previous generation (personally I'd use Rails but that's just one generation on from PHP/MySQL). Especially when you add in the cost of non uniformity if you let everyone choose their own slightly different flavour of the innumerable javascript tools available.

But as part of a team that has migrated a 5 year old codebase from Rails to React in the last year, whilst I was skeptical at first, React has been an absolute godsend. Everything we build now is so much more modular and much closer to how non tech people view our website (and so how they ask for features), which makes it easier to develop. React isn't designed to help "I need to build this 20 hour website quicker".

I think the problem is mostly cargo culting. Smart and outspoken developers use these tools, but they're also the ones dealing with complex problems at their jobs, not everybody needs to solve the problems they are solving. And "Honestly Rails is good enough for this app" doesn't make for a very sexy meetup presentation.

Sorry, I'm confused: what do you mean by "migrated a 5 year old codebase from Rails to React"? What are you using as your backend?

Just one of the many ways that modern Javascript baffles me - people pretend the client and server are equivalent.

You can still render placeholders from the server and fill these in with React

The more technical details you include the more people pick up and discuss minute technical details instead of the point of what I was trying to say, which is that my experience with a large codebase was these modern javascript tools have solved a lot of problems we had.

If you want all the gory details here they are: it was a Rails 3 app using Postgres and Elasticsearch that we migrated to React + node.js + webpack + babel, elastic search as the data store and using Keystone.js for backend data manipulation (which uses mongodb). Rails was indexing its data in Elasticsearch already so we could start serving data through node.js immediately without having to migrate all the data backend, which is being slowly moved to keystone.js.

Maybe they hardcoded the data in the views. Might be the cool way to do it soon enough.

Sorry I should have clarified. React + node.js. We need the option of HTML being sent to clients so React + Rails wasn't an option

> migrated a 5 year old codebase from Rails to React

This statement doesn't make sense to me, and is one of the points of the article. React is a view layer. That's it. So you wouldn't migrate from Rails to React. You'd migrate Rails to React + Relay + Webpack + etc. On top of all of that you then have to decide if you're sticking with Rails for your API or if you're switching over your entire back end as well. The decision debt is just insane, and given how often these things change, that debt never goes away.

It makes sense to me. The previous generations had pages that had more rendering on the server and "forms." Now, it's single page applications hitting REST end points.

So before, you had complex models, tightly bound back-end controllers, sending data to a view.

Now, you have simpler APIs on the server, you arrange and manage the data in the browser, getting more data as needed.

Rails is perfectly well suited to serve an API. In fact I believe it was the first to define off the shelf RESTful conventions for an entire controller and all verbs by default back ~2007 if I recall.

http://edgeguides.rubyonrails.org/api_app.html

Actually, Rails 5 implements an API mode so you can spin up a new app with only API-level conventions that runs on less memory and just serves JSON. You can add on the standard Postgres DB and Boom! "You just made Rails great again"

Right, that's what I linked to ;)

Oh, I didn't click that... Derp!

What did you you use for the backend?

> I still feel like a bad coder because i'm not doing it their way. :(

I've only been at it for about 2-3 years, and I must say, I feel this exact same way. Started on the LAMP stack in school and now I know nothing because what I know is "uncool" and outdated since MEAN and all of the encompassing JS libraries have become popular.

I caved and started to dabble in MEAN (even though I haven't perfected LAMP by a long shot yet..) and must say it is the most fun I have had while coding and setting up projects ever, however I can't help but feel it is like you say, "a frigging nightmare to maintain and deploy". Nothing seems intuitive...

>> now I know nothing because what I know is "uncool"

You want to know what's "uncool" around here for me? Wanting to markup a table with table elements, mostly for the accessibility benefits. I've never seen such an odd pushback. Tables are so "old" I'm told.

Actually, what people frown upon is using tables for layout. Using them to display actual tabular data is quite fine. (I mean, everything is fine at the end of the day as long as the end-user is happy, but you know what I mean...)

No, you don't understand. I don't want to use tables for layout, I want to use tables to display a good old-fashioned table. A table displayed in an otherwise normally marked up page. That is what's getting the pushback.

I guess I could say I want to use table elements to layout a table, which would trigger the "don't use tables for layout" argument.

So... ignore them? If you want to use a table for tabular data, then please - use a table!

If someone whines you've used a table, then ignore their whining and keep using table markup for tabular data.

Well, ignoring the situation is not a solution to this particular problem.

If it gets really bad, just mock them openly. Sure, you might not achieve your objective, but you'll have fun not getting there.

They're misunderstanding what people mean by "don't use tables". And they don't know what they're talking about.

When I was informed of it, I responded with "they are wrong". We'll see how it goes.

Is your intent for Section 508 compliance?

If the table cells have specific individual widths and heights, and contain a .gif or .jpg of equal size within them, then that is an inappropriate use of tables today.

This "no table for layout" thing is so strong that people keep insisting that I am saying table elements for layout. I am literally saying "using table elements for a table" and not "layout with a table". It is a table with tabular data in it, just plain text. It is a styled table, but a table nonetheless.

That's the normal way to do a table. Why import a dozen different libraries to render something that is HTML-included and renders in like 0 time because it's built right into the fucking browser.

But LAMP hasn't become outdated in 2-3 years. It has been steadily dating for a long time.

If your school taught you LAMP as "current" then that is the issue here.

> even though I haven't perfected LAMP by a long shot yet..

I've been doing this for 25 years, and I've felt the same way over and over - by the time I feel even a little bit comfortable with an approach, everybody else has already seemed to dip their toe in it, pronounced it unusable, and moved on to the next shiny thing, and wondered why I'm still over here banging rocks together.

> I still feel like a bad coder because i'm not doing it their way. :(

You’re doing it wrong. You’re not the one who should feel bad, they are the ones who should feel bad! You’re in the right. Try doing what I do: wave your cane around and shout at them to get off your lawn. Be sure to really drive it home by telling them the same two or three stories over and over again, about how things were back in “your day”[0] :)

In all seriousness, I sympathized with every thing you said until that very last sentence. For whatever reason, I never feel bad —— I just “know” that my way is the better way, and that their ways are just fashionable fads and will pass. If I turn out to be wrong and any of those things happens to wind up sticking, well... I’ll cross that bridge when I get there ;)

[0]: E.g., how much more vivid color was, how much brighter the day was, how much tastier the food was, how it was the Golden Age of Television, Film, Literature, Music, Journalism, and Politics, how men were men and you could tell them from boys by whether or not they had correctly implemented call-by-name argument-passing semantics in their Algol-60 compilers, and how everything was just generally better.

“What’s that? Your Web page is 32MB minified and gzipped? Back in my day, we only had 32MB of RAM total, if we were lucky, and we could still listen to mp3s and browse the Web and send snarky messages instantly to one another even then. Sure, our displays were tiny, low-resolution CRTs, and we liked it! Now get off my lawn!!”

/me listlessly stares 1000 yards past his junior developers...

sits here stunned at how perfectly you described my young adult days....

'gulp or grunt' are these actual JavaScript libraries/frameworks? Or are you referring to human bodily noises?

I'm soo 100% like You.

I've found my own stack of choice - requirejs+jade(pug)+npm scripts(to parse requirejs and ES6 with babel) just do my job - no matter if it is a front-end or mobile one.

I've also add to it Express.js if want to build something full-stack - no front-end frameworks, just jade(pug) and own way of files organization etc. Sometimes I have worse day and think that I'm behind new hyped stuff but then I realise that my way just works without any fancy setup..

in addition, I've took a look on react/ember/angular etc. but it just doesn't fit me - but at the same time I've took some principles from every of them and use it in my projects (e.g. code modularity)

> the tendency is to pull in Angular, Laravel, gulp or grunt, composer dependencies and a whole host of code for doing something really simple.

First experience with Resume Driven Development?

It's easy to show how complex those systems are. It's easy because they are complex. And that'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 (https://en.wikisource.org/wiki/I,_Pencil).

We're professionals, after all, and TypeScript and React were not build by some teenage hackers.

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's so complex now. The reason is that we started to build complex applications instead of enhancing grandma's blog using jQuery.animate, get over it.

And if a software developer talks about all of this tools in the same manner you've described, he has poor social skills, nothing related to the tooling.

He could also talk about the intricacies of scaling web services using k8s and OpenStack and you'll find another bunch of tools and concepts. If someone would actually talk like you've described it, he would play buzzword bingo in any domain of expertise like medicine students who want to sound smart using latin words.

I like how you phrased this. I have a similar feeling about this but I couldn't express it so clearly.

> We're professionals, after all, and TypeScript and React were not build by some teenage hackers.

Overall correct

> The reason is that we started to build complex applications instead of enhancing grandma's blog using jQuery.animate, get over it.

And this is where we disagree

Complexity is needed sometimes, needless complexity only brings the overall value down

If I want to do a website using Django I need to get: Django. Period.

I may need some other libraries, but they're much fewer than any basic node.js project, even with things like Flask

I have one package manager: pip. It works

With express.js you need a library to parse an HTTP request body ffs. https://github.com/expressjs/body-parser

and that's how you can use express.js to run a service that uses a different protocol to HTTP.

Express is one of the easiest libraries to learn in any programming language. It's certainly much easier to learn than Django, at least in part because it doesn't include the kitchen sink

> and that's how you can use express.js to run a service that uses a different protocol to HTTP.

Excuses, excuses. Good defaults are important. 99.99% of developers won't care about it.

Getting form data is Web development 101

> Getting form data is Web development 101

Is it? Certainly the latest hipster microservice only deals with JSON bodies.

To which you still need the body-parser module, I don't see your point

Let me try again: you might not be using Express to develop a website.

If you are, install the meta-package, or create one. Now you have your defaults.

> I have one package manager: pip. It works

Funny, because this is not the general sentiment in the Python community. See links like [1], [2], [3]. Thankfully, things are improving.

[1] http://lucumr.pocoo.org/2012/6/22/hate-hate-hate-everywhere/

[2] https://www.reddit.com/r/Python/comments/zrm3h/there_have_be...

[3] https://blog.ionelmc.ro/2015/02/24/the-problem-with-packagin...

I found Python packaging very easy. pip install works for tons of packages.

I agree to your sentiment that needless complexity is bad, technical debt is a real thing and it is plain reckless to use something for the sake of it.

But the term "complexity" gets used in two different meanings in your comment:

a) complexity of usage: You make the point that Django is easy to use, but it isn't simple software; it contains an ORM and is huge.

b) complexity of the system: Django is a complex system. If you are not using any of its benefits, it has needless complexity and you may be better off with a simple PHP script.

And this brings me to the conclusion that it's all about your use case. If you don't build a big SPA, you can get away with vanilla JS without using a transpiler or even a build pipeline.

The reason it's simple to develop something with a full-fledged framework like Django is that they have build a complex system to abstract all those complexities you don't have to think about anymore.

And I don't get your argument in regards to express.js because this is entirely a software architecture decision and they decided that a modular approach suits them well - maybe it's actually less complex for them to develop the software that way because they isolated the body-parser and other components. It's like comparing monolithic with micro kernels - it's all about trade-offs and the added complexity from a developers' point of view may be worth it for the specific use case. There is no general definition of "needless complexity", because the need is very subjective and different for each project.

Exactly.

When I read those comments on HN, I'm really curious to know how people think you can build, scale and maintain a web app like Facebook. Do they think you can achieve it like in 2006, with a single scrip.js containing 100 000 lines of jQuery soup?

jQuery is fine for any web site or small web apps, but as soon as you reach the 2000 LOC, it's crazy to continue with it.

You don't need complex tools to build complex systems.

The rapid pace of change in the javascript world is what he's poking fun at.

> We're professionals, after all, and TypeScript and React were not build by some teenage hackers.

On the other hand, Babel was :) He did a great writeup of his life during babel's explosion of popularity.

https://medium.com/@sebmck/2015-in-review-51ac7035e272#.nmef...

Thanks for the link, his story is great! I'm convinced that compilers and formal languages are the core fundamentals of computer science, amazing that he got into it so young.

Thanks for the link, great story.

Compiling a C project from sources for the first time (which was maybe five years ago and had a bunch of dependencies too) took me less time than it's currently taking me to read up on an overview of all these frameworks/libraries/technologies, let alone actually learn any of them.

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'll get a lot of different opinions if you go searching for them, so here are mine.

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.

For maximum browser support you need a transpiler, this would be a matter of preference because it isn't for you, it'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.

Once you have that setup, you really don't need anything else. You don't need jQuery unless you're trying to support IE8, which is a tiny proportion of the browser market and that will gum up your code significantly.

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're trying to learn JavaScript.

If you want the full-stack experience, Node.js is rapidly becoming the largest JavaScript community on the net. You'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.

There you go. State of the art front end JavaScript with two tools. Full stack with five. If it wasn't for the whirlwind massive chaos of the JavaScript community currently, fewer new developers would feel discouraged from becoming involved.

> React is very popular but it suits one very specific use case, it should be used almost nowhere else.

Which use case?

I've never worked with React but from yesterday's stateofjs.com I got the impression it's currently the go-to framework for everything.

It gives you components. If your webpage is loaded and significantly complex with a need for different things all over the place then it's for you. It was built for Facebook, which has stuff everywhere on every page.

If all you want is a normal webpage, like a blog, like all of the websites out there I'd say you do not need components. Just build your own object. That is a lot of stuff just to do something that has been done for decades without it, battle tested so to say. Another one of the problems with the JavaScript community currently is the number of people who treat their favourite tool like a religious experience.

React is a large hammer being used quite often to close a twist tie. The ecosystem of tools which have sprung up around it is far worse than React itself. Each one a larger amount of overkill than the last.

I'm sorry, but once you feel comfortable using React there are very few things that React would not be a good fit for, however small the task.

I started coding in JavaScript two years ago, right at the point React was gaining popularity. I made a gamble going for it 100%, and since then both the company I was working at back then and the one I started working at recently have fully switched to React for all new front-end development after seeing how much easier it is than anything they'd ever used before (jQuery, self-rolled prototype-based things, Backbone, Angular 1, Ember).

Yes, sure, you have to get the basics set up every time, and yes, sure you have to package React on every page. But as a gigantic win, you get a uniform way of dealing with the DOM every single time. React has well-defined best practices by now. When every Javascript coder in your workplace is familiar with React, it's usually best for you and for them to simply continue coding in React.

I feel that you are marginalising the amount of complexity you are adding to projects which might not need it. There are multiple routes toward completing the same task in development. My concerns surrounding additional complexity I feel are well founded, there are costs associated with such a thing.

If all you are doing is DOM manipulation, without doing a huge amount of it, that isn't such a complex task that it should require an entire framework. If you're doing more than that it outscopes what React can do.

That's just it. If all your developers are familiar with at least the basics of React and Webpack, you aren't adding any complexity. Once you know how things work, a simple Webpack configuration with Babel and 2 presets isn't complex anymore.

What would be complex, however, is introducing DOM logic in yet another way. We're all used how you just define the desired state in React and letting it figure out the transitions. When you suddenly ask your developers to write code that manually manipulates the DOM and has to take care of all the transitions between states, you end up with complex, unclear code that takes everyone a long time to understand.

React in itself is simple, but familiar with and comfortable with the complexity of Webpack is another story ;)

Ok, I guess Webpack isn't too complex, but its weird syntax (the whole right to left chaining) and poor documentation can be a barrier.

Webpack alone requires hundreds of dependencies. You are populating your node_modules directory with megabytes of code, any of which could stop working. If you plan to maintain your code for years into infinity then it's no problem. Otherwise the shop down the street doing the same thing without it will be much better off.

> the amount of complexity you are adding to projects which might not need it

If 80% of your projects are written in X, it's probably simpler to just use X for everything, even things that don't need it

> Which use case?

If you're building Facebook.

Come on, your response is pretty shallow, don't you think? Or do you genuinely believe a Facebook-like application is the only one that could benefit from organizing into modular, reusable components?

This is a very good reply. Someone trying to grab a foothold in front end development should keep it simple and add tools as they require them (if applicable). I used to develop for the web until I found iOS development to be more enjoyable because of the feeling of stability of the SDK. When I did do it, I got to the point where I said, fuck all this noise and just give me Nodejs/npm, MongoDB and raw JavaScript...

Right or wrong it felt like enough at the time. Just adding Angular felt dirty. Damn, I feel for you guys.

I have no trouble at all "keeping up" with the "insanity" that is front-end development. If you're confused learning new things, it means you're learning.

At my company, we have moved a lot of our front-end code to eslint-checked ES6 with some plugins, writing react/redux powered interfaces. New hires generally learn the codebase fast, you'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.

If you're building a hobby project, just start with a <html> tag with inline ES5 and css, and refactor and iterate from there. Use server-side templates. "keep it simple". But when building client-side interfaces at a higher complexity level, React is king.

My main problem is the speed, and bad backwards compatability. Generally speaking if I take a 2 year old C,C++ or Java project, I can be sure I can update to recent libraries and everything will just work with minimal fixes.

In Javascript it seems every time I pick a project up from a couple of years ago, every library version I was using is past end-of-life, and updating requires a major rewrite.

>I have no trouble at all "keeping up" with the "insanity" that is front-end development. If you're confused learning new things, it means you're learning.

This naive view though assumes that all learning and all stuff to learn is created equal and is all good.

That is, that the IT industry can't possibly produce junk for people to learn ("busywork", programming fads, over engineered platforms, oversold technologies, etc).

People who have been through the J2EE-hell of mid-noughties, which even its creators condemned and abandoned several years later, but which at the time was touted as "THE WAY" to build enterprise software, and you just had to "man up" and learn it, respectfully disagree.

I've recently decided that I'm using React for the next 3 years before I consider switching to something new.

JavaScript is a very special language, I think.

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.

It was nerver meant to build big applications and had a few issues that many people tried to assert.

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.

The whole "we want new stuff now" 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's super fashionable to hate on javascript, but I'd be very interested to see a similar rant on another area of software. I'm pretty convinced this is just how the industry works.

It's considerably worse in Javascript.

This is because:

+ HTML/Dom limitations + Browser fragmentation + It's used on the backend as well + Nobody is in charge. When someone is in charge, they usually provide the basic tooling and libs - hopefully they do it well - and then you only need ancilliary stuff for special projects. Obviously this can have drawbacks as well, but I'd argue that 2/3 of frameworks are actually trying to solve the same, core problems, just in different ways. They aren't providing 'more' just 'different'.

The same kind of rant applies to things like automake, but only Javascript has this incredibly high rate of churn. Possibly it's easier to build a new toolchain than to understand someone's existing one.

That's been my annoyance too. Instead of iterating on what's there everyone makes their own thing and tries to reinvent build tools, frameworks, web components, module loaders, transpilers, package mangers etc... It is improving somewhat. Some tools seem to be winning out and clearing the orbit around them but were still in the primeval js solar system with a few planets forming.

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 "Isn’t it remarkable that the computer can be programmed to draw like that?" instead of "My, what interesting data".

- Edward Tufte

People writing these kind of articles are really not looking at their current stack objectively.

If I'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.

Remember when Maven picked up, the bitchfests that surrounded it?

And debugging a server side app in production by picking at memory dumps, profilers, etc? Its not exactly easy.

The difference is that those problems are understood, and everyone knows the barrier for entry is higher.

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.

A good example of that problem is all of the big companies and startups hiring "full stack" engineers, which is code name for "pure backend engineer who has 10+ years of experience doing backend...and has heard of HTML".

Of course, that kind of people won't go far.

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

There's still quite a lot of people doing Angular 1.x though, so at least the train isn't that fast.

I sorta agree with you. I personally like JS and really like Node. Node can actually be pretty simple and fun to mess around with and experiment. I know HN likes to hate on it, but I have fun with it.

Frontend apps always end up seeming like a mess to me especially when suing the latest "best practices" for "maintainability" (ironic as most web apps are abandoned after a couple of years). Unfortunately JS being the only language I'm productive in sorta means I'll be doing some sort of frontend for a while.

And the best is, if you have a fundamental understanding of plain, vanilla javascript all these new frameworks are pretty easy to pick up. I went from jQuery -> Angular 1.x -> Ember 1.6 -> Ember 2.0 -> React and Redux in basically no time. It really wasn't that hard.

Hah, I just posted elsewhere this exact sentiment. My first "framework" was Javascript. Every new fancy thing that comes along is just more Javascript to me.

There's some truth to that.

My own experience was in writing a lot of vanilla JS, being pretty happy with it, and then wanting to grow bigger I investigated some of the frameworks. At the time, Angular 1.x was considered the thing, so I implemented a project in that (multiple drag and drop lists, items from lists into other lists, and so on), and tried to follow best practices as far as I could tell. DRY, decoupling, etc. It was pretty horrendous. I ended up with so many different services, service providers, components, dependency injectors, and all kinds of (to me) really quite complex abstract boilerplate that had nothing to do with the actual business problems.

I eventually got it all working, and thought I was doing pretty good. I then took a break from that project and came back to it 2 months later, and couldn't make head nor tail of it. So many angular-specific concepts and terminologies.

I've since come across mithril.js, and found it (for me) perfect. It's designed to let you build stuff really fast, and modularise things around your business logic, rather than have the whole of you application design enforced from the framework. Leo's blog posts https://lhorie.github.io/mithril-blog/ are fantastic, and I think made me understand a lot more of javascript itself, and how to design applications in much more 'well designed, but not framework specific' ways.

I wouldn't pick on the COBOL programmers too much – they've had a half a century of decent jobs, after all.

The lesson I'd draw from that is that you want to avoid siloing yourself. Most of those COBOL developers worked on the same kind of systems, often in the same place, for long periods of time. That kind of deep specialization is useful but also dangerous to you in direct relation to where that larger field is going.

In the web space, this is complicated by the somewhat unusual browser environment: in 5 years, you will always be glad that you spent time understanding the DOM, ES2016 and later, modern CSS, how to debug in every browser, etc. because ultimately everything is built on top of them.

You may or may not benefit from having spent time learning the framework of the day and that will be in direct relation to how much of that time was spent understanding broader concepts and styles versus dealing with idiosyncrasies and technical debt in the code-base. That's especially true for things like build tools which are easily replaced without visible changes to a project – they're useful and to be appreciated, but they're more overhead than part of your value as a developer.

There are still COBOL jobs too. Where I'm at Fortran is still pretty popular. Hell, I just wrote an internal app to communicate with a Vax!

Surely you can learn enough about this stuff in 4 weeks of full-time unemployment to pass an interview.

The good news is that the person hiring you doesn't know what any of this stuff means either. So just read a couple medium articles and fake it, man.

HN (and perhaps SV) might be a bit of an echo chamber that doesn't reflect industry overall.

In most decently sized cities, there seem to be plenty of development jobs available that make heavy use of solid software engineering and architecture using reliable, proven technology.

It's only anecdotal, but I know plenty of developers working for banks, manufacturers, and government who enjoy their jobs and get to solve problems that are interesting and challenging from both business and technical perspectives. They're not using outdated technology, either. The perception here sometimes seems to be that Java and .NET are slow moving dinosaurs, but they're both evolving, and organizations that from the outside seem stuffy and boring actually aren't afraid to keep up with the changes.

Interestingly, the devs I know at these companies also seem to enjoy a much higher status among their non-dev coworkers than devs at many startups and software product companies. I'm not sure why it has worked out this way, but it seems that in businesses where software isn't the end product, it's often easier for developers to be seen as trusted solvers of business problems rather than assembly line workers who are just stitching together raw materials to reify someone else's visions and ideas.

Before I digress too much, I'll circle back around to my point: it's still very possible to ignore the current front end development circus and enjoy a good career as a developer without the risk of turning yourself into an out of date dinosaur.

I'm also not implying that the worldview on HN is wrong, or that startups are bad, or that the current JS ecosystem is the worst thing ever. I'm just trying to remind everyone that there's a pretty big world out there where development skills are in demand, and a huge portion of that work doesn't involve front end work at all! It's even better if you're a developer who understands business (or is willing to learn). If you're a developer at a non-tech company, your ability to quickly create software that solve business problems can make you seem like a magician.

As goes the software world, the majority of these "applications" won't exist in 5 years.

Conversely, for those that do still exist, the new developers can simply bash the old technology stack and code and demand to rewrite in the new flavor of the week anyway.

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

I dunno I think they are on par as far as toolchain goes. autotools, cmake etc.. are no worse or better than gulp, webpack etc...

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/or make, shell, versions to make one line of JS change. And I sincerely hope it gets better. I want to develop web sometimes, but every time I approach a new code base, I feel like I am starting from ground zero.

Very accurate

And if you go for X instead of Y you're obviously a non-hipster loser that hasn't been up to this week's fad

The later part of your point is salient: the weird hipster 'magpie' culture in front-end programming has a lot of drawbacks.

The part I find funny is considering how often the "latest great thing" changes so quickly is that it shows a decent developer can shift to another thing in the ecosystem quickly. Making the "if you aren't using Brand X, then you're behind" attitude seem kind of silly. Considering the response can easily be "give me a few hours and I'll be using Brand X". I've shifted through a dozen or so "latest thing" in my career without much trouble at all.

As these rehashed JavaScript versions of http://harmful.cat-v.org/software/xml/soap/simple are on front page of Hacker News every other day, I can't even begin to imagine what kinds of rants we will see in the next 15 years or so.

"How it feels like to learn Machine Learning in 2025" (9 years from now, 671 upvotes, 158 comments)

In defense of JavaScript, there is an article that appeared here not long ago:

http://mrmrs.io/writing/2015/07/27/too-many-tools/

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.

Eventually winners will emerge and the losers will die out. Give it a few more years and it will stabilize.

I'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.

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've missed key requirements early in the process. This means you will likely need to refactor, rearrange, add/remove features, etc. Choose tools that make this inevitable process as quick and painless as possible. For me that's the number one goal.

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.

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'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.

If you are developing a web app, restrict JS to the client side only, get something like react to do it.

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.

tldr; JS for front-end. Go for back-end.

And that's way I feel much more comfortable in Dart ecosystem:

- sane SDK and sane - not surprising - lang without this hell

- jquery like functionality built in

- one package manager and package repository

- can be used on server as well

- nice tooling (WebStorm-IntelliJ, VisualStudio Code)

Would have preferred that Google had put their resources behind something like GopherJS instead of yet another C#/Java-like, feature-creep prone language.

their reasoning was AFAIK - lang needs to be C#, Java like to reach mainstream web devs

Funny, but it's not quite that complex.

How about "Here's a link to a CLI utility or git repo which will give you a working project in 2-3 hours"?

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.

I'm using React/Redux/Sagas/Webpack/etc. for the client, and Express (with ES6 and what have you) for the API.

Developing with these new technologies has been a delight, especially compared to hacking bits of jQuery together.

Sure I'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.

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.

Otherwise you can learn React in a few hours. What's the big deal?

Funny, but it's not quite that complex.

I'm using React/Redux/Sagas/Webpack/etc. for the client, and Express (with ES6 and what have you)

Funny, but that sounds like the very definition of complex.

I particularly love the "etc." and "what have you" because your stack is so complex you can't even be bothered to type them all out.

I don't see it as too different from "I'm using Rails, ActiveRecord, Sprockets, Ruby 2, CoffeeScript, etc".

Which stack do you prefer to use?

Why would you need to say you're using ActiveRecord or Ruby if you said you're using Rails? You've missed the point of the article.

Also, will everyone decide in 6 months times that, hmmm, you know what Ruby sucks and we should all start using BooRuubie next year instead?

Because I guarantee at the absolute minimum one of the technologies you mentioned will be out of favour this time next year.

Also, I can practically guarantee in a year's time when you come to do some maintenance work on that project and there's a bug and you google it, the code you find will be incompatible with what you've built.

Or someone new comes to setup the project and is googling about the config for something you mentioned, the article will be utterly wrong and will spend days just getting the damn thing to run.

You didn't answer his question. What stack do you prefer to use?

Purposefully, as it's utterly irrelevant to the discussion on whether a stack is complex or not.

It is absolutely relevant, since you're criticising his stack. Even if it wasn't, you could still reply, but for some reason you won't. Hmm...

I'm sorry, but you seem to have misunderstood this discussion. I'm not saying mine is any better, we're simply discussing whether a stack is complex.

So what I use is irrelevant.

If you're so desperate to know what I've used, since 2004:

    - VB6
    - vb.net net webforms
    - old school vbscript + dynamic ajax
    - c# using xslt + ajax xml, without really using webforms
    - c# webforms
    - PHP wordpress
    - asp.net MVC
    - silverlight
    - rails
    - MVC + Web API with a jQuery/datatables/handlebars
    - MVC + Web API with a jQuery/jQuery-tmpl/jQuery-forms
    - Durandal with OData
    - knockout with a mix of MVC + WebAPI

Some playing with django and backbone and angular and laravel for my own projects too, but not particularly in anger.

To be frank, the worst one for unnecessary complexity, by a far, far, far, far way, was durandal. Pile of shit. React/angular definitely suffer from a similar over complexity.

Generally speaking, recently I haven't really chosen a stack, the last 4 projects I've worked on have all been past that phase when I joined.

When I have, it was 3 years ago and at the time I stuck with jQuery/datatables, at the time backbone was trendy and I hate any js framework which relies on methods for properties having been burnt by supporting a colleague's internally homebrewed jQuery-a-like with early template system that used that earlier in my career. Nightmare to debug.

>Why would you need to say you're using ActiveRecord or Ruby if you said you're using Rails?

Exactly. "Rails" implies all of those other components. That's my point.

And your stack is relevant. I'm curious what simple stack you use, and how much more simple it is.

JavaEE? Or spring boot?

> which will give you a working project in 2-3 hours

> you can learn React in a few hours. What's the big deal?

Assuming we are still using the same example (filling a table with some data and filtering it), I think 2-3 hours is a good example of how long it takes to write that in plain Javascript and testing it on every browser back to IE6 while having lunch in between.

For sure, but the time spent learning React would provide value for all his future projects too.

I'd probably use React for a project that simple, particularly if it needed to be maintained and expanded by others.

Funny, I actually had that last year in a 2 hours midyear exam, access to Internet authorized. I was the only one to complete the exam and had the best mark, didn't use internet, just my own code lying around my pc, finished in half an hour, vanilla js/php LAMP.

But many of my class couldn't do it.

Here's a link to a CLI utility which will give you a working project in a matter of minutes.

https://github.com/stoikerty/dev-toolkit

It does depend what perspective you're looking at it from. I appreciate it generates awareness about a current state of affairs for newcomers. But it's always easier to complain about something that to grind your teeth on it and learn, research and develop. The latter, although more painful, is a driving force forward.

Help > Complain

Agreed. I started a new project a few months ago, and if I had listened to the advice in the threads that have popped up around this whiny article, I would have had to refactor my codebase 6 times already by "adding the stuff I need."

I made a decision from the start to use React, Redux, and Webpack with ES6/Babel. There was a bit of a learning curve, but I couldn't be happier using those tools. Recently I started adding Immutable, and I wish I had done so from the start.

I've tried adding Flow and Typescript to the project, and it's a major pain in the ass to do it now. I would have done it from the start, but I made the mistake of listening to some of those voices going on about "unnecessary complexity" and left it out.

I'd like to invite all the people saying to start a project in Vanilla JS or jQuery to do so, and let me know how it's going when you've got 15k lines of code and you want to refactor your app to use some of those complex tools.

Sometimes jQuery is all you need. Sometimes you don't even need that.

Lucky for him he didn't ask about tests :)

"I need to display data on a page, not perform Sub Zero’s original MK fatality."

This sums up my opinion of the whole React+Redux+Webpack+SatansSeventhCircleOfHellLib combination.

I think people that don't like to constantly learn new stuff shouldn'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.

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's not like you need know all of them, if you are really lost and don't know what to choose, just ask other developers around you or check out websites like http://stateofjs.com/ 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'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.

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't know the right people and right blogs.

And that's why no amount of good will and side projects will make up for hard, real world experience.

There's no need to jump straight into the deep end of tooling.

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.

There _are_ a vast amount of libraries in the js ecosystem, and it'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't worked with directly).

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.

And the result will likely be this...

https://xkcd.com/927/

I hear this a lot, but I don't get it. How would this help make things simpler or stop "this madness"? If anything it opens up the possibility for even more crazyness. The only difference is you (maybe) get to pick your favourite language instead of learning new ones.

It's not so much about picking your "favourite" language. That's what drove NodeJS to exist. But more about picking a more appropriate language that has a well engineered base class library and third party libraries. They will come. This comes down to choosing the best tool for the job at hand.

JavaScript developers have been able to, in recent years, benefit in some ways by being able to write their server-side in JS as well (see NodeJS). There are various buzzwords to describe this capability. WebAssembly will help normalise this so that other languages can also have this capability. By being able to share types between the server and web browser client, there are large productivity and program correctness gains to be unlocked.

People are hyping up webassembly way too much. Don't get me wrong it's going to be awesome being able to compile C++ and C programs that run on the Web runtime.

But it's not going to be without it's own issues. For one developers will likely have to wait for things like simd, pthreads or 64bit ints until later versions.

Also it won't magically make compiling your language of choice to the web less painful unless it's C++ or it fits into the C++ language model. Even when it gets the ability to hook into a garbage collector (I wouldn't count on it happening any time in the near future) it will likely have to fit in with the way js engines expect.

The frontend frameworks wars are pathological. It's useful, to me, to remember _why_ that's the case: because web sites/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's isn'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/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's the link to that: https://news.ycombinator.com/item?id=12635142

No seriously it's crazy. I tried doing some MEAN stuff for a while(I'm backend and can do some WPF UI MVVM ). Anyway it was insane I'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/programmer and a software engineer. As a small business owner, If I'm hiring a developer/programmer, I'm looking for specific skill sets in a given language/framework. I don't expect to hire a PHP programmer and throw them into React/Mobx/Webpack/Gulp/Babel/Websockets without a tremendous amount of training. Frankly, I don't even expect them to know SQL in any sort of advanced way. I'm paying less for that person and getting less in return. I'm taking on the challenge of "growing" them into what I want them to be in the future or letting them go if our project pivots

When I hire a software engineer, however, I'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.

In most cases, projects are a good mix of both software engineers and developers/programmers. The two can balance each other out and produce amazing things.

Lastly, everyone should be looking to improve their knowledge of their own industry. If you are a developer/programmer/software engineer, you should be looking at what is new/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/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.

I am learning Javascript in 2016. I also learned it in 1998. It was a simpler time back then, sure, BECAUSE YOU COULDN'T DO MUCH. Rollovers, alerts, scroll some annoying text in the status bar of a browser. This was about the extent of it.

I can do SO MUCH COOL STUFF with 2016 Javascript. Much of it comes with a complexity cost, but of course I'm free to code "raw" 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) & JQuery....yet I have no problem.

"-Ever heard of Python 3?" (go to top)

The article was pretty good as a JavaScript commentary, up until the last line that name-dropped Python 3. I don't think the Python community has anywhere near the problems that the JavaScript community is having.

For example, there aren't languages trying to transpile to Python, they aren't trying to translate new Python language features into old ones at runtime (at least not like 3.5 into 3.0, but there is some mess in 2 vs. 3 such as six), they aren't trying to shoehorn assembly language into it, and there aren't a dozen ways to do HTTP requests or manipulate DOM or make packages.

People love to joke about Python 3 and I totally get it. But compared to Javascript, the mess is nowhere nearly as great.

To make python 2 code compatible with python 3, a few things need changing. For 99% of the code it's very simple, and for the 1% big changes, well, you just need to go through it and refactor some of your code. People have been postponing this but we are well on our way. During the transitioning period, new stuff gets written in py3 and old stuff still runs with the py2. People have both installed. No big deal.

Now Javascript. There is plain javascript with slight variations for every browser. There are a million frameworks, a new one that becomes majorly popular about every two years, and they all work very differently. There is no single, straight upgrade path, it's almost like using completely different languages. There is no "we are nearly done with the transition". Instead there is five new frameworks to look at every year, each of which uses five others as dependencies (angular 2's tutorial is a good example, last time I checked) and one of which will become popular next year, by which time you're outdated if you haven't tried all five. The only new thing that needs explaining in py3, as far as I know, is byte objects vs string objects. Then a few syntax changes (I think OOP changed a little bit) and you're done.

I totally agree that Python is much less problem compared to Javascript but I think that it's not fair to compare a backend language to a frontend language. My only complain is that Python is not great at async operations so people have to create unstable async libraries such as gevent and it's usually cause trouble in production. Luckily Python 3 solves this problem but backward compatibility is one of the most important things that is important in a programming language. People usually develop backend services once and maintain it for years but frontend is subject to change more often.

> My only complain is that Python is not great at async operations

For most asynchronous IO operations, the old standby of threads works an absolute treat. There are certain pathological corner cases where a single thread can be blocked, but for the other 99.9% of use cases, it works fantastically.

Build your synchronous and stateless web code and throw it into a thread. Done. Even the more complex cases of a single worker needing to make multiple asynchronous calls can be handled easily without even having to leave the standard library.

Now then, this falls apart a bit when you have to deal with global state (and the assorted locks and deadlocks), but most web backends aren't too hard to write statelessly.

But spawn enough threads in Python and you risk entering scheduling hell, thanks to the global interpreter lock. EDIT: if you are CPU bound at all. If you are really really IO bound it's not a problem.

Event-driven programming is my go-to for nontrivial backend async in Python, and in Python 2 you almost certainly want to use a third party library for that.

(But maybe I'm just lazy. I try to avoid the headache of threads in python if I can.)

Python 3 has asyncio, which looks good, though I havn't used outside of toy projects at this point.

My favorite line from the article:

"I need to display data on a page, not perform Sub Zero’s original MK fatality."

The picture on the top sums it up.

How it feels to learn parallel parking in 2016

"I want to parallel park in that parking space."

You'll need a car first.

"When I was a kid I just walked into the parking spaces."

Yeah, but that's not really parallel parking, you were just walking into a parking space.

"Oh ok. So I'll get a car then."

Well, it's not that simple, you have to actually get inside the car in order to parallel park.

"What? Can't I just push the car?"

No way! First you have to unlock the car, start it and put it in gear.

"Oh. OK, how do I do that?"

First take out your key.

"What's that?"

It's a small attachment that should have come with your car. Then press the unlock button.

"I unlocked it and am sitting in the seat. Ready to park?

"Not quite. first, you need to put the key in the ignition"

What is an ignition?

"It's the small hole on the side of the steering wheel. Now turn it. No, the other way.

"OK, let's parallel park!"

Hold on now, you need to adjust your seat, rearview mirrors and side view mirrors to ensure that you can drive safely.

"But I don't want to drive, I just want to parallel park!"

It doesn't work like that.

"Fine. How do I get these side view mirrors to adjust?"

Well, first you have to select which mirror you want using the switch to your left, then push the directional arrows until it's at the correct angle.

"How do I know what the correct angle is?"

There are lots of opinions about this, just search Stack Overflow.

"This seems like a good angle. Let's park!"

Hold your horses, first you have to put the car in Drive...

...

Some things that we take for granted as simple really aren't and never have been. Within a generation the above will be completely outdated knowledge and you'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.

Just because you put words in that format doesn't make this a good analogy. You can teach someone to drive, including parallel parking in a couple of hours and then they just have to practice. The javascript ecosystem is legitimately complex. You can't just hand wave that away with a rhetorical flourish.

I agree that the JavaScript ecosystem is complex, that's why I said it in my comment. I'm just making fun of the notion that we should expect simplicity when web development has never been simple.

I have JavaScript Fatigue Fatigue.

Part of the reason why people can learn to drive in hours is because they have been riding in cars as passengers since birth. Though new at driving, they have lots of contextual knowledge and awareness. If you took someone who grew up on a desert island and taught them to parallel park, it would take considerably longer.

Likewise, experienced web developers have years of contextual knowledge of CLIs, documentation and coding. An experienced dev can reasonably be expected to bootstrap a JavaScript app within a few hours, even if they only used jQuery in the past.

Also because we have evolved with complex spatial awareness as an innate trait. Yes, I have been developing websites since 1994, and I have been on the bleeding edge most of that time. Of course I can come up to speed with whatever stack du jour the kids are fawning over these days, but that doesn't make it simple.

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:

1. people use

2. people are happy with

Try the results of this survey:

https://news.ycombinator.com/item?id=12627693

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

This misses the point.

It's about the unit test.

jQuery is easy to develop with but difficult to unit test.

React is slow to develop with but easier to unit test.

For small projects, jQuery is better.

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.

Unit tests is not the primary way to choose one frontend framework or another. It's one aspect to look at but i don't think this boils down to unit tests at all.

It's so interesting to me that so many people complain and no one does anything.

If Javascript is so bad just make any other JIT compiler run in browsers. Defeat the argument with action.

I'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.

Don't follow trends if you don't want to, but I don't believe anything in the OP was difficult if you understand why you're doing it and learn it properly.

The proliferation of frameworks is people's attempts to do something about it. But then XKCD 927 applies.

Link for the lazy: https://xkcd.com/927/

We cant force browsers to support other front end languages. JS is the only reasonable choice for front end development, Dart didn't end up going anywhere.

Why would you force anyone to do anything?

Just do it. You've got dozens of these threads full of competent software engineers and no one can put 10/100 people together and fix this?

I think it's easy to not want to learn something. It's hard to read this article and say "hey I want to learn all of that". But because it is hard it is valuable.

> What's wrong with HTML?

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't designed to do what we want it to.

Web components are working on this, except they're reimplementing every modularity feature that JS already provides (HTML imports, shadow dom) from scratch, and then they're implementing every feature that React gives you (custom elements) from scratch. But its still too early, and most tutorials don'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'm getting tired of these pointless non-specific rants. You could write an article about "How it feels to learn C++ in 2016" and make it all about the complexities of operating systems, linking, compilation, text editors and the QWERTY keyboard layout, and you'd still be as accurate.

All you need to "JavaScript in 2016" (as a beginner) is a config file and one or two commands. That's it. If that'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.

> All you need to "JavaScript in 2016" (as a beginner) is a config file and one or two commands

And 3 months from now in 2017 those 2 commands will be deprecated because no one uses those programs anymore.

As far as beginners are concerned, that shouldn't really matter.

Hide all that complexity in a `./build.sh` or `make` and hand them a config and a README. The author of the article is a web designer with a slightly technical problem to solve. He didn't even need to know about gulp, or grunt, or webpack or babel. Those tools are (should be) as relevant to his domain as the tools used to manufacture the circuits that run them.

Not everyone is a beginner web designer. Some people are trying to build things from scratch using JS.

"Just use this magic build.sh!" sounds a lot like "Just use this magic starter kit!" or "Just use yeoman!"

Who is supposed to write this 'build.sh' in this scenario of yours?

Without fail, every single magic build system or magic starter project I have ever used is now deprecated and abandoned.

  Makefiles? No one uses those anymore, use Grunt!
  Grunt?  No one uses that anymore, use Gulp!
  Gulp?  No one uses that anymore, use webpack!

I have a react app that I built on top of a starter kit that I now need to rebuild using create-react-app because the build process broke when I tried updating something.

Meanwhile, I can pick up a python project I worked on 10 years ago, or a go project I started 4 years ago and everything works exactly the same.

I don't think there are any stable ones, even Jetbrains' IDEs bang their head with all the JS tools' complexity nowadays.

The number of libraries is too high, but the bigger issue is the speed at which each one is replaced. I thought the ruby ecosystem was bad 10 years ago, and the python ecosystem bad 5 years ago, but these are like sloths on Vicodin compared to the absurd rate at which the JS community seems to adopt and deprecate libraries and frameworks and whatever else they're calling them today.

The worst thing is, every single thing these frameworks are trying to address are solved problems, and have been for decades. But people love reinventing wheels.

Reply on news.ycombinator.com