19 ms·

How it feels to learn JavaScript in 2016

okket 10y ago
Loosely related: "The S stands for Simple" http://harmful.cat-v.org/software/xml/soap/simple http://harmful.cat-v.org/software/xml/soap/simple
- mturmon 10y ago
  This is insightful. Of course, the OP is consciously playing off the earlier app-deployment spoof (https://circleci.com/blog/its-the-future/ https://circleci.com/blog/its-the-future/). But this earlier spoof may well be based, intentionally or not, on the SOAP piece you linked -- which was a hit on HN 7 years ago (https://news.ycombinator.com/item?id=2079631 https://news.ycombinator.com/item?id=2079631). Thus prompting the observation and related question: These three areas - front-end, deployment, RPC - seem to have engendered a churn in standard approaches, and a corresponding cultish devotion to certain toolkits -- leaving them open for satire. But yet, there is also a need for a guru to explain WTF to do, because a lot of practitioners need to get these jobs done. So, what is the deeper parallel between the areas? E.g., a lot of corporate resources suddenly poured into these problems, and everyone is funded to come up with, and promote, their own solution?
jlas 10y ago
Reminds me of https://circleci.com/blog/its-the-future/ https://circleci.com/blog/its-the-future/
- egwynn 10y ago
  FTA The following is inspired by the article “It’s the future” from Circle CI. You can read the original here (https://circleci.com/blog/its-the-future/).
- ABoldGambit 10y ago
  Ahhh I wondered why I was having massive deja vu reading OPs article! Both great posts.
jftuga 10y ago
This has to be one of my favorite HN posts of the year.
deleted 10y ago
[deleted]
gadrev 10y ago
This was actually a didactic piece. While criticizing the current state of affairs, it gives a nice overview of many of the emerging technologies and how they fit together, even if for some tasks it feels retarded to pull such an entangled mess of dependencies. You can then go insane diving into any particular one :)
- brlewis 10y ago
  Yes, but I really don't like the "How it feels to learn Javascript" title. Realistically you wouldn't give such a wide array of options to someone who wants to learn how to accomplish something specific.
  - ajmurmann 10y ago
    Yes, realistically if you were to have a conversation with an experienced advisor like the article is staging that wouldn't happen. However, the article reflected exactly how I felt trying to do more JS again a few months ago after not having done much JS for a few years.
- pbh101 10y ago
  Being primarily a Java dev, it felt to me like half of this was critiquing the churn rate of using different tools (warranted) and the other half was lamenting the fact that people built tools to solve the common problems they have when developing in large teams (largely unwarranted). Most of those tools have direct equivalents in the Java ecosystem (and there is tool-churn in Java too, just slower). Facebook, Google, large startups, and the others which are building these tools are doing so to solve the problems they experience in their teams' front-end dev processes. Ironing out the kinks in the code assembly line. And they are of course doing so in a path-dependent fashion: add tool N+1 to solve problem N+1 given the existing toolchain. The result is a lot of tools and a lot of context to imbibe at once, but it doesn't mean they are solving nonexistent problems. Just problems you don't have, or don't know you have, or don't have yet, or can afford to leave unmanaged when developing a small site with just a couple people.
  - 10y ago
egwynn 10y ago
See also: https://medium.com/@boopathi/it-s-the-future-7a4207e028c2 https://medium.com/@boopathi/it-s-the-future-7a4207e028c2
- btym 10y ago
  I knew I'd read this somewhere before!
buckbova 10y ago
"It’s 2016 man, no one uses jQuery anymore, it ends up in a bunch of spaghetti code. Everyone knows that." I prefer "jQuery soup."
patmcguire 10y ago
Reminds me of "starting Rails today is like starting to watch a soap opera in the 7th season" http://words.steveklabnik.com/rails-has-two-default-stacks http://words.steveklabnik.com/rails-has-two-default-stacks Be thankful, at least it's not 2013, the new-js-framework-on-the-front-page-of-HN-every-day era.
- choicewords 10y ago
  I remember when there was a huge fight in Rails to change JS framework. Seems quaint now.
- gremlinsinc 10y ago
  yeah many old-timer rails folks will say skip rails and use Phoenix instead lol.. for concurrency and all.
tibbon 10y ago
This is pretty much why I don't do front-end. I'm fully capable of it, but I just don't like keeping up with this flavor-of-the-week. It just doesn't feel like programming to me, or at least not the programming I enjoy. Strangely, I see so many new developers rushing toward the front-end, which seems much more complicated in many ways than just building solid web API services, analyzing data, etc.
- choicewords 10y ago
  There is a money issue. If you do keep up, you'll get amazing job offers. If you manage to really be on the edge, you can give talks as well, expose yourself as a consultant. That's much easier in JS than with Ruby, Python or whatever else.
  - tibbon 10y ago
    Fair enough. I've hit a sweet spot now in having done Ruby for ~8 years, so I can get away with saying, "having someone else deal with the front end. I just want to talk about data". The new problems I'm working to learn to solve are with ML, NLP, etc. I'd like to step away from web services completely soon, and just live completely with data.
    - choicewords 10y ago
      I'm in the same boat. I'm no longer interested in the plumbing, much more the type of questions that can be answered with large scale data, and other types of efficiencies that are dormant with 'pure' code.
    - gettersetter 10y ago
      I am curious, how did you transition into ml, nlp. I am thinking of transitioning to ml, as work is getting kind of boring for me, but most job requires at least a master in the relevant field. I am self studying right now, maybe going back for a master, but I felt I lack alot of necessary probability and linear algebra theorems. I can code svm, neural network from nothing. I understand basic markov chain, bayes network, but that is really just scratching the surface. Any recommendations?
imgabe 10y ago
I guess I'm behind the times in that I still use jQuery. Is it really worthwhile to go through everything described in this article to create a simple filterable table?
- jordache 10y ago
  if ALL you are displaying is a table, then you can write a quick little jQuery(or native JS) function to remap the array and re-draw the DOM. If your fancy little table is part of a large app, or even a simple app, it is much easier to implement the entire app using a framework like Angular. The model view concepts really help to tie things together.
  - zzalpha 10y ago
    Your use of the word "easier" is questionable. Even for trivial SPAs it's often easier to roll the basic functionality yourself. Flipping over to something like Angular introduces technical and cognitive overhead that often isn't worth the trouble for something simple.
    - jordache 10y ago
      What about maintainability? You want everyone who touches your code to figure out your custom solution for data binding? Or you could just follow the conventions established by an industry popular framework that is instantly consumable by another developer?
      - zzalpha 10y ago
        Seriously? If your application become sufficiently complex that it can't be easily grokked by a decent dev, that's when you know it's time to switch. Until then it's just over engineering (which the JS community admittedly loves).
        jordache 10y ago
        what is that complexity threshold? Self determined no doubt. Guy A believes his custom design is simple enough to comprehend by anyone. Guy B doesn't agree. It doesn't really matter at the end of the day. If you work in a team environment, the toolset will be pre-determined already. You don't have a choice.
gremlinsinc 10y ago
I'm looking into react, and I fix things in legacy code, but that's still mostly jquery, or native js. But backend I just get things done.. I much prefer working on teams where there are 'specialists' who do all the frontend and I just give them an API to feed into it.
maxlambert 10y ago
Hilarious article, but seriously, can somebody tell me where I should begin learning all of this stuff? What are the 2 or 3 top-priority things I should get started with, if I have experience with Django/HTML/JQuery, and want to expand into more advanced frontend programming?
- threatofrain 10y ago
  Have you looked into stateless React + Redux? These libraries are interesting in their suggestions for app architecture, and their api's are minimal. One day perhaps React and Redux will be replaced by something else, but I think the strategy of a GUI functional layer consuming a stream of events is here to stay, and I wouldn't be surprised if it spread to native app design.
dhruvkar 10y ago
I couldn't get through the entire thing. Even knowing that it's a fun/sarcastic piece of writing, the portrayed pain is all too real, as someone just starting to dive into the front-end. In all honesty, can I still use jQuery for new projects without issues in 2016? Is there a real reason not to?
- vinceguidry 10y ago
  Yes, you can. No, there's no real reason not to. But honestly, I'd go with React if you can. The reason is, if the app starts taking off, and you end up with a team maintaining your app, you're much less likely to end up with an unmaintainable mess in two years than if you use just jQuery. All applications, especially websites want frameworks. The framework is essentially a way to organize the massive amount of complexity boiled in. If you just roll with libraries, then you end up cobbling together a framework on top of it. You will then have to maintain this framework. This is fine when it's just you, it will coalesce into a bunch of conventions that's fairly easy for you to reason about. But once you start involving others, then you're going to see your nice conventions get rekd like a bull in a china shop. Not everybody sees problems the same way you do. If you pick the framework beforehand, then you don't need to maintain it, you can let the nice people at Facebook / Google do it for you. And whenever you finally get others involved, they're limited in the amount of architectural damage they can do because they have to stick to the conventions of the framework.
  - thatswrong0 10y ago
    I agree - I think React is simple enough that there's no reason not to besides the overhead of JSX preprocessing (which I suppose isn't required but I would definitely recommend). It really is more of a library than a framework, which is great for starting out because there are fewer concepts to understand. Then when you start adding more people and your application gets more complicated and you need to manage your data flow in a more consistent way, you can add something like Redux after the fact incrementally. As long as you don't let components become too large, refactoring isn't too difficult.
    - 10y ago
