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.
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.
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.
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.
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!
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.
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
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.
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.