Modern JavaScript for Ancient Web Developers
trackchanges.postlight.com
trackchanges.postlight.com
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.
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.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?
build:
NODE_ENV=production yarn build:server
NODE_ENV=production yarn build:client
test:
NODE_ENV=test yarn test "build:dist": "NODE_ENV=production babel ./src --out-dir ./dist"Makefiles are more versatile
It's probably not something I would do on a production server, but it wouldn't hurt either.
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!
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.
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?
I held JS at arm's length for way too long, trying to use it without actually learning it. I finally grew tired of being illiterate and read "You Don't Know JavaScript" by Kyle Simpson[0] and it was eye-opening. The preface[1] really spoke to me and I suspect it will speak to many others like me. I only wish I'd read it two years ago.
0. https://github.com/getify/You-Dont-Know-JS
1. https://github.com/getify/You-Dont-Know-JS/blob/master/prefa...
I have been foolishly looking at the documentation and wiki pages.
I have also enjoyed this site:
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
OK, so everything's changing all the time, everything you Google will be out of date, but it's worth it because... why, exactly?
Node doesn't block on IO. OK, cool. But the Erlang VM doesn't block on IO, either, AND it's not single threaded, so you can actually do parallel computation if you need to.
JS has a lot of raw speed these days. OK, cool. But raw speed is generally less important than good algorithms and parallelism, and if we really need raw speed in other languages, we can generally call out to C or something.
Rust has a unique value proposition: safety and speed. Erlang/Elixir have one: supervision and easy parallelism. Ruby has one: well-worn tools for web development.
I don't understand the value proposition for Javascript on the server, other than "hey, you already know Javascript, right?", to which the answer is "LOL I thought I did but apparently everything I know is wrong all the time".
I think I'm going to sit out the Javascript frenzy until it's all very stable and Googling gets me answers that aren't So Last Week. And maybe we'll be writing Rust for browsers via WebAssembly by then, anyway.
If all you're doing is throwing HTML templates on top of CRUD results, then yeah, Node.js doesn't get you much. But there are other problem domains where you're basically forced into it. My first startup (WYSIWYG casual game creation) would've been much easier if Node had existed when I was working on it; I spent a ridiculous amount of time writing polyglot Javascript/Actionscript runtime libraries and server-side compilers that would spit back a blob of Javascript in an AJAX request.
That will mostly disappear with WebAssembly, and then we can finally start using sane languages for front-end web development.
With differences in standard libraries, environment specifics and even language features available, I think a far more accurate statement would be "you can sometimes use some code on both the server and client".
In a typical React app (+TypeScript), I have atleast 40 dependencies in package.json (frontend-only). I know exactly what each dependency is required for. And each time I have a new app, I create that package.json one line at a time - just to make sure I don't add unnecessary dependencies.
But for a JS newbie, knowing what dependency is what and why - is pretty overwhelming, tedious and uncomfortable. This is assuming they already spent time learning JS and the frameworks in the first place. Its easier to give up that important learning when you have to deliver "just a landing page in Angular" and answer to managers. After few iterations, the result is a disaster that is difficult to maintain, buggy and much more difficult to add features. Ultimately that adds to the development/maintenance cost.
I know why the JS tooling is complex, but sometimes I wish JS projects were as simple (and controlled) as creating C# windows apps using VS - where the tooling is mostly hidden
So I created my own monolithic framework (npm xlib) which is basically a collection of my commonly used modules and my own helper utils.
You can "eject" from this beginner friendly mode if you want to have more freedom.
Funny thing is that we "ejected" on our current project, but I'm contemplating moving back to CRA as it just makes developing our React app super easy and stress-free.
And useful (arguably opinionated) stuff is missing like react-hot-loader, redux-logger, sass-loader, font loaders, customized webpack and webpack-dev-server. Also it does not differentiate between smart and dumb components. For large complex SPAs, all that stuff is very useful.
I did actually open up a discussion a couple days ago asking for discussion on what kinds of "official Redux-based addons" might look like: https://github.com/reactjs/redux/issues/2295 . Possible ideas include things like a small "redux-starter" wrapper library that sets up a store with sensible defaults. Dan Abramov also tossed out a list of ideas for a hypothetical more in-depth integrated library built on top of Redux's core behavior.
React-redux, React-router, Redux-thunk are all dependencies (as opposed to dev-dependencies/build utils) that might or might not be needed.
Being probably even more experienced (or at least older in the business) developer, I don't. :-)
That's quite different from some of the dreadnaught-weight frameworks which need a huge toolchain to run Hello World. That can be worth it if you have a huge complex application which uses all of that functionality but otherwise it turns simple projects into ongoing time commitments.
IMO, the biggest problem the js world has is that the folks keep creating solutions for really _big_ problems, but no one cares about creating solutions for folks that just want to get something done quickly.
Yeah, I know what they do and what they are used for. I don't know why they are needed. Browsers could have solved this problem from the start, with proper incremental module import syntax in JS scripts.
In terms of JavaScript I still don't understand why all that "tooling" is required. Every time I try to understand how the JavaScript tools fit together I end up just finding a .js file I can stick in the top of the HTML.
The "install with npm" on a website isn't helpful at all, because I'm not doing Node, I'm just building a website and doesn't want Node.
What would help is a big poster, showing how stuff fits together. Grunt, Bower, Node, NPM, it's just a big pile of confusing.
Also, the "Basic Concepts and Overviews" section of my React/Redux links list points to a number of other articles that describe what these tools are: https://github.com/markerikson/react-redux-links/blob/master... . To pick out just one as a good reference, see "The State of the Javascript Landscape in 2016": http://www.infoq.com/articles/state-of-javascript-2016 .
NPM is a package manager for you guessed it, Node. You use it to install dependencies, whatever those might be for your situation.
I will ignore Bower.
Grunt is a task runner, say you have a task like minifying javascript files. Grunt runs this task for you. Or CSS preprocessing, any task, it'll run it. There are other things in this space too. Grunt, gulp, webpack, browserify, etc.
The pieces aren't that hard to understand, you just have to read what they do.
Sure you can stick a JS file in an HTML file and you're good, but when you start building more complex apps where you need common code in parts, specific code in others, this becomes ridiculous to do by hand, that's why we have build tools.
That, and also other things, like compiling ES7+ JavaScript code to ES5 to run in most browsers, or compiling a typed JavaScript file to non-typed (e.g. TypeScript to JavaScript). You can also compile files to .css and .html from different languages like pug and scss. There's a large amount of various transformations that can be applied to web files.
Some of the other build steps we run: checking to ensure all dependencies are installed, concatenation, minification, obfuscation, code splitting, template compilation, copying files, deleting files, resolving require/bundling whatever that is called.
Of course that setup still works, but if you want to do anything a bit more advanced, you descend into a living hell that feels as complicated an impenetrable as J2EE did. As clunky as the JCP is, in the last years it helped create a couple of sane standards from existing implementations. I just wish there was something similar in JS world.
But it would also be useful for onboarding new members.
1. Async programming. Async programming is hands down the aspect of programming that college students do the worst on. As a TA at Berkeley I can say it was one of the hardest aspects of programming for students to do well in and yet Javascript starts with an total async model.
2. No testing. Some of this has to do with Javascript starting life as web browser only. Some of this has to do with writing test code for async programming. How does one write async test code? Very, very carefully.
3. Not invented here. Javascript is not a young language. It has been around more than 10 years and yet Javascript has the same chaotic ecosystem as a first year language. That's a permanent mind set, or ecosystem.
The natural conclusion of this kind of ecosystem is to eventually suggest developers just run in kernel mode and bypass user space altogether. Asynchronous code such as database pooling is hard to get correct. This why an app server has financial value: pay for the hard stuff. And, get this, the hard stuff can be abstracted away.. Same with distributed clustering. Because these kinds of difficult async services can be black box abstracted then we have a kernel, an OS and user space. Javascript challenges that notion, and all the experience and the history of why we have kernels to begin with. Javascript is asking developers to in effect become kernel developers, without doing testing , and with in ever changing 'not invented here' chaotic code base.
Does not bode well. Has nothing to do with language though.
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.
This perfectly captures how I feel about the proliferation of JavaScript. Thanks!
The way I see it, people try to push JavaScript everywhere, no matter how the domain is ill-suited for web technologies. We have even JS frameworks for microcontrollers and embedded development, for goodness' sake! What I fear is that this steals the mindshare of younger generation, and we'll be flooded with half-assed JS non-solutions to everything, while saner approaches fall off the hype train and wither away.
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
Rediscovering the horrors of setting up a Java web app in the early 2000s, except now you configure it with json instead of xml.
01 - Node, Yarn, package.json
02 - Babel, ES6, ESLint, Flow, Jest, Husky
03 - Express, Nodemon, PM2
04 - Webpack, React, HMR
05 - Redux, Immutable, Fetch
06 - React Router, Server-Side Rendering, Helmet
07 - Socket.IO
08 - Bootstrap, JSS
09 - Travis, Coveralls, Heroku
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.
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.
* Typed callable signatures
* Function autoloading
* Generics
Sounds nice! If I understand correctly, the setup is a bit more complicated.
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.
In django i would just create a model, a form class and a template and that would handle the rendering of the form, form validation, and saving the data into a db. But with react you would have to create the components and also create a separate api that would handle the retrival and saving of data.
Are there any ancient developers out there building web apps faster with react/vuejs/angular than django/rails?
No, you aren't an a "ancient web developer", ancient web development goes way back before "CSS" even existed when "standardization" was hot topic and Opera was the best of the best. JS-fans keep trying hard to dismiss everything "we won" before in favor of their own "js-based" flavors (sass/less/react/etc) favorite motto "one languague to rule them all, one language to bring them all" (... and in the darkness bind them).
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!
I'm not ancient but I am 39 and have been doing web programming for many years, going back to the days when PHP was popular. I switch over to primarily JavaScript and Node.js around 6 years or so ago.
To all the haters, there are very practical reasons I started using Node on the backend years ago. Trying to build a collaborative real-time web application with Twisted and whatever was a huge pain. With something like Node.js its much more practical because you get async and isomorphic (same codebase on client and server).
Point being, JavaScript has been a big deal for quite a long time, and it hasn't taken _all_ older developers up until just now to catch on.
And now we are actually one or two trends removed from that initial wave of popularity. Plenty of the young guys who basically wrote the book on Node.js and created the most downloaded-ever npm modules moved on to Go or whatever years ago. And plenty of them decided to move on to Rust (or a few picked up Nim if they are smart).
https://medium.com/@tjholowaychuk/farewell-node-js-4ba9e7f3e...
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...
1. Python + functional programming in Python
Python is hardly a pure functional language, but it's lovely and simple and has all the core concepts including list comprehensions. This leads you on to...
2. Haskell
If you want to find a pure functional solution to a Python problem, first search for the Haskell one and translate it. Then read Learn You a Haskell [0] which was the funniest programming book I ever read and almost, almost taught me about monads (I had it for a second, then tried to explain it in Python and all was lost)
Now you can relax cause the hard bit is done.
3. Read Javascript the Good Parts and only pay attention to the functional programming bits. Suddenly mentions of currying aren't so scary.
4. Work your way through the funfunfunction [1] videos, especially the functional playlist [2] and for added bonus he has videos where he works through the first few chapters of Learn You a Haskell.
Then you've got map, reduce, filter all completely under control. Now immutability makes more sense, arrow functions don't look so strange, promises are just friendly monads really and we all love those.
Now you've got Immutable.js [3], lodash, underscore all reasonable to understand.
React's moaning about state and pure functions makes reasonable sense.
5. Babel really isn't that hard. Just following the Meteor + React tutorial [5] got that all working without me really noticing. Then, holy moly you're all reacted up, with JSX and pure sweet smelling functions.
6. Follow some of Dan Abramov's excellent blog posts such as about getting eslint up and working in Sublime Text [4].
Yeah that's as far as I've got, but adding in Redux to this mix doesn't seem so scary, at least I understand the language now. Angular will just have to wait.
[0]: http://learnyouahaskell.com/
[1]: https://www.youtube.com/channel/UCO1cgjhGzsSYb1rsB4bFe4Q/
[2]: https://www.youtube.com/playlist?list=PL0zVEGEvSaeEd9hlmCXrk5yUyqUag-n84
[3]: https://www.youtube.com/watch?v=I7IdS-PbEgI
[4]: https://medium.com/@dan_abramov/lint-like-it-s-2015-6987d44c5b48
[5]: https://www.meteor.com/tutorials/react/creating-an-appAnd this is why its not the right path. Two things really strike me about 'modern' JS, one is that everyone rewrites the same dam things in a different way just to say "Yeah, I'm the person behind the <mumble, mumble> framework." which adds no value over the <grumble, grumble> framework, just that it uses some new construct of the hour.
The second is that when you're being thrown into a sea of change like that, you have to learn the fundamental language and its environment so that you can move between the frameworks and still be effective. Learning any particular system will apparently be useless.
I'm kind of still waiting for someone to build, like, an Erlang (or Elixir) for the frontend. Maybe compile actual Erlang to it via emscripten.
Then code up a way to interface with the DOM, as well as model it in tests, and I could be a frontend developer again! (except for CSS... hrm)
I'd be happy to never look at JS again, frankly.
I think Elm currently comes closest to what I'm looking for
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!
https://en.wikipedia.org/wiki/Rule_of_least_power
A lot of the times when technology is being created in a space where existing technologies already solve the problem, and even moresoe when these frameworks are an "extension" of such platforms, the NIH syndrome comes as a cause of being unfamiliar with how the original technology solves the problem. Rather than RTFM and internalizing that way of thinking, the libraries are rebuilt. Even worse, some get adopted by new developers that don't know better as being standard.
jQuery, motherfucker, I'm looking at you. HTML5 and CSS can go further than many expect, including myself.
"I had to let go of doing it The Right Way from the get-go, and allow myself to fumble through using suboptimal or just plain amateur setups just to get comfortable with individual tools"
Coming from languages that have good build and dependency management tools, JavaScript is a highly unproductive developer experience. Yes, you figure it all out eventually, but I shudder to think how much developer productivity is wasted today on JavaScript ecosystem complexity and constant tooling and library churn.
Hopefully 5 years from now, we'll all be looking back in disbelief at what we used to put up with to build web apps.
We've all been saying that for 20 years when it comes to web dev :/
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.
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.
So I feel like some of the concepts taught in the most recommended books such as Clean Code are only tangentially relevant and some times just plain irrelevant. On the other hand, massive books/material written for pure JS are really low quality compared to these classics (except some blog posts, but with these it's difficult to get a round education).
So the most difficult part for me was to find out which concepts were relevant for JS in high quality books and which were not, something that is not easy when you don't know these concepts. Then learn the things not mentioned that are important for a modern JS developer such as NPM, exporting modules, minimization+gzip+tree shaking, etc.
Simple browser = script src=x Simple node = index.js
What if you want some libraries included? specify your libs in package.json and npm install.
What if you want to publish your libs? Npm publish.
What if you want to have dependency tree bundled for browser as single script? Webpack
What if you want nice types, latest features and validation for larger projects ? Typescript loader in webpack
What if you want a nice state management library? Preact /react
There's a ton of crap and different ways of doing things but I bet fundamental things are here to remain which solve a large % of use cases.
I would say things are getting simpler in some manner. You don't really need lodash and jquery nowadays. The standard js in browsers has improved quite a bit.
Most important parts to learn about JavaScript: 1. Scope and closures, like that your function can access variables from a parent scope, and that those variables are frozen in time. 2. Events and "async", like button.onclick = someFunction, where "someFunction" is called when a user click on the button. If you learn just those two concepts you will know more then 95% of the JavaScript programmers out there and it will be more fun to write JavaScript! And all those frameworks are no longer needed.
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.
(function() {"use strict";
})();
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.
actually I think it is. that so much stuff comes out for it is a clear factor that we are not there yet. I also think that we either get a good language to compile to js (scalajs, elm, clojure) or that WASM will be stable and supports the DOM, before we reach the "JS endgame" (a stable technology which will have backwards compatible stuff for at least 5 years)
FTFY: Zero Problems, Not-Tested Solutions
Javascript + the node paradigm is such a bad systems approach that I've never even bothered dealing with learning it to any extent. One look at an async waterfall and nested callbacks + libuv 'transparently' handling blocking routines was enough for me.
I'd say look hard at your own skepticism and actually test it out. While it doesn't make sense to write a blog using React/Redux, what one needs to get over is he fact that Javascript is no longer just "rendering documents" but the next evolution in software development as everybody moves to using a common codebase and components.
Why build complicated native applications when a thinly wrapped SPA in Electron will be indistinguishable to the customer? The only objection here is the engineer's ego and reversion to the familiar.
Enterprises will still run on Java, but minimizing code and weight the ROI on managing existing legacy technical debt for a simple CRUD desktop application vs. utilizing current Javascript technologies will be a continued pattern as Javascript wins more buy-in from the corporate executives.
This is coming from the biggest Javascript skeptic. After learning that the problems Javascript were solving were already very difficult, I feel more comfortable speaking the most active language on the web. Nay, I feel anxious that I've not fully caught up with Javascript technologies.
At best, you can do things with it, and you still have to if you want to run on browsers, so if it makes you happy you have some happy years ahead of you before it becomes irrelevant. But other than running on browsers, the main reason anyone uses it is that they are familiar with it or have sunk costs and aren't really that aware of the alternatives. Javascript has nothing that many other languages didn't have before it, except that artificially enforced monopoly on running in browsers.
Opinion sure, but some are more probable than others, and valuable in predicting the future and allocating resources accordingly.
The most used language on stackoverflow is Javascript, does not tell you anything about trends?
Javascript is no longer the hack you are thinking of with ES6. ES6 is world class and I find it hard to fathom 19 year olds in SV building desktop applications using Java Swing & FX (which supposedly some old timer HN claim is happening which is a lie because it's way more time consuming, I've built with Java Swing and Electron and people commenting have no fucking clue the night and day difference) vs Node.js + Frontend framework of some sort. Walmart also adopted Node.js fairly quickly which sort of kills the argument that Java is king. In fact, less code is a trend in the enterprise with the rise of Scala and other less verbose languages that run on top of JVM.
Javascript has evolved from it's humble roots in the browser, it is now expanding and finding developer mindshare well beyond the browser (in case you didn't know about Node.js).
I find it hard to continue this discussion when it's clear you haven't spent any time recently with Javascript and instead relying on your outdated misconceptions about Javascript.
Please spend some time with the modern javascript tech stack before you offer a rebuttal so you are using the latest facts.
ES6 is NOT a hack. It's world class and expressive. It definitely doesn't resemble the old Javascript.
> prototypical-inheritance single-threaded language that was DESIGNED to run in the browser initially)
Yes, said by literally every evolving technology. Javascript is NOT rendering in your browser anymore. It's powering a lot of mission critical applications used by the same people who once bought into JVM and now choosing to opt for rewrite using lighter and saner stacks.
> While one can only complain of minor brain damage from learning it, and it certainly has it's front-end web uses
It's not limited to front-end but back-end. This alone brings a ton of value by removing the context switching between different languages.
Reading your comment, it's clear you haven't spent enough time with Javascript by calling it a "hack". Node.js is not a "hack" and neither is NPM. These are the new tools of the trade that's dominating all other stacks (just take a look at stackoverflow-its a measure of everyone).
I can't believe some people would be willing to push Java Swing/FX to their developers when a far more lighter and saner platform exists in the form of think HTML5 clients.
Single Page Applications are the same as desktop to 99.99% of the users out there. Your customers don't give a shit if it's written in Java Swing or Electron + SPA. What they do care is that you move as quick as their changing expectations. You can't do this with a late 90s technology built on the assumption software should mimic a heavily short sighted interpretation of the world-that you should write everything in terms of classes because the world is made out of objects and hide many parameters and layers buried under a hierarchy. To be more insulting, Java applications require a heavy JVM pre-requisite on the client side, riddled with zero day security vulnerabilities.
I just fired up Atom and various vim versions.
Atom uses 225.8 MB of RAM without any documents open.
MacVim uses 39.8 MB without any documents open.
Console vim uses 23.3 MB.
Console neovim uses 10.0 MB.
25x memory usage differences seem pretty distinguishable to me, especially in an application used to read and write plain text.
Vim is a terminal based IDE.
The sky is blue.