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...
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.
> 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.
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.
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.
At one job, we used Groovy for that--we had AIX boxes, some Linux, and Windows and all our scripts ran fine everywhere albeit there were JVMs that had to exist and be on the path.
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...
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...
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.
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).
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.
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.
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.
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`.
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.
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.
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.
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 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.
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 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.
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.
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.
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.
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.
> 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")?
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.
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.
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.
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).
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)
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 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.
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!)
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.
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.
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.
> 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.
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.
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.
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.
> 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 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.
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.
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.
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 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?
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?)
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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
> 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.
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.
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.
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).
321 comments
[ 3.0 ms ] story [ 423 ms ] threadI held JS at arm's length for way too long, trying to use it without actually learning it. I finally grew tired of being illiterate and read "You Don't Know JavaScript" by Kyle Simpson[0] and it was eye-opening. The preface[1] really spoke to me and I suspect it will speak to many others like me. I only wish I'd read it two years ago.
0. https://github.com/getify/You-Dont-Know-JS
1. https://github.com/getify/You-Dont-Know-JS/blob/master/prefa...
I have been foolishly looking at the documentation and wiki pages.
I have also enjoyed this site:
http://javascriptissexy.com/
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.
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...
How do I check for undefined in ES5 compatible way?
How do I check if I need a polyfill for cookie API?
The accepted answers for both were rediculous hacks because apparently there's no good and easy way to do it
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.
[1] https://github.com/leeoniya/domvm
The logical conclusion then is to wait a year and ignore everything this article says. Saves a lot of time. :)
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.
Portability.
Every technology of the past 40 years has claimed "portability" as its mantra, and yet here we are still.
C, Java. Far more computers run C than run Javascript.
Maybe nowaday it's different thanks to Windows subsystem for Linux.
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.
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.
At one job, we used Groovy for that--we had AIX boxes, some Linux, and Windows and all our scripts ran fine everywhere albeit there were JVMs that had to exist and be on the path.
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...
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.
Oh if only this was a joke. No.. its happening.
https://www.os-js.org/
https://node-os.com/
[1] https://xkcd.com/1508/
https://www.destroyallsoftware.com/talks/the-birth-and-death...
Well it worked for Emacs didn't it?
Browsers, on the other hand, promote the exact opposite - inconsistent and weak interfaces, and no interop.
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).
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.
"To run, use 'npm run'. To develop, use 'npm run dev'. To test, use 'npm test'."
Or, open up package.json and see what scripts are there... I don't get how that's any different? Why wouldn't you have scripted all that?
Makefiles are more versatile
It's probably not something I would do on a production server, but it wouldn't hurt either.
http://pydoit.org/
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].
[1]: https://github.com/tj/mmake
[2]: https://medium.freecodecamp.com/why-i-left-gulp-and-grunt-fo...
I've had success with ninja, although the scripts are a bit long-winded.
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.
Seriously, what the hell kind of attitude is that?
For anyone interested in learning React, here's my standard advice:
You should start out by reading through the official React docs and tutorial at https://facebook.github.io/react/, and use the official Create-React-App tool ( https://github.com/facebookincubator/create-react-app ) for setting up projects. It creates a project with a solid build setup, with no configuration needed on your part.
Past that, I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics.
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.
> There's a few different thoughts 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.
> 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?
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.
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.
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.
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.
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.
You're right. I had it confused with some starter kit that included react-router and redux!
https://github.com/krakenjs/grumbler
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.
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.
It most-likely fails at that, too, when the current technologies you're using become outdated.
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.
I would only quibble about the car-crash that has been attempting to download VS 2017 from behind a corporate (bank) firewall.
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.
Looking forward to the possibility of a jit in PHP 8.Sounds nice! If I understand correctly, the setup is a bit more complicated.
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.
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")?
Javascript (and most Enterprise) developers will tell you it's the former. Nearly every other developer will tell you it's the latter.
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.
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.
For the most part, PostgreSQL will do the job.
https://mitpress.mit.edu/sicp/full-text/sicp/book/node70.htm...
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).
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)
If they do I will never sleep again as the rickety POC gets deployed in the wild
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!
you can work at a fortune 500 company and still get paid in peanuts
Rediscovering the horrors of setting up a Java web app in the early 2000s, except now you configure it with json instead of xml.
Read: all your v1 sh*t's broken.
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.
I think my reaction to modern Javascript is to just ... don't.
These days it's all about the customer/user. And that user wants functionality!
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.
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.
The churn in tooling is unavoidable even if you use slightly less fashionable frameworks.
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.
And realistically speaking, yarn is not a discernable improvement over npm.
The cultural experiment has a huge cost to programmers and it's been an utter disaster. Even PHP has leapfrogged javascript.
Yarn will save you 10x the time you spend configuring it from using it just once. But go ahead, keep using NPM, new stuff is scary.
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.
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.
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. :-)
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.
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.
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.
https://github.com/verekia/js-stack-from-scratch/blob/master...
...in order to replicate dispatchEvent and addEventListener?
Relevant: https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
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?
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.
I don't know what "work-arounds" you're talking about.
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.
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 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.
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.
A version optimized for being read out loud would make for a very satisfying guided meditation audio.
delegate.
"Nothing. It's delegates all the way down."
You are the Bruce Lee of Modern Javascript programming and I salute you.
https://vimeo.com/3191188
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.
Check out the annotated source here: http://backbonejs.org/docs/backbone.html
Which is the reason Marionette exists in the first place (well that and boilerplate code).
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.
Still thinking about moving to the fire monkey framework but no need to rush these things
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.
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.
Whoo, look at this guy with the "performance" and the hoola hoops and transistor radios.
How's my (de)motivational speaking?