gasping

Glad to hear it. I wish you all the best.

> The 4 months of “hell” were really not that bad looking back at it now. All of this taught me a great lesson in humility and resourcefulness. It also taught me to be kind and loving to your fellow man all the while making sure to “pay it forward”.

But it didn't teach them to save a year's living expenses so they'd never get into this situation again? I wonder what is protecting them from becoming homeless if they fall on hard time again -- probably nothing. With that said, this was a really engrossing read and should reinforce the idea that responsible spending is absolutely key to a comfortable life for those of us who perhaps don't appreciate our nest egg of savings quite as much as we should.

This app just facilitates short-sighted abuse of commercial infrastructure while opening clients up to a massive security vulnerability. Doesn't surprise me one bit that this comes from China. They have a culture of extreme self-interest with complete disregard of the implications against other people or even themselves long term.

While I haven't used Angular, I have watched a live demonstration of it and was not impressed. Yes it's very boilerplate heavy and reminds me of some of the clunkier Java frameworks.

I'll keep my suggestion short and simple. Look into ReactJs. If your coworkers are sharp they may be willing to look into it too. It's not just another crappy framework.

Bold, and beautiful!! Quick everyone, scrap all your existing frameworks and jump on the flavor of the week!

Seriously though, I think it's borderline negligent to contribute any kind of hype to new javascript frameworks considering they are spraying out into the ecosystem like a broken fire hydrant. New javascript frameworks should be met with extreme skepticism, if not indifference, if we want this industry to be anything more than a joke.

Irrelevant analogy. The financial cost of choosing C# over VB is zero.

So what happened with io.js in the end? I can't keep up with the self-destruction of the industry, which should I be using, io.js or node?

MongoWeakReference

Front-end development considered harmful. Every moron wants to defecate out the next best frontend framework it's a joke at this point. Front end developers have made a mockery of the industry.

