> Node allows you to run isomorphic JavaScript that runs on both your server side and client side

But then you're writing JavaScript on the server side, and I think I'd rather shove live weasels down my trousers than write one line more of JavaScript than I absolutely must.

JavaScript is a fantastic language. I don't get this animosity towards it. A decade ago it was made fun of by people who "use real programming languages" but JavaScript has grown up. It's actually very good and very fast. ES6 brought improvements but honestly ES5 is still a great language.

JavaScript is not a fantastic language. It does a lot of things that make no sense. It converts between types in nonsensical ways. Eg in Ruby, you can't accidentally do `5 + "hi"` and get "5hi". If you really want to treat the number as a string, you can do `5.to_s + "hi"` and it works, but you don't do such crap accidentally.

In JavaScript, `4 / "cake"` returns `NaN`, which is sensible, but if I wanted to check whether I just accidentally did a bad division, `(4 / "cake") === NaN` will lie to me.

There are LOTS of quirks like this. JS is like a floor with boards missing all over the place. Yes, if you've walked on it every day for years, you've already stepped in every hole and know where they are. But that doesn't make it a good floor.

A good language is consistent. JS is not.

The fact that it now has fast implementations has nothing to do with it. This car goes 300mph, but don't use the left turn signal on Tuesdays because that sucker will blow you up.

> It does a lot of things that make no sense. It converts between types in nonsensical ways. Eg in Ruby, you can't accidentally do `5 + "hi"` and get "5hi". If you really want to treat the number as a string, you can do `5.to_s + "hi"` and it works, but you don't do such crap accidentally.

Uh, so two things here. First, even though it's a dynamic language you should know what your code is doing. Your code should never be be "accidentally" doing this. That would be very poor design outside of an accidental bug.

Second, some other dynamic languages do this or other weird type coercion (I mean type coercion exists for a reason; sounds like you're against it in general which is separate from JavaScript). PHP simply extracts numbers from strings and uses them in this case. Many languages use + as a concatenation operator JavaScript just doesn't have a good way to override it so it could work properly in all cases.

> In JavaScript, `4 / "cake"` returns `NaN`, which is sensible, but if I wanted to check whether I just accidentally did a bad division, `(4 / "cake") === NaN` will lie to me.

It's not lying to you; you're using a feature of the language wrong. That's like calling the wrong validation function and getting upset because it's not working like you wanted it to (because there is a validation function for NaN). At the same time a good design won't run into this issue anyway. Now I'll admit NaN is a bit of an oddball so yes it's not the most intuitive but at the same time don't say the language is lying to you.

> There are LOTS of quirks like this. JS is like a floor with boards missing all over the place. Yes, if you've walked on it every day for years, you've already stepped in every hole and know where they are. But that doesn't make it a good floor.

> A good language is consistent. JS is not.

Not really. This is the common statement repeated by those who don't use JavaScript and consider it an awful language. If you're following best practices I'd love to know where all these language quirks or inconsistencies are because I'm for sure not running into them.

NaN is not equal to NaN by the IEEE 754 standard. JavaScript, and many other modern languages, implement floating point numbers by this standard. E.g. in C#:

> 0.0/0.0 == Double.NaN

false

Totally agree. The lack of understanding of JavaScript's paradigm from some people make them blind about the language power, it has the enough amount of every needed paradigm there, including OOP, functional and evented. I see in the comments here people complaining about things like dynamic `this` when they just don't understand it's one of the biggest powers of JS.

JS is not object oriented. A prototype is not the same thing as an object. There are no classes in JS.

What you mean to say: JavaScript is not class-oriented.

Sure, there are features that JavaScript lacks compared to other object-oriented languages, but saying that it's not object-oriented is like saying that it's statically typed. It's just wrong, the language is full of objects.

Ok, tell me where on "object-oriented programming" is the word "class". Objects are not necessarily related to classes. And yes, a prorotype is a object that you can extend from, as well as from any other object, like prototype-based OOP works.

JavaScript sucked indeed. ES6 though, has brought many improvements, and the language now is quite decent. With the advent of async/await in ES7 (which is available now if you transpile with Babel), the callback hell is completely gone, and the language is actually beautiful, powerful, and concise.

I think we are exaggerating here. Javascript was terrible but with es6 it's just getting better, I know various languages and only Javascript manages to make me scream with its quirks, the others at most I feel disappointed. So "good" is an exaggeration, reasonable seems fine, but currently is either an OOP language where 'this' changes every time, or a functional language without native support for immutability, curried functions by default and a whole bunch of utilities that you expect from a language claiming to be functional. If it's a language with both mixed, must be compared to ruby which has consistent oop and functional programming with support for laziness and a super powerful ability to create dsl.

And in Javascript, it's still a nightmare importing a file. You either have a or you are on nodejs.

Damn, I see so much frustration from you for not being able to understand JavaScript here... once you understand it's a different language instead of trying to write your favorite language with JavaScript syntax it'll get better, buddy, relax :)

