12 ms·

How it feels to learn JavaScript in 2016

499 points by objectiveariel 10y ago

okket 10y ago
Previous discussion: https://news.ycombinator.com/item?id=12628921 https://news.ycombinator.com/item?id=12628921 (19 hours ago, 108 comments)
deleted 10y ago
[deleted]
thght 10y ago
Unfortunately this is pretty accurate..
raverbashing 10y ago
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
- jomamaxx 10y ago
  The later part of your point is salient: the weird hipster 'magpie' culture in front-end programming has a lot of drawbacks.
  - talmand 10y ago
    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.
TamDenholm 10y ago
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. :(
- raverbashing 10y ago
  > 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)
  - pjc50 10y ago
    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.
    - 10y ago
Scarblac 10y ago
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.
- sotojuan 10y ago
  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.
- treehau5 10y ago
  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.
  - talmand 10y ago
    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.
  - deckiedan 10y ago
    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/ 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.
sotojuan 10y ago
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
nbevans 10y ago
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.
- eej71 10y ago
  And the result will likely be this... https://xkcd.com/927/ https://xkcd.com/927/
- brunoc 10y ago
  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.
  - nbevans 10y ago
    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.
    - bobajeff 10y ago
      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.
petetnt 10y ago
As these rehashed JavaScript versions of http://harmful.cat-v.org/software/xml/soap/simple 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.
- majewsky 10y ago
  "How it feels like to learn Machine Learning in 2025" (9 years from now, 671 upvotes, 158 comments)
peterbraden 10y ago
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.
- jomamaxx 10y ago
  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'.
- deleted 10y ago
  [deleted]
- pjc50 10y ago
  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.
  - nkassis 10y ago
    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.
triplesec 10y ago
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 https://news.ycombinator.com/item?id=12635142
awestroke 10y ago
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.
- CJefferson 10y ago
  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.
- coldtea 10y ago
  >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.
- friendlygrammar 10y ago
  I've recently decided that I'm using React for the next 3 years before I consider switching to something new.
throwmenow_0139 10y ago
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 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.
- andreime 10y ago
  I like how you phrased this. I have a similar feeling about this but I couldn't express it so clearly.
- raverbashing 10y ago
  > 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 https://github.com/expressjs/body-parser
  - marrs 10y ago
HugoDaniel 10y ago
Lucky for him he didn't ask about tests :)
tkubacki 10y ago
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)
- kingmanaz 10y ago
  Would have preferred that Google had put their resources behind something like GopherJS instead of yet another C#/Java-like, feature-creep prone language.
  - tkubacki 10y ago
    their reasoning was AFAIK - lang needs to be C#, Java like to reach mainstream web devs
jlebrech 10y ago
i miss the days of Borland where the IDE would just run darn the thing.
deleted 10y ago
[deleted]
mirap 10y ago
This article looks like some dialogue taken from Fallout 1. :)
jbb555 10y ago
I do feel that the javascript people have made C++ look simple. Not so much the language perhaps, but making programs in it..
- nkassis 10y ago
  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...
buremba 10y ago
"-Ever heard of Python 3?" (go to top)
- nayuki 10y ago
  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.
- lucb1e 10y ago
  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.
  - buremba 10y ago
    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.
Kequc 10y ago
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.
- lucb1e 10y ago
  > 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.
  - 10y ago
forthefuture 10y ago
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.
- grabcocque 10y ago
  The proliferation of frameworks is people's attempts to do something about it. But then XKCD 927 applies.
  - kzisme 10y ago
    Link for the lazy: https://xkcd.com/927/ https://xkcd.com/927/
- Eire_Banshee 10y ago
  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.
  - forthefuture 10y ago
    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.
GrumpyNl 10y ago
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.
oolongCat 10y ago
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.
scottmf 10y ago
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?
- mattmanser 10y ago
  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.
  - scottmf 10y ago
    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?
    - mattmanser 10y ago
      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.
beardicus 10y ago
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.
frigo_1337 10y ago
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.
- justinsaccount 10y ago
  > 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.
  - frigo_1337 10y ago
    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.
    - justinsaccount 10y ago
      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.
marrs 10y ago
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.
- gambler 10y ago
  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.
- kraftman 10y ago
  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)
  - wccrawford 10y ago
grif-fin 10y ago
The picture on the top sums it up.
zengid 10y ago
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.
throwawayReply 10y ago
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.
- nkassis 10y ago
  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.
programminggeek 10y ago
Sometimes jQuery is all you need. Sometimes you don't even need that.
k__ 10y ago
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.
serhat 10y ago
JS should have stayed where it was, in the browser ;D
cjhanks 10y ago
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.
shados 10y ago
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.
mckoss 10y ago
Loved the Trump-ism buried in the middle of the dialog.
jpalomaki 10y ago
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.
- shados 10y ago
  And that's why no amount of good will and side projects will make up for hard, real world experience.
chriswwweb 10y ago
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/ http://stateofjs.com/ and you will notice that there are not that many frameworks that get used by a lot of devs.
drewpc 10y ago
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?
spion 10y ago
> 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)
interdrift 10y ago
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.
Lxr 10y ago
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.
inputcoffee 10y ago
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 https://news.ycombinator.com/item?id=12627693
paradite 10y ago
In defense of JavaScript, there is an article that appeared here not long ago: http://mrmrs.io/writing/2015/07/27/too-many-tools/ 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.
jdauriemma 10y ago
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.
- dasil003 10y ago
  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.
  - jdauriemma 10y ago
    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.
