31–40 of 46 posts
As someone who works in JS day in day out, I'm becoming less and less sure the entire ecosystem isn't an elaborate parody. Replacing one monolithic structure with another one because the component parts aren't right? Just skip the monolith part and use the components you want.
> use the components you want That's what he did. Anybody is free to use it or not... I'm starting to think a part of the javascript fatigue is caused by people complaining.
For those that didnt read more than the title, it's database agnostic. It scales vertically and horizontally. It's not a framework, frameworks are dead. Its just a bunch of packages that fit together like Lego pieces.
If you don't need these things (or don't know what they are) don't complicate your life! Get off HN and build something :-)
As someone who works in JS day in day out, I'm becoming less and less sure the entire ecosystem isn't an elaborate parody. Replacing one monolithic structure with another one because the component parts aren't right? Just skip the monolith part and use the components you want.
What eventually happened was that developers largely abandoned desktop software development, instead moving to the web. They were helped along by the malware epidemic of the early 2000s, which made consumers reluctant to try any new desktop software for fear that it would pwn their computer, and by the cross-platform nature of the web. Anyway, the problem became irrelevant, C++ usage shrunk back to the complex high-performance domains for which it remained uniquely suited, and now Javascript is the "too popular for its own good" lingua franca. Ironically, C++ now has a pretty solid standard library and a core of common best practices.
Makes me wonder if we'll see a similar transition in a couple years where people abandon the web for a new computing platform (or native mobile platforms?). The confusion is there, as is the consumer adoption, but we haven't yet had a compelling trigger the way that malware was a compelling trigger for the end of the desktop era. Privacy, maybe.
I'm not a frontend person. I'm backend and middleware and infrastructure, although I'm trying to figure out the front end stuff.
Maybe I just don't understand what people are trying to accomplish. In fact, I'm sure of that. I can't for the life of me figure out why you would want to have your front end so tightly coupled to you database.
Can someone explain to me in simple terms how and where I would use one of these JS frameworks in the context of a Python or Golang or Ruby/Rails app?
Earlier quoted context omitted.
Makes a point of Meteor's age and then proceeds to say that they're using 0.10 node with a bit about not upgrading anytime soon. Seems legit.
He was complaining about meteor using node 0.10. This uses node 5.x
I just don't understand how anyone can make a "best" decision these days. I'm not a frontend person. I'm backend and middleware and infrastructure, although I'm trying to figure out the front end stuff. Maybe I just don't understand what people are trying to accomplish. In fact, I'm sure of that. I can't for the life of me figure out why you would want to have your front end so tightly coupled to you database. Can so…
Expressive, concise code is always a good thing.
Meteor is excellent for MVPs and POCs; there are a lot of people out there with big ideas, but limited budgets to test out those ideas.
In Meteor, you can access your collections from the client and the server; and the vast number of packages on atmosphere makes writing a webapp in Meteor feel more like assembling lego than anything.
The speed at which we can write software is tightly correlated with our ability to innovate quickly; test things out, keep what works and throw away what doesn't.
I've developed things for clients in Meteor, in a matter of weeks what others have failed to deliver in year
90% or so startups fail, not because your front and backend were too tightly coupled, but because of a whole variety of other reasons. Given that most of that code will end up in the bin anyway, might as well focus on quantity, and switch to something more robust when need be.
I just don't understand how anyone can make a "best" decision these days. I'm not a frontend person. I'm backend and middleware and infrastructure, although I'm trying to figure out the front end stuff. Maybe I just don't understand what people are trying to accomplish. In fact, I'm sure of that. I can't for the life of me figure out why you would want to have your front end so tightly coupled to you database. Can so…
I like the idea of this; it's really what Meteor should be but they'd provide support/hosting/etc. One thing I'm concerned with in general with stacks like this is their use in mobile stuff - even React+React Router+Redux+redux-form adds a fair bit to a payload, even before you start developing an app. As nice as it is to use, for mobile I roll my own.