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.
I'm a web dev, been doing this 11 years. But i totally feel past it, granted i code less and less nowadays so i havent kept up with new technologies.
I've hired people that are much better at web dev than me and let them accomplish a task with pretty much whatever tech they want to use, because i believe you shouldn't constrict a developer if you dont have to. Even for a simple app that it'd take me 20 - 30 hours for me to create in basic jQuery, bootstrap and simple PHP/MySQL, the tendency is to pull in Angular, Laravel, gulp or grunt, composer dependencies and a whole host of code for doing something really simple. It ends up becoming a frigging nightmare to maintain and deploy, i just want to do a git pull and thats it deployed, but instead i've gotta do artisan commands, migrations, grunt commands etc etc etc.
Anyway, i tell myself that what their doing is a better way of doing things and i'm just someone with outdated knowledge, because when i do it, i use basic tech and accomplish the same task in less time and with WAAAY less lines of code. While its maybe not the best practices, its simple.
I still feel like a bad coder because i'm not doing it their way. :(
> I still feel like a bad coder because i'm not doing it their way. :(
Well, in some ways yes. But experience has a value
Today people use an Arduino to flash a led, "in my time" it could be done with 2 transistors (you can do it with one + one "funny" component I guess - like a transformer)
The point of flashing an LED with an Arduino is not to flash the LED, it's to get the tools setup and workflow working while learning the basics. It's the "hello world" of microcontroller programming.
I've heard this process called "flow flushing". With things like FPGAs it can take days to go from nothing to flashing an LED. Because the toolchain is large, complicated and opaque.
It sounds like the Javascript world have built large toolchains for large projects and have then cargo-culted into using the same toolchains for tiny projects when they don't have to.
Even for a simple app that it'd take me 20 - 30 hours
If your entire job is doing small apps that take a week of work, these tools are not much better than the previous generation (personally I'd use Rails but that's just one generation on from PHP/MySQL). Especially when you add in the cost of non uniformity if you let everyone choose their own slightly different flavour of the innumerable javascript tools available.
But as part of a team that has migrated a 5 year old codebase from Rails to React in the last year, whilst I was skeptical at first, React has been an absolute godsend. Everything we build now is so much more modular and much closer to how non tech people view our website (and so how they ask for features), which makes it easier to develop. React isn't designed to help "I need to build this 20 hour website quicker".
I think the problem is mostly cargo culting. Smart and outspoken developers use these tools, but they're also the ones dealing with complex problems at their jobs, not everybody needs to solve the problems they are solving. And "Honestly Rails is good enough for this app" doesn't make for a very sexy meetup presentation.
The more technical details you include the more people pick up and discuss minute technical details instead of the point of what I was trying to say, which is that my experience with a large codebase was these modern javascript tools have solved a lot of problems we had.
If you want all the gory details here they are: it was a Rails 3 app using Postgres and Elasticsearch that we migrated to React + node.js + webpack + babel, elastic search as the data store and using Keystone.js for backend data manipulation (which uses mongodb). Rails was indexing its data in Elasticsearch already so we could start serving data through node.js immediately without having to migrate all the data backend, which is being slowly moved to keystone.js.
> migrated a 5 year old codebase from Rails to React
This statement doesn't make sense to me, and is one of the points of the article. React is a view layer. That's it. So you wouldn't migrate from Rails to React. You'd migrate Rails to React + Relay + Webpack + etc. On top of all of that you then have to decide if you're sticking with Rails for your API or if you're switching over your entire back end as well. The decision debt is just insane, and given how often these things change, that debt never goes away.
It makes sense to me. The previous generations had pages that had more rendering on the server and "forms." Now, it's single page applications hitting REST end points.
So before, you had complex models, tightly bound back-end controllers, sending data to a view.
Now, you have simpler APIs on the server, you arrange and manage the data in the browser, getting more data as needed.
Rails is perfectly well suited to serve an API. In fact I believe it was the first to define off the shelf RESTful conventions for an entire controller and all verbs by default back ~2007 if I recall.
Actually, Rails 5 implements an API mode so you can spin up a new app with only API-level conventions that runs on less memory and just serves JSON. You can add on the standard Postgres DB and Boom! "You just made Rails great again"
> I still feel like a bad coder because i'm not doing it their way. :(
I've only been at it for about 2-3 years, and I must say, I feel this exact same way. Started on the LAMP stack in school and now I know nothing because what I know is "uncool" and outdated since MEAN and all of the encompassing JS libraries have become popular.
I caved and started to dabble in MEAN (even though I haven't perfected LAMP by a long shot yet..) and must say it is the most fun I have had while coding and setting up projects ever, however I can't help but feel it is like you say, "a frigging nightmare to maintain and deploy". Nothing seems intuitive...
>> now I know nothing because what I know is "uncool"
You want to know what's "uncool" around here for me? Wanting to markup a table with table elements, mostly for the accessibility benefits. I've never seen such an odd pushback. Tables are so "old" I'm told.
Actually, what people frown upon is using tables for layout. Using them to display actual tabular data is quite fine. (I mean, everything is fine at the end of the day as long as the end-user is happy, but you know what I mean...)
No, you don't understand. I don't want to use tables for layout, I want to use tables to display a good old-fashioned table. A table displayed in an otherwise normally marked up page. That is what's getting the pushback.
I guess I could say I want to use table elements to layout a table, which would trigger the "don't use tables for layout" argument.
If the table cells have specific individual widths and heights, and contain a .gif or .jpg of equal size within them, then that is an inappropriate use of tables today.
This "no table for layout" thing is so strong that people keep insisting that I am saying table elements for layout. I am literally saying "using table elements for a table" and not "layout with a table". It is a table with tabular data in it, just plain text. It is a styled table, but a table nonetheless.
That's the normal way to do a table. Why import a dozen different libraries to render something that is HTML-included and renders in like 0 time because it's built right into the fucking browser.
> even though I haven't perfected LAMP by a long shot yet..
I've been doing this for 25 years, and I've felt the same way over and over - by the time I feel even a little bit comfortable with an approach, everybody else has already seemed to dip their toe in it, pronounced it unusable, and moved on to the next shiny thing, and wondered why I'm still over here banging rocks together.
> I still feel like a bad coder because i'm not doing it their way. :(
You’re doing it wrong. You’re not the one who should feel bad, they are the ones who should feel bad! You’re in the right. Try doing what I do: wave your cane around and shout at them to get off your lawn. Be sure to really drive it home by telling them the same two or three stories over and over again, about how things were back in “your day”[0] :)
In all seriousness, I sympathized with every thing you said until that very last sentence. For whatever reason, I never feel bad —— I just “know” that my way is the better way, and that their ways are just fashionable fads and will pass. If I turn out to be wrong and any of those things happens to wind up sticking, well... I’ll cross that bridge when I get there ;)
--
[0]: E.g., how much more vivid color was, how much brighter the day was, how much tastier the food was, how it was the Golden Age of Television, Film, Literature, Music, Journalism, and Politics, how men were men and you could tell them from boys by whether or not they had correctly implemented call-by-name argument-passing semantics in their Algol-60 compilers, and how everything was just generally better.
“What’s that? Your Web page is 32MB minified and gzipped? Back in my day, we only had 32MB of RAM total, if we were lucky, and we could still listen to mp3s and browse the Web and send snarky messages instantly to one another even then. Sure, our displays were tiny, low-resolution CRTs, and we liked it! Now get off my lawn!!”
/me listlessly stares 1000 yards past his junior developers...
I've found my own stack of choice - requirejs+jade(pug)+npm scripts(to parse requirejs and ES6 with babel) just do my job - no matter if it is a front-end or mobile one.
I've also add to it Express.js if want to build something full-stack - no front-end frameworks, just jade(pug) and own way of files organization etc. Sometimes I have worse day and think that I'm behind new hyped stuff but then I realise that my way just works without any fancy setup..
in addition, I've took a look on react/ember/angular etc. but it just doesn't fit me - but at the same time I've took some principles from every of them and use it in my projects (e.g. code modularity)
The worst is, if you don't keep up with this, good luck getting a web job five years from now, you'll be the equivalent of a Cobol programmer. Can't get off the train.
There's still quite a lot of people doing Angular 1.x though, so at least the train isn't that fast.
I sorta agree with you. I personally like JS and really like Node. Node can actually be pretty simple and fun to mess around with and experiment. I know HN likes to hate on it, but I have fun with it.
Frontend apps always end up seeming like a mess to me especially when suing the latest "best practices" for "maintainability" (ironic as most web apps are abandoned after a couple of years). Unfortunately JS being the only language I'm productive in sorta means I'll be doing some sort of frontend for a while.
And the best is, if you have a fundamental understanding of plain, vanilla javascript all these new frameworks are pretty easy to pick up. I went from jQuery -> Angular 1.x -> Ember 1.6 -> Ember 2.0 -> React and Redux in basically no time. It really wasn't that hard.
Hah, I just posted elsewhere this exact sentiment. My first "framework" was Javascript. Every new fancy thing that comes along is just more Javascript to me.
My own experience was in writing a lot of vanilla JS, being pretty happy with it, and then wanting to grow bigger I investigated some of the frameworks. At the time, Angular 1.x was considered the thing, so I implemented a project in that (multiple drag and drop lists, items from lists into other lists, and so on), and tried to follow best practices as far as I could tell. DRY, decoupling, etc. It was pretty horrendous. I ended up with so many different services, service providers, components, dependency injectors, and all kinds of (to me) really quite complex abstract boilerplate that had nothing to do with the actual business problems.
I eventually got it all working, and thought I was doing pretty good. I then took a break from that project and came back to it 2 months later, and couldn't make head nor tail of it. So many angular-specific concepts and terminologies.
I've since come across mithril.js, and found it (for me) perfect. It's designed to let you build stuff really fast, and modularise things around your business logic, rather than have the whole of you application design enforced from the framework. Leo's blog posts https://lhorie.github.io/mithril-blog/ are fantastic, and I think made me understand a lot more of javascript itself, and how to design applications in much more 'well designed, but not framework specific' ways.
I wouldn't pick on the COBOL programmers too much – they've had a half a century of decent jobs, after all.
The lesson I'd draw from that is that you want to avoid siloing yourself. Most of those COBOL developers worked on the same kind of systems, often in the same place, for long periods of time. That kind of deep specialization is useful but also dangerous to you in direct relation to where that larger field is going.
In the web space, this is complicated by the somewhat unusual browser environment: in 5 years, you will always be glad that you spent time understanding the DOM, ES2016 and later, modern CSS, how to debug in every browser, etc. because ultimately everything is built on top of them.
You may or may not benefit from having spent time learning the framework of the day and that will be in direct relation to how much of that time was spent understanding broader concepts and styles versus dealing with idiosyncrasies and technical debt in the code-base. That's especially true for things like build tools which are easily replaced without visible changes to a project – they're useful and to be appreciated, but they're more overhead than part of your value as a developer.
HN (and perhaps SV) might be a bit of an echo chamber that doesn't reflect industry overall.
In most decently sized cities, there seem to be plenty of development jobs available that make heavy use of solid software engineering and architecture using reliable, proven technology.
It's only anecdotal, but I know plenty of developers working for banks, manufacturers, and government who enjoy their jobs and get to solve problems that are interesting and challenging from both business and technical perspectives. They're not using outdated technology, either. The perception here sometimes seems to be that Java and .NET are slow moving dinosaurs, but they're both evolving, and organizations that from the outside seem stuffy and boring actually aren't afraid to keep up with the changes.
Interestingly, the devs I know at these companies also seem to enjoy a much higher status among their non-dev coworkers than devs at many startups and software product companies. I'm not sure why it has worked out this way, but it seems that in businesses where software isn't the end product, it's often easier for developers to be seen as trusted solvers of business problems rather than assembly line workers who are just stitching together raw materials to reify someone else's visions and ideas.
Before I digress too much, I'll circle back around to my point: it's still very possible to ignore the current front end development circus and enjoy a good career as a developer without the risk of turning yourself into an out of date dinosaur.
I'm also not implying that the worldview on HN is wrong, or that startups are bad, or that the current JS ecosystem is the worst thing ever. I'm just trying to remind everyone that there's a pretty big world out there where development skills are in demand, and a huge portion of that work doesn't involve front end work at all! It's even better if you're a developer who understands business (or is willing to learn). If you're a developer at a non-tech company, your ability to quickly create software that solve business problems can make you seem like a magician.
As goes the software world, the majority of these "applications" won't exist in 5 years.
Conversely, for those that do still exist, the new developers can simply bash the old technology stack and code and demand to rewrite in the new flavor of the week anyway.
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".
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.
I hear this a lot, but I don't get it. How would this help make things simpler or stop "this madness"? If anything it opens up the possibility for even more crazyness. The only difference is you (maybe) get to pick your favourite language instead of learning new ones.
It's not so much about picking your "favourite" language. That's what drove NodeJS to exist. But more about picking a more appropriate language that has a well engineered base class library and third party libraries. They will come. This comes down to choosing the best tool for the job at hand.
JavaScript developers have been able to, in recent years, benefit in some ways by being able to write their server-side in JS as well (see NodeJS). There are various buzzwords to describe this capability. WebAssembly will help normalise this so that other languages can also have this capability. By being able to share types between the server and web browser client, there are large productivity and program correctness gains to be unlocked.
People are hyping up webassembly way too much. Don't get me wrong it's going to be awesome being able to compile C++ and C programs that run on the Web runtime.
But it's not going to be without it's own issues. For one developers will likely have to wait for things like simd, pthreads or 64bit ints until later versions.
Also it won't magically make compiling your language of choice to the web less painful unless it's C++ or it fits into the C++ language model. Even when it gets the ability to hook into a garbage collector (I wouldn't count on it happening any time in the near future) it will likely have to fit in with the way js engines expect.
As these rehashed JavaScript versions of http://harmful.cat-v.org/software/xml/soap/simple are on front page of Hacker News every other day, I can't even begin to imagine what kinds of rants we will see in the next 15 years or so.
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.
+ HTML/Dom limitations
+ Browser fragmentation
+ It's used on the backend as well
+ Nobody is in charge. When someone is in charge, they usually provide the basic tooling and libs - hopefully they do it well - and then you only need ancilliary stuff for special projects. Obviously this can have drawbacks as well, but I'd argue that 2/3 of frameworks are actually trying to solve the same, core problems, just in different ways. They aren't providing 'more' just 'different'.
The same kind of rant applies to things like automake, but only Javascript has this incredibly high rate of churn. Possibly it's easier to build a new toolchain than to understand someone's existing one.
That's been my annoyance too. Instead of iterating on what's there everyone makes their own thing and tries to reinvent build tools, frameworks, web components, module loaders, transpilers, package mangers etc... It is improving somewhat. Some tools seem to be winning out and clearing the orbit around them but were still in the primeval js solar system with a few planets forming.
I have no trouble at all "keeping up" with the "insanity" that is front-end development. If you're confused learning new things, it means you're learning.
At my company, we have moved a lot of our front-end code to eslint-checked ES6 with some plugins, writing react/redux powered interfaces. New hires generally learn the codebase fast, you're well protected from shooting yourself in the foot thanks to type checking and linting and the absence of globals. Our team is many times more productive with this stack than with the es5 + knockoutjs code we built with before.
If you're building a hobby project, just start with a <html> tag with inline ES5 and css, and refactor and iterate from there. Use server-side templates. "keep it simple". But when building client-side interfaces at a higher complexity level, React is king.
My main problem is the speed, and bad backwards compatability. Generally speaking if I take a 2 year old C,C++ or Java project, I can be sure I can update to recent libraries and everything will just work with minimal fixes.
In Javascript it seems every time I pick a project up from a couple of years ago, every library version I was using is past end-of-life, and updating requires a major rewrite.
>I have no trouble at all "keeping up" with the "insanity" that is front-end development. If you're confused learning new things, it means you're learning.
This naive view though assumes that all learning and all stuff to learn is created equal and is all good.
That is, that the IT industry can't possibly produce junk for people to learn ("busywork", programming fads, over engineered platforms, oversold technologies, etc).
People who have been through the J2EE-hell of mid-noughties, which even its creators condemned and abandoned several years later, but which at the time was touted as "THE WAY" to build enterprise software, and you just had to "man up" and learn it, respectfully disagree.
It's easy to show how complex those systems are. It's easy because they are complex. And that's pretty normal. Let someone talk about Java Enterprise development, the symptoms of your body and their diagnoses or just try to explain how to build a pencil (https://en.wikisource.org/wiki/I,_Pencil).
We're professionals, after all, and TypeScript and React were not build by some teenage hackers.
I think the problem is that everybody remembers how they build that one website using jQuery in the early 2000s and now wonders why everything's so complex now. The reason is that we started to build complex applications instead of enhancing grandma's blog using jQuery.animate, get over it.
And if a software developer talks about all of this tools in the same manner you've described, he has poor social skills, nothing related to the tooling.
He could also talk about the intricacies of scaling web services using k8s and OpenStack and you'll find another bunch of tools and concepts. If someone would actually talk like you've described it, he would play buzzword bingo in any domain of expertise like medicine students who want to sound smart using latin words.
and that's how you can use express.js to run a service that uses a different protocol to HTTP.
Express is one of the easiest libraries to learn in any programming language. It's certainly much easier to learn than Django, at least in part because it doesn't include the kitchen sink
I agree to your sentiment that needless complexity is bad, technical debt is a real thing and it is plain reckless to use something for the sake of it.
But the term "complexity" gets used in two different meanings in your comment:
a) complexity of usage: You make the point that Django is easy to use, but it isn't simple software; it contains an ORM and is huge.
b) complexity of the system: Django is a complex system. If you are not using any of its benefits, it has needless complexity and you may be better off with a simple PHP script.
And this brings me to the conclusion that it's all about your use case. If you don't build a big SPA, you can get away with vanilla JS without using a transpiler or even a build pipeline.
The reason it's simple to develop something with a full-fledged framework like Django is that they have build a complex system to abstract all those complexities you don't have to think about anymore.
And I don't get your argument in regards to express.js because this is entirely a software architecture decision and they decided that a modular approach suits them well - maybe it's actually less complex for them to develop the software that way because they isolated the body-parser and other components. It's like comparing monolithic with micro kernels - it's all about trade-offs and the added complexity from a developers' point of view may be worth it for the specific use case. There is no general definition of "needless complexity", because the need is very subjective and different for each project.
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.
Thanks for the link, his story is great! I'm convinced that compilers and formal languages are the core fundamentals of computer science, amazing that he got into it so young.
Compiling a C project from sources for the first time (which was maybe five years ago and had a bunch of dependencies too) took me less time than it's currently taking me to read up on an overview of all these frameworks/libraries/technologies, let alone actually learn any of them.
Would have preferred that Google had put their resources behind something like GopherJS instead of yet another C#/Java-like, feature-creep prone language.
The article was pretty good as a JavaScript commentary, up until the last line that name-dropped Python 3. I don't think the Python community has anywhere near the problems that the JavaScript community is having.
For example, there aren't languages trying to transpile to Python, they aren't trying to translate new Python language features into old ones at runtime (at least not like 3.5 into 3.0, but there is some mess in 2 vs. 3 such as six), they aren't trying to shoehorn assembly language into it, and there aren't a dozen ways to do HTTP requests or manipulate DOM or make packages.
People love to joke about Python 3 and I totally get it. But compared to Javascript, the mess is nowhere nearly as great.
To make python 2 code compatible with python 3, a few things need changing. For 99% of the code it's very simple, and for the 1% big changes, well, you just need to go through it and refactor some of your code. People have been postponing this but we are well on our way. During the transitioning period, new stuff gets written in py3 and old stuff still runs with the py2. People have both installed. No big deal.
Now Javascript. There is plain javascript with slight variations for every browser. There are a million frameworks, a new one that becomes majorly popular about every two years, and they all work very differently. There is no single, straight upgrade path, it's almost like using completely different languages. There is no "we are nearly done with the transition". Instead there is five new frameworks to look at every year, each of which uses five others as dependencies (angular 2's tutorial is a good example, last time I checked) and one of which will become popular next year, by which time you're outdated if you haven't tried all five. The only new thing that needs explaining in py3, as far as I know, is byte objects vs string objects. Then a few syntax changes (I think OOP changed a little bit) and you're done.
I totally agree that Python is much less problem compared to Javascript but I think that it's not fair to compare a backend language to a frontend language. My only complain is that Python is not great at async operations so people have to create unstable async libraries such as gevent and it's usually cause trouble in production. Luckily Python 3 solves this problem but backward compatibility is one of the most important things that is important in a programming language. People usually develop backend services once and maintain it for years but frontend is subject to change more often.
> My only complain is that Python is not great at async operations
For most asynchronous IO operations, the old standby of threads works an absolute treat. There are certain pathological corner cases where a single thread can be blocked, but for the other 99.9% of use cases, it works fantastically.
Build your synchronous and stateless web code and throw it into a thread. Done. Even the more complex cases of a single worker needing to make multiple asynchronous calls can be handled easily without even having to leave the standard library.
Now then, this falls apart a bit when you have to deal with global state (and the assorted locks and deadlocks), but most web backends aren't too hard to write statelessly.
But spawn enough threads in Python and you risk entering scheduling hell, thanks to the global interpreter lock. EDIT: if you are CPU bound at all. If you are really really IO bound it's not a problem.
Event-driven programming is my go-to for nontrivial backend async in Python, and in Python 2 you almost certainly want to use a third party library for that.
(But maybe I'm just lazy. I try to avoid the headache of threads in python if I can.)
Python 3 has asyncio, which looks good, though I havn't used outside of toy projects at this point.
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.
It gives you components. If your webpage is loaded and significantly complex with a need for different things all over the place then it's for you. It was built for Facebook, which has stuff everywhere on every page.
If all you want is a normal webpage, like a blog, like all of the websites out there I'd say you do not need components. Just build your own object. That is a lot of stuff just to do something that has been done for decades without it, battle tested so to say. Another one of the problems with the JavaScript community currently is the number of people who treat their favourite tool like a religious experience.
React is a large hammer being used quite often to close a twist tie. The ecosystem of tools which have sprung up around it is far worse than React itself. Each one a larger amount of overkill than the last.
I'm sorry, but once you feel comfortable using React there are very few things that React would not be a good fit for, however small the task.
I started coding in JavaScript two years ago, right at the point React was gaining popularity. I made a gamble going for it 100%, and since then both the company I was working at back then and the one I started working at recently have fully switched to React for all new front-end development after seeing how much easier it is than anything they'd ever used before (jQuery, self-rolled prototype-based things, Backbone, Angular 1, Ember).
Yes, sure, you have to get the basics set up every time, and yes, sure you have to package React on every page. But as a gigantic win, you get a uniform way of dealing with the DOM every single time. React has well-defined best practices by now. When every Javascript coder in your workplace is familiar with React, it's usually best for you and for them to simply continue coding in React.
I feel that you are marginalising the amount of complexity you are adding to projects which might not need it. There are multiple routes toward completing the same task in development. My concerns surrounding additional complexity I feel are well founded, there are costs associated with such a thing.
If all you are doing is DOM manipulation, without doing a huge amount of it, that isn't such a complex task that it should require an entire framework. If you're doing more than that it outscopes what React can do.
That's just it. If all your developers are familiar with at least the basics of React and Webpack, you aren't adding any complexity. Once you know how things work, a simple Webpack configuration with Babel and 2 presets isn't complex anymore.
What would be complex, however, is introducing DOM logic in yet another way. We're all used how you just define the desired state in React and letting it figure out the transitions. When you suddenly ask your developers to write code that manually manipulates the DOM and has to take care of all the transitions between states, you end up with complex, unclear code that takes everyone a long time to understand.
Webpack alone requires hundreds of dependencies. You are populating your node_modules directory with megabytes of code, any of which could stop working. If you plan to maintain your code for years into infinity then it's no problem. Otherwise the shop down the street doing the same thing without it will be much better off.
Come on, your response is pretty shallow, don't you think? Or do you genuinely believe a Facebook-like application is the only one that could benefit from organizing into modular, reusable components?
This is a very good reply. Someone trying to grab a foothold in front end development should keep it simple and add tools as they require them (if applicable). I used to develop for the web until I found iOS development to be more enjoyable because of the feeling of stability of the SDK. When I did do it, I got to the point where I said, fuck all this noise and just give me Nodejs/npm, MongoDB and raw JavaScript...
Right or wrong it felt like enough at the time. Just adding Angular felt dirty. Damn, I feel for you guys.
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.
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.
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.
I can not emphasize this enough. Keep it simple. I see to many software written through solutions just because they are a hype. Pick the right tools for the job.
In my experience the whole complex JavaScript comes when you try to build the entire thing using JavaScript.
If you are developing a web app, restrict JS to the client side only, get something like react to do it.
On the server side I stick with Go(lang). This separation helps me and my team think of these two separate problems, well.. separately. Isomorphic this isomorphic that is when things start to go all in sane.
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?
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.
I'm sorry, but you seem to have misunderstood this discussion. I'm not saying mine is any better, we're simply discussing whether a stack is complex.
So what I use is irrelevant.
If you're so desperate to know what I've used, since 2004:
- VB6
- vb.net net webforms
- old school vbscript + dynamic ajax
- c# using xslt + ajax xml, without really using webforms
- c# webforms
- PHP wordpress
- asp.net MVC
- silverlight
- rails
- MVC + Web API with a jQuery/datatables/handlebars
- MVC + Web API with a jQuery/jQuery-tmpl/jQuery-forms
- Durandal with OData
- knockout with a mix of MVC + WebAPI
Some playing with django and backbone and angular and laravel for my own projects too, but not particularly in anger.
To be frank, the worst one for unnecessary complexity, by a far, far, far, far way, was durandal. Pile of shit. React/angular definitely suffer from a similar over complexity.
Generally speaking, recently I haven't really chosen a stack, the last 4 projects I've worked on have all been past that phase when I joined.
When I have, it was 3 years ago and at the time I stuck with jQuery/datatables, at the time backbone was trendy and I hate any js framework which relies on methods for properties having been burnt by supporting a colleague's internally homebrewed jQuery-a-like with early template system that used that earlier in my career. Nightmare to debug.
> which will give you a working project in 2-3 hours
> you can learn React in a few hours. What's the big deal?
Assuming we are still using the same example (filling a table with some data and filtering it), I think 2-3 hours is a good example of how long it takes to write that in plain Javascript and testing it on every browser back to IE6 while having lunch in between.
Funny, I actually had that last year in a 2 hours midyear exam, access to Internet authorized. I was the only one to complete the exam and had the best mark, didn't use internet, just my own code lying around my pc, finished in half an hour, vanilla js/php LAMP.
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.
Agreed. I started a new project a few months ago, and if I had listened to the advice in the threads that have popped up around this whiny article, I would have had to refactor my codebase 6 times already by "adding the stuff I need."
I made a decision from the start to use React, Redux, and Webpack with ES6/Babel. There was a bit of a learning curve, but I couldn't be happier using those tools. Recently I started adding Immutable, and I wish I had done so from the start.
I've tried adding Flow and Typescript to the project, and it's a major pain in the ass to do it now. I would have done it from the start, but I made the mistake of listening to some of those voices going on about "unnecessary complexity" and left it out.
I'd like to invite all the people saying to start a project in Vanilla JS or jQuery to do so, and let me know how it's going when you've got 15k lines of code and you want to refactor your app to use some of those complex tools.
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.
235 comments
[ 5.6 ms ] story [ 252 ms ] threadAnd 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
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. :(
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.
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.
If you want all the gory details here they are: it was a Rails 3 app using Postgres and Elasticsearch that we migrated to React + node.js + webpack + babel, elastic search as the data store and using Keystone.js for backend data manipulation (which uses mongodb). Rails was indexing its data in Elasticsearch already so we could start serving data through node.js immediately without having to migrate all the data backend, which is being slowly moved to keystone.js.
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.
So before, you had complex models, tightly bound back-end controllers, sending data to a view.
Now, you have simpler APIs on the server, you arrange and manage the data in the browser, getting more data as needed.
http://edgeguides.rubyonrails.org/api_app.html
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 guess I could say I want to use table elements to layout a table, which would trigger the "don't use tables for layout" argument.
If someone whines you've used a table, then ignore their whining and keep using table markup for tabular data.
If the table cells have specific individual widths and heights, and contain a .gif or .jpg of equal size within them, then that is an inappropriate use of tables today.
If your school taught you LAMP as "current" then that is the issue here.
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.
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...
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?
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.
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.
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.
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.
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.
- Edward Tufte
https://xkcd.com/927/
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.
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.
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'.
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.
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.
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.
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
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
Excuses, excuses. Good defaults are important. 99.99% of developers won't care about it.
Getting form data is Web development 101
Is it? Certainly the latest hipster microservice only deals with JSON bodies.
If you are, install the meta-package, or create one. Now you have your defaults.
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.
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.
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...
- 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)
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.
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 most asynchronous IO operations, the old standby of threads works an absolute treat. There are certain pathological corner cases where a single thread can be blocked, but for the other 99.9% of use cases, it works fantastically.
Build your synchronous and stateless web code and throw it into a thread. Done. Even the more complex cases of a single worker needing to make multiple asynchronous calls can be handled easily without even having to leave the standard library.
Now then, this falls apart a bit when you have to deal with global state (and the assorted locks and deadlocks), but most web backends aren't too hard to write statelessly.
Event-driven programming is my go-to for nontrivial backend async in Python, and in Python 2 you almost certainly want to use a third party library for that.
(But maybe I'm just lazy. I try to avoid the headache of threads in python if I can.)
Python 3 has asyncio, which looks good, though I havn't used outside of toy projects at this point.
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.
I started coding in JavaScript two years ago, right at the point React was gaining popularity. I made a gamble going for it 100%, and since then both the company I was working at back then and the one I started working at recently have fully switched to React for all new front-end development after seeing how much easier it is than anything they'd ever used before (jQuery, self-rolled prototype-based things, Backbone, Angular 1, Ember).
Yes, sure, you have to get the basics set up every time, and yes, sure you have to package React on every page. But as a gigantic win, you get a uniform way of dealing with the DOM every single time. React has well-defined best practices by now. When every Javascript coder in your workplace is familiar with React, it's usually best for you and for them to simply continue coding in React.
If all you are doing is DOM manipulation, without doing a huge amount of it, that isn't such a complex task that it should require an entire framework. If you're doing more than that it outscopes what React can do.
What would be complex, however, is introducing DOM logic in yet another way. We're all used how you just define the desired state in React and letting it figure out the transitions. When you suddenly ask your developers to write code that manually manipulates the DOM and has to take care of all the transitions between states, you end up with complex, unclear code that takes everyone a long time to understand.
Ok, I guess Webpack isn't too complex, but its weird syntax (the whole right to left chaining) and poor documentation can be a barrier.
If 80% of your projects are written in X, it's probably simpler to just use X for everything, even things that don't need it
If you're building Facebook.
Right or wrong it felt like enough at the time. Just adding Angular felt dirty. Damn, I feel for you guys.
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.
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.
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?
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?
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.
So what I use is irrelevant.
If you're so desperate to know what I've used, since 2004:
Some playing with django and backbone and angular and laravel for my own projects too, but not particularly in anger.To be frank, the worst one for unnecessary complexity, by a far, far, far, far way, was durandal. Pile of shit. React/angular definitely suffer from a similar over complexity.
Generally speaking, recently I haven't really chosen a stack, the last 4 projects I've worked on have all been past that phase when I joined.
When I have, it was 3 years ago and at the time I stuck with jQuery/datatables, at the time backbone was trendy and I hate any js framework which relies on methods for properties having been burnt by supporting a colleague's internally homebrewed jQuery-a-like with early template system that used that earlier in my career. Nightmare to debug.
Exactly. "Rails" implies all of those other components. That's my point.
And your stack is relevant. I'm curious what simple stack you use, and how much more simple it is.
> 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.
I'd probably use React for a project that simple, particularly if it needed to be maintained and expanded by others.
But many of my class couldn't do it.
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 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.
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.