Awesome article on the state of web development and how it’s going down the proverbial toilet, in part thanks to NPM.
https://medium.com/@wob/the-sad-state-of-web-development-1603a861d29f#.g4cbwvkkl
It’s nice to see that I’m not alone. I used to think that it was just because I’m relatively new to NPM in general.
At least Meteor is taking gigantic steps in improving this freakshow. 
What do you guys think? Do you agree with the article or is the author (and myself) just too new to NPM?
Maybe 1 or 2 pages on your app will have really complex UI, but the other 95% of the app does not. So you pay a huge penalty doing a SPA. You’re typically writing all the basic CRUD stuff in a SPA from scratch. The backend framework you’re using can’t help you in any way.
The author hasn’t tried Meteor … 
Coming from .net the wild-wild-west of the JavaScript ecosystem is just mind-boggling, I have little to no idea how anybody actually manages to make a decision on anything, let alone actually maintain a system over say five years.
I cannot tell you how much I would give to just be able to use c# and the .net framework in the browser. One well documented, well thought out, consistent, backwards compatible, structured framework that I could use on both client and server would be so much more productive for me.
The attraction of Meteor is that if I can’t have that, then at least Meteor gives us most of that, albeit at the cost of having to give up using a strongly typed language.
I’ve said it before, but Microsoft has totally dropped the ball on the rise of the SPA; ASP.NET is still focussed on statically rendered pages with a sprinkling of AJAX, leaving long time .netters like us looking for a holistic solution outside of the Microsoft landscape. .Net people aren’t used to thinking about what linting package to use, we just start coding. ASP.NET is clinging on as a REST endpoint provider via Web API, but once GraphQL takes hold it’s going to be harder and harder to find a reason to keep using ASP.NET at all, at which point you can imagine there will be an exodus.
There’s a massive opportunity for whoever can provide a one-stop solution to building SPAs to those in the .net world looking around for a solution for writing SPAs, you have to give MDG props for seeing that one coming.
I also miss C#, especially Linq. You had confidence in your tools and in your code. With NPM and Javascript, eh… not so much. Hopefully 1.3 and the Meteor guide touches hard on testing and brings developers some good night sleep knowing tests are there to catch them.
One year ago, Meteor was just that. I was super productive on everything, one new feature everyday.
Then came React, and they began to talk (or not talk) about deprecating things, and everything became muddy.
I have been stuck in analysis paralysis for the last 8 months, my projects barely moving as i was trying new things.
For the last three weeks i have been refactoring my main app to ES6 modules, the end result is (will be) great, but my projects are not moving, and my users don’t care that my code as been refactored.
Yeah we’re trying to get as close as we can. Unfortunately there’s a big element of also being up to date with some of the newest stuff. But ideally at some point the churn in the general JS ecosystem will slow down a bit and then we’ll be there with all the parts nicely packaged together.
It’s interesting - for me coming from both background in asp.net C# and ruby/rails – react/meteor/webpack./redux feels much nicer, more exciting, fun and creative.
• one language
• UI complexity handled beautifully by react/component architecture
• hot reload
• realtime updating
For making dynamic apps, and interesting UIs that reach across platform and the wider web – I am thoroughly more excited to be working in this stack than where I was before.
I think this is why the guide is so important, as soon as the 1.3 version is out I plan to just double-down on whatever the guide says for, say, six months and just not think about alternatives, just push code out the door and learn my meteor craft. Then I’ll look up, see what’s happening and think about Mantra or other frameworks if needed.
I do agree with that, and I’m loving that React feels like it may be a better paradigm than traditional MVC (be that server or client side). I’m probably just suffering from trying to learn JavaScript, ES6, SimpleSchema, Meteor, React, Flux, Redux, GraphQL, etc. simultaneously!
Yea for sure agree. It’s pretty much a time where we as developers have to embrace the fact that working and learning are gonna have to be happening simultaneously. But I think we’re all in the same boat!
you should use TypeScript
This. QFT.
I can’t understand that people actually think the React/ES2015 syntax is a substantial improvement in terms of clarity, readability, maintainability, etc.
I wish I had this article and photo when I made the ‘gutter slang’ comment in the How To Improve React thread. This article expresses exactly what I was offhandedly alluding to; and much more coherently.
It boggles my mind. And yes, former .Net programmer. There are obvious differences in what we expect from a technology stack from what everybody else expects.
Honestly I would look at it like this… JavaScript is finally getting features that most all languages have. We’re migrating the old ‘hacks’ (eg… require, module.export) to the language standard. I think the article was half satire as well.
Also another point… you don’t have to migrate to the newer syntax either. require still works. You can still use script tags and Ecmascript 1.3 if you’d like. They’ve gone to long lengths to make sure it still works today. I’ve just migrated bits and pieces as I open and edit a file… otherwise it gets left alone.
I think the real issue is people feeling guilty for not having the latest thing in their codebase. If it works… leave it 
If one doesn’t want innovation churn… choose a different server language and stick to serverside rendering as much as possible (or an older framework like Ember)… React is not the choice for a slow changing UI layer 
I’m on your page here. I don’t really get these “javascript/node” is so bad posts. Here’s my answer to it. I hope it’s not offending to anyone.
Everything in your article painting Node as nice and easy, is directly a result of Meteor’s world-class developer UX. Praise MDG, not Node.
Just read this and have to agree. After being in php/composer land for a few years, js/npm is a happier place for me…
You do.
Ruby still supports the old hash syntax, but try pushing that syntax on production systems these days and code review will make you change it.
# Nobody does this anymore.
{ :example => 'hash' }
# Ecosystem moved on to this.
{ example: 'hash' }
You go where the herd goes.
But why should MDG pick “the worst fucking language” for doing there awesome stuff… I have to say i felt kind of offended due to the high frequency of “fuck/fucking” in his text. package.json and npm install has sth. to do with node - not with meteor. That meteor as a framwork makes stuff easier is just normal. Noone would code sth. complex in php without a framework, too.
Been doing years of full-stack Javascript development and I like it a lot more then PHP or Java. I love how NPM works and I’m thrilled that it is the standard for front-end code as well now. The long awaited Javascript language improvements are finally dripping in and things will get better and easier once everything is settled a bit. Only thing I miss is strong typing, but we can fix that with TypeScript of Flow.
After doing the MEAN stack (well, something similar) for a while, Meteor has been a breath of fresh air. Bringing all the pieces together. Can’t wait for Meteor 1.3 in all it’s glory…
2015 has been an awesome year. Let’s celebrate and build stuff!
Right, I agree conforming to one style is a win but my point is that you can leave it (mostly) as is and it won’t break. Later you can updated when re-factoring. Customers don’t care about taking 2 weeks to migrate to arrow functions, classes, or import statements… these things can be slowly migrated as you have time.
I doubt Basecamp blocked off weeks to convert hash rockets to the 2.0 symbol hashes. As far as I know using hash-rockets today won’t break your app.