You could of course write something that compiles to JavaScript. There's a ton of options, some are even pretty nice (I like ClojureScript; want to try out Elm).

Elm is client side only.

Elm can be installed run from the command line.

Do you mean there's a way to run non-html-anchored Elm? Links would be wonderful!

Then use PureScript.

This is where Typescript comes in. It's beautiful.

> You can pick a nice ORM (like sequelize)

I'm gonna stop you right there. Node is a helpful tool and I enjoy using it, but Sequelize was nothing but pure pain when I used it. You're much better off running raw SQL, or using a query builder like KnexJS.

I would never use Sequelize for more than a 1-table read or update.

honestly, in JS/Node, I find it easiest to use a SQL adapter that can handle template strings as parameterized queries...

    const results = await sql.query`
      SELECT ...
      WHERE foo = ${bar}
    `;

    if (!results && results.length) return;
    await myQueue.add(results);

Which works unbelievably well... There's not nearly as much need for boilerplate/translation layers in what is already a dynamic environment. I wrote a wrapper for ms-sql when migrating data, it took 2-3 days to get it done, but writing queries as above was so easy to work with it was incredibly nice. I'd rather work with a db that has a friendlier API to work with or abstract around... but writing a little template driven sql is often better than layers of boilerplate like an ORM.. and I still don't really get mongoose.

Maybe I'm missing something, but that looks like SQL Injection ready to happen.

sql.query is a function that will receive two arrays, one is the strings part, the other is the injected values... the template processor takes those arrays and turns it into a parameterized query to the database.

Very cool! In that example though... where's the array? And don't backticks do string interpolation?

Backticks by themselves will do string interpolation. But backticks with a function name in front will do something a bit different. In this case 'sql.query' is a function and the JS will pass it an array which represents the contents of the backtick string. There the function can do what it likes and return a result. 'sql.query' builds a proper (and safe!) SQL query and executes it.

The backtick feature in ES2015 is really cool and allows for some great DSL type features.

This feature is apparently called "tagged template strings"; more on MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Neat! Thanks for the awesome explanation!

That looks fantastic, I'll take that any day over an ORM in JS.

Here's the one I wrote for mssql[1], though it should really be updated, and probably use tedious directly, instead of mssql.

[1] https://www.npmjs.com/package/mssql-ng

I still count three frameworks :)

(React, Node, sequelize, I'm not counting webpack but I probably would if it's anything like as much of a pain as Grunt or Gulp or... And as you say, this is the lightweight version.)

And how many frameworks can you count in a win forms or wpf application?

If we're going to count frameworks, there'd be no end it. As I once said, programming is abstraction upon abstraction.

Like an onion, a Russia doll or better still, inception.

Frameworks abound everywhere, at every layer. You just need to adjust your scope as you see fit, to find them.

Honestly from the programmer's perspective, it's really just one framework: .NET. I know that .NET abstracts away other frameworks such as the Win32 API, but generally you don't need to know any Win32 API etc. to make a Winforms / WPF / etc. application. With modern "web application" style development, it seems these days you need to know multiple frameworks by default, for better or for worse.

More to the point, .NET was designed from the get go as an enterprise programming language. The web was not designed from the beginning to be a universal application platform, it was designed to display formatted hyperlinked text. Much of the hack-y feel of today's web development -- as well as other aspects such as the rather poor security -- springs from this. If the web were designed from the get-go to be a universal sandboxed application platform, I feel that many things (ranging from the scripting language choice to the DOM model) would have looked a lot different today. Standard, non interactive HTML + CSS (what the web was designed for) certainly doesn't feel too hacky after all.

I'm not sure what sre you talking about, if you program with c# and wpf, you need to know xaml and their weird syntax, you need to know prism which is a framework to properly organize your UI, you need to know a server language like asp. Net if you want to deal with backend code.

Prefer winform? That's much like react without using jsx, and if yoy want fancy graphics is much more complicated than html. Now sure you can stick to system style, but you can also buy css themes, use bootstrap, material ui frameworks to have your already prepared ui in html too.

