> If you don’t have a human expert at hand, at the very least, check the date on that Medium article or tutorial or the last commit in that GitHub repository. If it’s more than a year old, it’s almost certainly not the way to go.
The logical conclusion then is to wait a year and ignore everything this article says. Saves a lot of time. :)
I'm still using Make for all my minification / bundling / test running needs. Now and again I think to learn some trendy tech then never get round to it. Next time I remember it's already something different. :)
The extreme amount of neomania in JavaScript land is what keeps me away from it altogether. The idea that all JS articles and GitHub repositories are outdated after a year means the entire ecosystem is fragile.
I'll leave the always-chasing-the-next to the programming bootcampers, and I'll work on building skills that will be useful long after the next 100 javascript frameworks are dead instead.
I can highly recommend Sacha Greif's article "A Study Plan to Cure Javascript Fatigue" ( https://medium.freecodecamp.com/a-study-plan-to-cure-javascr... ) as a great place to start. It gives an excellent series of steps for tackling modern Javascript concepts one piece at a time: Javascript, React, ES6, and state management.
For anyone interested in learning React, here's my standard advice:
Past that, I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics.
Highly oppose the recommendation of create-react-app for first-comers. You're much better of learning one thing at a time. Like you said: Javascript -> React -> ES6 -> State management.
create-react-app throws a ridiculous amount of crap in your face that you might end up not liking anyhow. If anything should overwhelm you then that project is it.
We have two working students at our company that were told to start their projects with CRA and they were clueless after two months. Learn one thing at a time.
The trick to being successful with JavaScript is to relax and allow yourself to slightly sink into your office chair as a gelatinous blob of developer.
When you feel yourself getting all rigid and tense in the muscles, say, because you read an article about how you're doing it wrong or that your favourite libraries are dead-ends, just take a deep breath and patiently allow yourself to return to your gelatinous form.
Now I know what you're thinking, "that's good and all, but I'll just slowly become an obsolete blob of goo in an over-priced, surprisingly uncomfortable, but good looking office chair. I like money, but at my company they don't pay the non-performing goo-balls." Which is an understandable concern, but before we address it, notice how your butt no-longer feels half sore, half numb when in goo form, and how nice that kind of is. Ever wonder what that third lever under your chair does? Now's a perfect time to find out!
As long as you accept that you're always going to be doing it wrong, that there's always a newer library, and that your code will never scale infinitely on the first try, you'll find that you can succeed and remain gelatinous. Pick a stack then put on the blinders until its time to refactor/rebuild for the next order of magnitude of scaling, or the next project.
In my experience using last year's darling framework instead of this year's is an excellent way to go. The codebase is stable and full-featured, the plugin ecosystem is rich, the documentation is extensive, and stackoverflow is already filled with accepted answers.
It's a myth that new languages and frameworks offer better productivity. Mostly it's just the flavor that's different, not the calories. Sometimes you get a genuine improvement, like react, but the vast majority of frameworks are completely optional when it comes to getting stuff done. I'm always reminded of this when I observe the Delphi team at work. Still lapping any web developer when it comes to shipping features.
Great post—and the title got a laugh out of this self-described "ancient" web developer—but interestingly, there's not much (any?) info in there about learning JavaScript/ECMAScript the language. It and the articles it links are mainly focused on the ecosystem and tooling.
I held JS at arm's length for way too long, trying to use it without actually learning it. I finally grew tired of being illiterate and read "You Don't Know JavaScript" by Kyle Simpson[0] and it was eye-opening. The preface[1] really spoke to me and I suspect it will speak to many others like me. I only wish I'd read it two years ago.
And I learned to like ES6 from it. I've had to since JS is the de-facto language where I presently work. And I immediately recognized the functional bits that turned out, for me, to be the best parts: functors, monads, currying and the like.
However the problem I've found is that as our code scales up in size and sophistication it requires greater mental effort and discipline from the team to maintain consistency and manage complexity. ES6+, for better or worse, is a kitchen sink language. The hard part is getting everyone to agree on the subset to use and enforcing standards.
At first I thought this was a wonderful language for teaching FP in: it's forgiving, people can learn concepts as they go and put them into practice right away without having to go whole-hog on FP. This works for senior developers for the most part. However for junior developers, I've found, it can add to the confusion.
And if I'm reading the tea-leaves right it seems like Microsoft and Facebook have been having the same issues with large Javascript projects. Why else build tools to help manage the complexity if the language already provides them? It seems like there's a good language buried in Javascript, somewhere, but the lack of a sound-type system and a plethora of historical baggage obscures it.
All in all learning Javascript is worth it if only access to an ecosystem of highly-active development is valuable. It can be a pleasure to write... but my advice today would be to learn a pure FP language first and come back to Javascript if you need to.
> Great post—and the title got a laugh out of this self-described "ancient" web developer
I'm happy it ended up being a self description. I was a little worried it was going to be a bit of directed humor that might be unintentionally offensive. Not that I'm generally thin-skinned about that, but it would have been a bit much to have an article about "you're old so you don't know how to do stuff, so let me explain it to you". I could see someone attempting that in humor, and it just coming across badly...
> Things haven’t settled down long enough for curriculums and guides to gel and mature, and for best practices to become authoritative for more than a few months... When you’re working with an ancient language like PHP, you Google a question or problem, and almost 100% of the time you will find a 5-year-old Stack Overflow answer that solves it... Not so much with modern JavaScript
OK, so everything's changing all the time, everything you Google will be out of date, but it's worth it because... why, exactly?
Node doesn't block on IO. OK, cool. But the Erlang VM doesn't block on IO, either, AND it's not single threaded, so you can actually do parallel computation if you need to.
JS has a lot of raw speed these days. OK, cool. But raw speed is generally less important than good algorithms and parallelism, and if we really need raw speed in other languages, we can generally call out to C or something.
Rust has a unique value proposition: safety and speed. Erlang/Elixir have one: supervision and easy parallelism. Ruby has one: well-worn tools for web development.
I don't understand the value proposition for Javascript on the server, other than "hey, you already know Javascript, right?", to which the answer is "LOL I thought I did but apparently everything I know is wrong all the time".
I think I'm going to sit out the Javascript frenzy until it's all very stable and Googling gets me answers that aren't So Last Week. And maybe we'll be writing Rust for browsers via WebAssembly by then, anyway.
One of the worst problems I see for the new JS developers is the tooling-overload. Being an experienced developer, I know why that tooling is required - but new devs are just overwhelmed with the information out there (and understandably so). And most of the todo-list projects tend to over-simplify the tooling. It takes time to learn the tooling and understand its importance
In a typical React app (+TypeScript), I have atleast 40 dependencies in package.json (frontend-only). I know exactly what each dependency is required for. And each time I have a new app, I create that package.json one line at a time - just to make sure I don't add unnecessary dependencies.
But for a JS newbie, knowing what dependency is what and why - is pretty overwhelming, tedious and uncomfortable. This is assuming they already spent time learning JS and the frameworks in the first place. Its easier to give up that important learning when you have to deliver "just a landing page in Angular" and answer to managers. After few iterations, the result is a disaster that is difficult to maintain, buggy and much more difficult to add features. Ultimately that adds to the development/maintenance cost.
I know why the JS tooling is complex, but sometimes I wish JS projects were as simple (and controlled) as creating C# windows apps using VS - where the tooling is mostly hidden
As an Ancient Developer I see the problem with Javascript as not being the language, but the ecosystem.
1. Async programming. Async programming is hands down the aspect of programming that college students do the worst on. As a TA at Berkeley I can say it was one of the hardest aspects of programming for students to do well in and yet Javascript starts with an total async model.
2. No testing. Some of this has to do with Javascript starting life as web browser only. Some of this has to do with writing test code for async programming. How does one write async test code? Very, very carefully.
3. Not invented here. Javascript is not a young language. It has been around more than 10 years and yet Javascript has the same chaotic ecosystem as a first year language. That's a permanent mind set, or ecosystem.
The natural conclusion of this kind of ecosystem is to eventually suggest developers just run in kernel mode and bypass user space altogether. Asynchronous code such as database pooling is hard to get correct. This why an app server has financial value: pay for the hard stuff. And, get this, the hard stuff can be abstracted away.. Same with distributed clustering. Because these kinds of difficult async services can be black box abstracted then we have a kernel, an OS and user space. Javascript challenges that notion, and all the experience and the history of why we have kernels to begin with. Javascript is asking developers to in effect become kernel developers, without doing testing , and with in ever changing 'not invented here' chaotic code base.
Does not bode well. Has nothing to do with language though.
While "async" programming is very hard to learn, it comes naturally in JavaScript. For example button.onclick = buttonClickedFunction
And learning "async" programming is a well worth investment. I've spent 10 years as a coach/trainer and one strategy I used was to start with the hard stuff, if they master for example the "snatch" (olympic lifting) all other gym exercises will be easy. And it's the same thing with JavaScript. If you master "async"/events then everything else will be easy.
I see that JavaScript has it's place in the browser but the whole back-end thing scares me. The ugly code (callbacks, etc), npm injecting only God knows what into your back-end servers, tons of work-arounds for trying to make JS not so ugly, are over the top.
The JS everywhere is so much like the "only tool you have is a hammer, so every problem looks like a nail" thing, it's amazing.
Creating a simple, secure, extensible middle-tier is a solved problem and is not in need of JS trying to solve it in a much more obtuse way. I've created many myself in everything from Delphi, PHP, C#, Groovy, to Java and I would never pick JS for that layer.
And a final thought, PHP used to get tons of bad press for being messy, etc, etc. But this JS stuff takes that mess to a whole new level. Perhaps PHP devs moved to node/js so they could make a mess and everyone would still think they are the cool kids?
I'd probably still prefer .Net, but ES6 and TypeScript have made nodejs pretty bearable for me. I'd prefer it to and maybe even argue it's a better platform for concurrency than Python at this point, even 3.5, for most situations.
The concurrency you get with async/await is nice enough and performant enough over 0 concurrency to make it pretty good. You don't get thread pools and it's not the fastest at single threaded processing.. And there is only one number representation which is a hassle forcing the use of BigNum occasionally.. The stdlib is a mix of callback and events and requires wrapping for good async/await consumptions and.. Well there are a lot of drawbacks.
C# on CLR is superior IMHO as a platform and language in nearly every way except... It's not JS. If you are moving around between a ton of stuff constantly you'll end up doing a lot of JS(and in my case TypeScript because I've successfully introduced it multiple times) due to frontend work and the employee common denominator.
Edit: This is a bit of a ramble. I don't think NodeJS is the best thing going. But while I personally would prefer C#, Go(depending on project), F#, potentially clojure, and etc after removing personal preference and adding in all the other factors that come in to play when selecting a technology that a team has to use and support -> nodejs/TypeScript is often a pretty good option.
Javascript on the backend is HORRIBLE. From a dev UX perspective it's a terrible cluster of random errors, and strange workarounds.
One time a project I was working on wouldn't run with some random ass error from some random ass node module. Try try try, not working. Spent 2 hours trying to find an answer online. For the hell of it I tried again and this time it ran with NO code changes.
That's the day Javascript as a backend language died for me. It's a house of cards stuck together with chinese knockoff glue.
If you have NPM on the server, uninstall it asap! Running NPM on the server is very dangerous! Use rsync from development/staging instead. Personally I avoid bloated modules, and keep everything in SCM. NPM (the archive) is a superb service, but you should not depend on it.
Full stack polyglot here. I have no idea how you justify anything you just said with facts. It sounds a lot more like you didn't learn the language or are repeating something you read of the internet.
You don't need many callbacks in the backend. Use await / async or promises for most problems instead of callbacks. Of course, callbacks are a fine tool when suitable.
I don't know what "work-arounds" you're talking about.
An internet writes a cheerful, helpful guide for dealing with the fact that like a sort of digital ice-nine, JavaScript turns everything it touches into a sluggish, half-finished, poorly-integrated pile of shit much like itself. Most of Hackernews assures itself that this is the natural order of things. One Hackernews traces "new" and "exciting" JavaScript features as far back as SICP, the Torah of the Scheme cult; his voice, along with those of the other dissenters, is quickly drowned out.
This perfectly captures how I feel about the proliferation of JavaScript. Thanks!
The way I see it, people try to push JavaScript everywhere, no matter how the domain is ill-suited for web technologies. We have even JS frameworks for microcontrollers and embedded development, for goodness' sake! What I fear is that this steals the mindshare of younger generation, and we'll be flooded with half-assed JS non-solutions to everything, while saner approaches fall off the hype train and wither away.
> The sheer number of tools and plugins and packages and dependencies and editor setup and build configurations required to do it “the right way” is enough to stall you before you even get started.
At some point you have to ask yourself how much of this is good engineering (does it help the end user?) and how much it's just having fun and impressing fellow engineers. Is the complicated build process worthwhile just to obtain a nicer syntax (for the current definition of "nicer")?
I think why there's so much churn in javascript frameworks is that in a dynamically typed system as soon as the framework objects get too big and complicated they become burdensome to remember and everyone starts chasing the next "bloat free" system. Then the "bloat free" system gains features and complexity and everyone gets annoyed and chases after the next thing. Ever wonder why Java codebases last forever and ever without being scrapped for the latest whiz bang every year? It's the static typing and the lack of cleverness in the language. The static typing helps manage the complexity and you can delete stuff and know you didn't break anything because the compiler will say so immediately. This is why Typescript is such a breath of fresh air. I actually get some help from the IDE like I'm used to with statically typed languages.
The curse of having been around for a while is that after a while it looks like the world is on auto-repeat. The antidote for this is to take a deep breath, smile (without looking condescending), say "that's interesting" and then wait and see what can stand the test of time.
Nah, your employer the bank paid a company $100k to use their app server, there's no developer-facing XML. It's hidden behind a GUI that the ops guys don't understand but won't let anyone else touch.
I was very frustrated when I tried to move to gulp+sass+babel+uglifier tool chain, It took me an afternoon to set everything up before I can write any actual code.
The whole thing looks like to be designed toward make big and long-term maintained website, not toward helping you to hack up throw away site quickly.
Stuff like gulp, after I installed it globally, I still have to install it per project, which makes little sense to me.
It used to be just "compass init; compass watch", and start write stuff, uglify JS before deploy, then done.
I still hates JS, I don't get why a language once hated by everyone, now is sexy again.
PHP in contrast, have improved a lot since 5.3, and it actually quite fun to write these days.
I'm an ancient web developer who would build entire web apps in django. I've tried creating forms with react, but it took 10 times longer to build it in react than it would have in django, maybe i'm just new to react, but i don't see how it would be faster even with more experience.
In django i would just create a model, a form class and a template and that would handle the rendering of the form, form validation, and saving the data into a db. But with react you would have to create the components and also create a separate api that would handle the retrival and saving of data.
Are there any ancient developers out there building web apps faster with react/vuejs/angular than django/rails?
Really ancient web developers know that Javascript adds hardly anything to most web pages. Some HTML, CSS, a few iframes (or just frames!) and form POST, and you've got a web site that's faster than most of today's junk.
I think my reaction to modern Javascript is to just ... don't.
While I love web/JS-only "apps", You are absolutely right! If you are not making a game like for example agar.io, you will be just fine with a static HTML page, or "old school" server rendered web app.
Except she stopped before he learned async/await, which is how you usually actually want to do async in Node.js now. It is even built into new versions finally without transpilation.
I'm not ancient but I am 39 and have been doing web programming for many years, going back to the days when PHP was popular. I switch over to primarily JavaScript and Node.js around 6 years or so ago.
To all the haters, there are very practical reasons I started using Node on the backend years ago. Trying to build a collaborative real-time web application with Twisted and whatever was a huge pain. With something like Node.js its much more practical because you get async and isomorphic (same codebase on client and server).
Point being, JavaScript has been a big deal for quite a long time, and it hasn't taken _all_ older developers up until just now to catch on.
And now we are actually one or two trends removed from that initial wave of popularity. Plenty of the young guys who basically wrote the book on Node.js and created the most downloaded-ever npm modules moved on to Go or whatever years ago. And plenty of them decided to move on to Rust (or a few picked up Nim if they are smart).
> Then JavaScript and its modern frameworks ate backend, frontend, and everything in between, and it was time to re-become a web developer in 2017 — who writes JavaScript.
Gee, I always thought that Javascript was a mediocre language, sufficient for its initial purpose. I assumed that node.js was just someone's idea of "wouldn't it be neat if I could have this on the backend too and use the same representation of data on backend + frontend?"
I have to admit it sure does sound popular these days. But I still am under the impression (delusion?) that a dedicated backend implementation in a better-suited-language is what I really need. That said, I have little experience with web dev.
This is like one of those pharmaceutical ads that vividly tells you about all the hideous side-effects of the drug. The cognitive dissonance is so high that even if the benefits happened to outweigh the downsides, I wouldn't know or care because it's just too ridiculous to even think about. And I'm not suffering from any disease the drug claims to treat, either.
[+] [-] tedunangst|9 years ago|reply
The logical conclusion then is to wait a year and ignore everything this article says. Saves a lot of time. :)
[+] [-] gbuk2013|9 years ago|reply
[+] [-] ericdykstra|9 years ago|reply
The extreme amount of neomania in JavaScript land is what keeps me away from it altogether. The idea that all JS articles and GitHub repositories are outdated after a year means the entire ecosystem is fragile.
I'll leave the always-chasing-the-next to the programming bootcampers, and I'll work on building skills that will be useful long after the next 100 javascript frameworks are dead instead.
[+] [-] jasonkostempski|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] ramijames|9 years ago|reply
Seriously, what the hell kind of attitude is that?
[+] [-] mullsork|9 years ago|reply
[+] [-] acemarke|9 years ago|reply
For anyone interested in learning React, here's my standard advice:
You should start out by reading through the official React docs and tutorial at https://facebook.github.io/react/, and use the official Create-React-App tool ( https://github.com/facebookincubator/create-react-app ) for setting up projects. It creates a project with a solid build setup, with no configuration needed on your part.
Past that, I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics.
[+] [-] mullsork|9 years ago|reply
create-react-app throws a ridiculous amount of crap in your face that you might end up not liking anyhow. If anything should overwhelm you then that project is it.
We have two working students at our company that were told to start their projects with CRA and they were clueless after two months. Learn one thing at a time.
[+] [-] Waterluvian|9 years ago|reply
When you feel yourself getting all rigid and tense in the muscles, say, because you read an article about how you're doing it wrong or that your favourite libraries are dead-ends, just take a deep breath and patiently allow yourself to return to your gelatinous form.
Now I know what you're thinking, "that's good and all, but I'll just slowly become an obsolete blob of goo in an over-priced, surprisingly uncomfortable, but good looking office chair. I like money, but at my company they don't pay the non-performing goo-balls." Which is an understandable concern, but before we address it, notice how your butt no-longer feels half sore, half numb when in goo form, and how nice that kind of is. Ever wonder what that third lever under your chair does? Now's a perfect time to find out!
As long as you accept that you're always going to be doing it wrong, that there's always a newer library, and that your code will never scale infinitely on the first try, you'll find that you can succeed and remain gelatinous. Pick a stack then put on the blinders until its time to refactor/rebuild for the next order of magnitude of scaling, or the next project.
[+] [-] Joeri|9 years ago|reply
It's a myth that new languages and frameworks offer better productivity. Mostly it's just the flavor that's different, not the calories. Sometimes you get a genuine improvement, like react, but the vast majority of frameworks are completely optional when it comes to getting stuff done. I'm always reminded of this when I observe the Delphi team at work. Still lapping any web developer when it comes to shipping features.
[+] [-] pvg|9 years ago|reply
You are the Bruce Lee of Modern Javascript programming and I salute you.
https://vimeo.com/3191188
[+] [-] mwpmaybe|9 years ago|reply
I held JS at arm's length for way too long, trying to use it without actually learning it. I finally grew tired of being illiterate and read "You Don't Know JavaScript" by Kyle Simpson[0] and it was eye-opening. The preface[1] really spoke to me and I suspect it will speak to many others like me. I only wish I'd read it two years ago.
0. https://github.com/getify/You-Dont-Know-JS
1. https://github.com/getify/You-Dont-Know-JS/blob/master/prefa...
[+] [-] agentultra|9 years ago|reply
And I learned to like ES6 from it. I've had to since JS is the de-facto language where I presently work. And I immediately recognized the functional bits that turned out, for me, to be the best parts: functors, monads, currying and the like.
However the problem I've found is that as our code scales up in size and sophistication it requires greater mental effort and discipline from the team to maintain consistency and manage complexity. ES6+, for better or worse, is a kitchen sink language. The hard part is getting everyone to agree on the subset to use and enforcing standards.
At first I thought this was a wonderful language for teaching FP in: it's forgiving, people can learn concepts as they go and put them into practice right away without having to go whole-hog on FP. This works for senior developers for the most part. However for junior developers, I've found, it can add to the confusion.
And if I'm reading the tea-leaves right it seems like Microsoft and Facebook have been having the same issues with large Javascript projects. Why else build tools to help manage the complexity if the language already provides them? It seems like there's a good language buried in Javascript, somewhere, but the lack of a sound-type system and a plethora of historical baggage obscures it.
All in all learning Javascript is worth it if only access to an ecosystem of highly-active development is valuable. It can be a pleasure to write... but my advice today would be to learn a pure FP language first and come back to Javascript if you need to.
[+] [-] flukus|9 years ago|reply
[+] [-] kbenson|9 years ago|reply
I'm happy it ended up being a self description. I was a little worried it was going to be a bit of directed humor that might be unintentionally offensive. Not that I'm generally thin-skinned about that, but it would have been a bit much to have an article about "you're old so you don't know how to do stuff, so let me explain it to you". I could see someone attempting that in humor, and it just coming across badly...
[+] [-] nawitus|9 years ago|reply
[+] [-] gm-conspiracy|9 years ago|reply
I have been foolishly looking at the documentation and wiki pages.
I have also enjoyed this site:
http://javascriptissexy.com/
[+] [-] nathan_long|9 years ago|reply
OK, so everything's changing all the time, everything you Google will be out of date, but it's worth it because... why, exactly?
Node doesn't block on IO. OK, cool. But the Erlang VM doesn't block on IO, either, AND it's not single threaded, so you can actually do parallel computation if you need to.
JS has a lot of raw speed these days. OK, cool. But raw speed is generally less important than good algorithms and parallelism, and if we really need raw speed in other languages, we can generally call out to C or something.
Rust has a unique value proposition: safety and speed. Erlang/Elixir have one: supervision and easy parallelism. Ruby has one: well-worn tools for web development.
I don't understand the value proposition for Javascript on the server, other than "hey, you already know Javascript, right?", to which the answer is "LOL I thought I did but apparently everything I know is wrong all the time".
I think I'm going to sit out the Javascript frenzy until it's all very stable and Googling gets me answers that aren't So Last Week. And maybe we'll be writing Rust for browsers via WebAssembly by then, anyway.
[+] [-] smdz|9 years ago|reply
In a typical React app (+TypeScript), I have atleast 40 dependencies in package.json (frontend-only). I know exactly what each dependency is required for. And each time I have a new app, I create that package.json one line at a time - just to make sure I don't add unnecessary dependencies.
But for a JS newbie, knowing what dependency is what and why - is pretty overwhelming, tedious and uncomfortable. This is assuming they already spent time learning JS and the frameworks in the first place. Its easier to give up that important learning when you have to deliver "just a landing page in Angular" and answer to managers. After few iterations, the result is a disaster that is difficult to maintain, buggy and much more difficult to add features. Ultimately that adds to the development/maintenance cost.
I know why the JS tooling is complex, but sometimes I wish JS projects were as simple (and controlled) as creating C# windows apps using VS - where the tooling is mostly hidden
[+] [-] mybrid|9 years ago|reply
1. Async programming. Async programming is hands down the aspect of programming that college students do the worst on. As a TA at Berkeley I can say it was one of the hardest aspects of programming for students to do well in and yet Javascript starts with an total async model.
2. No testing. Some of this has to do with Javascript starting life as web browser only. Some of this has to do with writing test code for async programming. How does one write async test code? Very, very carefully.
3. Not invented here. Javascript is not a young language. It has been around more than 10 years and yet Javascript has the same chaotic ecosystem as a first year language. That's a permanent mind set, or ecosystem.
The natural conclusion of this kind of ecosystem is to eventually suggest developers just run in kernel mode and bypass user space altogether. Asynchronous code such as database pooling is hard to get correct. This why an app server has financial value: pay for the hard stuff. And, get this, the hard stuff can be abstracted away.. Same with distributed clustering. Because these kinds of difficult async services can be black box abstracted then we have a kernel, an OS and user space. Javascript challenges that notion, and all the experience and the history of why we have kernels to begin with. Javascript is asking developers to in effect become kernel developers, without doing testing , and with in ever changing 'not invented here' chaotic code base.
Does not bode well. Has nothing to do with language though.
[+] [-] z3t4|9 years ago|reply
[+] [-] ben_pr|9 years ago|reply
The JS everywhere is so much like the "only tool you have is a hammer, so every problem looks like a nail" thing, it's amazing.
Creating a simple, secure, extensible middle-tier is a solved problem and is not in need of JS trying to solve it in a much more obtuse way. I've created many myself in everything from Delphi, PHP, C#, Groovy, to Java and I would never pick JS for that layer.
And a final thought, PHP used to get tons of bad press for being messy, etc, etc. But this JS stuff takes that mess to a whole new level. Perhaps PHP devs moved to node/js so they could make a mess and everyone would still think they are the cool kids?
[+] [-] Rapzid|9 years ago|reply
The concurrency you get with async/await is nice enough and performant enough over 0 concurrency to make it pretty good. You don't get thread pools and it's not the fastest at single threaded processing.. And there is only one number representation which is a hassle forcing the use of BigNum occasionally.. The stdlib is a mix of callback and events and requires wrapping for good async/await consumptions and.. Well there are a lot of drawbacks.
C# on CLR is superior IMHO as a platform and language in nearly every way except... It's not JS. If you are moving around between a ton of stuff constantly you'll end up doing a lot of JS(and in my case TypeScript because I've successfully introduced it multiple times) due to frontend work and the employee common denominator.
Edit: This is a bit of a ramble. I don't think NodeJS is the best thing going. But while I personally would prefer C#, Go(depending on project), F#, potentially clojure, and etc after removing personal preference and adding in all the other factors that come in to play when selecting a technology that a team has to use and support -> nodejs/TypeScript is often a pretty good option.
[+] [-] sergiotapia|9 years ago|reply
One time a project I was working on wouldn't run with some random ass error from some random ass node module. Try try try, not working. Spent 2 hours trying to find an answer online. For the hell of it I tried again and this time it ran with NO code changes.
That's the day Javascript as a backend language died for me. It's a house of cards stuck together with chinese knockoff glue.
[+] [-] bradmwalker|9 years ago|reply
[+] [-] z3t4|9 years ago|reply
[+] [-] Can_Not|9 years ago|reply
[+] [-] nawitus|9 years ago|reply
I don't know what "work-arounds" you're talking about.
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] bitwize|9 years ago|reply
[+] [-] TeMPOraL|9 years ago|reply
This perfectly captures how I feel about the proliferation of JavaScript. Thanks!
The way I see it, people try to push JavaScript everywhere, no matter how the domain is ill-suited for web technologies. We have even JS frameworks for microcontrollers and embedded development, for goodness' sake! What I fear is that this steals the mindshare of younger generation, and we'll be flooded with half-assed JS non-solutions to everything, while saner approaches fall off the hype train and wither away.
[+] [-] zeteo|9 years ago|reply
At some point you have to ask yourself how much of this is good engineering (does it help the end user?) and how much it's just having fun and impressing fellow engineers. Is the complicated build process worthwhile just to obtain a nicer syntax (for the current definition of "nicer")?
[+] [-] narrator|9 years ago|reply
[+] [-] dwaltrip|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] bborud|9 years ago|reply
[+] [-] brandonmenc|9 years ago|reply
Rediscovering the horrors of setting up a Java web app in the early 2000s, except now you configure it with json instead of xml.
[+] [-] ourmandave|9 years ago|reply
Read: all your v1 sh*t's broken.
[+] [-] empthought|9 years ago|reply
[+] [-] icc97|9 years ago|reply
[+] [-] albb0920|9 years ago|reply
The whole thing looks like to be designed toward make big and long-term maintained website, not toward helping you to hack up throw away site quickly.
Stuff like gulp, after I installed it globally, I still have to install it per project, which makes little sense to me.
It used to be just "compass init; compass watch", and start write stuff, uglify JS before deploy, then done.
I still hates JS, I don't get why a language once hated by everyone, now is sexy again. PHP in contrast, have improved a lot since 5.3, and it actually quite fun to write these days.
[+] [-] sparkling|9 years ago|reply
[+] [-] skyisblue|9 years ago|reply
In django i would just create a model, a form class and a template and that would handle the rendering of the form, form validation, and saving the data into a db. But with react you would have to create the components and also create a separate api that would handle the retrival and saving of data.
Are there any ancient developers out there building web apps faster with react/vuejs/angular than django/rails?
[+] [-] zlynx|9 years ago|reply
I think my reaction to modern Javascript is to just ... don't.
[+] [-] nkristoffersen|9 years ago|reply
These days it's all about the customer/user. And that user wants functionality!
[+] [-] z3t4|9 years ago|reply
[+] [-] ilaksh|9 years ago|reply
I'm not ancient but I am 39 and have been doing web programming for many years, going back to the days when PHP was popular. I switch over to primarily JavaScript and Node.js around 6 years or so ago.
To all the haters, there are very practical reasons I started using Node on the backend years ago. Trying to build a collaborative real-time web application with Twisted and whatever was a huge pain. With something like Node.js its much more practical because you get async and isomorphic (same codebase on client and server).
Point being, JavaScript has been a big deal for quite a long time, and it hasn't taken _all_ older developers up until just now to catch on.
And now we are actually one or two trends removed from that initial wave of popularity. Plenty of the young guys who basically wrote the book on Node.js and created the most downloaded-ever npm modules moved on to Go or whatever years ago. And plenty of them decided to move on to Rust (or a few picked up Nim if they are smart).
[+] [-] wyldfire|9 years ago|reply
Gee, I always thought that Javascript was a mediocre language, sufficient for its initial purpose. I assumed that node.js was just someone's idea of "wouldn't it be neat if I could have this on the backend too and use the same representation of data on backend + frontend?"
I have to admit it sure does sound popular these days. But I still am under the impression (delusion?) that a dedicated backend implementation in a better-suited-language is what I really need. That said, I have little experience with web dev.
[+] [-] rdiddly|9 years ago|reply