vlunkr 10y ago
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
clebio 10y ago
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).
holtalanm 10y ago
"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.
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.
alistproducer2 10y ago
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.
jiaweihli 10y ago
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.
mountaineer22 10y ago
My favorite line from the article: "I need to display data on a page, not perform Sub Zero’s original MK fatality."

499 points by objectiveariel 10y ago

okket 10y ago

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

deleted 10y ago

[deleted]

thght 10y ago

Unfortunately this is pretty accurate..

raverbashing 10y ago

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

jomamaxx 10y ago
The later part of your point is salient: the weird hipster 'magpie' culture in front-end programming has a lot of drawbacks.
- talmand 10y ago
  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.

TamDenholm 10y ago

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. :(

raverbashing 10y ago
> 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)
- pjc50 10y ago
  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.
  - 10y ago

Scarblac 10y ago

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.

sotojuan 10y ago
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.
treehau5 10y ago
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.
- talmand 10y ago
  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.
- deckiedan 10y ago
  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/ 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.

sotojuan 10y ago

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

nbevans 10y ago

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.

eej71 10y ago
And the result will likely be this... https://xkcd.com/927/ https://xkcd.com/927/
brunoc 10y ago
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.
- nbevans 10y ago
  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.
  - bobajeff 10y ago
    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.

petetnt 10y ago

As these rehashed JavaScript versions of http://harmful.cat-v.org/software/xml/soap/simple 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.

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

peterbraden 10y ago

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.

jomamaxx 10y ago
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'.
deleted 10y ago
[deleted]
pjc50 10y ago
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.
- nkassis 10y ago
  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.

triplesec 10y ago

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 https://news.ycombinator.com/item?id=12635142

awestroke 10y ago

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.

CJefferson 10y ago
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.
coldtea 10y ago
>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.
friendlygrammar 10y ago
I've recently decided that I'm using React for the next 3 years before I consider switching to something new.

throwmenow_0139 10y ago

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

andreime 10y ago
I like how you phrased this. I have a similar feeling about this but I couldn't express it so clearly.
raverbashing 10y ago
> 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 https://github.com/expressjs/body-parser
- marrs 10y ago

HugoDaniel 10y ago

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

tkubacki 10y ago

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)

kingmanaz 10y ago
Would have preferred that Google had put their resources behind something like GopherJS instead of yet another C#/Java-like, feature-creep prone language.
- tkubacki 10y ago
  their reasoning was AFAIK - lang needs to be C#, Java like to reach mainstream web devs

jlebrech 10y ago

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

deleted 10y ago

[deleted]

mirap 10y ago

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

jbb555 10y ago

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

nkassis 10y ago
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...

buremba 10y ago

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

nayuki 10y ago
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.
lucb1e 10y ago
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.
- buremba 10y ago
  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.

Kequc 10y ago

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.

lucb1e 10y ago
> 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.
- 10y ago

forthefuture 10y ago

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.

grabcocque 10y ago
The proliferation of frameworks is people's attempts to do something about it. But then XKCD 927 applies.
- kzisme 10y ago
  Link for the lazy: https://xkcd.com/927/ https://xkcd.com/927/
Eire_Banshee 10y ago
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.
- forthefuture 10y ago
  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.

GrumpyNl 10y ago

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.

oolongCat 10y ago

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.

scottmf 10y ago

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?

mattmanser 10y ago
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.
- scottmf 10y ago
  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?
  - mattmanser 10y ago
    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.

beardicus 10y ago

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.

frigo_1337 10y ago

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.

justinsaccount 10y ago
> 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.
- frigo_1337 10y ago
  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.
  - justinsaccount 10y ago
    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.

marrs 10y ago

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.

gambler 10y ago
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.
kraftman 10y ago
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)
- wccrawford 10y ago

grif-fin 10y ago

The picture on the top sums it up.

zengid 10y ago

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.

throwawayReply 10y ago

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.

nkassis 10y ago
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.

programminggeek 10y ago

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

k__ 10y ago

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.

serhat 10y ago

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

cjhanks 10y ago

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.

shados 10y ago

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.

mckoss 10y ago

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

jpalomaki 10y ago

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.

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

chriswwweb 10y ago

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/ http://stateofjs.com/ and you will notice that there are not that many frameworks that get used by a lot of devs.

drewpc 10y ago

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?

spion 10y ago

> 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)

interdrift 10y ago

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.

Lxr 10y ago

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.

inputcoffee 10y ago

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 https://news.ycombinator.com/item?id=12627693

paradite 10y ago

In defense of JavaScript, there is an article that appeared here not long ago: http://mrmrs.io/writing/2015/07/27/too-many-tools/ 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.

jdauriemma 10y ago

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.

dasil003 10y ago
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.
- jdauriemma 10y ago
  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.

vlunkr 10y ago

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

clebio 10y ago

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

holtalanm 10y ago

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

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.

alistproducer2 10y ago

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.

jiaweihli 10y ago

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.

mountaineer22 10y ago

My favorite line from the article: "I need to display data on a page, not perform Sub Zero’s original MK fatality."