sotojuan 10y ago
I'm in a weird position where I like JavaScript and Node but dislike frontend (or at least I am disliking it more and more). With Node, I can get quite far with just a couple of dependencies that install quickly. I don't need transpilation unless I want to use TypeScript or PureScript and I can target any version I want. I find it very fun to mess around with Node and a bunch of little modules. I am slowly "transferring" back to server-rended pages using Node or Elixir. Probably not good for my employment (even in NYC most JS jobs are frontend), but whatever. If I was learning JS right now and didn't care about employment I'd just learn Node (which just means learning JS really) and experiment with stuff.
- cycomachead 10y ago
  JavaScript, admittedly, has a few more quicks than the average language but I quite like it. I know a lot of people who also feel the same way. (And as many how, of course, hate JS.) It still feels to me like we're in the early days of node and the dev infrastructure for "modern" sites. Hopefully, things stabilize soon(ish).
vladimir-y 10y ago
Article title is absolutely not correct, front-end developer is supposed to build an entire UI and corresponding client-side logic, not just write some abstract JavaScript code, code itself is nothing. So it's not about write JS code, but about building maintainable and scalable applications. All that stuff is actually required to build something maintainable, especially modules. React is not a silver bullet, but nowadays SPA and components approach should be familiar for any front-end developer. I like Typescript was mentioned there.
krylon 10y ago
This makes me think of a sentence I read years ago: "We love to fight complexity with complexity." I think whoever said this referred to the various IPC methods on Windows, but I do not remember for sure. Seems like some things never change.
at-fates-hands 10y ago
You also have to keep in mind a few things: 1 - I've never referred to myself as an "engineer" since I don't see myself as one, nor do I have an engineering degree. This includes the fact I do not have a four year CS degree either. 2 - Front end development has now split. Being a web "designer" means you know HTML5, CSS3 which includes LESS, SASS, PostCSS and other CSS pre-procssors 3 - Being a web "developer" means you're more likely to be a Javscript developer. Meaning you're familiar with Angular, Backbone (I know its soooo 2014 isn't it?), React and other JS frameworks. Every interview I've done in the past two years has almost exclusively focused on JS and how well I know standard JS. Closures, inheritance, debugging, etc. Nobody cares if you know much else other than that.
- Pherdnut 10y ago
  Where are you interviewing? All I get is Angular and React questions for interviews where I stated up-front to the initial contact that I'm no expert on either and have tended to stay focused on core technology developments when studying on my own time.
- Pherdnut 10y ago
  There is no excuse for not knowing CSS as a front end/UI developer. That so few know much of anything about it nowadays, or think they don't actually need to is tragic, IMO.
tempodox 10y ago
It's bad enough the facts on the ground make it a virtual impossibility to circumvent JS altogether. The best we can do is always wearing gloves when handling it and to never write it manually. JS, for the oversimplified thing it is, is just systematically overextended with the loads it has to carry now. No framework on earth will make that go away. And neither will ES6.
romaniv 10y ago
And to think that I went into web dev precisely to avoid dealing with complex build chains and horrible UI libraries...
- Cthulhu_ 10y ago
  That's because when you started, all of the complexity was in the back-end; this has moved to the front-end, with backends becoming simpler and more focused on providing data.
  - romaniv 10y ago
    The overall complexity was still order of magnitude smaller. There were no transpilers, shims, or complicated multi-step builds, and I knew every single library I was using.
mgrennan 10y ago
This is what happens when management gives up and turns IT to developers. And I believe that happened when accountants took over because of Sarbanes Oxley. The accountants had no idea what they where getting into. Then the Tech Bubble happened and $$$ filled their eyes. Developers became GODs and now... This happened.
OtterCoder 10y ago
Takeaway: use Elm.
alexmuro 10y ago
If you are doing a simple project, there is nothing wrong with just using jquery (or imho d3). If you know that your project is always going to be pretty simple or especially if you are learning. I have been teaching a number of people javascript at my lab lately and I think its unwise to teach new javascripters using any of the modern tools or transpiling until someone runs into one the problems that those tools solve. Having been a javascript coder consistently from the jquery days until now, I am not pining for the simple old days of yore. It can be hard to learn everything that goes into a big front end app these days but when used correctly all those tools are there for a reason.
- mpwoz 10y ago
  This needs to be higher. You shouldn't use any of these tools just because people tell you to. If you can't see what problem something solves, then start at a simpler/lower level of abstraction until you run into that problem, and can appreciate the tool that solves it. Of course, this advice doesn't apply if you actually need to write a production app, and aren't just playing around for learning purposes :)
