What's the best framework for a personal/learning project? My only recent .js experience has been with d3.js.
Go React. Great community. Learn ReactJS and now you can use the knowledge to build native apps with React native.
Ask HN: Is Meteor.js still a thing?
81–90 of 107 posts
Re: Ask HN: Is Meteor.js still a thing?
#82I speak from personal experience when I say companies are migrating away from Meteor. For me personally it's to a React/RxJS front-end stack in combination with a traditional Ruby/PostgreSQL/REST api back-end. This had the disadvantage of losing the back-end reactivity Meteor is known for, but at the same time it's a much more stable, decoupled and scalable stack. Meteor simply felt too much like a black box that cau…
Any thoughts on RxDB? https://github.com/pubkey/rxdb
I'm a fan of RxDB. It makes a lot of sense to combine something like PouchDB with RxJS to create a reactive datastore. The only thing that bothers me a bit about it is the dependency on CouchDB (at least in case you want to have online sync). Not that I have anything against CouchDB (it's a great piece of technology IMO), but it's definitely not suited for all use cases and is in general a lot more restrictive/less powerful than a more general-purpose database like PostgreSQL.
Re: Ask HN: Is Meteor.js still a thing?
#83Earlier quoted context omitted.
Thumbs up for Rocket.Chat, love it!
How does Rocket compare with Mattermost these days?
I didn't use Mattermost, but probably the biggest advantage of Rocket.Chat is that it is totally free to use. On the other hand the UI is sometimes not as polished as other commercial solutions.
Re: Ask HN: Is Meteor.js still a thing?
#84Earlier quoted context omitted.
We use RxJS for data loading and global state management. Started with redux first, but really disliked all the boilerplate code. RxJS enabled us to have a really smart data loading and caching mechanisme that automatically pushes changes to all streams that rely on a particular piece of data whenever that data changes. No need for reducers, selectors, actions, constants or sagas. Just components with one or many RxJ…
I don't really understand RxJS that well, but here is where my understanding is at. RxJS helps with composition and dataloading. On a theorectical level, isn't it ideal to have Redux used with RxJS? How do you do global state management with RxJS?
The official Redux documentation [0] mentions using RxJS with Redux. According to the docs they work great together but you might not need Redux with RxJS.
I haven't come across a project using only React and RxJS though. There is redux-observable [1] if you haven't seen yet that combines Redux and RxJS.
[0]: http://redux.js.org/docs/introduction/PriorArt.html#rxjs
Re: Ask HN: Is Meteor.js still a thing?
#85Meteor developer for a long time here. Meteor, today, is still a good match for small to medium applications that provide real-time features in more than 50% components/pages. For most applications Meteor becomes a real pain in the ass. I wrote several applications for multiple clients, in 4 years I haven't wrote a single one that used the real-time features properly. A tradicional stack is simply much more flexible…
With Meteor, I wanted legos but they provided an assembled fortress. It just didn't work out for me. I'm not saying that my situation is everyone else's, but the lack of flexibility led to me to turn away from it.
I have, at a high level, looked at the Apollo project and I think they are beginning to become more modular. So the direction is good, but it no longer has the selling points that it once had: it's no a longer a one-size-fits-all solution.
Re: Ask HN: Is Meteor.js still a thing?
#86Earlier quoted context omitted.
> React/RxJS front-end stack Tangent here, but I see this combo a lot and I don't understand what RxJS is adding to the equation on the front-end. What were/are your motivations for using RxJS?
We use RxJS for data loading and global state management. Started with redux first, but really disliked all the boilerplate code. RxJS enabled us to have a really smart data loading and caching mechanisme that automatically pushes changes to all streams that rely on a particular piece of data whenever that data changes. No need for reducers, selectors, actions, constants or sagas. Just components with one or many RxJ…
Totally agreed, after I jumped through the hoops of learning RxJS I realized it can replace all the libraries you mentioned just because of the way RxJS worked. If you are interested, I created a small little Redux-clone based on Observables/RxJS as a fun project, but am using it in my side projects in production now: https://github.com/Dynalon/reactive-state
Re: Ask HN: Is Meteor.js still a thing?
#87I really wanted to buy into Meteor. It felt like the second coming of Rails. I just couldn't get onboard with something I couldn't plug SQL into. A psql adapter never came.
I wonder if you can run it over ToroDB.
Yes, it's possible to have Wekan Meteor.js MongoDB ToroDB => PosgreSQL or MySQL read-only mirroring, for reporting etc if needed
Re: Ask HN: Is Meteor.js still a thing?
#88Do not touch this platform. it caused us so much problems and didnt seem to solve any real issue. each new project we start without it is a bliss.
you dont need it and the voodoo bugs it will create.
you can just use react+node js. works great together and will be lot easier to solve platform issues when they come
Re: Ask HN: Is Meteor.js still a thing?
#89I've been working on Meteor apps for a few years now, and my TLDR answer for you is, no, don't use it.
The releases since 1.3 have definitely pushed it in the right direction:
* NPM instead of atmosphere
* React/Vue/whatever instead of Blaze
* ES Modules (import/export syntax) in place of global variables everywhere and a dependency loading system that i-shit-you-not came down to loading things in alphabetical order
* ESNext support
* Getting Node and NPM up to current LTS versions
Next stop on their roadmap is integrating Apollo, at which point it'll basically be a turnkey system for building React/Vue apps on top of GraphQL. Most of what originally made Meteor what it was will have been removed in place of sensible best practices that everybody else in the JS world has since moved on to.
But for me the sticking point is that Meteor is built on a couple of assumptions that, in my humble opinion, are fundamentally incorrect.
1. Focusing on writing code that runs on both the server and the client is a useful idea.
2. MiniMongo is a sensible way to handle the data layer and reactivity everywhere is helpful.
I personally reckon these are both crappy ideas, and combined with the "magic" parts of the framework, they encourage people who are new to full stack JS to develop bad habits and skip learning some of the real fundamentals that every developer should know in relation to security, performance and scalability.
Re: Ask HN: Is Meteor.js still a thing?
#90Earlier quoted context omitted.
We use RxJS for data loading and global state management. Started with redux first, but really disliked all the boilerplate code. RxJS enabled us to have a really smart data loading and caching mechanisme that automatically pushes changes to all streams that rely on a particular piece of data whenever that data changes. No need for reducers, selectors, actions, constants or sagas. Just components with one or many RxJ…
Totally agreed, after I jumped through the hoops of learning RxJS I realized it can replace all the libraries you mentioned just because of the way RxJS worked. If you are interested, I created a small little Redux-clone based on Observables/RxJS as a fun project, but am using it in my side projects in production now: https://github.com/Dynalon/reactive-state
This is nice! Thanks for sharing