Wow, there's a ton of jerks here dissing the variety of javascript frameworks here.
Look, the web is a fast evolving platform. Similarly, the best way to understand the tradeoffs a framework makes is write your own own! You probably shouldn't use it in production, but it's a good exercise. And writingcode is so easy to do (just code for awhile!) that we're getting a proliferation of it. This is a good thing!
I just wrote a carousel widget in jquery. Yeah, I know there are 10million carousel widgets I could have downloaded, but I wanted to understand it better so I made it on my own. (And yeah, I know carousels suck, tell my company's marketers that.)
We don't hear complaints when people try building new game engines from scratch. Granted, maybe those aren't posted on HN often?
@minionslave, @untog, @sergiotapia, looking at you guys.
// edit: And looking at the github page, this isn't really a new framework anyway? It's like... the web-dev equivalent of a review paper. He looked at meteor's stack, and swapped a lot of the component pieces. And that's cool and informative.
It might. There is no other good way to directly reply to multiple comments without duplicating the reply. Maybe it will encourage them to join this discussion. It also is less vague than leaving them off.
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.
The same thing happened with C & C++ ecosystem in the late 90s. C++ of the time was missing critical infrastructure in its stdlib - smart pointers, windowing systems, developer-friendly networking, common protocols, package managers, and in C's case even string & collection types - with the result that everybody made their own class library to fill in the gaps. MFC, ATL, Motif, Qt, GLib/GObject/GTK+, wxWidgets, and many others.
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.
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 :-)
This is far closer to mainstream JS - with the benefits that offers, eg, wide user base, maintained version of node, etc - while offering the same 'change item in browser, DOM updates, DB replicates, other clients see changes' as Meteor did.
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.
Very true, but there are some promising build tools like Rollup and React API-compatible alternative libraries with smaller sizes available for a payload-sensitive context.
"Meteor is awesome! But after 3 years, it's starting to show it's age."
Edit: Reading more into it, this is just a starter kit and not a replacement for Meteor. You lose everything that made Meteor insanely popular, for what exactly? RethinkDB?
I think by "age", the author means the framework hasn't evolved to incorporate newer ideas that have become popular and proliferated the front-end world.
There's react integration with Meteor. There's only 1 piece missing at rethinkdb to have rethink integration. Redux is possible. Webpack is possible. Node 5 is also being investigated, and not much is standing in the way.
Look, I get you want to play around with all the new toys for a hobby project. But no professional developer can afford the cost of getting burned by switching to a brand new framework and running into bugs. Meteor gives you the toys a little bit later (I know, web developers find 6 months to be an eternity), but at least you get them when they're proven and stable. Start developing real apps for real companies and you'll see the value of that.
Looks interesting - I only briefly tried Meteor, but it seemed like one of those very tightly-coupled frameworks - everything is all nice and sweet as long as you're using all of the official stuff, but try to switch out something, and you're in a world of pain. Sounds like this is trying to both switch out some of Meteor's choices that haven't aged so well and also make the whole package more modular.
Nice project, but wouldn't call it yet Meteor alternative. It looks more like Meteor 0.x, but done with a few different tools.
Still it doesn't solve my main problem with Meteor adoption. Right now if you would like to use Meteor you need to start from scratch using specified database. That limit adoption a lot. I would love if Meteor could be adopted more incrementally by companies (e.g. write collaboration layer to your existing app).
JavaScript people have programming ADHD.
"This system works fine, but we've been using it for too long, let's just rewrite it with the latest greatest"
"Angular, let's rewrite that from scratch"
Imagine is Microsoft released a totally new version of C# every year, and stops supporting it.
> "This system works fine, but we've been using it for too long, let's just rewrite it with the latest greatest"
You realise this is the opposite of that? Common, popular, existing tools, working together out of the box, replacing something that's generally regarded as weird and custom by the general JS community?
Why do you feel the need to categorize people based on the programming language that they used to write some code? I prefer "JavaScript people" to needlessly condescending people any day of the week.
> "This system works fine, but we've been using it for too long, let's just rewrite it with the latest greatest"
This is an uncharitable, unhelpful and totally unnecessary dismissal of this project. The author clearly explains the reasoning behind this project and even charts out each individual distinction. This isn't new for new's sake; features like CSS Modules and code splitting are real features that have real productivity impacts. Perhaps you don't think these features are useful or maybe you prefer a different technique for solving these problems, but either way nobody is forcing you to use it.
> Imagine is Microsoft released a totally new version of C# every year, and stops supporting it.
Except this is a completely inapt analogy. This is one individual who put together a package to solve their own problems and open sourced the code FOR FREE. If the endless supply of JavaScript tooling is a problem for you, that's your problem, you're not obligated to use or even evaluate every project that hits the front page of HN and if you're not a JavaScript programmer then I don't see why you even care.
Quit bitching about people building things you don't like.
your analogy doesn't make sense... Javascript people don't rewrite a "totally new version of Javascript every year", they create/rewrite framework/lib like in every language ecosystem. The fact that there's A LOT of this happening is just the consequence of the language popularity.
> I'm so totally impressed at this Way New Development Paradigm. Let's call it the "Cascade of Attention-Deficit Teenagers" model, or "CADT" for short.
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 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?
When I had to learn Python to do my job, I read a few pages on python.org, and one of the things it mentioned was that 'a python developer can do in a month what a C++ developer can do in a year".
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.
Most of this stuff is really designed around doing Single Page Apps, where most of your business logic is in JS that runs on the frontend, and only the critical security and validation stuff and such is on the server. Generally, the server just slings JSON back and forth to the database and does some validations and such instead of rendering full HTML pages with templates. If it makes sense to build a particular app like this, it can result in a really slick user experience.
Look, the web is a fast evolving platform. Similarly, the best way to understand the tradeoffs a framework makes is write your own own! You probably shouldn't use it in production, but it's a good exercise. And writingcode is so easy to do (just code for awhile!) that we're getting a proliferation of it. This is a good thing!
I just wrote a carousel widget in jquery. Yeah, I know there are 10million carousel widgets I could have downloaded, but I wanted to understand it better so I made it on my own. (And yeah, I know carousels suck, tell my company's marketers that.)
We don't hear complaints when people try building new game engines from scratch. Granted, maybe those aren't posted on HN often?
@minionslave, @untog, @sergiotapia, looking at you guys.
// edit: And looking at the github page, this isn't really a new framework anyway? It's like... the web-dev equivalent of a review paper. He looked at meteor's stack, and swapped a lot of the component pieces. And that's cool and informative.