Same issues with qt libraries... The thing is simple: inevitably you need more layer of complexity if you need to be able to maintain the code while being open to changes.

For simple apps, sure winform is faster, for complex apps, no way, it's the same.

And you can't really say that.net is a single framework when it includes so much stuff that is bigger than react, node, webpack, css and html put together

I would have to disagree on the last sentence -- there is nothing in any definition of a software framework I know about that suggests that a software framework cannot encompass more than one function. .NET indeed does have a much larger solution stack then most web frameworks, for better or worse (there are advantages and disadvantages to this approach). But that does not disqualify it from being a framework in my opinion.

Web programming is more fragmented in nature, for better or worse. I think that was more my point with the first paragraph (and also a response that most .NET programmers don't need to care too much about any backbone frameworks .NET was built on). .NET provides you with a full front-to-back ecosystem. With web applications, you usually chose, at minimum, some form of Javascript framework, some back end framework, and some form of style framework. (Full stack frameworks for some reason have not taken off in the web ecosystem.) Even that description simplifies some of the fragmentation, due to the bewildering amount of choice. If you want to implement a Flux pattern in React for instance, there are over a dozen versions out there to chose from.

I don't think this necessarily says anything about app complexity or speed of development at all, agreed. Complex apps are going to be the same. I do think that the current fragmented, churn-y nature of the Javascript ecosystem can be a barrier to entry for simple apps at the moment; for that reason, I'll welcome the day when the Javascript ecosystem reaches peak "Javascript fatigue", becomes a bit more stabilized.

True it's a single framework, my point was only the size... I mean, the amount of knowledge you need is probably the same you need to work with web stack.

Also, if you need a backend even if it's written in same language, is still a different thing, much like node and web javascript. Choosing a different backend languages usually is made because of the advantages it brings (Rails for prototyping, Erlang or Elixir for stability, Java for performance and so on)

You are confusing .Net, C# and WP* frameworks. .Net is closer to the JVM, C# is the language and WP* are libraries that interact with w32 apis

Not trying to be pedantic, just posting to set the record straight:

- WPF, WinForms, ASP.NET, ADO.NET etc. etc. are all officially part of the .NET Framework.

- WPF doesn't do much (or any) direct interaction with Win32. It uses Direct#D for rendering.

- The CLR is the .NET equivalent of the JVM.

It's useful to look at the .NET Framework the same way as the standard library that ships with the JVM. They're both large standard libraries that include GUI Library (AWT, Swing, JavaFX, Winforms, WPF), database access (JDBC, ADO.NET).

In both cases, the extensive standard library can easily be used by multiple languages (i.e. VB, C#, F# in .NET, Java, Scala, Clojure and many others on the JVM).

As rpeden pointed out, it's you that are confusing the things. CLR is what JVM is for C#, while all the stuff I mentioned are inside the .net framework

Ah I wouldn't count Node as a framework as I'd equate it to the JVM in Java world. But you are right, I'd probably lump webpack in there as it does have a fair bit of depth to it if you want to get the most out of it.

You still need to use Express or something similar on the server side for Javascript, I mean, if we are talking about standard procedures here. Plus with React, you are still doing that Javascript/CSS thingy and HTML of course at some point, so there is no avoiding that, and clearfixes, polyfills, etc, etc.

But all of these things you're bitching about combined are far smaller than even ASP.Net without including anything client-side.

Node is a runtime, not a framework/language, and if you use a JS friendly DB (there are many with transparent APIs available (rethinkdb, mongo, etc) then it's all just JS.

I would argue that React is different enough so as to almost be called its own language. After all, it does use "JSX", whatever the hell that means ;-)

> ... to abstract away SQL

SQL already is an abstraction, why would I want to abstract it away? Why not abstract JS away instead?

Well, everything is an abstraction, down to zeroes and ones.

Oh, it goes so much further down than that.

It's all just fluctuating fields in the vacuum?

Turtles all the way down.

Until you're working on a project where the turtles eat the errors...

Funny story, that's how I've been describing the issue with how errors have been handled on the project I'm working on, where there are SO many areas where errors are just ignored... so they don't propagate up the chain/stack... doubly annoying in a node environment where it's all supposed to be error first (as in the first thing you think about and check for).

I was describing the problem as "turtles all the way down, except the turtles are eating all the errors, and the rabbits can't find them"

> Why not abstract JS away instead?

Lots of projects are already doing this: Elm, ClojureScript, PureScript, etc.

"thats it"

250mb worth of dependecies later...