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.
Personal anecdote: I chose React as a starting point as its component model and lifecycle API just clicked better with my mind. I tried Angular 1.x and, while I liked that it defined application structure more, I couldn't motivate myself to study its component model and lifecycle. Things might have changed since Angular 2.x, but I don't want to go through a technology churn again trying it out. Then I noticed React Native plus other spinoffs like React Native for Desktop. Those projects seem fairly active and appeared to be offering mostly consistent APIs (React, JSX) for a somewhat narrower but still large set of use cases for cross-platform application development. So at that point, I decided to freeze the searches and build out the rest of the choice around it, partly based on the React community's support of the libraries and tools (Redux, Webpack, etc.)
I do catch myself getting distracted here and there checking out other libraries and tools, and they might genuinely be superior in the context of an objective, head-to-head comparison. But having built up some familiarity and skills using the current choices, I can't justify the time and attention span lost switching to another set of libraries. Afterall, by then, something even better will have come along. :)
EDIT: I wanted to just add, "The fewer APIs I have to look up in the docs to use, the better" also has been a guiding principle as well. For example, I just use Webpack for build as well as bundling, as I don't want another API in the project for the builds (like Gulp, even though devs seems to like it).
I usually see 3 categories:
- I want to learn Web Development.
- I want to learn Web Development, but in all actuality I'm going to quit in 3 days.
- I want to learn Web Development, but in all actuality I just want something working with no effort.
None of these need an informed decision. The latter 2 don't matter anyway, and the first one is better off starting with a vanilla ajax request[0], and they likely know it. When it comes down to it, "I'm going to make an app today" means your decision likely doesn't have long-term consequences and an informed decision isn't all that important. Pick up jquery like the other 80% of the living internet[1].
[0] https://webdesign.tutsplus.com/tutorials/an-example-of-ajax-...
Either way, by going through the problem solving process, you will develop some of the skills needed to recognise the motivation behind the solutions provided by 3rd party libraries and you will be in a better position to evaluate them.
Because low-level JS sucks, of course. It sucks that the DOM specifies that each node in HTML has a property .childNodes but the object that resides in that property is not an array with a .forEach() method so you find yourself either doing `Array.prototype.slice.call(x.childNodes, 0)` (in ES5, for compatibility), or `[... x.childNodes]` (in ES6 because it's prettier and more obvious what you're going for). And it sucks that HTML tables don't come with any built-in sorting mechanisms, and it sucks to be dealing with XMLHttpRequests directly. That's why these frameworks build on top of those things.
But I really think that if you're starting out, you should start out with this sucky stuff and then choose your framework based on what you learn about your pain points, rather than the other way around. If you find yourself needing to support older browsers then you will learn these cross-compilation tools; if you find yourself eventually turning it into a RESTful API written Node.js then you'll probably be OK with just ES6. Or if you find yourself writing similar sortable table widgets for the third time, you start googling "has some framework already solved this stuff?" and you eventually stumble upon the search "grid component" which will get you checking out either Vue.js, React (though you'll quickly realize that it's not native to React, there are several options there), and Ext.js, all of which have fine grid components that you might start using. Now you're doing a short research project to incorporate those things into your present workflow, which is much better than doing a long research project to decide which one of these things will be your Firm Foundation For All Things To Be Built Here.
The other huge thing about knowing plain JS is that you can start by messing with other peoples' web sites; just Ctrl-Shift-J on whatever page you happen to be on, "how would I add a little button that would replace all instances of the name 'Paul Graham' on this comments thread with the phrase 'my little pony'...? I think it would be hilarious if all these techies were talking about ponies instead."
I'm a member of the second group since, like 1995.
Right now we're on the nth cycle of lemming like enthusiasm which is currently favoring React because it just tried Angular two years ago and writing a new site with React sounds a whole lot more awesome than fixing the incomprehensible pile of crap you wrote in Angular which, guess what, seemed like a great idea at the time because of the mess you made with jquery UI.
I was choosing UE4 for technical reasons and completely ignoring my comfort with the system. I was completely unable to get motivated and it absolutely brought my mood down for that year.
Then I recently picked Unity back up (and had to learn a year or more of what I'd missed, including the new UI stuff) and it feels so much better. I'm getting things made and my mood has improved quite a bit.
I haven't completely given up on UE4, but I'm no longer trying to shoe-horn it into my development. I'll wait until it really is the right tool for the job this time.
We were building on Unity 4 and kept getting awful looking details and figured 'game engine swap' and went Cryengine. Holy shit, what a bad one. Cryengine and Unreal Engine have well-thought pipelines for asset management and they work great with professional studios that use the complete professional Adobe pipeline. Remember that Unreal Engine is a professional product being shoe-horned for indies where as Unity is an indy product now being shoe-horned for professionals.
The learning curve for React is pretty smooth, so I'd mostly check if they had experience of building the types of apps we were doing with other approaches - and whether they'd seen any ill effects from those choices.
If you have any experience in other front end frameworks, that'll usually be enough to get you through that part of the interview anyhow.
Also realise that a lot of the time the requirements are really just a wish list. I was recently sent a job spec that "required" a year of Angular 2 experience. Rather unlikely, given that Angular 2 is still in beta.
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.
The only situation where you are not affected is if you're a freelancer and you don't need to worry about what's going on around you.
I'm not going to mention where, but I worked at a well known company which you've heard of (you probably would know it as an innovative company), and everyone who worked there was very talented, there is absolutely no doubt about that. But I got sick of what's happening around me and quit recently.
Here's what happened: In the last couple of years a few people started talking about all this "cool new javascript testing/packaging/templating/single page app building" frameworks. Since it is indeed a "cool thing" to talk about these, and since they believe that potential new hires would be excited to learn that we use these hip new technologies to power our company, they started implementing EVERYTHING that the OP mentioned in the article. Of course, I'm sure it looks really cool from a recently graduated college kid's point of view when they interview. But anyway, suddenly the company culture started revolving around these hip technology advocates. I can understand why but at the same time it's really stupid because they keep switching out their stack and spend their money on useless crap instead of actually spending it on building the actual product. For example, they've transitioned from browserify to grunt to webpack in just last two years.
So when I read this article I totally sympathized with the guy.
If you're a web developer who works at a large company that wants to be seen as "innovative" (especially the ones that are already seen as being technically innovative), this is exactly what's going on. And you only have two choices: You either jump on the bandwagon and become one of the "in" crowd, or complain like the rest and be left behind and seen as a "laggard". When I saw these otherwise intelligent programmers moving like bunch of lemmings to adopt the latest new technology I couldn't help but feel pity for them. They grow old day by day thinking they're becoming a better programmer but all they're doing is learning some library that's designed so that the code monkeys can be managed better. They should be spending less time on those meta things and spend more time on building what a user wants instead. At least that's why I became a programmer.
The best way I've found to counter this is to give your own demonstration showing how you achieved the same (or better) coolness with existing technology, and you did it faster, and it can be integrated into the code base today.
This gives your argument real substance and people have to at least now argue against facts and data rather than hand-wavy speculation.
I researched all the major tools and committed to django, react, fluxxor, leaflet. As the major parts. All but leaflet (now OpenLayers) are still around and growing well.
The most important thing is that I got to pick which tools felt most resilient to rapid development and lots of rookie mistakes. Even if they may have been overkill or not ideal or some thing I cant possibly know as a newcomer.
In the past I did chase the dream of the one toolset to end them all and it had me never committing for any meaningful duration.
I'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. :(
If your entire job is doing small apps that take a week of work, these tools are not much better than the previous generation (personally I'd use Rails but that's just one generation on from PHP/MySQL). Especially when you add in the cost of non uniformity if you let everyone choose their own slightly different flavour of the innumerable javascript tools available.
But as part of a team that has migrated a 5 year old codebase from Rails to React in the last year, whilst I was skeptical at first, React has been an absolute godsend. Everything we build now is so much more modular and much closer to how non tech people view our website (and so how they ask for features), which makes it easier to develop. React isn't designed to help "I need to build this 20 hour website quicker".
I think the problem is mostly cargo culting. Smart and outspoken developers use these tools, but they're also the ones dealing with complex problems at their jobs, not everybody needs to solve the problems they are solving. And "Honestly Rails is good enough for this app" doesn't make for a very sexy meetup presentation.
This statement doesn't make sense to me, and is one of the points of the article. React is a view layer. That's it. So you wouldn't migrate from Rails to React. You'd migrate Rails to React + Relay + Webpack + etc. On top of all of that you then have to decide if you're sticking with Rails for your API or if you're switching over your entire back end as well. The decision debt is just insane, and given how often these things change, that debt never goes away.
I've only been at it for about 2-3 years, and I must say, I feel this exact same way. Started on the LAMP stack in school and now I know nothing because what I know is "uncool" and outdated since MEAN and all of the encompassing JS libraries have become popular.
I caved and started to dabble in MEAN (even though I haven't perfected LAMP by a long shot yet..) and must say it is the most fun I have had while coding and setting up projects ever, however I can't help but feel it is like you say, "a frigging nightmare to maintain and deploy". Nothing seems intuitive...
You want to know what's "uncool" around here for me? Wanting to markup a table with table elements, mostly for the accessibility benefits. I've never seen such an odd pushback. Tables are so "old" I'm told.
I've been doing this for 25 years, and I've felt the same way over and over - by the time I feel even a little bit comfortable with an approach, everybody else has already seemed to dip their toe in it, pronounced it unusable, and moved on to the next shiny thing, and wondered why I'm still over here banging rocks together.
If your school taught you LAMP as "current" then that is the issue here.
You’re doing it wrong. You’re not the one who should feel bad, they are the ones who should feel bad! You’re in the right. Try doing what I do: wave your cane around and shout at them to get off your lawn. Be sure to really drive it home by telling them the same two or three stories over and over again, about how things were back in “your day”[0] :)
In all seriousness, I sympathized with every thing you said until that very last sentence. For whatever reason, I never feel bad —— I just “know” that my way is the better way, and that their ways are just fashionable fads and will pass. If I turn out to be wrong and any of those things happens to wind up sticking, well... I’ll cross that bridge when I get there ;)
--
[0]: E.g., how much more vivid color was, how much brighter the day was, how much tastier the food was, how it was the Golden Age of Television, Film, Literature, Music, Journalism, and Politics, how men were men and you could tell them from boys by whether or not they had correctly implemented call-by-name argument-passing semantics in their Algol-60 compilers, and how everything was just generally better.
“What’s that? Your Web page is 32MB minified and gzipped? Back in my day, we only had 32MB of RAM total, if we were lucky, and we could still listen to mp3s and browse the Web and send snarky messages instantly to one another even then. Sure, our displays were tiny, low-resolution CRTs, and we liked it! Now get off my lawn!!”
/me listlessly stares 1000 yards past his junior developers...
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)
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.
I've found my own stack of choice - requirejs+jade(pug)+npm scripts(to parse requirejs and ES6 with babel) just do my job - no matter if it is a front-end or mobile one.
I've also add to it Express.js if want to build something full-stack - no front-end frameworks, just jade(pug) and own way of files organization etc. Sometimes I have worse day and think that I'm behind new hyped stuff but then I realise that my way just works without any fancy setup..
First experience with Resume Driven Development?
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.
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
Funny, because this is not the general sentiment in the Python community. See links like [1], [2], [3]. Thankfully, things are improving.
[1] http://lucumr.pocoo.org/2012/6/22/hate-hate-hate-everywhere/
[2] https://www.reddit.com/r/Python/comments/zrm3h/there_have_be...
[3] https://blog.ionelmc.ro/2015/02/24/the-problem-with-packagin...
But the term "complexity" gets used in two different meanings in your comment:
a) complexity of usage: You make the point that Django is easy to use, but it isn't simple software; it contains an ORM and is huge.
b) complexity of the system: Django is a complex system. If you are not using any of its benefits, it has needless complexity and you may be better off with a simple PHP script.
And this brings me to the conclusion that it's all about your use case. If you don't build a big SPA, you can get away with vanilla JS without using a transpiler or even a build pipeline.
The reason it's simple to develop something with a full-fledged framework like Django is that they have build a complex system to abstract all those complexities you don't have to think about anymore.
And I don't get your argument in regards to express.js because this is entirely a software architecture decision and they decided that a modular approach suits them well - maybe it's actually less complex for them to develop the software that way because they isolated the body-parser and other components. It's like comparing monolithic with micro kernels - it's all about trade-offs and the added complexity from a developers' point of view may be worth it for the specific use case. There is no general definition of "needless complexity", because the need is very subjective and different for each project.
Express is one of the easiest libraries to learn in any programming language. It's certainly much easier to learn than Django, at least in part because it doesn't include the kitchen sink
The rapid pace of change in the javascript world is what he's poking fun at.
On the other hand, Babel was :) He did a great writeup of his life during babel's explosion of popularity.
https://medium.com/@sebmck/2015-in-review-51ac7035e272#.nmef...
When I read those comments on HN, I'm really curious to know how people think you can build, scale and maintain a web app like Facebook. Do they think you can achieve it like in 2006, with a single scrip.js containing 100 000 lines of jQuery soup?
jQuery is fine for any web site or small web apps, but as soon as you reach the 2000 LOC, it's crazy to continue with it.
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.
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.
If all you want is a normal webpage, like a blog, like all of the websites out there I'd say you do not need components. Just build your own object. That is a lot of stuff just to do something that has been done for decades without it, battle tested so to say. Another one of the problems with the JavaScript community currently is the number of people who treat their favourite tool like a religious experience.
React is a large hammer being used quite often to close a twist tie. The ecosystem of tools which have sprung up around it is far worse than React itself. Each one a larger amount of overkill than the last.
Right or wrong it felt like enough at the time. Just adding Angular felt dirty. Damn, I feel for you guys.
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.
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.
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.
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.
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'.
- Edward Tufte
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.
In most decently sized cities, there seem to be plenty of development jobs available that make heavy use of solid software engineering and architecture using reliable, proven technology.
It's only anecdotal, but I know plenty of developers working for banks, manufacturers, and government who enjoy their jobs and get to solve problems that are interesting and challenging from both business and technical perspectives. They're not using outdated technology, either. The perception here sometimes seems to be that Java and .NET are slow moving dinosaurs, but they're both evolving, and organizations that from the outside seem stuffy and boring actually aren't afraid to keep up with the changes.
Interestingly, the devs I know at these companies also seem to enjoy a much higher status among their non-dev coworkers than devs at many startups and software product companies. I'm not sure why it has worked out this way, but it seems that in businesses where software isn't the end product, it's often easier for developers to be seen as trusted solvers of business problems rather than assembly line workers who are just stitching together raw materials to reify someone else's visions and ideas.
Before I digress too much, I'll circle back around to my point: it's still very possible to ignore the current front end development circus and enjoy a good career as a developer without the risk of turning yourself into an out of date dinosaur.
I'm also not implying that the worldview on HN is wrong, or that startups are bad, or that the current JS ecosystem is the worst thing ever. I'm just trying to remind everyone that there's a pretty big world out there where development skills are in demand, and a huge portion of that work doesn't involve front end work at all! It's even better if you're a developer who understands business (or is willing to learn). If you're a developer at a non-tech company, your ability to quickly create software that solve business problems can make you seem like a magician.
The lesson I'd draw from that is that you want to avoid siloing yourself. Most of those COBOL developers worked on the same kind of systems, often in the same place, for long periods of time. That kind of deep specialization is useful but also dangerous to you in direct relation to where that larger field is going.
In the web space, this is complicated by the somewhat unusual browser environment: in 5 years, you will always be glad that you spent time understanding the DOM, ES2016 and later, modern CSS, how to debug in every browser, etc. because ultimately everything is built on top of them.
You may or may not benefit from having spent time learning the framework of the day and that will be in direct relation to how much of that time was spent understanding broader concepts and styles versus dealing with idiosyncrasies and technical debt in the code-base. That's especially true for things like build tools which are easily replaced without visible changes to a project – they're useful and to be appreciated, but they're more overhead than part of your value as a developer.
My own experience was in writing a lot of vanilla JS, being pretty happy with it, and then wanting to grow bigger I investigated some of the frameworks. At the time, Angular 1.x was considered the thing, so I implemented a project in that (multiple drag and drop lists, items from lists into other lists, and so on), and tried to follow best practices as far as I could tell. DRY, decoupling, etc. It was pretty horrendous. I ended up with so many different services, service providers, components, dependency injectors, and all kinds of (to me) really quite complex abstract boilerplate that had nothing to do with the actual business problems.
I eventually got it all working, and thought I was doing pretty good. I then took a break from that project and came back to it 2 months later, and couldn't make head nor tail of it. So many angular-specific concepts and terminologies.
I've since come across mithril.js, and found it (for me) perfect. It's designed to let you build stuff really fast, and modularise things around your business logic, rather than have the whole of you application design enforced from the framework. Leo's blog posts https://lhorie.github.io/mithril-blog/ are fantastic, and I think made me understand a lot more of javascript itself, and how to design applications in much more 'well designed, but not framework specific' ways.
I 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.
Conversely, for those that do still exist, the new developers can simply bash the old technology stack and code and demand to rewrite in the new flavor of the week anyway.
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
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.
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.
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.
- 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)
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?
https://github.com/stoikerty/dev-toolkit
It does depend what perspective you're looking at it from. I appreciate it generates awareness about a current state of affairs for newcomers. But it's always easier to complain about something that to grind your teeth on it and learn, research and develop. The latter, although more painful, is a driving force forward.
Help > Complain
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.
Which stack do you prefer to use?
> you can learn React in a few hours. What's the big deal?
Assuming we are still using the same example (filling a table with some data and filtering it), I think 2-3 hours is a good example of how long it takes to write that in plain Javascript and testing it on every browser back to IE6 while having lunch in between.
But many of my class couldn't do it.
I'd probably use React for a project that simple, particularly if it needed to be maintained and expanded by others.
I made a decision from the start to use React, Redux, and Webpack with ES6/Babel. There was a bit of a learning curve, but I couldn't be happier using those tools. Recently I started adding Immutable, and I wish I had done so from the start.
I've tried adding Flow and Typescript to the project, and it's a major pain in the ass to do it now. I would have done it from the start, but I made the mistake of listening to some of those voices going on about "unnecessary complexity" and left it out.
I'd like to invite all the people saying to start a project in Vanilla JS or jQuery to do so, and let me know how it's going when you've got 15k lines of code and you want to refactor your app to use some of those complex tools.
This sums up my opinion of the whole React+Redux+Webpack+SatansSeventhCircleOfHellLib combination.
Second JS is not changing so fast imho and there are not so many frameworks that stand out of the crowd. Yeah there are lots of frameworks and libraries on github and even this is a good thing because it shows JS has a vibrant community that loves to create stuff. But it's not like you need know all of them, if you are really lost and don't know what to choose, just ask other developers around you or check out websites like http://stateofjs.com/ and you will notice that there are not that many frameworks that get used by a lot of devs.
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.
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.
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.
When I hire a software engineer, however, I'm paying more and getting more (hopefully). I expect software engineers to understand engineering principles and be able to work in almost any language. At a foundational level, they understand the basics of compiled vs interpreted languages, OOP vs functional programming, client vs server, optimization, testing, databases, networking, software release life cycle...and how to employ all of those. I expect to give them a business problem and have them develop an entire technical solution using whatever tools are best suited for that job.
In most cases, projects are a good mix of both software engineers and developers/programmers. The two can balance each other out and produce amazing things.
Lastly, everyone should be looking to improve their knowledge of their own industry. If you are a developer/programmer/software engineer, you should be looking at what is new/upcoming in the industry. You need to remain fresh or you become obsolete. In a very small example, the move from Python 2 to Python 3 has been a long road. If you are not aware of the improvements in Python 3 over Python 2, how can you actually determine if Python 3 is a good choice for your project? How can you take advantage of the improvements? What about Go vs Python 3? How does Erlang/Elixir fit in to the equation?
I 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.
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.
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.
"I need to display data on a page, not perform Sub Zero’s original MK fatality."
"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.
I have JavaScript Fatigue Fatigue.
Likewise, experienced web developers have years of contextual knowledge of CLIs, documentation and coding. An experienced dev can reasonably be expected to bootstrap a JavaScript app within a few hours, even if they only used jQuery in the past.
1. people use
2. people are happy with
Try the results of this survey:
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.
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.
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.
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)
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.
And 3 months from now in 2017 those 2 commands will be deprecated because no one uses those programs anymore.
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.
The worst thing is, every single thing these frameworks are trying to address are solved problems, and have been for decades. But people love reinventing wheels.