I don't think you understand how badly 10gen overmarketed Mongo as something that it isn't. I personally believe the people at 10gen deserve legal repercussions (I expect we'll see this in the coming years), even incarceration for the pure lies they spouted that cost companies so much. MongoDB is a trojan horse, a trap, completely incapable of serving any real-world need. If someone thinks MongoDB is working from them, they just don't realize yet how it's subtly broken.

> …we eliminate so-called “structured programming” constructs like “for” and “if”. Only function calls, variables, and constants are allowed. The result is that we end up with something that looks a lot more like assembly code; but instead of “GOTO” statements, we use callbacks…

Oh god please no.

Building a nontrivial app in node is already a nightmare.

Lenovo going down the drain. All they had to do was continue the Thinkpad legacy left by IBM. It's honestly breathtaking how badly they've fucked up. After the touch-based function keys, ruining the trackpoint buttons and now this. It's unbelievable.

This bears no resemblance to react whatsoever. By taking out the render, getInitialState, componentWillMount and other lifecycle methods Riot.js completely misses the ideology behind react and becomes just another templating library. Waste of time, anyone reading this should stick with React.

Not to mention we've moved past code tags like "each={ item, i in items }".

Yes there is. It becomes harder to separate the wheat from the chaff.

This was really good but there were a few levels that left a bit to be desired. Some of them were basically "find a way to mash this code into these functions without exceeding the instruction cap" while others encouraged quite elegant programming. The last one of the final stage was probably the best example, I thought it was quite elegant.

> incl. an acid db.

Why would you want to use a database for this problem? The input data would take time to load into an ACID db and we're only interested in a single ternary value within that data. The output data is just a few lists of boolean values so it has no reason to be in a database either.

This is a textbook stream processing problem. Adding a database creates more complexity for literally no benefit assuming the requirements in the linked article were complete. I would be baffled to see a solution to this problem that was anything more than a stream processor, to say nothing of a database being involved.

Are you saying you're using a single MongoDB collection as a dumping ground for all your entities? I hope you're not building a real product that someone has to maintain.

What? When would it ever be OK to lose parts of an invoice. Mongo apologists baffle me sometimes. To anyone considering MongoDB, don't be fooled, you probably want to stick with an RDBMS.

MongoDB will always be a relevant example of false advertising and over-marketing (to the point of 10gen probably opening themselves to litigation) and how we all need to stop drinking the kool-aid.

There is LITERALLY no reason to use MongoDB today. If you're thinking of using MongoDB, for the love of god just try PostgreSQL.

They'll probably spend it on marketing MongoDB as a replacement to relational databases. Brainwashing isn't cheap.

PostgreSQL wants to be web scale but it will never touch MongoDB scale. MongoDB is true web scale with full cloud compatibility and horizontal scaling like how clouds spread out in the real world. MongoDB mimics physics because physics is green technology. MongoDB is truly efficient with zero carbon footprint unlike PostgreSQL which is like diesel exhaust clogging up your network pipes when you try to shard upwards and outwards into the virtual scalable cloud atmosphere. PostgreSQL chokes your environment and doesn't support 10gen's new invention the MAPREDUCE which is the successor to outdated SQL. If you use PostgresSQL with auto-scale your will never support big data but MongoDB can scale up to even 100GB of big rich object data without relations so the data truly represents your client's needs.

> Yet almost everything is built with a tool that's merely good enough for the task. Which usually makes it one of the right tools.

I agree with you there so long as you understand which tools are good for which tasks.

> we're talking about handling some http requests and someone's weekend project that managed to register a domain name.

Node.js and cgi-node are not marketed as being strictly for weekend or toy projects. In fact, cgi-node is marketed as a tool that can do everything except cook your breakfast (see the last sentence of the cgi-node homepage). This just shows how badly over-marketed these products are.

> What is the right tool anyways

It's going to depend on the problem. Node.js's major failings are in the (arguably) poorly designed programming language and the continuous passing of callbacks. If your product can work within those constraints then Node.js might be the right choice. For most people Node.js will not be the right choice.

> Bottom line is that you're getting wound up by a project that has 9 commits

I don't care about how big or small the codebase is. I just care about it being marketed as a valid solution to most problems when it's really just a trap in most cases.

> I think your PHP job security is safe for now, my friend.

Pointless personal jab based on an incorrect assumption. I do not work in PHP and I don't see Node.js as a threat to the job security of any competent developer.

They aren't use cases. They are company names. Which parts of their product runs on Node.js? And have you spoken to their developers about their projects? Just because a big company deployed something doesn't make it viable.

Yes, usually by their manager. Things like Node.js get over-marketed to the public, managers are fooled into thinking it's a valid solution to their problem, then they force developers to use it against their will. node-cgi increases the number of scenarios where Node.js can be inappropriately forced down the throats of otherwise competent developers.

And there's also the long tail of inexperienced developers who made their own decision to use it and left a broken application that an experienced developer is called in to fix.

I also prefixed my statement with "akin to", which is to say it's not literally being shoved down the throats of developers but the effect is similar.

I agree that Node.js is pretty good for thin REST APIs, it's one of the few scenarios that Node.js actually works quite well. It's the other 99% of use cases that I take issue with.

You're quite right. Node.js is more like a trap for inexperienced developers who probably won't even understand why Node.js is an awful tool when used to solve the wrong problem because they have no real experience (I believe Node.js is the wrong answer to the wrong problem in all but a very few exceptional circumstances).

I don't think so. I'm all for lowering barriers to entry but there is a point where it becomes harmful to the ecosystem and to the developers themselves. Software development is, in my opinion, an engineering discipline, and so it's hugely important to use the right equipment for a specific task. If somebody truly can't learn how to do server-side development properly then they need to pass the job onto someone who can. Software development is hard. Not everyone can do it. This isn't a bad thing. Understanding that software development is hard allows us to move forward and gain a more broad knowledge of our field. Ignore that, and we end up repeating history. See: the templating syntax in node-cgi. There is no reason for that to exist in 2015. This is not how we advance a STEM field.

This is why Node.js is receiving an enormous backlash from the programming community. People keep peddling it as a solution to all problems when in reality it has very limited utility in all but a few use cases. Pushing this thing over old CGI technology and adding a hideous spaghetti-code HTML interleaving syntax is akin to shoving it further down the throats of the masses who don't want or need Node.js. The best thing to do is leave Node.js in its corner of the ecosystem and let people find it if they need it. Why are we even talking about CGI? It's 2015. This does nothing good for the developer ecosystem.

I've got a running theory for the next 10 or so years of development. Node.js's sole purpose was to lower the barrier to entry of server-side development. With the barrier to entry lowered, inexperienced developers with no knowledge of proper tooling are beginning to reinvent the wheel and make the same mistakes we did 10 or fifteen years ago. We're going to see a tragic repeat of the worst decisions made over the past few decades only this time they'll be running on what is arguably one of the most poorly designed programming languages, Javascript. Those who are too inexperienced to understand history are doomed to repeat it.

I've seen that video and cried bitter tears. I just don't know who's at the wheel web development right now. With all the garbage being pedaled out over the past few years, especially Javascript stuff and reinvention-of-the-wheel technologies like MongoDB, I'm seriously thinking of leaving the industry. It's a tough choice because I've got a pretty decent mortage to pay off but I just feel like the industry is being taken over by teenagers with no real world experience or street knowledge.

Unfortunately reality just doesn't work that way. Projects are completed. Developers move on. New developers eventually are employed to make upgrades only to find the entire toolchain was built by some guy in a coffee shop 15 years ago and no longer works.