Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of Meteor Part 1: What Went Wrong

discovermeteor.com

Post reply on HN
Print view View original

151–160 of 189 posts

Re: The State of Meteor Part 1: What Went Wrong

#151

Post by terda12 »

warcode wrote: post #25

Meteor has been perfect for the single page web apps I've been making as side projects. I don't know any other frameworks where I could have completed an encrypted chat application as fast and painless as I did with meteor. All the things mentioned as "going beyond basics" seem like things that meteor was never designed for and that we have other tools to handle. I really feel like the problem is with the people behi…

I resonate with your comment the most.

I feel like Meteor fulfills two niches in the Node world

* Experimental Javascript full stack framework

* Providing a foundation for full stack apps instead of having the developer do it.

Re: The State of Meteor Part 1: What Went Wrong

#152

Post by [deleted] »

wsvincent wrote: post #75

I'm currently using Meteor to teach a college-level course on Web Development for beginners. https://csci16.hellometeor.com/ It's incredible how accessible Meteor is for this purpose: * One line complete local setup * One line deployment (to Meteor servers, but still) * Javascript only (no need to learn Python, Ruby, etc in addition) * Out of the box User Accounts * Simple templating engine with Blaze I can think of…

[deleted]

Re: The State of Meteor Part 1: What Went Wrong

#153

Post by JonnieCache »

ianamartin wrote: post #84
minimaxir wrote: post #71

Earlier quoted context omitted.

> I completely fail to understand why some developers seem to be allergic to learning about data structures and the means of query-ing them I'm not a fan of Meteor's dependency of Mongo either, but proper database architecture for a rDBMS is not an obvious skill. Even with an ORM (Rails/Django), it still takes care to set up PK/FK relationships and that's not necessarily taught in a CS curriculum. Mongo would be suff…

I might be speaking to a sparse audience here, but I don't come from a CS curriculum. I'm a violinist and a music theorist who happens to have learned enough to make a better living by writing code. I don't know what gets taught in CS degree plans. But I will say that if I can learn how to model, query, and display data, then pretty much anyone can. Especially those with the benefit of a CS degree. I don't use an ORM…

>But I will say that if I can learn how to model, query, and display data, then pretty much anyone can.

This isn't really true.

>This could be a case where I just don't know enough.

It sounds like you've picked up some very important things pretty well tbh. Better than a lot of people in the industry.

I mean, your code could be a complete mess for all I know. But what you're describing is a potentially very powerful and robust design. You're likely not giving yourself enough credit.

Hey, if you can navigate the tangled nightmare of conflicting redundancy that is music theory, modelling business objects and doing CRUD on them is surely a piece of cake ;)

Re: The State of Meteor Part 1: What Went Wrong

#155

Post by ChristianBundy »

elbigbad wrote: post #37
mariusmg wrote: post #26

Earlier quoted context omitted.

"likewise with frontend JS frameworks" And jQuery. Probabil still the most used JS library.

I believe this is correct to the point where jQuery is synonymous with javascript and thus doesn't need to be even mentioned. Plus jQuery isn't really a framework.

I strongly disagree, there are many people (myself included) who strongly discourage the use of jQuery. There are much better solutions out there that follow the "do one thing well" philosophy.

Re: The State of Meteor Part 1: What Went Wrong

#156

Post by aioprisan »

muloka wrote: post #130
fefifofu wrote: post #128

This article does a disservice to Meteor. The article feels drama filled and says many things are broken when they are not. "Blaze is threatened by React". You can use React or you can use Blaze. If React becomes so popular that Blaze is not longer used, that's OK... nothing to be threatened about. It's nice that Meteor can move with a trend. "Tracker and Minimongo might eventually disappear as well". Tracker and Min…

RethinkDB is still a strong possibility as an alternative, it's similar enough to MongoDb. While there is no official core SQL support yet there are 3rd party add ons for PostgreSQL and MySQL available.

Today, there are 0 add-ons that support MySQL, that are actively maintained or worked on, that you can download through atmosphere, the package manager.

Re: The State of Meteor Part 1: What Went Wrong

#157

Post by edwinnathaniel »

