> 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. :)
Same with me except I'm using bash and the CLI to all the modern tools.
In 6 months I'll still remember how bash works and I get super simple debugging since I can just echo out the command it was about to run and start poking.
I'm still not sure why the JS community seems determined to slowly bootstrap an OS in javascript.
For projects with not-overly-complicated builds, I have had success writing each desired script as a shell script, but then calling said shell script with an npm script.
The shell scripts are nice for longevity, self-documenting, and if you have to call them with non-javascripty things.
Calling them with npm scripts is nice for consistency, readability for many devs, and some of the path-setting/node.js process.env-var stuff that you are able to do in an npm script.
I'm guessing it's the inner-platform effect in action, but I could have sworn that there's a more detailed name for it in reference to Javascript in particular -- something about systems always existing on the edge of acceptability or of legibility, or thereabouts. I think this was on Ward's Wiki, but I can't find it...
You joke, but Emacs commands just interface the standard tools on your system, not replace them.
And yes, Emacs programs get deprecated fast (compared to UNIX programs, they are way, way slow compared to JS code), but somehow people don't suffer to update them (mostly because people developing for Emacs know about that "compatibility" word).
It works for Emacs because it gives everything a consistent yet very powerful user interface, that facilitates heavy interoperability. In fact, that interface is more consistent and more powerful than most people have in their operating system.
Browsers, on the other hand, promote the exact opposite - inconsistent and weak interfaces, and no interop.
That's a load of crap, there's nothing portable about a JS environment that requires build xyz of browser pqr, plus the hardware requirements, bandwidth requirements, etc. Take any ONE of those away and you're hosed (e.g., try loading even a single web page from Amazon on 56k).
Every technology of the past 40 years has claimed "portability" as its mantra, and yet here we are still.
Sure, but the web is a unique portability story in the history of computing. Has any other platform been an open standard that ends up being table stakes for any new entrant? Think about it, if you try to make a computer without a web browser today, you'd be laughed out of the market.
Number of machines that can run code written in the language isn't really the best metric for realistic portability. Sure, your toaster might run C and not JS, but it isn't going on run your C anyway.
My browser isn't running my JavaScript, it's running yours. In fact, the capability to run my own code in my own browser is being slowly but systematically removed from the browser.
When I said "you" I meant "the developer" not "the user": the class of devices that run C and not JS is also a class of devices that generally don't run third party code. If you aren't a hardware manufacturer (or trying to sell middleware to one) the fact the embedded systems run binaries that were programmed in C isn't in any way relevant.
bash, make, and a POSIX suite probably run on many more platforms than nodejs does.
There is the caveat that too many people think they're writing portable shell scripts etc., but really they only work with GNU tools on Linux or MacOS. Then again, the same probably applies to many JS build scripts that end up relying on OS-specific behavior somewhere...
In my previous job, we had some bash scripts for a lot of things. It worked pretty well among Linux and Mac users in the team, but one day we had a new developer who was a windows user … We rewritten all those scripts in JavaScript using Grunt.
Maybe nowaday it's different thanks to Windows subsystem for Linux.
Wouldn't it be better for one developer to learn and adapt to the rest of the team? I don't get why all the rest had to adapt to this single person who didn't know shell.
There's a benefit to having multiple platforms on your development team if you are developing something for multiple platforms.
It's too often I see projects with "supports Linux, OSX, and Windows" only to find that none of the maintainers actually own a Mac and therefore it is filled with bugs and often requires the user to "find their own dependencies".
If we are talking days of time and not weeks, the benefits of making (and keeping) your whole system cross platform could pay off big time in the future when you or someone on your team wants to switch, or you just want to easily test on other platforms.
Exactly: Having a developer working on windows was a blessing since it allowed someone in the team to test on EI11 before we shipped to the product team, and it really improved our reactivity on this plateform. It wasn't our main target since our product was using webRtc(i.e. Firefox and Chrome), but it was supposed to fail gracefully on IE.
At least these days you can download VirtualBox images for free to test on IE11. But yeah, it's a luxury if there's a Windows developer that you can have fixing all the IE11 bugs ;).
There's plenty of other POSIX userlands for Windows before WSL (cygwin, Ming). There are also plenty of other cross platform programming environments before Grunt (Perl, Python, Ruby, Lua, Haskell, numerous lisps, etc).
JavaScript isn't unique. It's not even the best at what it does. It just has a monopoly in the browser so people latched on to it.
That's what every sane developer does and has been doing since the beginning of Node.js including tj (of express.js, koa, ... fame) [1] so you're in good company.
I remember a hilarious comment about "build systems becoming obsolete in year" (supposedly referring to the like of webpack, babel, grunt/gulp/broccoli, css.next if anyone is actually using it, etc.).
The newest trend as of a year ago is to ... use shell scripting [2].
In my experience npm scripts become way too complex on real world applications. But maybe I simply work on apps complex enough for this to become an issue. I've used grunt, gulp, webpack and npm scripts in multiple projects. Still not sure which is my favourite, probably gulp.
An advantage of using make is if you come back to a project a year later, you don't need to remember how to build the thing. It's documented in the makefile.
Makefiles are more stable, webpack just went through a breaking change to 2.0.
Makefiles are more versatile, they can be used not just for Javascript files, but for anything. I have a django project that uses lib-fann on the backend, and Selenium for data collection. I wish I had put that into a makefile because I can't remember the commands I used to build it, and now I have to take the time to go figure it out.
Makefiles have conventions for not just building, but also running: "make all" to build, "make run" to run, and if you have an unusual project, you can get plain "make" to print out out some documentation explaining what to do. Webpack has webpack-dev-server but then you have to remember that command.
Ultimately a lot of that could be had by a README file, of course, but Makefiles are easier.
Not the GP, but if I'm going to use make anyway, sure. init/systemd/upstart scripts for a system install, make run for a local install. It's exactly the same idea as running "node start" (apologies if I have the invocation wrong, I'm not really familiar with the node ecosystem).
A makefile is just a way to group commands together conveniently (at least, that's one aspect of it). So you can just type "make run-server" or whatever you want and it's just like running a script.
It's probably not something I would do on a production server, but it wouldn't hurt either.
It is also a way to write down and share very complicated command lines that you want to generate only one time because it is a pain to type it each time. So, a kind of self-documentation.
Not a JS dev, but if I run "ls" or "tar xf foo.tar.gz" and I see "Makefile", I instinctively run "make". Ditto for "./configure", although I'd probably despair if autotools were needed for a JS project ;)
I haven't had any trouble building and running projects years later without make. It has been a problem (in many languages) if I'm following a tutorial that didn't specify it's runtime and library dependency versions explicitly like an npm file or cargo file.
I've found that too much JS stuff produce multiple output files for make to be really comfortable --- make's support for multiple output files is very rudimentary and unless you follow the insanely complex and undocumented procedure to the letter, builds fail under obscure and almost impossible-to-debug circumstances.
I've had success with ninja, although the scripts are a bit long-winded.
How long are the builds? If it's not long then you could not worry about outputs and incremental builds and/or only worry about it where it makes sense.
I was just recently in the position of having to figure out a "modern" javascript workflow. After getting over my stupefaction that modular js requires compilation, I ended up with a Makefile, ./src, ./lib, and ./bin.
Same here! It does its job well. It frustrates me, however, that some of the JavaScript tooling (in particular, bundlers) are incapable of outputting their dependency tree. It makes efficient builds much harder, as you now need to manually track the dependencies of various files. Essentially, the equivalent of `gcc -M`.
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.
The thing with JavaScript is that as it evolves the opportunity to invent, and then solve, new problems presents itself.
Heck, most of the problems/solutions aren't even particularly new - they are just a JS implementation of other older concepts.
"...but it's just a client-side reimplementation of XSLT... BLOODY XSLT FFS!"
-- A developer, somewhere.
But for all the weird, wobbly wheels we reinvent, it reflects the time-honoured tradition of something getting a little better each time you rebuild it.
Each time the industry churns another fad we collectively learn something. Some of that filters back into browser development, some of that informs the development of the next set of frameworks and libraries, and some of it just forces us to ask difficult questions about our preconceptions.
But for me at least that's the appeal of a language like js - Programming is easy, solving problems is hard, so we keep trying.
I do some mentoring, and one of my mentoring calls was with a bootcamper where the instructor, mid-"cohort", decided to switch to Angular 2 - while it was still in beta. I was able to help (I had been working with it since earliest betas) but was quick to let this student know how poorly prepared they were about to be for the job market upon "graduation".
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.
> First, you can generally divide learners into two categories. There's a smaller group of people who feel the need to understand every abstraction and bit of tooling that they're using before they feel comfortable using all of those to build something. The larger group just wants to learn the actual tool or library at hand.
> The reason create-react-app exists in the first place is because "set up Webpack and Babel" was basically being viewed as a prerequisite for even the simplest React tutorial (even though you can use React without any build tooling whatsoever). That presented a large barrier for learning. By providing a one-command project creation tool with sensible (and even opinionated) defaults, CRA lowers the barrier for learning React, and allows experimentation while still having all the "nice" aspects like JSX, class properties syntax, and even hot reloading.
> So, no, it's definitely not a bad practice to use CRA!!! It's a fantastic tool to help you start learning and/or get right into building an application without hassle.
> If you want to learn more about the various aspects of configuring Webpack and other build tooling, there's several resources. If you look at the actual config files included in the react-scripts dependency (which contains the actual CRA configuration and build setup), you can see the heavily-commented list of options that CRA provides. Also, my React/Redux links list has a large section of Webpack tutorials, including some that start from the simplest possible Webpack config and add more options from there.
To emphasize this: what CRA gives you is just a preconfigured project that builds properly out of the box. It doesn't force a state management lib on you. It doesn't force a router. It DEFINITELY does NOT "throw a bunch of stuff" at you. Maybe you have CRA confused with some other tool?
"Set up webpack and babel" shouldn't just be a step, it should be something you learn: You need to understand why you need Webpack, why you need babel, what problems they solve, the reason they're now part of your toolchain.
It doesn't take long to understand that, and that's not to say C-R-A isn't useful, but I personally find it to be a gap if I have these massive tools as part of my pipeline and don't understand why and how they're separate from the rest of my libraries.
Should it be something you learn? Sure. Should it be the first thing you learn in the stack, or something that blocks you from shipping? Shrug. Some people feel the need to depth-first-search their stack as part of the learning process. But at some point you have to say "This is as deep in the stack as I'm going to care about today" -- otherwise you end up sitting down to make a web app and studying particle physics.
I think 2 years ago, you absolutely needed to go that deep, mostly because when you sat down to work in the React ecosystem, you were almost certainly going to end up debugging something in a webpack config. I don't think that's the case today. It's a nice-to-have, and certainly will bring value eventually, but at this point I'm hoping to pull my non-C-R-A apps onto C-R-A so that managing the tooling isn't my job.
Plenty of devs ship plenty of business value in Rails without understanding the full stack, and that's fine. It's worth taking a deep dive when needed, or when specific concerns make themselves known, but saying "you need to learn everything now!" is a huge barrier to entry -- getting those out of the way is a good thing.
Yeah I get you. I understand the use case of "We just need to ship something for a client now", I've been there plenty myself and C-R-A solves a real problem (as well as it being useful for experienced devs etc).
But as far as learning goes, I really think it's critical to learn what the components you are using do. Otherwise, you have react, and a black box you don't understand next to it.
That's fine. When you want to learn what's in the black box you can dig into it. The key is unblocking people on their path to their initial goal (eg. learn React) so they don't give up after getting stuck on a prerequisite (learn to configure webpack, learn to configure babel).
You don't _need_ those to learn React. Yes, you probably should use them for a production app, but you don't need them _just_ to learn React. (And it's still possible to use React in prod without Webpack and Babel. We're adding a couple new features to an existing ES5/Backbone app which still uses Require.js, so no Webpack or Babel there. We don't get to use JSX syntax, but the react-hyperscript-helpers lib keeps things reasonably readable.)
CRA serves three primary purposes: it allows React learners to set up an environment without having to learn Webpack and Babel first; it allows experienced React devs to spin up a project without having to do all the configuration work (or copy and paste it from somewhere); and it also provides a common starting point for instructions and tutorials. For example, my recent blog post on using the Cesium.js 3D globe library with Webpack and React ( http://blog.isquaredsoftware.com/2017/03/declarative-earth-p...) was able to start by just saying "Create a CRA project, eject, and modify these two config values".
So yes, knowing what all the tools are used for and how to configure them is a good thing. But that should NOT be a barrier or prerequisite for someone who just wants to learn how to use React.
> You need to understand why you need Webpack, why you need babel, what problems they solve, the reason they're now part of your toolchain.
I feel this is applicable here:
> > First, you can generally divide learners into two categories. There's a smaller group of people who feel the need to understand every abstraction and bit of tooling that they're using before they feel comfortable using all of those to build something. The larger group just wants to learn the actual tool or library at hand.
You say "you _need_ to understand why you need Webpack/Babel", but that isn't the case.
People learn in different ways. I learned React using CRA, because you get an immediately productive React environment. Later on I learned what Webpack and Babel were for.
If you forced me to learn Babel and Webpack first, while all I wanted to do was check out the React buzz, I would have been turned off immediately.
But the point is you did end up learning it. I didn't claim you need to understand them before you understand React... however, you also don't need them yet when you are learning react. You can use React just fine without them; it gets cumbersome, but by that point, it's time to learn about the toolchain - which is the ideal point to learn about it: you are now facing the problems they are solving.
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.
Delphi lapping the web has less to do with delphi and more to do with the web. Web development sucks and all the frameworks and javascript engines and css preprocessors are just plaster and paint over that fundamentally broken structure.
I do wonder what would happen if modern adaptive development practices ("agile") were coupled with older high productivity dev platforms like Delphi. I suspect it'd be a good combination.
Disagree -- the web platform itself is pretty solid. Websites made decades ago are still accessible. The tooling that exists today will probably last much shorter.
Right. Apart from Flash, Java applets, and the old MS alternative. Those websites aren't accessible in practice, the technologies they're based on are dead or dying.
CSS preprocessors is something I don't want to get into (ex web dev jack of trades 5 legged pony): install gulp, node, npm, git pull, etc. just to build/compile a stylesheet ? Erk. So now I have to work around CSS hacks and the processing quirks, etc. /ranting
Question: what's wrong with ExtJS. Granted, I haven't used it in several years and at the time found that it produced a lot of difficult to track down bugs, but at the same time it seemed like a reasonable choice for a certain type of app. If you need to build something that emulated a desktop app in the browser, say for an internal dashboard, why would Ext be a bad choice today?
The last time I used ExtJS was a few years ago, so it may have changed but: Its tables all the way down. Horrible html generated from a really clunky declarative library. If you only ever _just_ want to make a windows 2000 deskop-like experience for older browsers, than yes it is serviceable. Also very painful to extend / create custom work when you're dealing with that level of nesting. ExtJS solves an old problem that you very likely will not run in to today. Better to use modern-ish libraries and use SASS or LESS to get that good 'ol early 2000s desktop look.
ExtJS has two modes, modern mode is based on sencha touch and uses CSS-based layout, classic mode is based on the older ExtJS rendering model and uses tables for layout. You get a richer feature set in classic mode, but the end goal is to achieve parity and then phase it out.
They're a pretty isolated eco system, although it seems they're working to improve that. Right now they use their own ant-based build system, have their own ES6-incompatible class system and you're pretty far removed from HTML/CSS. So it's really hard to leverage "regular" JS frontend skills there.
Which might be fine if the system would work properly, as Ext would not directly compete with more "bare metal" component systems, but work as some kind of browser-based GUI DSL (which was what got a lot of people into it back in the days when DHTML was young).
Sadly, they seem more focused on introducing new features than fixing bugs or making all those elements work together (recent example: Conflict between new two-way binding and old statefulness of grid column sorting/order/filtering).
Mindshare isn't as good as with almost any other lib (some guy had the same problem you have with 6.2 with version 3.4, no solution ever posted), and due to it not being open source, there's not exactly a large community working on it, fixing things, adding new components etc.
And for all that, you have to pay a pretty stiff fee.
We pulled a Backbone app up out of storage along with some others. Then we wrote a few more versions in modern frameworks. It's an internal comparison app. Two things of note.
1) We always start from the Backbone app, it's the easiest to convert to other frameworks.
2) It ran right out of the box, no problems. No library muck and no fixes.
That being said I did eventually move on to writing new stuff in Angular2x, but I stand by Backbone as good and reliable.
Literally this. It still does everything I need and not a thing more and is entirely grokable whilst being extendable. Amazing little piece of software.
I trip out every time I look at the source of it and Underscore. There's nothing there, it's all so simple, it's like the bare minimum amount of code that can be there to do the things it does.
If you create a bunch of stuff then don't dereference/unlink/whatever you want to call it in JS-land it you're going to have a bunch of references to stuff laying around. I don't fault Backbone for that.
Yeah, I cut my teeth on Backbone and I'm super glad for the experience. And as git-pull mentioned, the source code is nicely annotated (and concise), so it makes debugging easy.
Udacity teaches Knockout as their front-end framework in their Front-End Nanodegree. I would guess it's because it's extremely simple to learn (no Babel or anything) yet also very powerful in teaching code organization concepts (such as ViewModel).
It certainly isn't "modern," and doing anything remotely complicated will have you clawing at your eyes, but Udacity teaches it not as a framework to use, but as a framework to learn from. If I hadn't learned the basics of code organization by creating a simple app from Knockout, I'd be writing a _lot_ of logic in the render function of my React components (rather than computing them in a `mapStateToProps` selector), and I see a lot of beginner programmers do this.
Not to say that React is _bad_ for a beginner to learn, but it makes it very easy to do things the wrong way without letting you know it's wrong. With Knockout, you literally _can't_ put any logic in the View layer without it looking ugly, which is a beautiful pattern for a beginner.
> 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.
I'm slowly coming round to the idea of committing to Angular for these reasons, just as HN commenters seem to be increasingly talking about React as the current Big Thing.
You should be a motivational speaker (or demotivational speaker); I already feel a lot of better about myself (well, I feel worse about myself, but am more comfortable with it).
Well said! I wish I had discovered this truth few years before. In fact while it's especially true for JavaScript it's also true e.g. for Ruby ecosystem ~5 (?) years ago, with all the endless stream of test, factory, workers gems etc.
Me too. Found myself trying to work out a pattern behind it all, something on the edge of discovery but just too far out of reach... But then I decided to let javascript be javascript, and focus on the documentation of libraries to further my understanding, which in turn developed my understanding of JavaScript. Some things you just need to let go.
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.
The value proposition is "You can use the same code on both the server and client" (in addition to "You already know Javascript"). That's a really big advantage in some cases. Think of collaborative editing (where you need to apply operational transforms on all clients + the server), or form validation, or game replay, or anything where you want to give real-time feedback to the user while also validating those operations on the server.
If all you're doing is throwing HTML templates on top of CRUD results, then yeah, Node.js doesn't get you much. But there are other problem domains where you're basically forced into it. My first startup (WYSIWYG casual game creation) would've been much easier if Node had existed when I was working on it; I spent a ridiculous amount of time writing polyglot Javascript/Actionscript runtime libraries and server-side compilers that would spit back a blob of Javascript in an AJAX request.
>The value proposition is "You can use the same code on both the server and client"
With differences in standard libraries, environment specifics and even language features available, I think a far more accurate statement would be "you can sometimes use some code on both the server and client".
I can relate. I have been working on the front endfor 8 years. I don't understand why people would want it for the back end when better alternatives exist.
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
JS held a lot of appeal for me - coming from the Java world - because you didn't need a lot of tooling but basically a text editor and a browser. Add a handful of libraries and I started liking that goofy little language.
Of course that setup still works, but if you want to do anything a bit more advanced, you descend into a living hell that feels as complicated an impenetrable as J2EE did. As clunky as the JCP is, in the last years it helped create a couple of sane standards from existing implementations. I just wish there was something similar in JS world.
I also like that all you need is a simple editor and a browser or NodeJS or both. I think the problem is going from writing static or server rendered HTML into making a web/js app, you try to reuse the design patterns from server HTML rendering, witch is like using the wrong side of a hammer. If you write a web/JS-rendered app all the HTML you need is <script src="main.js"></script>
In the case of React, the team behind Create React App [1] is doing an excellent job at taking care of all the build system, with only one Dev dependency: a script, which allows developers to focus solely on their non dev dependencies while providing all the necessary tooling to focus on doing their job: crafting software.
You can "eject" from this beginner friendly mode if you want to have more freedom.
Funny thing is that we "ejected" on our current project, but I'm contemplating moving back to CRA as it just makes developing our React app super easy and stress-free.
CRA helps starters with plain React, but I believe CRA doesn't come in default with Redux (react-redux), react-router, redux-thunk.
And useful (arguably opinionated) stuff is missing like react-hot-loader, redux-logger, sass-loader, font loaders, customized webpack and webpack-dev-server. Also it does not differentiate between smart and dumb components. For large complex SPAs, all that stuff is very useful.
Correct, because none of those are needed for use with React itself, and different applications will use a wide variety of different libraries (Redux vs MobX, etc). Also, the phrase "doesn't differentiate between smart and dumb components" is pretty irrelevant in this discussion, because that's merely a conceptual distinction.
I did actually open up a discussion a couple days ago asking for discussion on what kinds of "official Redux-based addons" might look like: https://github.com/reactjs/redux/issues/2295 . Possible ideas include things like a small "redux-starter" wrapper library that sets up a store with sensible defaults. Dan Abramov also tossed out a list of ideas for a hypothetical more in-depth integrated library built on top of Redux's core behavior.
>Being an experienced developer, I know why that tooling is required
In terms of JavaScript I still don't understand why all that "tooling" is required. Every time I try to understand how the JavaScript tools fit together I end up just finding a .js file I can stick in the top of the HTML.
The "install with npm" on a website isn't helpful at all, because I'm not doing Node, I'm just building a website and doesn't want Node.
What would help is a big poster, showing how stuff fits together. Grunt, Bower, Node, NPM, it's just a big pile of confusing.
I recently gave a "Modern Web Dev Overview" presentation that talks about the history of web dev technologies, the problems that these tools are trying to solve, and how they fit together. You might find it useful: http://blog.isquaredsoftware.com/2016/10/presentation-modern... .
Don't think of Node as a web server, that's what I'm guessing your understanding of it is. Think of it as a copy of JS that is available on your machine.
NPM is a package manager for you guessed it, Node. You use it to install dependencies, whatever those might be for your situation.
I will ignore Bower.
Grunt is a task runner, say you have a task like minifying javascript files. Grunt runs this task for you. Or CSS preprocessing, any task, it'll run it. There are other things in this space too. Grunt, gulp, webpack, browserify, etc.
The pieces aren't that hard to understand, you just have to read what they do.
Sure you can stick a JS file in an HTML file and you're good, but when you start building more complex apps where you need common code in parts, specific code in others, this becomes ridiculous to do by hand, that's why we have build tools.
I might be daft but I honestly don't even understand what "build" is in the context of a language that isn't compiled. Is it copying files to an output location together with dependencies and possibly including some transformations (minify etc)?
"Is it copying files to an output location together with dependencies and possibly including some transformations (minify etc)?".
That, and also other things, like compiling ES7+ JavaScript code to ES5 to run in most browsers, or compiling a typed JavaScript file to non-typed (e.g. TypeScript to JavaScript). You can also compile files to .css and .html from different languages like pug and scss. There's a large amount of various transformations that can be applied to web files.
Some of the other build steps we run: checking to ensure all dependencies are installed, concatenation, minification, obfuscation, code splitting, template compilation, copying files, deleting files, resolving require/bundling whatever that is called.
>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
Being probably even more experienced (or at least older in the business) developer, I don't. :-)
Most tools solve very specific problems that usually only matter on large scale production apps. Webpack, for example, is fantastic if you need to create split points in your code to absolutely minimize the amount of js you send to the client. Or, if there is a chunk of js code (like React, or jquery) that rarely changes and could benefit from being part of a separately cached bundle.
IMO, the biggest problem the js world has is that the folks keep creating solutions for really _big_ problems, but no one cares about creating solutions for folks that just want to get something done quickly.
>Most tools solve very specific problems that usually only matter on large scale production apps. Webpack, for example, is fantastic if you need to create split points in your code to absolutely minimize the amount of js you send to the client. Or, if there is a chunk of js code (like React, or jquery) that rarely changes and could benefit from being part of a separately cached bundle.
Yeah, I know what they do and what they are used for. I don't know why they are needed. Browsers could have solved this problem from the start, with proper incremental module import syntax in JS scripts.
Kind of but you can use it differently: I like writing pure modern ES6, APIs, etc. and using Babel only to compile ES5 + polyfills for old browsers. You can develop directly in most current browsers, avoid lengthy compile times, etc. and there's zero lock-in if you prefer a separate tool next year.
That's quite different from some of the dreadnaught-weight frameworks which need a huge toolchain to run Hello World. That can be worth it if you have a huge complex application which uses all of that functionality but otherwise it turns simple projects into ongoing time commitments.
I know js devs hate monolitic frameworks, but as I also come from C# land I find the cognitive cost of "what micro framework should I choose?" to be annoying.
So I created my own monolithic framework (npm xlib) which is basically a collection of my commonly used modules and my own helper utils.
I wish you could write comments in JSON files... What I would give to write the reason I kept this package at version 0.9.1 instead of upgrading to 1.0.0...
But it would also be useful for onboarding new members.
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.
> es6 and TypeScript have made nodejs pretty bearable for me
I'm glad you found a solution, but I think the fact that you need typescript to make javascript bearable is an issue. Typescript isn't javascript, so the implication is that what we get out of the box is not bearable, and we then have competing languages, tooling, workflows, etc. and no "right way" to do things. Just more fragmentation, and an unbearable default.
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.
Everytime I try to get excited about Javascript on the server and built anything of substance, every damned module's example code is nothing but a bunch of console.logs. There's must be some magical framework I'm missing where that's a way to build apps. (Console Dot Logs on Fails?)
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")?
My best experience is with Ember and Ember-CLI where the build process is pre-defined and laid out for you, and the requirements to start a project are: have node + bower + ember-cli installed globally, type `ember new project-name`, `npm install` it to get the dependencies, then start writing ES6. Type `ember build` when you're ready to create a browser-ready artifact. As far as tooling and build processes go, IMO it's less cumbersome than setting up a proper Go environment and cross-compiling to different platforms.
>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.
Javascript (and most Enterprise) developers will tell you it's the former. Nearly every other developer will tell you it's the latter.
Enterprise Java developers are used confusing and magical build tools, so a few tools for JavaScript isn't going to strike them as being weird or complex.
I don't think I agree. Willingness to learn vs willingness to expend mental capacity are different. Sometimes the mental capacity to learn the abstraction equals what it would take to just deal with the complexity that the abstraction is attempting to hide.
Imo, most of that is worth it. It does not help end user specifically, but it helps you a lot. Looking at the screen shot, some of it turns the old ugly JavaScript and css into something sane, less browser difference sensitive. Some of it generates/minifies result and some of it are libraries you would have to write by yourself.
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.
Maybe it's not "statically typed" but "strongly typed" that counts. Both Python & Ruby are strongly typed. Speaking personally, I definitely appreciate anything that helps make sure type conversions are intentional and predictable. Whether that's truly the explanation for the larger trends, I don't know, but it's a thought.
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.
My development team spends more time evaluating new tools and doing proof of concepts for problems I am pretty certain could be solved just fine with existing web service providers available for Tomcat and an old fashioned PostGres install that I don't know if they are ever going to build the actual solution.
If they do I will never sleep again as the rickety POC gets deployed in the wild
I was mostly referring to the enthusiasm that tends to spring up around technology that isn't really all that good. The merits of the underlying technology isn't important for adoption -- the momentum of the community is. Programming languages don't win on merit. They win on ease of entry and community.
Hence so many programming languages (and/or implementations of them) that, in sober retrospect, are horseshit.
I've even seen that the community around a language or a technology doesn't have to be a positive one. Even negative communities can create momentum. Which is puzzling to me, but probably not to a political scientist who would actually know something about the behaviors of multitudes.
As for keeping your cool and seeing what sticks: nobody has ever regretted being on the fence for a few years before committing a big chunk of your professional life to a technology. The only thing that really happens is that stuff is even better by the time you make your bet. You don't really lose out on anything by waiting.
(That being said: like anyone else, I've charged in early and started using technologies prematurely. And regretted it)
I have a slightly different take on the latter: we learned that doing specialized persistence that solves hard problems is hard. And it is pointless when it doesn't even solve the most basic problems of reliably storing data.
We also learned that just because something calls something a "database", it doesn't mean that it replaces what came before it. There's room for new categories of things that solve different problems than, say, relational databases, when it comes to persistence.
We ended up just simply not caring about how "modern right way to do things" looks like. Essentially any persistent data can be stored into PostgreSQL and NFS mounted storage server and ideal way to do rich clientside javascript is to serialize the whole thing out of some server-side object tree.
I've come to be suspicious of people who claim to do things in a "modern" way :-).
I had a roundabout journey from trying to beat more traditional technologies into shape to deal with massive transaction rates, giving up, writing more specialized (but narrow scope) stuff, then changing jobs to a (competing) company that pioneered building more general alternatives to SQL servers (for internal use).
As I came out of that company I saw all these projects trying to mimic what we had been doing so I figured "okay, good, I'll try that then". Since I'd spent the last decade in territories where traditional SQL servers posed challenges.
I learned quite a few things. The first was that while I had been working with people who really knew how the guts of a database worked, in "the real world", most developers see the database as something that contains black magic. You'll meet people who don't even know how to design a schema given certain dominant access patterns -- and it'll be their job to design, and work with the schema. This surprised me.
The second was that people who weren't really up for the task would make database products. Not to mention any names, but I remember reading through the source code of one of the more popular "modern" NoSQL databases and wondering "how are they getting away with this? They are not even trying". It was bad on a technical level, an architectural level and it demanded too much proactive behavior and attention from developers. And they happily marketed it as something it most definitively wasn't.
As a consequence I also misjudged how fast NoSQL databases would evolve early on, and much more importantly: mature.
One database we used curiously never lost any data and never corrupted its data (which all the other databases we used did), but holy shit was it a lot of work to keep the database humming. It was just so godawfully sloppy and focus was on adding features -- not tightening up what was already there. And things stayed like that. For a long time.
So how do I approach persistence now? I put as much as I can into things like PostgreSQL and when I really need high speeds to solve narrowly focused problems, I write custom solutions for that. But I try to make things as trivial as possible and I fret over any implicit or explicit promise I try to make.
Promises are cool. Here's how they're described in the the classic book "Structure and Interpretation of Computer Programs" (SICP), first published in 1985:
If you read this book, you'll soon start to see a lot of the concepts its presents manifested in many places. And a lot of those come from well before the book itself was published, in some cases by decades (Lisp and Lambda calculus for example).
The amount of effort we've put in to avoid just basic sane development practices and discipline is astounding.
We _could_ spend a few days thinking through the problem and developing a solution that makes sense using our known tools and technologies, by analyzing the issue at fundamental properties, OR FUCK IT, spend a year writing a new JS library that is so full of obfuscated crud that no one can tell if you actually solved the problem or not.
I get it, writing new libraries is fun, but the old tools are there because they've been working, and well, for 30-40 years.
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.
PHP is the diamond in the rough. Don't let all the bad tutorials fool you, beneath is a great platform where you are truly productive.
You get far by only having PHP and you get twice that by only installing composer.
No insane build steps, no running server process that needs to be hot reloaded, composer is faster relative npm, decent typing system and built in development web server.
To make PHP a superb language(okay, a better language :-) I wish for three things.
* Typed callable signatures
* Function autoloading
* Generics
Looking forward to the possibility of a jit in PHP 8.
In Visual Studio you go from 0 to "Hello world" in about as much time it takes to download and install the behemoth. And if you're having trouble with some part of the toolchain you'll know that everybody using the same version of VS will have the same tools so there's a very clear way to find help: "Visual Studio {$version} {$description_problem}".
While ASP.Net used to be (pre MVC) the shitty enterprise sloth that was holding you back to any serious quick development now a full web stack looks like more work to maintain than using VS. I think that should alarm some people.
Things should "just work" while I am getting things done. And if not there should be a reliable way to troubleshoot it.
PHP definitely got better while it still has a lot to improve. It just looks a lot less ugly when I see it, actually smart sometimes.
You should be able to use one IDE with full autocomplete (not autoguess) and a full stack going from project creation to project publishing. Otherwise your time is wasted.
When you install a package locally, executable files get added to node_modules/.bin. So you can run gulp using node_modules/.bin/gulp. Also, npm scripts automatically have that directory added to their path when they are run, which lets you use npm run to access things like gulp.
> i will come back once you JS folks have agreed on a tool set and actually use it for more than 6 months.
It works as a joke too, but the vast majority of JS developers aren't using tools younger than 6 months old. Even current hotness Vue.js was originally released in 2015, and Webpack was initially released in 2012.
My point wasn't that there aren't interesting tools younger than 6 months, just that nothing compels JS devs to use them or even pay attention to them until they're as established (in age, use, GitHub stars, whatever) as is comfortable for them.
The trouble is that yarn is legitimately better than npm. My life is better as a developer because of yarn.
I'm not claiming that all those transitions were for the best, far from it, but the real question for any language community to answer is: "how much churn is acceptable in the pursuit of better?" JS is an ongoing cultural experiment in seeing what happens when you turn that dial to 11.
I'll share my personal experience, which is that the move to Vue.js 2 was fairly straightforward. The project's handy "migration helper" helped a lot. Still, it's not something I jumped on immediately.
I haven't upgraded my projects to Webpack 2 yet. I'm interested but not compelled to, and I'll do it when it makes sense for me.
Does that make JavaScript a bad ecosystem? I have a hard time thinking of thoughtful major releases as a bad thing.
If Knockout has been around for over a decade (v3.4.2 was released a couple weeks ago), isn't it also the perfect examples that churn isn't a given just because JavaScript?
The churn comes from the community, not from any particular library. Only having experience with knockout but not react or angular for instance will halve your job opportunities for instance.
How ancient a web developer are you? When I started doing web work in 1994 people couldn't agree on C vs Perl. When C fell into disuse it was Perl vs PHP vs Python vs Ruby. Unless you liked ASP/VBScript or just wanted to use Flash/ActionScript for everything. Or Java Applets.
If there was a time when web folks agreed on a tool set I missed it.
If there was a time when web folks agreed on a tool set I missed it.
It's not really about agreeing on everything, though, is it? What matters is having enough standardisation and longevity that you can make intelligent decisions today and expect your code to work for a useful length of time and to play nicely with code written by others who also make intelligent decisions today.
You can run a CGI process written in whatever programming language you want under any of the popular web servers today, and it will work essentially the same way as it did 20 years ago.
Until browser developers decided that backwards compatibility was too much trouble to continue supporting, which is a relatively recent development, you could also run Flash or Java applets written many years ago with essentially the same results today.
There was a brief period of stability in 06-08 where everyone just used either Rails or Django (pick your poison) + JQuery on the frontend. Once 09 hit everything exploded.
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?
> I'm an ancient web developer who would build entire web apps in django
No, you aren't an a "ancient web developer", ancient web development goes way back before "CSS" even existed when "standardization" was hot topic and Opera was the best of the best. JS-fans keep trying hard to dismiss everything "we won" before in favor of their own "js-based" flavors (sass/less/react/etc) favorite motto "one languague to rule them all, one language to bring them all" (... and in the darkness bind them).
It depends on the requirements. If you need a very complicated form with lots of dynamic parts, it will be quicker and a better user experience to do all the dynamic stuff on the front end, then pass the data to the back-end for simple processing. There is no universal solution.
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.
They want functionality, but they don't care if the functionality is brought to them with a SPA built on the latest JS fart or some older than two years stack.
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).
While async/await is a nice abstraction/sugar, you will be much better off actually learning "async" programming without the training wheel. Then once you master "async" you can go back to use the abstraction/sugars if it still makes sense. For example Promises are very bad abstraction because you will make a lot of errors if you don't have a deep understanding.
> 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.
I have 10+ years of web dev experience and have been underwhelmed with node on the backend. One of the supposed strengths is I/O scalability but in my experience it has little advantage over the JVM or .net so why not just use one of those and get both I/O and computation scaling.
I also have not been as impressed with the backend code you can find in node compared to just about anything else. Useful projects are abandoned or obsoleted, documentation can be very poor and the pointless churn is well documented here and elsewhere. Basically all problems you'd expect without a standard library or corporate backing. Though those things hardly seem necessary given the high quality of Elixir/Phoenix or Rails. I guess what I'm trying to say here is you'll be better off using just about anything else on the backend. The only positives that come to mind is having ES6/TS/JSON everywhere and perhaps socket.io is a better option than some JVM/.net server/client communication libraries.
I think it's important to keep some perspective here.
JavaScript is a popular language for one major reason: for native front-end web development, it has effectively been the only language. If you didn't want to use plug-ins, you were going to use JS. If you wanted to use some other language, it was going to be transpiled to JS.
Node is also popular for one major reason: it's the same language that people who do front-end work already know, but running on the back-end. You can (mostly) use the same libraries on either side. You can take someone who's familiar with one side, and they can reasonably quickly be productive writing code for the other.
None of this changes the fact that JavaScript is a very mediocre language by modern standards. Like many popular languages, it has improved over time, but like many popular languages that have been around for a while, it has a lot of fundamental warts that you can never fully escape.
Neither does any of this change the fact that JavaScript's surrounding tool and library ecosystem is very mediocre by modern standards. The lack of stability, standardisation and longevity cripples progress and results in huge amounts of duplicated or otherwise wasted effort. This is partly a cultural thing, and partly due to technical limitations in a language that was never designed for programming in the large but is now being pressed into service in that role.
JavaScript is the language of the moment because web development is the high profile field of the moment, but don't let the blog posts fool you. Enthusiastic but often inexperienced developers working in JavaScript write as if everything else is somehow old-fashioned and out-of-date, yet many ideas hailed as radical advances in the JS community have been absolutely routine in most of the programming world for decades. There are plenty of people getting on with doing useful work -- often much more productively -- using those oh so horrible, old-fashioned, out-of-date tools. They just don't need to shout from the rooftops that they now have a standard way to import code from one file and call it from another one, or to combine code from multiple files but strip out parts that are never used to keep the size of the output down, or to separate input, output and data processing, because the rest of the world was learning these lessons in the 1970s and 1980s. :-)
I partly agree with you but I still like JavaScript and the ecosystem around it.
There's something to be said wrt. "worse is better" when it comes to JavaScript, as in "JavaScript is such a crappy language that it has managed to go unnoticed by architecture astronauts for most of the time". By which I mean, JavaScript front-end code of the jquery-era is extremely compact and to the point, avoiding metadata layers and other bloat.
In judging JavaScript backend code, lack of experience of developers should be taken into account, who mostly came from front-end developer roles.
Node was a good idea for highly connected IO based networking. It think it goes a bit far when used for web development (rendering performs on the main loop).
As far as reuse goes, no idea. I've heard mixed reviews. I do know that missing a var or a let can cause big, hard to trace state issues on the server.
"rendering performs on the main loop" - rendering on the backend is not a good idea, just use static templating (e.g. serve a static index.html file to the browser).
There is no practical difference to the server whether it converts data to JSON or converts data to semantic HTML. Either one is rendering, or neither is.
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.
Looking at some of these examples/techniques reminds me of the "Enterprise FizzBuzz" that we used to make fun of... except now no one is laughing and it's a serious technique. The magic Redux strings are were I draw the line. Absolutely not.
Seriously, when your "hello world" example is 150 lines of totally non-DRY code littered with constants and conditionals ... I feel bad for people trying to learn this style of web dev. It's ill-suited to the vast majority of use cases out there today.
I attacked the modern Javascript approach through first focusing on functional programming.
1. Python + functional programming in Python
Python is hardly a pure functional language, but it's lovely and simple and has all the core concepts including list comprehensions. This leads you on to...
2. Haskell
If you want to find a pure functional solution to a Python problem, first search for the Haskell one and translate it. Then read Learn You a Haskell [0] which was the funniest programming book I ever read and almost, almost taught me about monads (I had it for a second, then tried to explain it in Python and all was lost)
Now you can relax cause the hard bit is done.
3. Read Javascript the Good Parts and only pay attention to the functional programming bits. Suddenly mentions of currying aren't so scary.
4. Work your way through the funfunfunction [1] videos, especially the functional playlist [2] and for added bonus he has videos where he works through the first few chapters of Learn You a Haskell.
Then you've got map, reduce, filter all completely under control. Now immutability makes more sense, arrow functions don't look so strange, promises are just friendly monads really and we all love those.
Now you've got Immutable.js [3], lodash, underscore all reasonable to understand.
React's moaning about state and pure functions makes reasonable sense.
5. Babel really isn't that hard. Just following the Meteor + React tutorial [5] got that all working without me really noticing. Then, holy moly you're all reacted up, with JSX and pure sweet smelling functions.
6. Follow some of Dan Abramov's excellent blog posts such as about getting eslint up and working in Sublime Text [4].
Yeah that's as far as I've got, but adding in Redux to this mix doesn't seem so scary, at least I understand the language now. Angular will just have to wait.
From the article -- The point is, learning modern JavaScript requires human intervention. 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.
And this is why its not the right path. Two things really strike me about 'modern' JS, one is that everyone rewrites the same dam things in a different way just to say "Yeah, I'm the person behind the <mumble, mumble> framework." which adds no value over the <grumble, grumble> framework, just that it uses some new construct of the hour.
The second is that when you're being thrown into a sea of change like that, you have to learn the fundamental language and its environment so that you can move between the frameworks and still be effective. Learning any particular system will apparently be useless.
I've had a productive enough time for the last 5 or so years not following any of the JS sphere and just sticking to jquery and the occasional other small library (dynamic color picking widgets and the like) as appropriate. It's not a sea of change unless you make it one.
That is a solid strategy, and one I endorse, but it is one that is criticized by this article and others like it which would consider you an 'old tyme' jS developer. :-(
Outstanding. Sadly, your article simply confirms for me that I want to stay in my world which starts at the application server and ends with the database.
I went from barely knowing html and CSS to slinging react/redux apps with es6, bundled with webpack, out for paying clients in less than a year.
If you just take your time, carefully go through tutorials and study a couple of open source projects you'll be fine. Especially if you already have years of development experience. You can do it!
This is perhaps why it's not a good idea to learn JavaScript. Since there's a lot of kids down there that learned how to throw something together in the course of a year.
Eh. I started out by learning Javascript and creating a basic CRUD app using the MEAN stack. Year after, I was hired as a contractor at a Fortune 500 company, and then transitioned into full-time at the same company 2 years later. Now I juggle around several different programming languages; I'm honestly glad that I started with Javascript.
A lot of the times when technology is being created in a space where existing technologies already solve the problem, and even moresoe when these frameworks are an "extension" of such platforms, the NIH syndrome comes as a cause of being unfamiliar with how the original technology solves the problem. Rather than RTFM and internalizing that way of thinking, the libraries are rebuilt. Even worse, some get adopted by new developers that don't know better as being standard.
jQuery, motherfucker, I'm looking at you. HTML5 and CSS can go further than many expect, including myself.
Great article. This quote in particular resonated for me:
"I had to let go of doing it The Right Way from the get-go, and allow myself to fumble through using suboptimal or just plain amateur setups just to get comfortable with individual tools"
Coming from languages that have good build and dependency management tools, JavaScript is a highly unproductive developer experience. Yes, you figure it all out eventually, but I shudder to think how much developer productivity is wasted today on JavaScript ecosystem complexity and constant tooling and library churn.
Hopefully 5 years from now, we'll all be looking back in disbelief at what we used to put up with to build web apps.
After burning a lot of time getting all the javascript tooling I wanted working, for the umpteenth open source front-end javascript library I wanted to publish, I threw together this:
Pretty opinionated on the tooling it uses, but good if you just want to say "Fuck it, I want to fork some boilerplate, write some code, and build/distribute it", then worry about the finer details later, and swap in specific tooling that you need later.
I also dislike forced tooling, which was the reason for writing domvm [1] which can be used as a drop-in <script> with no tooling. It's a practical mix of virtual-dom, composable components and OO (as needed).
Pardon the shameless plug, but the whole project started as an easy way for moving from jQuery spaghetti to a fast data-driven virtual-dom view layer so seems fitting to post here.
I've been long enough here on HN to remember how people used to laugh at Java in the comments, bemoaning the time it took to set everything up before you can start working with it (although it wasn't really that much trouble then, and it certainly isn't now) compared to how easy it was to start working with Javascript ("Hey, all you need is a browser and an editor"). How the tables have turned.
The main problem I've found (as an modern JS developer) is that in many situations "mainstream" (AKA C/C++) CS topics are not so relevant to JS. Javascript is Async by default, function-based instead of OO (until recently), dynamic typed and was made to mess with the DOM.
So I feel like some of the concepts taught in the most recommended books such as Clean Code are only tangentially relevant and some times just plain irrelevant. On the other hand, massive books/material written for pure JS are really low quality compared to these classics (except some blog posts, but with these it's difficult to get a round education).
So the most difficult part for me was to find out which concepts were relevant for JS in high quality books and which were not, something that is not easy when you don't know these concepts. Then learn the things not mentioned that are important for a modern JS developer such as NPM, exporting modules, minimization+gzip+tree shaking, etc.
The only reason I want to learn about modern Javascript development is to learn how I can replace it all with a small shell script. I assume it's all basically a new, more complicated incarnation of PHP that can run in that horrifying bloated ubiquitous user interface from hell that everyone is addicted to. (Get off my lawn!)
Express/Node seems to work just fine for me at this point. I settle on Vue for the frontend, and that's about it. The bundling/minifying/whateverfying flavors of the week, I've basically passed on. Always added so much more crap to a project, and in a lot of cases made everything bigger.
I'd like to take this time to show some love to ISAPI extensions and filters. Wrote some kickass stuff with that technology about 15 years ago (in Delphi of course).
I recall using some open source Delphi software that allowed auto reload of an ISAPI.DLL just by replacing the DLL in the folder. That saved an iisreset. Never got a chance to thank the technical wizard that created that.
What if you want some libraries included? specify your libs in package.json and npm install.
What if you want to publish your libs? Npm publish.
What if you want to have dependency tree bundled for browser as single script? Webpack
What if you want nice types, latest features and validation for larger projects ? Typescript loader in webpack
What if you want a nice state management library? Preact /react
There's a ton of crap and different ways of doing things but I bet fundamental things are here to remain which solve a large % of use cases.
I would say things are getting simpler in some manner. You don't really need lodash and jquery nowadays. The standard js in browsers has improved quite a bit.
You don't have to use every damn framework and compile to JS language out there ... You will do just fine with vanilla JS!
Most important parts to learn about JavaScript:
1. Scope and closures, like that your function can access variables from a parent scope, and that those variables are frozen in time.
2. Events and "async", like button.onclick = someFunction, where "someFunction" is called when a user click on the button.
If you learn just those two concepts you will know more then 95% of the JavaScript programmers out there and it will be more fun to write JavaScript! And all those frameworks are no longer needed.
I had to let go of doing it The Right Way from the get-go, and allow myself to fumble through using suboptimal or just plain amateur setups just to get comfortable with individual tools.
Javascript started as a language for small programs. While it's possible to write well-structured large programs in Javascript, the language does not compel modularity. By default, everything is global. Modules and objects have to be built out of closures. There are many ways to do this, and if you have several libraries, each probably does it differently. Hence the pain level.
and write all global variables in ALL_CAPS, or with Big First Letter if it's a constructor function / Class.
If you want global functions, give them name-spaces, like UTIL.handyFunction = function handyFunction() {}
Sometime it feels like people intentionally make their code hard to copy/reuse ... While the code might do awesome stuff, it will however not live long due to manageability problems. When the author reads his own code six moth later, he's unable to fix that bug or add that feature, because he has forgot about the hundreds of global variables, functions and couplings he had in his head when writing the program.
At some point someone will write an MS Access or File Maker Pro in JS. And finally a Visual Basic 6 client as well as an SQL database right in an single page JS app. At that point client side JS tools will stabilize. vb6.js will then last forever.
I know I'm struggling with modern JavaScript tooling.
I've been using React with JSX and maybe as little as React router too. Trying to get router added was so painful. NPM, Babel, we pack, grunt, gulp, etc and then you find you've been given instructions for something on an old react version and you need different tooling for a new one. Or the instructions give you something that's really only suitable in dev not production.
I actually gave up trying to add Flux and wrote my own implementation in vanilla JS which seems ludicrous to me.
mmm... I am surrounded by Java guys who worked with SWING (gone and forgotten) JSP and STRUTS (same story). They talk about the beauty of Java 8 and that they are waiting for Java 9.
I wish I could tell them about this article, because out there plenty of people still treat JS as a toy
> because out there plenty of people still treat JS as a toy
actually I think it is. that so much stuff comes out for it is a clear factor that we are not there yet.
I also think that we either get a good language to compile to js (scalajs, elm, clojure) or that WASM will be stable and supports the DOM, before we reach the "JS endgame" (a stable technology which will have backwards compatible stuff for at least 5 years)
As an old SA and systems programmer my exposure to 'js everywhere' (node + angular -w- nosql backend) has convinced me that it's best left to hobbyists and experimenters. The same kind of folks that liked the
gentoo linux distribution. If you can make your business run with js front to back good for you. I don't want the pain.
Javascript + the node paradigm is such a bad systems approach that I've never even bothered dealing with learning it to any extent. One look at an async waterfall and nested callbacks + libuv 'transparently' handling blocking routines was enough for me.
The big objection to Javascript is likely arising from what you've seen 10~20 years ago. The fact is, the older you are, the more likely you will reject it.
I'd say look hard at your own skepticism and actually test it out. While it doesn't make sense to write a blog using React/Redux, what one needs to get over is he fact that Javascript is no longer just "rendering documents" but the next evolution in software development as everybody moves to using a common codebase and components.
Why build complicated native applications when a thinly wrapped SPA in Electron will be indistinguishable to the customer? The only objection here is the engineer's ego and reversion to the familiar.
Enterprises will still run on Java, but minimizing code and weight the ROI on managing existing legacy technical debt for a simple CRUD desktop application vs. utilizing current Javascript technologies will be a continued pattern as Javascript wins more buy-in from the corporate executives.
This is coming from the biggest Javascript skeptic. After learning that the problems Javascript were solving were already very difficult, I feel more comfortable speaking the most active language on the web. Nay, I feel anxious that I've not fully caught up with Javascript technologies.
That isn't a fact, just a personal opinion. Disagreement with that opinion isn't a matter of ego or having an outdated view. A lot of people have looked hard at the language and actually tested it out and found many actual flaws. To rule that out you have to assume that everyone except you is just being stupid.
At best, you can do things with it, and you still have to if you want to run on browsers, so if it makes you happy you have some happy years ahead of you before it becomes irrelevant. But other than running on browsers, the main reason anyone uses it is that they are familiar with it or have sunk costs and aren't really that aware of the alternatives. Javascript has nothing that many other languages didn't have before it, except that artificially enforced monopoly on running in browsers.
I find it amusing to find so many luddites on HN. Take what you will but you are going to find to hard software engineering jobs in 10 years when everything moves to Javascript and Frontend Application development becomes the new norm. With progressive web apps, that day is closer than you think.
Opinion sure, but some are more probable than others, and valuable in predicting the future and allocating resources accordingly.
The most used language on stackoverflow is Javascript, does not tell you anything about trends?
Javascript is no longer the hack you are thinking of with ES6. ES6 is world class and I find it hard to fathom 19 year olds in SV building desktop applications using Java Swing & FX (which supposedly some old timer HN claim is happening which is a lie because it's way more time consuming, I've built with Java Swing and Electron and people commenting have no fucking clue the night and day difference) vs Node.js + Frontend framework of some sort. Walmart also adopted Node.js fairly quickly which sort of kills the argument that Java is king. In fact, less code is a trend in the enterprise with the rise of Scala and other less verbose languages that run on top of JVM.
Javascript has evolved from it's humble roots in the browser, it is now expanding and finding developer mindshare well beyond the browser (in case you didn't know about Node.js).
I find it hard to continue this discussion when it's clear you haven't spent any time recently with Javascript and instead relying on your outdated misconceptions about Javascript.
Please spend some time with the modern javascript tech stack before you offer a rebuttal so you are using the latest facts.
Wow. just wow. The notion that anyone less than pleased with the idea of Javascript everywhere is a luddite is beyond shockingly absurd.
"Javascript-everywhere"(as you appear to advocate) is, at it's core, a denial of the rest of the technological eco-system. (The web makes a lousy UI... see "the 90's")
Languages have their use-cases. Javascript is only becoming hackier and hackier as it attempts to agglomerate "classes" etc. (as a prototypical-inheritance single-threaded language that was DESIGNED to run in the browser initially)
While one can only complain of minor brain damage from learning it, and it certainly has it's front-end web uses, I find your comment utterly bizarre.
ES6 is NOT a hack. It's world class and expressive. It definitely doesn't resemble the old Javascript.
> prototypical-inheritance single-threaded language that was DESIGNED to run in the browser initially)
Yes, said by literally every evolving technology. Javascript is NOT rendering in your browser anymore. It's powering a lot of mission critical applications used by the same people who once bought into JVM and now choosing to opt for rewrite using lighter and saner stacks.
> While one can only complain of minor brain damage from learning it, and it certainly has it's front-end web uses
It's not limited to front-end but back-end. This alone brings a ton of value by removing the context switching between different languages.
Reading your comment, it's clear you haven't spent enough time with Javascript by calling it a "hack". Node.js is not a "hack" and neither is NPM. These are the new tools of the trade that's dominating all other stacks (just take a look at stackoverflow-its a measure of everyone).
I can't believe some people would be willing to push Java Swing/FX to their developers when a far more lighter and saner platform exists in the form of think HTML5 clients.
Single Page Applications are the same as desktop to 99.99% of the users out there. Your customers don't give a shit if it's written in Java Swing or Electron + SPA. What they do care is that you move as quick as their changing expectations. You can't do this with a late 90s technology built on the assumption software should mimic a heavily short sighted interpretation of the world-that you should write everything in terms of classes because the world is made out of objects and hide many parameters and layers buried under a hierarchy. To be more insulting, Java applications require a heavy JVM pre-requisite on the client side, riddled with zero day security vulnerabilities.
A closer analog to Atom is Sublime. It uses less than 50MB of RAM, and starts faster than Atom. (Myself, I've found VS Code to be a good compromise in the middle)
The logical conclusion then is to wait a year and ignore everything this article says. Saves a lot of time. :)