ilostmykeys 10y ago
If you stay on the surface and follow trends you will think front end web development is insanity inducing. But if you go deeper, develop your own thinking and deep patterns you will realize that the web platform is doing just fine and is progressing better than most languages/platforms out there.
_Marak_ 10y ago
I've found using Babel / React / transpile tool-chain is actually fairly impossible to use for the majority of developers. I've given up on it several times in favor of plain-ole-javascript and jQuery. The amount of time it takes to ramp-up on the technical knowledge isn't insurmountable. The main issue is bloat in both code size and dependency chain instability. On a slow connection, you might find yourself battling against your tool chain for half the day. In the case you actually hit a code problem with the underlying technologies, it's going to be hours if not days searching Github for the patched version of the module. If you actually are able to path the specific dependency, it will probably break something else. I do have hope though. We are starting to see a lot of really cool Babel / React components and projects. I think with a bit more time, we'll get stability in the eco-system as there are less deltas to the underlaying code dependencies and the browser vendors catch up with ES7 features.
istjohn 10y ago
This was spot on for me as a hobbyist who has returned to JS after a hiatus of roughly 3 years. On the one hand, it's exciting to see JS evolving into a sophisticated language with dozens of new constructs specced out. On the other hand, as a casual enthusiast I feel trapped between using a small subset of the features available, or wrestling with a tangle of temporary crutches while implementations catch up with the new standards.
voidfunc 10y ago
Just a couple days I got into a conversation with my coworker about UI stuff. I had to test something against our dev UI. Last time I did UI work was back when having index.html, img/, css/ and js/ directories with maybe a script or two was the norm. I had to fucking run make and I still have no fucking idea what was going on when I ran make which compiled a bunch of shit. There was all this NPM shit going on (isn't NPM part of Node.js which is a server-side framework? WTF?). I got it working and promptly noped the fuck out that horror show. The web is a giant fucking pile of dog shit in 2016.
- arctangent 10y ago
  It doesn't have to be this way. Unfortunately, we live in a world where younger developers "show their skill" by making things overcomplicated in order to create unnecessary barriers to entry to our proto-profession. My usual response is to refuse to work on such a project if I don't have the authority to change how things are done to make them more sane.
  - ocfx 10y ago
    Yeah because refusing to work on projects because of tooling selection gets you far in life...
  - minitech 10y ago
    “make and npm” doesn’t sound overcomplicated. It sounds like someone didn’t take the time to find out what they were working with, didn’t really need to because it’s not their area, and decided to have an opinion about it anyway.
  - rbanffy 10y ago
    > in order to create unnecessary barriers to entry to our proto-profession. I wouldn't say it's malice. I think they simply don't know better.
    - meddlepal 10y ago
      Agreed. Possibly a consequence of the ageism in our industry too.
deleted 10y ago
[deleted]
adamrezich 10y ago
Cross-posting my comment from reddit: I don't know about anyone else, but the problem I personally have with the crazy, messy JavaScript ecosystem is: - I am a relatively experienced amateur programmer (with limited [nine months] professional experience) - I can learn any new programming language, library, methodology, or whatever pretty easily - I don't have any formal experience using anything of this newfangled stuff; like the author of the article, my frontend experience involves plain ol HTML/CSS/JS, with a little jQuery to make things easier - nobody wants to hire me unless I have `n` years experience with newfangled language/framework/methodology `x`, `y`, and `z` - I don't have a CS degree Unless you're a massive operation like Facebook or something... just give me a week to look through your website's codebase, I'll figure out how you guys do things and I'll start being productive before you know it. If you're using stuff that I've never used before, I'll learn it. I should be a more attractive hire than someone who has `n` years of experience only using `x`, `y`, or `z`, because the way I think about getting things done with computers isn't tied down to any one specific framework... but it seems that this isn't how hiring works in the industry right now... which is directly at odds with the rapidly-changing nature of web development! As a result, I don't feel inclined to learn any of this new crap. What's the point? Apparently I should've learned it all `n` years ago, and it's too late now?
- nikdaheratik 10y ago
  It sounds like your gripe isn't with the knowledge base, but with the people doing the hiring. The issues there are very real in that, if you're dealing with a non-trivial codebase, there's no way to tell whether someone with very little real world experience is a competent programmer or just "faking" until you've got them working on it for a few weeks, and even then they may not be worth the time you put into training them until a couple of months down the line. And the people in HR for most organisations don't have a clue how to tell the difference. So they make up a bunch of gatekeeper requirements that allow them to filter out anyone that doesn't fit the mold early in the process. They're still likely to find someone who can do the work this way even if it means throwing out a decent percentage of other candidates. It's messed up, but it's kind of where the lack of technical knowledge in HR, and the need to avoid any potential lawsuits have left us.
realrocker 10y ago
Ok, So I have only ever done backends and some android stuff,and been trying to learn building UIs. It's been hard. This post finally cleared some of the confusions I had but was afraid to ask.
- voltagex_ 10y ago
  I'm a (mostly backend) web dev, and I've been trying to get a simple Android app up and running - it's definitely more challenging than I'm used to.
trowawee 10y ago
It continually shocks me how much whining developers do about sometimes having to learn new things. The requirements for continued education are shockingly low (read: non-existent) in our industry, compared to other, similar intellectual/white collar industries - doctors in California are legally required to do 50 hours of CME/2 years, lawyers in California are legally required to do 25 hours of CLE/3 years, and those are both fairly standard. There are a tremendous amount of jobs out there that won't require you to learn anything new, ever, if you don't want to (think of how many thousand brain-dead Java jobs are out there). There are plenty more that will require you to learn one or two new things (any of the hundreds of consultancies and companies that picked a fairly standardized stack and work with it all the time). And then there is a tiny subset of companies that are actively working with new tech and trying new things, and a tiny subset of people actually using all of those new things. Whining about how "it's too complicated!" because someone somewhere provided you with some new programming tools for free because they thought those tools were useful and cool is an ugly look for a profession that's so prone to patting itself on the back while loudly proclaiming how forward-thinking it is.
- brianvan5155 10y ago
  Learning in other industries is offered in institutional settings as part of the profession. Learning in the dev world consists of aimlessly screwing around with an undocumented, unsupported, glitchy web/server stack for many many hours unpaid after you've already spent 40 hours that week putting bread on the table. The whining has less to do with the "learning" and more to do with the yak-shaving part of it torturing us endlessly in the off-hours. And, unlike in medicine and law, there is precious little professionally-written, detailed, helpful literature to help us along the way. There's just "quick install" and then a command/api reference. That is... not up to the level at which medicine and law have their industry practices & standards documented.
- pdimitar 10y ago
  There is always that one person that says "others have it worse, thus you're whining if you have trouble doing your job". Not a valid argument, and won't ever be. Plus don't forget our education isn't formal. Doctors and lawyers have it much, MUCH more standardized than ourselves. We the devs are pretty much do-it-alls that have to learn 95% of their skills on the go. You won't ever hear me complaining about learning things on the go. I love it. What I hate however is putting up with the lame work of people who probably can't do much more in their lives beyond tying their shoes. That's what this thread is about -- partially anyway.
chajath 10y ago
My advice would be to pick one tech stack that is prevailing in the market and master it. Once you master one you will see similar concepts been largely repeated in other frameworks.
cycomachead 10y ago
Slightly related, but if you're helping someone start out learning to code, it's worth reading this: http://pgbovine.net/programmers-talking-to-beginners.htm http://pgbovine.net/programmers-talking-to-beginners.htm You don't _need_ react to build a cool site in 2016, but if you're dead set on that, then this piece is a good intro to the set of questions that arise!
carsongross 10y ago
If you are sick of javascript on the front end, but don't want to give up the fancy-pants UI, you could do worse than my library, intercooler, which lets you add AJAX to your app with a few HTML attributes. http://intercoolerjs.org http://intercoolerjs.org Make REST work the way it was intended, supports CSS transitions, request indicators, etc. Good little library that eliminates a lot of complexity for web apps that don't need all this junk (most of them.)
- commentzorro 10y ago
  Just saw intercooler referenced in a post a couple days ago and took a look. It does look refreshingly simple to get started. I've got a basic app with JSON end points already created. I was going to give VUE a go but after looking at intercooler I'm going to create an alternate set of /IC/* URLS and send out HTML instead. I'll soon see how it works for this task.
  - carsongross 10y ago
    I'd love to hear what your experience is. Thanks for giving it a try!
  - qohen 10y ago
    Just saw intercooler referenced in a post a couple days ago and took a look. It does look refreshingly simple to get started. Aaaaaand...we've come full-circle now: Intercooler depends on JQuery, version 1.10.0 or higher. :-)
    - commentzorro 10y ago
      >Intercooler depends on JQuery, version 1.10.0 or higher. I don't have any real problems with jQuery being in the mix for intercooler. Even with that, jQuery appears to be an underlying library used for convenience rather than a library an intercooler coder would have to know and code against. I do appreciate the irony when taken in context with the original article though.
resonantjacket5 10y ago
This encapsulates my experience learning angular 2 and react these past two years. Lol
glenndebacker 10y ago
I don't use ES6 because of the cool kids, but because it makes some Javascript things more tolerable. One constructive thing that I would like to add is that the "You don't know JS" book series has really taught me a lot about the common pitfalls of JavaScript. Since then my JS stress levels have been reduced dramatically!
dvcrn 10y ago
I know the irony of introducing a new tool in the comments of this particular blogpost, but a while back I decided to completely ditch javascript and go the clojurescript route. I've been super happy ever since. The syntax is stable, clojure is extremly well designed, the ecosystem a lot clearer and tools - well you have lein as the main one and that's about it. On top of clojure, you get google closure for free and can optimize the hell out of it with advanced mode compilation out of the box. And that's the 'vanilla' experience! No separate library required! You can still interface with normal js and npm modules of course but you find yourself using npm install a lot less. All major tools have cljs wrappers that are just a joy to use (looking at reagent (react), re-frame (redux), om (react+graphql)
keymone 10y ago
one thing i disagree with is how functional programming concepts are equated to all the bullshit javascript ecosystem has grown to be.
- ChoHag 10y ago
  I didn't think they were equated. I got rather a sense of exasperation that javascript includes them at all.
mwexler 10y ago
I couldn't help but yell "Third Base!" at the end of this. https://en.wikipedia.org/wiki/Who%27s_on_First%3F https://en.wikipedia.org/wiki/Who%27s_on_First%3F
SadWebDeveloper 10y ago
> Oh, like Bower! > Oh, like Angular! IMHO if you know about those you pretty much most of the terminology the "js guy" is using, personally speaking i know Angular haven't used yet bower in any project.
- 16bytes 10y ago
  If you used Bower and Angular in 2011 and disappeared for 5 years, then nearly all of the stuff that the "js guy" talks about would be new to you.
Pherdnut 10y ago
Our industry has been overrun by resume-bullet-point silicon-valley-framework-coddling noobs/whores. I have always prided myself on staying up on the latest in core web technology. It's the reason I know what a !@#$ing tragic waste most of these idiotic frameworks are. jQuery had the DOM covered and is in fact now redundant itself and could be managed with a much, much lighter lib that spends a lot less time normalizing assuming you're dropping support for browsers even Microsoft no longer covers. LESS and SASS were good for vars and should have stopped there. Standard browser support is finally in the works for that. But you certainly don't need both and for FFS you're just making an unmaintainable styling mess using all of the other features, especially (noob, please), nesting which needlessly adds to selector count like nobody's business. We do NOT need to ASP/JSPify the DOM. Keeping content/structure code separated from the behavior code was the reason proper front end devs were running circles around Java/ASP.net devs. What the fucking fuck is the point of adding your own custom tags to HTML, which already had a perfectly serviceable approach to binding behavior to it? Or creating an XML-like syntax you mix/match directly with your JS? Silicon valley noobs, please. I had lazy loading scrollable tables that could handle 50,000+ lines of data back when Google Docs was choking on 2,800. This shit is not hard. Stop wining and spend the time you apply to learning frameworks with next to no core technology understanding to actually learning the technology you have before you start adding pointless layers that solve nothing on top of what's already there and you'll be shocked at how not-hard it can really be. Or let's not. Let's load a massive freaking ridiculous CSS and JS library by the Twitter devs, because, yes, surely they know through their work with a site that essentially boils down to a single text area, a great deal about handling complex layout and UI concerns. AMD for a web app? Okay, I can see it, certainly for non-trivial SPAs , which NOT EVERY SITE NEEDS TO BE. But first, how complicated is this web app? If not-very, why were people struggling with linking scripts in the right order? Why did they need to link so many damn things to get the job done in the first place? And FFS, it's just "data-binding." Calling it "Two-way" is redundant and makes you sound like a jackass who doesn't know what the fuck is actually happening. And it's just a pattern. And not a very hard one to implement. MVC and MV? are great. Really, whatever the fuck keeps data separated from an app layer from your DOM-handling is fantastic. Frameworks that make it easy to follow such patterns in a way that all developers can become familiar with are great too. But sweet JavaScript Jesus why won't they just stop there? We used to laugh at Java developers. What the fuck are we doing to ourselves? Why haven't I gotten an honest to god core web technology or native JavaScript question at an interview in like 3 years? We have indeed, ruined JavaScript. Thanks a lot assholes.
Globz 10y ago
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.
drumttocs8 10y ago
Psst... Meteor solves the entire build process for you... you can use React with it now... it integrates with npm now... you can use Apollo with it to connect to any type of database...
laacz 10y ago
As a person who has to build a relatively simple webapp from time to time, it's tiresome. I usually take a look around - what's trendy. It results into lost night, since I learn that everything requires two times more stuff than six months ago. In the end I go with vanilla JavaScript and whatever new APIs I can use and polyfill. No, wait. I made a webapp with React. While occasionally seeing Flux and friends mentioned, I was strong. I went with vanilla ReactJS. I mean, those web stacks just get obsolete too soon. Your super tuned gulp setup will be obsolete in a year or two. What will you do then? Re-learn all new things? It seems to me that there is a frontend development stack bubble coming. When I had to change bootstrap's base font size, I had to download and learn awful amounts of stuff. Which is on my machine. And I will never use it again.
rcarmo 10y ago
Wow. 140+ comments and nobody mentioned the Python 3 jab :) Seriously now, I gave up front-end stuff when it began requiring me to use Node to bundle files together, and find it terrifying to see Yeoman used as a code generator for non-JS runtimes and frameworks... building software atop quicksand (be it frameworks or libraries) that shift every week is insane, and it feels like the modern day version of just-in-time job security. My use of thumb these days is to not use more JavaScript than what I can read in one sitting, unless a) it's D3 or a similar single-purpose library and b) I get a Docker container to run npm and all its funk inside that I NEVER have to look inside of. My dream is that JavaScript dies and that the industry moves to something like Elm, ClojureScript or TypeScript, with a functional and/or hard typed approach.
hiester 10y ago
Like a lot of 21-year-olds, javascript has gotten big and strong, but its brain hasn't finished developing yet. It hasn't figured out what it wants to do with its life. It engages in binge drinking a little more than is healthy. It's sowing its wild oats. Didn't we all when we were 21 (or didn't we wish we did)? It has 3000 Facebook friends. Last year it had a best friend, but now it's hanging out with someone else and doesn't even talk to that other one any more. It's kind of preoccupied with being cool and popular. Young adults can be very self-conscious and anxiety-ridden. Constantly checking its status on social media ("OMG, I wonder what I look like on iOS 10?") probably isn't helping things. Still, it's really smart and helpful and has a lot of talent. Give it time. Cut it some slack. It will find its way, make something of itself, and make you proud. You'll see.
anta40 10y ago
The last time I touch JS was probably many years ago, while learning web development in the university. I mostly write desktop+native mobile apps, and without doubt my JS skill is very rusty :( Any suggestions how to catch up with JS trend nowadays? JS for web dev is pretty much unavoidable, right?
partycoder 10y ago
Web development is very volatile. It is also a discipline that lowered its entry barrier a lot, and now coding camps are producing a deluge of graduates, all of them attracted by the promise of a 6 figure salary. Even if pessimistically only 10% of them are good, they graduate every 14 weeks compared to 208 weeks for a CS graduate. As of 2016, learning JavaScript might be very profitable, but I wonder for how much longer.
pdonorio 10y ago
I was moving from Full Stack to Backend/DevOps without even noticing, in the last six months. At least with this post I can now admit it to my self and explain why to others on LinkedIn.
DiegoZoracKy 10y ago
This article is very good and sums up very well a feeling that a lot of us is having right now. However, i think that title is throwing an error, as the article is not about learning JavaScript, but, only about learning Front End. I wrote a little about it here: https://medium.com/@DiegoZoracKy/stop-blaming-on-javascript-when-all-you-want-is-to-talk-about-front-end-73ff19fef861 https://medium.com/@DiegoZoracKy/stop-blaming-on-javascript-...
DiegoZoracKy 10y ago
This article is very good and sums up very well a feeling that a lot of us is having right now. However, i think that title is throwing an error, as the article is not about learning JavaScript, but, only about learning Front End. I wrote a little about it here: https://medium.com/@DiegoZoracKy/stop-blaming-on-javascript-when-all-you-want-is-to-talk-about-front-end-73ff19fef861 https://medium.com/@DiegoZoracKy/stop-blaming-on-javascript-...
scotty79 10y ago
I'm getting away with npm, webpack, typescript, babel and react (with jsx) with some lo-dash. Never learned browserify, barely grunt and bower, happily forgot thorough knowledge of gulp. Actively pushed out all of the awfulness of angular.
davidjnelson 10y ago
My comment from the medium post: I think the key takeaway here is: a) requirements suck always, b) figure out what the real problem is that needs to be solved, c) fashion your solution to the unique needs and culture of the team you are a part of. Computers are hard. I’ve been specializing in front end stuff for 4 years and it still took me a month to master the react ecosystem. It’s better than anything that came before it though by a landslide. People whine a lot expecting everything to be easy. There is a laundry list of classic cognitive distortions present in these types of articles. If this is literally your only requirement and no new features will ever be added: “create a page that displays the latest activity from the users, so I just need to get the data from the REST endpoint and display it in some sort of filterable table, and update it if anything changes in the server”. Which I highly doubt, but let’s go with that premise. What you’d really want is to be step back and look at the needs of the app. The real needs are websockets for real time, and a way to tail the oplog of the database you are using to get the latest data pushed without needing to have the websocket proxy you’ll setup poll on the server side. The front end implementation is fairly irrelevant here, IF nothing ever changes ( yeah right ). If that is truly the case ( it’s not, believe me ), then just use a jquery datatable plugin which updates it’s data when new websocket data comes in. That’s like 100 lines of code, done. If you’re using mongo it’s not too hard server side because you tail the oplog, the way meteor does. If you’re using something else you might have to poll server side to get the new data, which is honestly the hardest part of this problem. The front end of this is not the issue frankly based on the requirements presented. This is IF this is all a one off project that never changes and will never need new features or bugfixes. If it ever needs to be changed, you do benefit a lot from using more modern technologies so instead of a lump of jquery spaghetti you have clean component api boundaries which can be easily unit tested and modified in isolation without breaking other areas of the app. Every situation is different. As presented, this is more of a server side problem than a front end problem. What data stores are you using, how are you going to get that data in real time, how are you going to set up a web socket server, how are you going to scale said web socket server etc. I think that blog post comes off as attacking the wrong problem and complaining that computers are hard. It doesn’t appear the requirements were clearly understood and evaluated. Picking the right tool for the job is really a thing. Dogma is dangerous in software for sure. On that point, I agree.
geddski 10y ago
I wrote a post that might help anyone feeling overwhelmed about all the things to learn: What Not to Learn http://gedd.ski/post/what-not-to-learn/ http://gedd.ski/post/what-not-to-learn/
StokeMasterJack 10y ago
That article could have been shorted to: I'm old.
StokeMasterJack 10y ago
I have no patience for this kind of article. Here is the fundamental essence of the article that drives me nuts: the assertion that the reason someone would move to one of these new technologies is because "it's trendy" or "everyone is doing it", "or angular is so 2015", "it's for hipsters". This is the standard mantra of old people everywhere who are too old to learn new stuff. If the guy would have taken the time to learn the purpose of these tools, their pros and cons, and why one would choose to use them or not use them, that would be interesting. But that would take a bit more time. And actually learning something new. While I emphasize with old people who feel the world is moving too fast (I am one of them), I have no tolerance for the basic anti-logic of the article: the assumption that new technology only exists because of trendy hipsters who just like change for the sake of change. This logic only exists to soothe the mind of old people who don't want to learn new things.
avesus 10y ago
Some parts of the article go too far (developers finding their own ways to make things, continuously), but common idea of using Babel and writing in modern JS is prevalent - because you have to use a bundler to concatenate source code and import dependencies. But using a bundler feels like a compile step - and it's so easy and desirable to add another step and enable modern JavaScript ES2016+ in your web app. And this part is now a standard de-facto, but some people use make, others gulp, I happy with npm run or just bash scripts. But common idea of bundling and JS compiling holds true for all developers. Actually, not yet completely solved problems in terms of consensus how to do things stay here: delay loading (login form/admin panel/main app code or features separation), component assets dependencies, modular CSS, and, of course, frontend and server side architectures with CycleJS, Elm, SAM, Redux, Angular 2 as candidates but those yet have unsolved problems: either work slow (and making simple app's size more than 1 MB zipped) or you have to write some boilerplate of source code lines. And comparing side there, of course, ability to componentise infinitely and hierarchically. And for accessing data GraphQL emerges as hot modern technology. And a lot of other cool things to keep tracking every day... It never stops, growing larger and allowing to reuse all third-party dependencies (beside of components - every team mostly prefers writing their own, because those play better with their chosen software architecture) and constantly rewriting your own source code.

okket 10y ago

Loosely related: "The S stands for Simple" http://harmful.cat-v.org/software/xml/soap/simple http://harmful.cat-v.org/software/xml/soap/simple

mturmon 10y ago
This is insightful. Of course, the OP is consciously playing off the earlier app-deployment spoof (https://circleci.com/blog/its-the-future/ https://circleci.com/blog/its-the-future/). But this earlier spoof may well be based, intentionally or not, on the SOAP piece you linked -- which was a hit on HN 7 years ago (https://news.ycombinator.com/item?id=2079631 https://news.ycombinator.com/item?id=2079631). Thus prompting the observation and related question: These three areas - front-end, deployment, RPC - seem to have engendered a churn in standard approaches, and a corresponding cultish devotion to certain toolkits -- leaving them open for satire. But yet, there is also a need for a guru to explain WTF to do, because a lot of practitioners need to get these jobs done. So, what is the deeper parallel between the areas? E.g., a lot of corporate resources suddenly poured into these problems, and everyone is funded to come up with, and promote, their own solution?

jlas 10y ago

Reminds me of https://circleci.com/blog/its-the-future/ https://circleci.com/blog/its-the-future/

egwynn 10y ago
FTA The following is inspired by the article “It’s the future” from Circle CI. You can read the original here (https://circleci.com/blog/its-the-future/).
ABoldGambit 10y ago
Ahhh I wondered why I was having massive deja vu reading OPs article! Both great posts.

jftuga 10y ago

This has to be one of my favorite HN posts of the year.

deleted 10y ago

[deleted]

gadrev 10y ago

This was actually a didactic piece. While criticizing the current state of affairs, it gives a nice overview of many of the emerging technologies and how they fit together, even if for some tasks it feels retarded to pull such an entangled mess of dependencies. You can then go insane diving into any particular one :)

brlewis 10y ago
Yes, but I really don't like the "How it feels to learn Javascript" title. Realistically you wouldn't give such a wide array of options to someone who wants to learn how to accomplish something specific.
- ajmurmann 10y ago
  Yes, realistically if you were to have a conversation with an experienced advisor like the article is staging that wouldn't happen. However, the article reflected exactly how I felt trying to do more JS again a few months ago after not having done much JS for a few years.
pbh101 10y ago
Being primarily a Java dev, it felt to me like half of this was critiquing the churn rate of using different tools (warranted) and the other half was lamenting the fact that people built tools to solve the common problems they have when developing in large teams (largely unwarranted). Most of those tools have direct equivalents in the Java ecosystem (and there is tool-churn in Java too, just slower). Facebook, Google, large startups, and the others which are building these tools are doing so to solve the problems they experience in their teams' front-end dev processes. Ironing out the kinks in the code assembly line. And they are of course doing so in a path-dependent fashion: add tool N+1 to solve problem N+1 given the existing toolchain. The result is a lot of tools and a lot of context to imbibe at once, but it doesn't mean they are solving nonexistent problems. Just problems you don't have, or don't know you have, or don't have yet, or can afford to leave unmanaged when developing a small site with just a couple people.
- 10y ago

egwynn 10y ago

See also: https://medium.com/@boopathi/it-s-the-future-7a4207e028c2 https://medium.com/@boopathi/it-s-the-future-7a4207e028c2

btym 10y ago
I knew I'd read this somewhere before!

buckbova 10y ago

"It’s 2016 man, no one uses jQuery anymore, it ends up in a bunch of spaghetti code. Everyone knows that." I prefer "jQuery soup."

patmcguire 10y ago

Reminds me of "starting Rails today is like starting to watch a soap opera in the 7th season" http://words.steveklabnik.com/rails-has-two-default-stacks http://words.steveklabnik.com/rails-has-two-default-stacks Be thankful, at least it's not 2013, the new-js-framework-on-the-front-page-of-HN-every-day era.

choicewords 10y ago
I remember when there was a huge fight in Rails to change JS framework. Seems quaint now.
gremlinsinc 10y ago
yeah many old-timer rails folks will say skip rails and use Phoenix instead lol.. for concurrency and all.

tibbon 10y ago

This is pretty much why I don't do front-end. I'm fully capable of it, but I just don't like keeping up with this flavor-of-the-week. It just doesn't feel like programming to me, or at least not the programming I enjoy. Strangely, I see so many new developers rushing toward the front-end, which seems much more complicated in many ways than just building solid web API services, analyzing data, etc.

choicewords 10y ago
There is a money issue. If you do keep up, you'll get amazing job offers. If you manage to really be on the edge, you can give talks as well, expose yourself as a consultant. That's much easier in JS than with Ruby, Python or whatever else.
- tibbon 10y ago
  Fair enough. I've hit a sweet spot now in having done Ruby for ~8 years, so I can get away with saying, "having someone else deal with the front end. I just want to talk about data". The new problems I'm working to learn to solve are with ML, NLP, etc. I'd like to step away from web services completely soon, and just live completely with data.
  - choicewords 10y ago
    I'm in the same boat. I'm no longer interested in the plumbing, much more the type of questions that can be answered with large scale data, and other types of efficiencies that are dormant with 'pure' code.
  - gettersetter 10y ago
    I am curious, how did you transition into ml, nlp. I am thinking of transitioning to ml, as work is getting kind of boring for me, but most job requires at least a master in the relevant field. I am self studying right now, maybe going back for a master, but I felt I lack alot of necessary probability and linear algebra theorems. I can code svm, neural network from nothing. I understand basic markov chain, bayes network, but that is really just scratching the surface. Any recommendations?

imgabe 10y ago

I guess I'm behind the times in that I still use jQuery. Is it really worthwhile to go through everything described in this article to create a simple filterable table?

jordache 10y ago
if ALL you are displaying is a table, then you can write a quick little jQuery(or native JS) function to remap the array and re-draw the DOM. If your fancy little table is part of a large app, or even a simple app, it is much easier to implement the entire app using a framework like Angular. The model view concepts really help to tie things together.
- zzalpha 10y ago
  Your use of the word "easier" is questionable. Even for trivial SPAs it's often easier to roll the basic functionality yourself. Flipping over to something like Angular introduces technical and cognitive overhead that often isn't worth the trouble for something simple.
  - jordache 10y ago
    What about maintainability? You want everyone who touches your code to figure out your custom solution for data binding? Or you could just follow the conventions established by an industry popular framework that is instantly consumable by another developer?
    - zzalpha 10y ago
      Seriously? If your application become sufficiently complex that it can't be easily grokked by a decent dev, that's when you know it's time to switch. Until then it's just over engineering (which the JS community admittedly loves).
      - jordache 10y ago
        what is that complexity threshold? Self determined no doubt. Guy A believes his custom design is simple enough to comprehend by anyone. Guy B doesn't agree. It doesn't really matter at the end of the day. If you work in a team environment, the toolset will be pre-determined already. You don't have a choice.

gremlinsinc 10y ago

I'm looking into react, and I fix things in legacy code, but that's still mostly jquery, or native js. But backend I just get things done.. I much prefer working on teams where there are 'specialists' who do all the frontend and I just give them an API to feed into it.

maxlambert 10y ago

Hilarious article, but seriously, can somebody tell me where I should begin learning all of this stuff? What are the 2 or 3 top-priority things I should get started with, if I have experience with Django/HTML/JQuery, and want to expand into more advanced frontend programming?

threatofrain 10y ago
Have you looked into stateless React + Redux? These libraries are interesting in their suggestions for app architecture, and their api's are minimal. One day perhaps React and Redux will be replaced by something else, but I think the strategy of a GUI functional layer consuming a stream of events is here to stay, and I wouldn't be surprised if it spread to native app design.

dhruvkar 10y ago

I couldn't get through the entire thing. Even knowing that it's a fun/sarcastic piece of writing, the portrayed pain is all too real, as someone just starting to dive into the front-end. In all honesty, can I still use jQuery for new projects without issues in 2016? Is there a real reason not to?

vinceguidry 10y ago
Yes, you can. No, there's no real reason not to. But honestly, I'd go with React if you can. The reason is, if the app starts taking off, and you end up with a team maintaining your app, you're much less likely to end up with an unmaintainable mess in two years than if you use just jQuery. All applications, especially websites want frameworks. The framework is essentially a way to organize the massive amount of complexity boiled in. If you just roll with libraries, then you end up cobbling together a framework on top of it. You will then have to maintain this framework. This is fine when it's just you, it will coalesce into a bunch of conventions that's fairly easy for you to reason about. But once you start involving others, then you're going to see your nice conventions get rekd like a bull in a china shop. Not everybody sees problems the same way you do. If you pick the framework beforehand, then you don't need to maintain it, you can let the nice people at Facebook / Google do it for you. And whenever you finally get others involved, they're limited in the amount of architectural damage they can do because they have to stick to the conventions of the framework.
- thatswrong0 10y ago
  I agree - I think React is simple enough that there's no reason not to besides the overhead of JSX preprocessing (which I suppose isn't required but I would definitely recommend). It really is more of a library than a framework, which is great for starting out because there are fewer concepts to understand. Then when you start adding more people and your application gets more complicated and you need to manage your data flow in a more consistent way, you can add something like Redux after the fact incrementally. As long as you don't let components become too large, refactoring isn't too difficult.
  - 10y ago

sotojuan 10y ago

I'm in a weird position where I like JavaScript and Node but dislike frontend (or at least I am disliking it more and more). With Node, I can get quite far with just a couple of dependencies that install quickly. I don't need transpilation unless I want to use TypeScript or PureScript and I can target any version I want. I find it very fun to mess around with Node and a bunch of little modules. I am slowly "transferring" back to server-rended pages using Node or Elixir. Probably not good for my employment (even in NYC most JS jobs are frontend), but whatever. If I was learning JS right now and didn't care about employment I'd just learn Node (which just means learning JS really) and experiment with stuff.

cycomachead 10y ago
JavaScript, admittedly, has a few more quicks than the average language but I quite like it. I know a lot of people who also feel the same way. (And as many how, of course, hate JS.) It still feels to me like we're in the early days of node and the dev infrastructure for "modern" sites. Hopefully, things stabilize soon(ish).

vladimir-y 10y ago

Article title is absolutely not correct, front-end developer is supposed to build an entire UI and corresponding client-side logic, not just write some abstract JavaScript code, code itself is nothing. So it's not about write JS code, but about building maintainable and scalable applications. All that stuff is actually required to build something maintainable, especially modules. React is not a silver bullet, but nowadays SPA and components approach should be familiar for any front-end developer. I like Typescript was mentioned there.

krylon 10y ago

This makes me think of a sentence I read years ago: "We love to fight complexity with complexity." I think whoever said this referred to the various IPC methods on Windows, but I do not remember for sure. Seems like some things never change.

at-fates-hands 10y ago

You also have to keep in mind a few things: 1 - I've never referred to myself as an "engineer" since I don't see myself as one, nor do I have an engineering degree. This includes the fact I do not have a four year CS degree either. 2 - Front end development has now split. Being a web "designer" means you know HTML5, CSS3 which includes LESS, SASS, PostCSS and other CSS pre-procssors 3 - Being a web "developer" means you're more likely to be a Javscript developer. Meaning you're familiar with Angular, Backbone (I know its soooo 2014 isn't it?), React and other JS frameworks. Every interview I've done in the past two years has almost exclusively focused on JS and how well I know standard JS. Closures, inheritance, debugging, etc. Nobody cares if you know much else other than that.

Pherdnut 10y ago
Where are you interviewing? All I get is Angular and React questions for interviews where I stated up-front to the initial contact that I'm no expert on either and have tended to stay focused on core technology developments when studying on my own time.
Pherdnut 10y ago
There is no excuse for not knowing CSS as a front end/UI developer. That so few know much of anything about it nowadays, or think they don't actually need to is tragic, IMO.

tempodox 10y ago

It's bad enough the facts on the ground make it a virtual impossibility to circumvent JS altogether. The best we can do is always wearing gloves when handling it and to never write it manually. JS, for the oversimplified thing it is, is just systematically overextended with the loads it has to carry now. No framework on earth will make that go away. And neither will ES6.

romaniv 10y ago

And to think that I went into web dev precisely to avoid dealing with complex build chains and horrible UI libraries...

Cthulhu_ 10y ago
That's because when you started, all of the complexity was in the back-end; this has moved to the front-end, with backends becoming simpler and more focused on providing data.
- romaniv 10y ago
  The overall complexity was still order of magnitude smaller. There were no transpilers, shims, or complicated multi-step builds, and I knew every single library I was using.

mgrennan 10y ago

This is what happens when management gives up and turns IT to developers. And I believe that happened when accountants took over because of Sarbanes Oxley. The accountants had no idea what they where getting into. Then the Tech Bubble happened and $$$ filled their eyes. Developers became GODs and now... This happened.

OtterCoder 10y ago

Takeaway: use Elm.

alexmuro 10y ago

If you are doing a simple project, there is nothing wrong with just using jquery (or imho d3). If you know that your project is always going to be pretty simple or especially if you are learning. I have been teaching a number of people javascript at my lab lately and I think its unwise to teach new javascripters using any of the modern tools or transpiling until someone runs into one the problems that those tools solve. Having been a javascript coder consistently from the jquery days until now, I am not pining for the simple old days of yore. It can be hard to learn everything that goes into a big front end app these days but when used correctly all those tools are there for a reason.

mpwoz 10y ago
This needs to be higher. You shouldn't use any of these tools just because people tell you to. If you can't see what problem something solves, then start at a simpler/lower level of abstraction until you run into that problem, and can appreciate the tool that solves it. Of course, this advice doesn't apply if you actually need to write a production app, and aren't just playing around for learning purposes :)

ilostmykeys 10y ago

If you stay on the surface and follow trends you will think front end web development is insanity inducing. But if you go deeper, develop your own thinking and deep patterns you will realize that the web platform is doing just fine and is progressing better than most languages/platforms out there.

_Marak_ 10y ago

I've found using Babel / React / transpile tool-chain is actually fairly impossible to use for the majority of developers. I've given up on it several times in favor of plain-ole-javascript and jQuery. The amount of time it takes to ramp-up on the technical knowledge isn't insurmountable. The main issue is bloat in both code size and dependency chain instability. On a slow connection, you might find yourself battling against your tool chain for half the day. In the case you actually hit a code problem with the underlying technologies, it's going to be hours if not days searching Github for the patched version of the module. If you actually are able to path the specific dependency, it will probably break something else. I do have hope though. We are starting to see a lot of really cool Babel / React components and projects. I think with a bit more time, we'll get stability in the eco-system as there are less deltas to the underlaying code dependencies and the browser vendors catch up with ES7 features.

istjohn 10y ago

This was spot on for me as a hobbyist who has returned to JS after a hiatus of roughly 3 years. On the one hand, it's exciting to see JS evolving into a sophisticated language with dozens of new constructs specced out. On the other hand, as a casual enthusiast I feel trapped between using a small subset of the features available, or wrestling with a tangle of temporary crutches while implementations catch up with the new standards.

voidfunc 10y ago

Just a couple days I got into a conversation with my coworker about UI stuff. I had to test something against our dev UI. Last time I did UI work was back when having index.html, img/, css/ and js/ directories with maybe a script or two was the norm. I had to fucking run make and I still have no fucking idea what was going on when I ran make which compiled a bunch of shit. There was all this NPM shit going on (isn't NPM part of Node.js which is a server-side framework? WTF?). I got it working and promptly noped the fuck out that horror show. The web is a giant fucking pile of dog shit in 2016.

arctangent 10y ago
It doesn't have to be this way. Unfortunately, we live in a world where younger developers "show their skill" by making things overcomplicated in order to create unnecessary barriers to entry to our proto-profession. My usual response is to refuse to work on such a project if I don't have the authority to change how things are done to make them more sane.
- ocfx 10y ago
  Yeah because refusing to work on projects because of tooling selection gets you far in life...
- minitech 10y ago
  “make and npm” doesn’t sound overcomplicated. It sounds like someone didn’t take the time to find out what they were working with, didn’t really need to because it’s not their area, and decided to have an opinion about it anyway.
- rbanffy 10y ago
  > in order to create unnecessary barriers to entry to our proto-profession. I wouldn't say it's malice. I think they simply don't know better.
  - meddlepal 10y ago
    Agreed. Possibly a consequence of the ageism in our industry too.

deleted 10y ago

[deleted]

adamrezich 10y ago

Cross-posting my comment from reddit: I don't know about anyone else, but the problem I personally have with the crazy, messy JavaScript ecosystem is: - I am a relatively experienced amateur programmer (with limited [nine months] professional experience) - I can learn any new programming language, library, methodology, or whatever pretty easily - I don't have any formal experience using anything of this newfangled stuff; like the author of the article, my frontend experience involves plain ol HTML/CSS/JS, with a little jQuery to make things easier - nobody wants to hire me unless I have `n` years experience with newfangled language/framework/methodology `x`, `y`, and `z` - I don't have a CS degree Unless you're a massive operation like Facebook or something... just give me a week to look through your website's codebase, I'll figure out how you guys do things and I'll start being productive before you know it. If you're using stuff that I've never used before, I'll learn it. I should be a more attractive hire than someone who has `n` years of experience only using `x`, `y`, or `z`, because the way I think about getting things done with computers isn't tied down to any one specific framework... but it seems that this isn't how hiring works in the industry right now... which is directly at odds with the rapidly-changing nature of web development! As a result, I don't feel inclined to learn any of this new crap. What's the point? Apparently I should've learned it all `n` years ago, and it's too late now?

nikdaheratik 10y ago
It sounds like your gripe isn't with the knowledge base, but with the people doing the hiring. The issues there are very real in that, if you're dealing with a non-trivial codebase, there's no way to tell whether someone with very little real world experience is a competent programmer or just "faking" until you've got them working on it for a few weeks, and even then they may not be worth the time you put into training them until a couple of months down the line. And the people in HR for most organisations don't have a clue how to tell the difference. So they make up a bunch of gatekeeper requirements that allow them to filter out anyone that doesn't fit the mold early in the process. They're still likely to find someone who can do the work this way even if it means throwing out a decent percentage of other candidates. It's messed up, but it's kind of where the lack of technical knowledge in HR, and the need to avoid any potential lawsuits have left us.

realrocker 10y ago

Ok, So I have only ever done backends and some android stuff,and been trying to learn building UIs. It's been hard. This post finally cleared some of the confusions I had but was afraid to ask.

voltagex_ 10y ago
I'm a (mostly backend) web dev, and I've been trying to get a simple Android app up and running - it's definitely more challenging than I'm used to.

trowawee 10y ago

It continually shocks me how much whining developers do about sometimes having to learn new things. The requirements for continued education are shockingly low (read: non-existent) in our industry, compared to other, similar intellectual/white collar industries - doctors in California are legally required to do 50 hours of CME/2 years, lawyers in California are legally required to do 25 hours of CLE/3 years, and those are both fairly standard. There are a tremendous amount of jobs out there that won't require you to learn anything new, ever, if you don't want to (think of how many thousand brain-dead Java jobs are out there). There are plenty more that will require you to learn one or two new things (any of the hundreds of consultancies and companies that picked a fairly standardized stack and work with it all the time). And then there is a tiny subset of companies that are actively working with new tech and trying new things, and a tiny subset of people actually using all of those new things. Whining about how "it's too complicated!" because someone somewhere provided you with some new programming tools for free because they thought those tools were useful and cool is an ugly look for a profession that's so prone to patting itself on the back while loudly proclaiming how forward-thinking it is.

brianvan5155 10y ago
Learning in other industries is offered in institutional settings as part of the profession. Learning in the dev world consists of aimlessly screwing around with an undocumented, unsupported, glitchy web/server stack for many many hours unpaid after you've already spent 40 hours that week putting bread on the table. The whining has less to do with the "learning" and more to do with the yak-shaving part of it torturing us endlessly in the off-hours. And, unlike in medicine and law, there is precious little professionally-written, detailed, helpful literature to help us along the way. There's just "quick install" and then a command/api reference. That is... not up to the level at which medicine and law have their industry practices & standards documented.
pdimitar 10y ago
There is always that one person that says "others have it worse, thus you're whining if you have trouble doing your job". Not a valid argument, and won't ever be. Plus don't forget our education isn't formal. Doctors and lawyers have it much, MUCH more standardized than ourselves. We the devs are pretty much do-it-alls that have to learn 95% of their skills on the go. You won't ever hear me complaining about learning things on the go. I love it. What I hate however is putting up with the lame work of people who probably can't do much more in their lives beyond tying their shoes. That's what this thread is about -- partially anyway.

chajath 10y ago

My advice would be to pick one tech stack that is prevailing in the market and master it. Once you master one you will see similar concepts been largely repeated in other frameworks.

cycomachead 10y ago

Slightly related, but if you're helping someone start out learning to code, it's worth reading this: http://pgbovine.net/programmers-talking-to-beginners.htm http://pgbovine.net/programmers-talking-to-beginners.htm You don't _need_ react to build a cool site in 2016, but if you're dead set on that, then this piece is a good intro to the set of questions that arise!

carsongross 10y ago

If you are sick of javascript on the front end, but don't want to give up the fancy-pants UI, you could do worse than my library, intercooler, which lets you add AJAX to your app with a few HTML attributes. http://intercoolerjs.org http://intercoolerjs.org Make REST work the way it was intended, supports CSS transitions, request indicators, etc. Good little library that eliminates a lot of complexity for web apps that don't need all this junk (most of them.)

commentzorro 10y ago
Just saw intercooler referenced in a post a couple days ago and took a look. It does look refreshingly simple to get started. I've got a basic app with JSON end points already created. I was going to give VUE a go but after looking at intercooler I'm going to create an alternate set of /IC/* URLS and send out HTML instead. I'll soon see how it works for this task.
- carsongross 10y ago
  I'd love to hear what your experience is. Thanks for giving it a try!
- qohen 10y ago
  Just saw intercooler referenced in a post a couple days ago and took a look. It does look refreshingly simple to get started. Aaaaaand...we've come full-circle now: Intercooler depends on JQuery, version 1.10.0 or higher. :-)
  - commentzorro 10y ago
    >Intercooler depends on JQuery, version 1.10.0 or higher. I don't have any real problems with jQuery being in the mix for intercooler. Even with that, jQuery appears to be an underlying library used for convenience rather than a library an intercooler coder would have to know and code against. I do appreciate the irony when taken in context with the original article though.

resonantjacket5 10y ago

This encapsulates my experience learning angular 2 and react these past two years. Lol

glenndebacker 10y ago

I don't use ES6 because of the cool kids, but because it makes some Javascript things more tolerable. One constructive thing that I would like to add is that the "You don't know JS" book series has really taught me a lot about the common pitfalls of JavaScript. Since then my JS stress levels have been reduced dramatically!

dvcrn 10y ago

I know the irony of introducing a new tool in the comments of this particular blogpost, but a while back I decided to completely ditch javascript and go the clojurescript route. I've been super happy ever since. The syntax is stable, clojure is extremly well designed, the ecosystem a lot clearer and tools - well you have lein as the main one and that's about it. On top of clojure, you get google closure for free and can optimize the hell out of it with advanced mode compilation out of the box. And that's the 'vanilla' experience! No separate library required! You can still interface with normal js and npm modules of course but you find yourself using npm install a lot less. All major tools have cljs wrappers that are just a joy to use (looking at reagent (react), re-frame (redux), om (react+graphql)

keymone 10y ago

one thing i disagree with is how functional programming concepts are equated to all the bullshit javascript ecosystem has grown to be.

ChoHag 10y ago
I didn't think they were equated. I got rather a sense of exasperation that javascript includes them at all.

mwexler 10y ago

I couldn't help but yell "Third Base!" at the end of this. https://en.wikipedia.org/wiki/Who%27s_on_First%3F https://en.wikipedia.org/wiki/Who%27s_on_First%3F

SadWebDeveloper 10y ago

> Oh, like Bower! > Oh, like Angular! IMHO if you know about those you pretty much most of the terminology the "js guy" is using, personally speaking i know Angular haven't used yet bower in any project.

16bytes 10y ago
If you used Bower and Angular in 2011 and disappeared for 5 years, then nearly all of the stuff that the "js guy" talks about would be new to you.

Pherdnut 10y ago

Our industry has been overrun by resume-bullet-point silicon-valley-framework-coddling noobs/whores. I have always prided myself on staying up on the latest in core web technology. It's the reason I know what a !@#$ing tragic waste most of these idiotic frameworks are. jQuery had the DOM covered and is in fact now redundant itself and could be managed with a much, much lighter lib that spends a lot less time normalizing assuming you're dropping support for browsers even Microsoft no longer covers. LESS and SASS were good for vars and should have stopped there. Standard browser support is finally in the works for that. But you certainly don't need both and for FFS you're just making an unmaintainable styling mess using all of the other features, especially (noob, please), nesting which needlessly adds to selector count like nobody's business. We do NOT need to ASP/JSPify the DOM. Keeping content/structure code separated from the behavior code was the reason proper front end devs were running circles around Java/ASP.net devs. What the fucking fuck is the point of adding your own custom tags to HTML, which already had a perfectly serviceable approach to binding behavior to it? Or creating an XML-like syntax you mix/match directly with your JS? Silicon valley noobs, please. I had lazy loading scrollable tables that could handle 50,000+ lines of data back when Google Docs was choking on 2,800. This shit is not hard. Stop wining and spend the time you apply to learning frameworks with next to no core technology understanding to actually learning the technology you have before you start adding pointless layers that solve nothing on top of what's already there and you'll be shocked at how not-hard it can really be. Or let's not. Let's load a massive freaking ridiculous CSS and JS library by the Twitter devs, because, yes, surely they know through their work with a site that essentially boils down to a single text area, a great deal about handling complex layout and UI concerns. AMD for a web app? Okay, I can see it, certainly for non-trivial SPAs , which NOT EVERY SITE NEEDS TO BE. But first, how complicated is this web app? If not-very, why were people struggling with linking scripts in the right order? Why did they need to link so many damn things to get the job done in the first place? And FFS, it's just "data-binding." Calling it "Two-way" is redundant and makes you sound like a jackass who doesn't know what the fuck is actually happening. And it's just a pattern. And not a very hard one to implement. MVC and MV? are great. Really, whatever the fuck keeps data separated from an app layer from your DOM-handling is fantastic. Frameworks that make it easy to follow such patterns in a way that all developers can become familiar with are great too. But sweet JavaScript Jesus why won't they just stop there? We used to laugh at Java developers. What the fuck are we doing to ourselves? Why haven't I gotten an honest to god core web technology or native JavaScript question at an interview in like 3 years? We have indeed, ruined JavaScript. Thanks a lot assholes.

Globz 10y ago

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.

drumttocs8 10y ago

Psst... Meteor solves the entire build process for you... you can use React with it now... it integrates with npm now... you can use Apollo with it to connect to any type of database...

laacz 10y ago

As a person who has to build a relatively simple webapp from time to time, it's tiresome. I usually take a look around - what's trendy. It results into lost night, since I learn that everything requires two times more stuff than six months ago. In the end I go with vanilla JavaScript and whatever new APIs I can use and polyfill. No, wait. I made a webapp with React. While occasionally seeing Flux and friends mentioned, I was strong. I went with vanilla ReactJS. I mean, those web stacks just get obsolete too soon. Your super tuned gulp setup will be obsolete in a year or two. What will you do then? Re-learn all new things? It seems to me that there is a frontend development stack bubble coming. When I had to change bootstrap's base font size, I had to download and learn awful amounts of stuff. Which is on my machine. And I will never use it again.

rcarmo 10y ago

Wow. 140+ comments and nobody mentioned the Python 3 jab :) Seriously now, I gave up front-end stuff when it began requiring me to use Node to bundle files together, and find it terrifying to see Yeoman used as a code generator for non-JS runtimes and frameworks... building software atop quicksand (be it frameworks or libraries) that shift every week is insane, and it feels like the modern day version of just-in-time job security. My use of thumb these days is to not use more JavaScript than what I can read in one sitting, unless a) it's D3 or a similar single-purpose library and b) I get a Docker container to run npm and all its funk inside that I NEVER have to look inside of. My dream is that JavaScript dies and that the industry moves to something like Elm, ClojureScript or TypeScript, with a functional and/or hard typed approach.

hiester 10y ago

Like a lot of 21-year-olds, javascript has gotten big and strong, but its brain hasn't finished developing yet. It hasn't figured out what it wants to do with its life. It engages in binge drinking a little more than is healthy. It's sowing its wild oats. Didn't we all when we were 21 (or didn't we wish we did)? It has 3000 Facebook friends. Last year it had a best friend, but now it's hanging out with someone else and doesn't even talk to that other one any more. It's kind of preoccupied with being cool and popular. Young adults can be very self-conscious and anxiety-ridden. Constantly checking its status on social media ("OMG, I wonder what I look like on iOS 10?") probably isn't helping things. Still, it's really smart and helpful and has a lot of talent. Give it time. Cut it some slack. It will find its way, make something of itself, and make you proud. You'll see.

anta40 10y ago

The last time I touch JS was probably many years ago, while learning web development in the university. I mostly write desktop+native mobile apps, and without doubt my JS skill is very rusty :( Any suggestions how to catch up with JS trend nowadays? JS for web dev is pretty much unavoidable, right?

partycoder 10y ago

Web development is very volatile. It is also a discipline that lowered its entry barrier a lot, and now coding camps are producing a deluge of graduates, all of them attracted by the promise of a 6 figure salary. Even if pessimistically only 10% of them are good, they graduate every 14 weeks compared to 208 weeks for a CS graduate. As of 2016, learning JavaScript might be very profitable, but I wonder for how much longer.

pdonorio 10y ago

I was moving from Full Stack to Backend/DevOps without even noticing, in the last six months. At least with this post I can now admit it to my self and explain why to others on LinkedIn.

DiegoZoracKy 10y ago

This article is very good and sums up very well a feeling that a lot of us is having right now. However, i think that title is throwing an error, as the article is not about learning JavaScript, but, only about learning Front End. I wrote a little about it here: https://medium.com/@DiegoZoracKy/stop-blaming-on-javascript-when-all-you-want-is-to-talk-about-front-end-73ff19fef861 https://medium.com/@DiegoZoracKy/stop-blaming-on-javascript-...

DiegoZoracKy 10y ago

scotty79 10y ago

I'm getting away with npm, webpack, typescript, babel and react (with jsx) with some lo-dash. Never learned browserify, barely grunt and bower, happily forgot thorough knowledge of gulp. Actively pushed out all of the awfulness of angular.

davidjnelson 10y ago

My comment from the medium post: I think the key takeaway here is: a) requirements suck always, b) figure out what the real problem is that needs to be solved, c) fashion your solution to the unique needs and culture of the team you are a part of. Computers are hard. I’ve been specializing in front end stuff for 4 years and it still took me a month to master the react ecosystem. It’s better than anything that came before it though by a landslide. People whine a lot expecting everything to be easy. There is a laundry list of classic cognitive distortions present in these types of articles. If this is literally your only requirement and no new features will ever be added: “create a page that displays the latest activity from the users, so I just need to get the data from the REST endpoint and display it in some sort of filterable table, and update it if anything changes in the server”. Which I highly doubt, but let’s go with that premise. What you’d really want is to be step back and look at the needs of the app. The real needs are websockets for real time, and a way to tail the oplog of the database you are using to get the latest data pushed without needing to have the websocket proxy you’ll setup poll on the server side. The front end implementation is fairly irrelevant here, IF nothing ever changes ( yeah right ). If that is truly the case ( it’s not, believe me ), then just use a jquery datatable plugin which updates it’s data when new websocket data comes in. That’s like 100 lines of code, done. If you’re using mongo it’s not too hard server side because you tail the oplog, the way meteor does. If you’re using something else you might have to poll server side to get the new data, which is honestly the hardest part of this problem. The front end of this is not the issue frankly based on the requirements presented. This is IF this is all a one off project that never changes and will never need new features or bugfixes. If it ever needs to be changed, you do benefit a lot from using more modern technologies so instead of a lump of jquery spaghetti you have clean component api boundaries which can be easily unit tested and modified in isolation without breaking other areas of the app. Every situation is different. As presented, this is more of a server side problem than a front end problem. What data stores are you using, how are you going to get that data in real time, how are you going to set up a web socket server, how are you going to scale said web socket server etc. I think that blog post comes off as attacking the wrong problem and complaining that computers are hard. It doesn’t appear the requirements were clearly understood and evaluated. Picking the right tool for the job is really a thing. Dogma is dangerous in software for sure. On that point, I agree.

geddski 10y ago

I wrote a post that might help anyone feeling overwhelmed about all the things to learn: What Not to Learn http://gedd.ski/post/what-not-to-learn/ http://gedd.ski/post/what-not-to-learn/

StokeMasterJack 10y ago

That article could have been shorted to: I'm old.

StokeMasterJack 10y ago

I have no patience for this kind of article. Here is the fundamental essence of the article that drives me nuts: the assertion that the reason someone would move to one of these new technologies is because "it's trendy" or "everyone is doing it", "or angular is so 2015", "it's for hipsters". This is the standard mantra of old people everywhere who are too old to learn new stuff. If the guy would have taken the time to learn the purpose of these tools, their pros and cons, and why one would choose to use them or not use them, that would be interesting. But that would take a bit more time. And actually learning something new. While I emphasize with old people who feel the world is moving too fast (I am one of them), I have no tolerance for the basic anti-logic of the article: the assumption that new technology only exists because of trendy hipsters who just like change for the sake of change. This logic only exists to soothe the mind of old people who don't want to learn new things.

avesus 10y ago

Some parts of the article go too far (developers finding their own ways to make things, continuously), but common idea of using Babel and writing in modern JS is prevalent - because you have to use a bundler to concatenate source code and import dependencies. But using a bundler feels like a compile step - and it's so easy and desirable to add another step and enable modern JavaScript ES2016+ in your web app. And this part is now a standard de-facto, but some people use make, others gulp, I happy with npm run or just bash scripts. But common idea of bundling and JS compiling holds true for all developers. Actually, not yet completely solved problems in terms of consensus how to do things stay here: delay loading (login form/admin panel/main app code or features separation), component assets dependencies, modular CSS, and, of course, frontend and server side architectures with CycleJS, Elm, SAM, Redux, Angular 2 as candidates but those yet have unsolved problems: either work slow (and making simple app's size more than 1 MB zipped) or you have to write some boilerplate of source code lines. And comparing side there, of course, ability to componentise infinitely and hierarchically. And for accessing data GraphQL emerges as hot modern technology. And a lot of other cool things to keep tracking every day... It never stops, growing larger and allowing to reuse all third-party dependencies (beside of components - every team mostly prefers writing their own, because those play better with their chosen software architecture) and constantly rewriting your own source code.