terda12 wrote: post #144
edwinnathaniel wrote: post #126

There does not seem a day to go by without a NodeJS-based framework/library get the heat from the community ever since December 2015. It appears that 2016 is the year when the hype from NodeJS died down and vendors/OSS-community must now deal with the hard, un-glamorous, work to clean up, maintain, prepare roadmap, and so on. Which is good! Or it could also be the year where people realized that the use-case for Node…

> Or it could also be the year where people realized that the use-case for NodeJS is fairly very very specific/niche (unless if they love JS so much that they're willing to absorb the pain using NodeJS + its ecosystem). I disagree with this point... I think Node is very versatile and solid. I dont see anything niche about it. It does very few basic jobs well, 1) providing a good package system (NPM) and 2) giving us…

I see BigCo who uses NodeJS only use it for their front-end appserver that farms the actual work to microservices _that are not written in NodeJS_ behind the scene.

I've had a conversation with someone where I asked "how do you deal with Money in NodeJS" where the response was to farm it out to a services written in either C# or Java. No Money processing is done in JS (maybe because JS lack BigDecimal? or no standard Money library that deals with ISO-level currency?).

LinkedIN used NodeJS for their mobile app back-end if I recalled. I would assume that NodeJS is just a front-end appserver talking to myriad back-end microservices written in other languages.

So this is where I stand given the lack of good stable solid libraries provided by NodeJS: its place is just sitting as a gateway front-end appserver that pass processed request to a bunch of services in the back-end and get response back from those services, do minimum massaging, and spits JSON back to the front-end. This is why I kind of labelled NodeJS as a niche. Sure, Trello uses NodeJS all the way left and right but I suppose you can write web-app back-end using Go or C++ too. Painful but works.

My faith in JS for back-end is definitely pretty low given that working with either callback or promise isn't fun but that's personal preference more than anything else.

Anyhow... I'd love to see real production level NodeJS code that deals with complex business logic (as opposed to super-high-level presentations without insight to the actual code) before I feel comfortable choosing NodeJS in general.

Re: The State of Meteor Part 1: What Went Wrong

#158

Post by Pent »

tbrock wrote: post #72

> Once a new Meteor user starts to go beyond the basics and look into things like routing, pagination, subscription caching & management, server-side rendering, or database joins, they realize that the difficulty curve quickly ramps up. Routing? Really? I am not an expert but I think if routing, of all things, is hard in to do in your web framework, you most likely have a problem. That's requirement zero!

Routing in Meteor is non-trivial if you want it to behave how a single-page app should behave. The defaults provide the bare minimum of usability and arguably worse than what we had with server-side rendering. It's exasperated by the fact that the routing libraries are not part of the core framework.

Re: The State of Meteor Part 1: What Went Wrong

#159

Post by pm24601 »

dack wrote: post #145
pm24601 wrote: post #103

We used meteor at my last company. By far and away the biggest issue was being stuck with Mongo. NoSQL databases have their place. But they are not a universal solution to everything (or even most things). Relational DBs exist for a reason. Being stuck with Mongo is the major reason why I wouldn't use meteor again. The other stuff was minor and had solutions. We also built an open source library that wrapped up colle…

Yeah this might be one of the biggest complaints about Meteor, and is definitely valid. It's being worked on actively!

Good to hear. Most data resides in RDBs. If Meteor can't access that data.... Meteor limits itself.

Re: The State of Meteor Part 1: What Went Wrong

#160

Post by pm24601 »

cmdkeen wrote: post #14
s_kilk wrote: post #10

Earlier quoted context omitted.

Same. Welding the frontend to the backend is a definite no-go for me, regardless of the supposed benefits of this isomorphism.

I think the big problem with isomorphism is that there's a fundamental disconnect between the lifetimes of front and back end systems. Well written back end code (hell, badly written back end code) could be left running for decades with better front ends bolted on. A front end system written even a couple of years ago starts to be less maintainable as developer skill sets move on, best practice evolves etc.

I used meteor for 2 years professionally.

The issue that you raise is less important with meteor because updating the server code updates the client code.

Post reply on HN