SDSL – Succinct Data Structure Library for C++ - <AUTHOR> https://github.com/simongog/sdsl-lite <comment><USER2> The SDSL is very easy to use, and its versatility is quite amazing. It's also rather interesting to look at the list of papers that cite it: [https://scholar.google.com/scholar?cites=6772708594529960585](https://scholar.google.com/scholar?cites=6772708594529960585) and [https://scholar.google.com/scholar?q=SDSL- lite](https://scholar.google.com/scholar?q=SDSL-lite)

</comment><comment><USER3> Cool library. Any thoughts on getting it to work with Visual C++ 2015. It now has pretty decent C++11 support, you already use CMake, and this library seems like something that is inherently OS neutral.

Even when I am ultimately deploying on Linux, I will often develop and debug my os-independent logic using Visual C++ on Windows and then when that is working well, recompile using g++ or clang++.

<comment><USER4> We are working on VS support. Last time we tried to port to VS some of the constexpr stuff we use was not available yet. The next release (in 1-2 month) should have full VS2015 support.

<comment><USER5> Um...is that legal? Nothing in VS is licensed GPLv3.

</comment></comment></comment><comment><USER6> Very nice! Why did you choose GPLv3 instead of LGPLv3?

<comment><USER4> The library is very template heavy and thus most of the code is in the header files so I guess it wouldn't change much in this case?

Additionally, we (the main authors) have lots of contributions from other researchers which we would ask for permission to the change the license (I think?).

<comment><USER7> Also, using GPL for a library is often the better choice!

Many people believe that GPL is for programs and LGPL for libraries - as if the "L" would stand for "Library". But that's wrong! This was never the intention. The "L" stands for "Lesser" and means less protection than GPL, for very special circumstances.

According to FSF, you should use LGPL only for libraries that are competing with widely accepted proprietary libraries. For anything new and original, you should use GPL - to promote Free Software.

"Why you shouldn't use the Lesser GPL for your next library"

[https://www.gnu.org/licenses/why-not- lgpl.en.html](https://www.gnu.org/licenses/why-not-lgpl.en.html)

(I disagree with that article in one point: If you compete with pervasive software, use a simple license like ISC/MIT/BSD rather than LGPL, to promote their usage even more.)

<comment> UK-AL It makes the library unusable for anyone, but open source software.

If you write any sort of software, and link against this library, boom all the code needs to be GPL'ed.

I don't think that's a good thing for promoting a library's use. Most people will just not use the library, and leave a bad taste in there mouth rather than spread the use of GPL.

If you want your library to popular don't use GPL.

What happens is that someone else comes a long and creates a MIT version. Eventually it gets replaced with the MIT version.

<comment><USER7> _> It makes the library unusable for anyone, but open source software._

Well, the author is free to dual-license it to propriertary software for some fee - if they want.

 _> I don't think that's a good thing for promoting a library's use_

But it's a good thing for promoting Open Source!

That's the tactic question here: Do you want to promote your name and your library, or do you want to encourage more people to open source their stuff? In general you achieve both, but the question is: Which aspect is more important to you?

 _> If you want your library to popular don't use GPL. What happens is that someone else comes a long and creates a MIT version._

See [https://news.ycombinator.com/item?id=10158535](https://news.ycombinator.com/item?id=10158535)

<comment><USER8> I have a very different question when I chose license for my software. I ask if my software might end up being used in a product where someone could get sued for sharing software online.

I would personally be fine with a new license that simply said "Be nice or don't use my software. You can't sue people who use or share this software. You can't apply for patents and sue people who are being creative and code. You can't stop people from understanding the software that they run on their own machine.". However I doubt many companies would prefer that over GPLv3 so it easier to just use a commonly understood license which Linux distributions understand and find legally acceptable.

<comment><USER7> _> Be nice or don't use my software. You can't sue people who use or share this software_

Would such a rule even be enforcable? If so, what's the penalty if a company sues users anyway?

I like how the GPL(v3) makes such rules enforcable by trackling them "from behind". For example, the patent protection does _not_ work by saying "you must not sue people with your patents", which one would naively write into one's license. Rather, they say (roughly) "if you distribute the software, this includes a free patent license to all receivers." And this is just one example. There is very clever legal stuff in the GPL, especially v3.

So I guess that the GPLv3 already does exactly what you want. It just doesn't express this as directly as you would, but more "from behind". However, this is for very good reasons, as it is necessary to do it that way, to make all this stuff enforcable within the legal framework of copyright law.

<comment><USER8> I doubt such rule would work in US courts as the legal tradition there put emphasis on exact wordings and would look for precedents which could direct the court into an interpretation.

The courts where I live (Sweden) would look more into what the author intended rather than the exact wording, so it will accepts much lesser precise wording than other systems. The downside is that you are basically asking what one judge and 3 politicians (lowest court instance) think is the authors intention, common sense in this context, and if the distributor acted with malice or not.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> this looks very cool but it is a shame about the license and a shame about the code style.

STL is a poor exemplar to follow - its a real wasteland of a library and very deficient compared to libraries for other modern languages.

however i will now go and learn these things and reinvent some wheels to make myself a better programmer.

thanks. :)

</comment><comment><USER10> How does it compare in terms of memory and speed, to the GNU implementation of STL?</comment>


How a startup should leverage a personal assistant - <AUTHOR> http://blog.asmartbear.com/virtual-assistant-startup.html <comment><USER2> Dear everyone ever (especially "a smart bear", who should know better): stop saying "leverage" when all you mean is "use".

"I leveraged my fingers to type this reply."

"I leveraged the wheels on my car to drive to work this morning."

Etc.

Please stop.

<comment><USER3> Generally "leverage" means to apply a little effort/cost to get a relatively large result.

That's exactly what Rob does with VA's -- applies a relatively small cost to save him a ton of time, much more so than alternatives like trying to automate it with code.

<comment><USER2> Generally the advantage of using a thing is that you get a proportionally larger benefit compared to the required cost/effort. Otherwise you wouldn't use it.

I didn't say that the use of the term was illegitimate, part of the reason why "leverage" is so pervasively abused is because it can be legitimately used (or leveraged) so abundantly.

Much like "really" the term "leverage" is almost never needed and abused far more often than used appropriately. Yes, you can really use "really" really very legitimately really often, but that doesn't mean you should, really. The same applies to "leverage" which has been leveraged far past the point of reasonableness into the realm of abuse.

Personally I think the term "leverage" is best reserved for situations where something is put to use in an unusual or especially advantageous way. Making use of an assistant to take care of mundane chores so that you can concentrate on more pressing matters is hardly novel (not within the last few millenia at least), though it is still quite sound advice.

</comment></comment></comment><comment><USER4> I think his advice on outsourcing marketing, sales and support to an off-shore virtual personal assistant is profoundly dangerous.

When you've just launched, you have no idea what parts of your product are truly helpful to your customers and which have been a waste of time to build. Before my company launched I was completely off-base as to what we should be directing attention to, and it was only through talking with early customers that we identified where the focus of effort should be directed.

That direction wasn't obvious, either. It was only through speaking with many customers over many weeks that a vague idea of what just might be the best thing to focus upon emerged.

The author states that: "If you do not outsource these tasks, they will get in the way of work that's truly productive for your business.". However, without talking directly with customers, you are unlikely to know which activities are 'truly productive for your business'.

Outsource support at your peril.

<comment><USER3> You obviously didn't read the article.

He never said to outsource customer development. You made that up.

In one of the actual examples, he had the VA simply form a list of 100 potential people he could reach out to for market research. Then he did the research himself. This is exactly the opposite of what you think he said.

The other example was doing simple data-entry with a back-end ordering system because it was easier (at first) than automating it.

<comment><USER4> Yes, I did read the article. Then I re-read it before commenting since I found the advice in that section to be so surprisingly bad.

I did not make up my quoted comments. I pulled them right from the posted article and used them in context.

Right under "Point #2: After Your Product Launch", the author states:

"Customers make it necessary to put processes in place for marketing, sales, support, and back-end admin tasks. Any ongoing work that can be described in a written process can be outsourced to a VA and save incredible amounts of time for the founders.

"If you do not outsource these tasks, they will get in the way of work that's truly productive for your business."

The author is stating that a startup should outsource their support and I still think that outsourcing customer support for a new product is an extremely bad idea, no matter how easily that support process can be documented.

Feedback from customer support is one of the best ways for a business to identify where a product can be improved. Yes, you can easily describe support in a written process, but you cannot possibly anticipate what customers will tell you during those support calls.

The information shared during those early support calls is absolute gold.

</comment></comment></comment><comment><USER5> Wouldn't it better go get an intern for this?

Even with a paid intern, for minimum wage, probably even get government tax credits for a new "hire", and still end up ahead.

<comment><USER6> government tax credits for hiring someone? tell me more.

I mean, yeah, I agree with you, for unskilled work, an intern is often the best option. I have my sister doing that work for me; I know that she's extremely responsible, and I trust her with my bank account, something I'd have a hard time doing with another random intern.

but actually, hiring people locally is a fairly large pain in the ass, unless you are willing to ignore the law when it comes to contractor/employee classification. (and really, that law is such that nearly all 'contractor' jobs I've had have been technically misclassified... illegal. But, if you want to work, you get used to working illegally. I'm doing my damnedest right now to not hire illegally, but it's real work.)

I've personally just gotten myself an office, so I've got to make my SysAdmin an actual employee now rather than a contractor, as he's actually working in my office rather than just working from home when he feels like it.

As far as I can tell, the government isn't giving me any breaks for this; far from it. I've gotta calculate and pay all kinds of taxes that I didn't have to worry about before. Granted, now my former contractor is going to have to pay fewer taxes, so it's not all bad. I mean, my accountant just deals with that sort of thing without spending my time on it, and I'm better equipped to maintain an accountant than my SysAdmin is, but still... especially if I didn't have an accountant, hiring a foreign contractor is _much_ lower overhead than hiring a local.

</comment></comment><comment><USER7> Not being based in the US, I can't help but wonder how this sort of thing fits in with labor laws in Europe.

<comment><USER8> Look at it this way...in the US, lets say a good job in an office pays $50,000 per year, and a doctor in the US makes $100,000. Now imagine there is a wealthy nation in Europe with a few entrepreneurs who have more money than time, and they need people familiar with American business practices and fluent in American English to complete some basic tasks.

Of course they could find these workers locally, but let's say that because of a strong economy and high cost of living, the average salary is $250,000 per year in that country. The entrepreneurs go online and find a few Americans who would otherwise have been working the aforementioned "good jobs" that pay $50,000, except that the economy is so bad that those jobs are unavailable. The entrepreneurs hire the Americans at a rate of $100,000 to perform the job remotely.

The Americans get a better salary they would have otherwise gotten, and they get to work from home. The Europeans get a much cheaper worker ($100k vs $250k). Everybody's happy. I don't see what labor laws would be violated, and I don't see who would be hurt by such a scenario.

<comment><USER9> _I don't see what labor laws would be violated_

The easiest one to violate is accidentally turning your contractor into an employee, and if that happens, may God have mercy on your soul, because the local tax agency will not.

<comment><USER10> It's going to be awfully hard for any taxing authority (at least in the US) to characterize a contractor hired through a service (in the manner described in the article)as an employee:

1\. The contractor presumably has other clients/customers 2\. The contractor is not in your facility 3\. The contractor is using his/her own tools and equipment

There are a number of other tests, but this is actually probably one of the "safer" ways to hire contractors.

</comment></comment></comment></comment><comment><USER11> I'm very skeptical of virtual admins. Every time I consider it, I realize most everything I want them to do requires them to be in the city I'm in. I've seen a number of friends and colleagues e ruin relationships and look like jerks after they got their VA. It appears to come from a latent blue collar desire for status, the same one that makes people put $3,000 rims on a $2,000 car, or buy a $3,000 television when they can't afford their mortgage payments.

When a close friend or colleague gets a VA and starts telling e to schedule social or business events through their VA instead of doing it themselves, I stop calling them. The only word for this is Douchebag, downmod me if you will.

</comment><comment><USER12> What kind of person do you think you'll get for those peanuts? $6 per hour is below minimum wage here. A PA is a skilled worker, not a cleaner.

<comment><USER13> Where's 'here'? His $6 rate if for Filipinos, which I'm guessing is an ok rate (given a minimum wage of $2k / yr: [http://en.wikipedia.org/wiki/List_of_minimum_wages_by_countr...](http://en.wikipedia.org/wiki/List_of_minimum_wages_by_country))

<comment><USER8> $6/hour is a very high rate for a virtual assistant in the Philippines. I pay $4/hour for skilled web/graphic designers and programmers, all with at least 4 year degrees, some with masters or higher. For virtual assistants/data entry/data mining, I pay around $2.50/hour. That works out to $400/month for virtual assistants, $640/month for designers/coders. Even better, my team is in Cebu, Philippines, which enjoys a much lower cost of living than Manila (think Atlanta vs New York City), so this money goes even farther for them.

For those of you outraged by those numbers, consider that a typical nurse in the Philippines will make $120/month, and a doctor will make $300-800 (<http://bulatlat.com/news/4-37/4-37-sick.html> or [http://doktorko.com/_blog/index.php?mod=blog_article&a=1...](http://doktorko.com/_blog/index.php?mod=blog_article&a=132&md=897)). The president of the Philippines earns $1000/month (officially, that is).

<comment><AUTHOR> Do you typically use the same firm/people? If so, would you mind passing along their contact info or posting it here? (my contact info is in my profile)</comment></comment></comment></comment>


Ask HN: What skills are important to teach to kids today? - <AUTHOR> Hi HN Community,<p>I am a parent of a 9yo and a 12yo. My husband and I have been thinking if there is anything else we should be teaching our kids apart from academics and usual extracurricular classes they do at school. What skills have you taught or you think are important to teach to kids today? (Have read a few threads on HN on how to and not to teach programing.) <comment><USER2> household life skills that everyone should know. cooking, cleaning, laundry, yardwork.

things that are surprisingly lacking with youth these days, in my experience.

and with mine... "there is more to the internet than Google/Gmail."</comment>


The State of Meteor Part 1: What Went Wrong - <AUTHOR> https://www.discovermeteor.com/blog/the-state-of-meteor-part-1-what-went-wrong/ <comment><USER2> The big mistake was trying to provide anything beyond Minimongo on the client side. People are very picky about what front-end frameworks they use on the front end, and typically people who have strong opinions about that are less opinionated about what they use on the back end. I'm firmly in that camp, for instance. I've been a huge fan of Firebase for a while because it frees me from the tedium of having to create another REST application just to talk to a database. If Meteor had, from the beginning, focused on simply being a kick- ass open-source alternative to Firebase they would be killing it right now.

It was a monumental task to try to create something that would please both front-end and back-end web engineers. Another issue with Meteor is that it was envisioned, not extracted. [1] From Rail's creator, DHH: "First, Rails is not my job. I don't want it to be my job. The best frameworks are in my opinion extracted, not envisioned. And the best way to extract is first to actually do."

Meteor was the goal, not an actual, real-world application. Often when this is the case the software ends up solving a bunch of problems that seem logical to solve, but in practice are not actually practical (another framework like this that comes to mind is the notorious famo.us project). Compare this to Rails and React which were forged in the crucible of real, day-to-day development and problem solving.

[1] - [http://david.heinemeierhansson.com/posts/6-why-theres-no- rai...](http://david.heinemeierhansson.com/posts/6-why-theres-no-rails-inc)

<comment><USER3> Let's avoid turning this into a "Meteor is doomed" or "Meteor failed" comment thread; Meteor is and has been growing consistently since it launched (see: [https://twitter.com/Rahul/status/673992512768507905](https://twitter.com/Rahul/status/673992512768507905)). The title of Sacha's post reads a bit inflammatory, suggesting something "went" wrong and that it's too late now. Rather, as his post explains, the community is currently in a bit of an identity crisis as two groups with disparate sets of opinions on where Meteor should go from here collide.

As someone who's been building with Meteor since 2012, I see all of this as a good thing. It's a sign more and more people are lending their voices and opinions to Meteor's direction. As NPM support arrives with 1.3, and as a more agnostic approach to view frameworks becomes part of core, we'll continue to see more people join, because the platform will be more open towards them.

Meteor _was_ a new platform. It's now a mature, growing platform. And it will be a successful platform if we all keep contributing.

<comment> at-fates-hands Agreed.

This seems to be the same issue with other frameworks when they get to a point where they have enough adaptation and find out they need to change/update parts of their framework to get it to the next level.

Same thing is happening right now with AngularJS. Been around for a while, had massive adaptation, then they realized they needed to make major changes. Enter pivot to 2.0 which pissed a lot of people off, but the heat is dying down now and people are coming to their senses.

I'm pretty sure at some point React and other frameworks will hit their wall too.

<comment><USER4> Rails didn't hit that wall. Neither will Ember. FYI Ember is introducing new ideas by the second (pods, composable components, components over controllers, DDAU, etc) but the community eagerly awaits and embraces them. I don't know why that is.

<comment><USER5> Rails forked sometime ago (around 2.0) into Merb then later on merged back into Rails 3.

Similarly Node forked into io.js then later back into Node 4.

<comment><USER6> This is really a fantastic point. It's sometimes as if people think these type of projects exist in isolation and any perceived flaws are permanent. They often fail to appreciate how much the flaws will invoke a response to address them, making them better than they would have been had the flaws never been strongly felt by the community in the first place.

</comment></comment></comment></comment></comment></comment><comment><USER7> The startup I'm with right now just finished a meteor/react project that I led. This article really touched on our major pain-point with the learning cliff that you hit after a certain point. We used FlowRouter since it has React support, but managing subscriptions correctly (let alone caching them) took _way_ more time than we had anticipated. It wasn't until near the end of the project that we realized none of us actually had a total mastery of what was going on under the hood in meteor, which was a terrifying realization. All things considered, though, I think our biggest mistake was biting off more than we could chew in using React and Meteor, when we had never made an app using either before. On the other hand, blaze is pretty rough...

<comment><USER8> It's good to realize the mistake here, so good job. Never jump on the new thing. Always lean toward the _simple_ thing. Always prefer tools closer to your core competencies. Meteor is really fun to play with and the community is very good, but Meteor creates _complexity_ over time.

It's also worth mentioning that unless you have a real-time app whose data model fits nicely with schema-less document storage, Meteor is almost never the right tool for the job. And even if your project has those requirements, there are plenty of high-quality alternatives to Meteor.

<comment><USER9> I've experienced this pain point (exceedingly complex systems) over and over again, and it's something I'm pretty passionate about. There's a lot of experimentation in JavaScriptLand that involves doing something _cool_ or _novel_ while totally forgetting about managing complexity. This is exactly why I built Nodal [1], I just wanted a fast, easy solution to build API servers.

We're a new thing, but the focus is on simplicity and how easy the system is to grok. The goal is to reduce complexity via separation of concerns as related to _systems_ , not just programming modules (actually, Nodal itself is opinionated and some parts are tightly coupled. The argument there is consistency within the service to keep it easy to reason about. There's no DSL outside of the ORM, which reads like Django's. Just ES6 JavaScript.) We're not trying to compete in the space of "real-time apps" at all, because microservice architectures are tried, tested, and much easier to reason about (at the expense of having separate codebases - which I actually view as a positive).

I did a write-up about it this week [2] and we're focused on trying to tackle pain points re: web app complexity as best we can.

1\. [http://nodaljs.com/](http://nodaljs.com/)

2\. [https://medium.com/@keithwhor/hello-nodal-why-we-re- building...](https://medium.com/@keithwhor/hello-nodal-why-we-re-building- node-js-servers-for-everybody-dce14b27a233#.q3nogd5qg)

</comment></comment></comment><comment><USER10> 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 Minimongo aren't giant stick bugs near Australia that need to be preserved. It's ok if they are replaced. They are internal tools for Meteor provide its "reactivity". I doubt reactivity is going away.

Other non-scary things: Routing is solved by community packages. Pagination, forms... really? Server-side rendering has the "spiderable" package, but the SEO / server-side rendering problem isn't unique to Meteor.

The database issue is valid. Meteor uses MongoDB. But, you shouldn't go down the Meteor road and try to shoe-horn a relational DB into non-relational DB, then say WTF. You knew from the beginning that non-relational DBs have their own set of problems. My limited understanding is that MongoDB was picked because it was the easiest way to get the reactivity that the MDG was looking for. Meteor road maps says SQL support is on its way.

I don't know where the OP is going with this. Maybe this is the part 1 of the late night TV commercial where they list all of our problems (think Slap Chop), then in Part 2 he'll solve all of our Meteor problems if we buy the next book he writes.

<comment><USER5> 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.

<comment><USER11> There are no Postgres or Mysql add-ons for Meteor that are actively maintained or even close to production ready. Hopefully you can prove me wrong on this, but I've looked and have only found preview releases and alpha quality packages.

<comment><USER5> This looks promising [https://github.com/jordangarside/Meteor-GraphQL- PostgreSQL-D...](https://github.com/jordangarside/Meteor-GraphQL-PostgreSQL- Demo)

</comment></comment></comment></comment><comment><USER12> I'm currently using Meteor to teach a college-level course on Web Development for beginners.

[https://csci16.hellometeor.com/](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 no other framework/language combo where true beginners can deploy a live, database-driven website in a couple of hours. I really wish Meteor could focus more on this aspect: becoming THE entry-level framework for learning web development.

However Meteor's business model is around hosting, so it's inevitable they move further and further towards the needs of professional, rather than entry- level, developers. And this takes them further into the areas outlined in this article where they are currently weak.

<comment><USER13> I'm biased as the co-teacher, but I've been hugely impressed by progress our students have made in just three weeks. Meteor really does fit in well to the beginner curriculum.

<comment><USER14> Looking at the course page, it does indeed look like meteor is a good fit; it appears that if the course was from the late 90s it would be 2 parts html, 1 part css and 1 part cgi.

But for a _little_ higher level I always liked web2py[1] - it always felt like they managed to balance bundling/simplicity with _proper_ documentation that build confidence in what is (and is not) included: like having a db schema accompanying the section on built-in auth[2].

But it certainly fails the test of "just one language". And it appears their chosen host (pythonanywhere) need to fresh up their SNI/SSL handling.

[1] [http://www.web2py.com](http://www.web2py.com)

[2] [http://web2py.com/books/default/chapter/29/09/access- control](http://web2py.com/books/default/chapter/29/09/access-control)

<comment><USER15> I like web2py too though there don't seem to be too many people using it. Comparing to things like Meteor and Rails it's striking how it's remained backward compatible and much the same since it was launched 8 years ago.

</comment></comment></comment></comment><comment><USER16> The thing which prevented me to use meteor for big projects is it looks really monolithic from the outside.

What happens if suddenly I want to rewrite part of the back-end or part of the front-end with something else for various reasons ? What happens if I want to switch from MongoDb to RethinkDb or Postgres for some reason ? It's good to have default choices but it looks from the outside that the default choices with meteor are pretty fixed.

But maybe I'm wrong, that's just how it looks like from the outside.

<comment><USER17> > What happens if I want to switch from MongoDb to.. Postgres.. The default > choices with meteor are pretty fixed

This is exactly the reason I'm not using meteor - and it's not so much wanting the ability to _switch_ backends as knowing in advance I want to use an SQL database like Postgres, and not Mongo. With meteor, it's Mongo or nothing.

I believe SQL integration is on their roadmap, but I think now it's too late.

You can in fact use React as the view layer with meteor, so for an app using React, the remaining killer feature of meteor 6 months ago was optimistic updates, with database sync all handled. But, there was still the hard limitation that you must use it with Mongo, which simply made it a no go. I commented about this here, a couple of times, and others did too. I even asked a few months ago if there was a library that just provided the optimistic updates feature. Well, now there is one that looks promising, though it's still early days and I've not used it yet - Facebook's Relay - with complete React integration, caching, request management and optimisation, and yes, optimistic updates and sync. The difference though, is that it talks to a graphql server, which can be written over any database at all - with Relay the frontend is entirely agnostic about the database used, by design, because it talks to it through a middle tier. There's no reason for me to wait for meteor to implement SQL integration any more, because now another solution has come along.

I still don't understand why meteor made the choice of a hard dependency on Mongo if they ever wanted to become mainstream. Had they not, it's very likely that many developers, myself included, would have picked up meteor over the past year and would be hooked on it. Now though, that train is rapidly leaving the station, at least for devs on the React stack. I think they missed their window.

<comment><USER18> Query subscription is the reason. You can add a monitor to the equivalent of "select * from docs" in mongodb and get notified by the db when a docs row is inserted. Some RDBMS:es can solve the same task ad-hoc using triggers, but it is not the same and is much more resource intensive. That makes it hard to achieve Meteor's goal of "any data change is immediately reflected in all clients" with any db other than mongodb.

<comment><USER19> It's actually even easier in CouchDB than Mongo. One of the smaller mysteries to me has always been why Meteor went all-in on Mongo rather than Couch.

</comment></comment></comment></comment><comment><USER20> > Meteor has yet to establish itself as a mainstream development technology on > the same level as Rails or even vanilla Node.js... almost four years after > Meteor first launched, I have to admit I thought the framework would be more > widespread by now. So what happened?

A more general answer, I feel like the web programming world doesn't really need new frameworks, does it? Rails or Django got mainstream adoption because there was a need at the time, likewise with frontend JS frameworks (which seems to be consolidating around just 2 - React and Angular), and likewise with Node as filling a need for easy async. I'm not that knowledgeable on Meteor [1], however I think by default it's reasonable to expect no new frameworks to have mainstream adoption without a major change to the web.

[1] I don't know if Meteor's x-platform appeal is enough to convert users from other x-platform, native and/or hybrid solutions (Ionic, Titanium, RubyMotion, etc.).

<comment><USER21> "likewise with frontend JS frameworks"

And jQuery. Probabil still the most used JS library.

<comment><USER22> 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.

<comment><USER23> 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.

</comment></comment></comment></comment><comment><USER24> Personally, the one thing I don't like about Meteor is that it insist on using MongoDb. That along makes me NOT want to use it, despite other cool features.

</comment><comment><USER25> I was never able to get on board with Meteor because of the Mongo dependency. Not to get too far off topic, but Mongo is guaranteed to lose data under certain well-defined conditions.

I completely fail to understand why some developers seem to be allergic to learning about data structures and the means of query-ing them. It's not really that hard. If you can JS, you can SQL.

<comment><USER26> I currently use Meteor for a production app, but only use Mongo as a scratch pad (holding data until the user is mostly done changing their mind and other minor UI state). Data is then packaged and sent to MS SQL Server for long term storage and reporting.

As an example, a user can start updating a piece of data (eg: sales order, item, etc), with everyone able to see the changes as they happen (no hard need for locking, easy to support temporary network loss). Once they are done with changes, they are sent to SQL.

The advantage of doing it this way, is that the data stored in SQL Server can be completely optimized for reporting/storage and doesn't need the schema to support UI requirements. This makes things much simpler for people writing the UI as they don't have to change the SQL schema often to support the shinny new UI widget of the day and the report writers don't have to sift through a million useless to them tables/columns or partially entered rows to find the data they need.

<comment><USER27> This is very interesting. Could you give a little more details on how you accomplish this? How do you serialize unstructured Mongo data into MS SQL? Does this system break down when front-end people change the data structures in Mongo? I'm not familiar with Meteor but maybe you could explain in broad strokes

<comment><USER26> There are several ways we go about it depending on the needs of the data to be stored in SQL. All of our data in SQL and Mongo has a uuid as the primary key and effectively lets us use merge-style replication techniques, and support temporary offline use of our application.

If the Mongo data is flat, its very easy to go from Mongo->SQL, only a type mapper is needed.

The lumpy data case gets more complicated, as its dependent on the data. The complex data generally ends up translating into master/detail tables or similar ideas. Various pieces of data that is nice to have, but changes with the UI/customer needs, gets stuffed into several key/value tables (one for each type).

For the completely dynamic Mongo data we store in SQL, we alter the SQL table programmatically to meet the new schema (in part of our application, customers must be able to drive the schema). This way works in our specific application, but it requires a lot of work to make sure your users cant paint themselves into corners with their schema.

So far we haven't experienced any issues with the front-end people changing data structures, as the changes they generally make only impact fields that are not stored in SQL. Completely new features generally require the addition of new columns/tables to SQL, but every application has that issue. During startup of the server it double checks the schema of all of the tables used and updates as needed.

<comment><USER27> thanks very much for the explanation. That sounds like interesting work and a great solution

</comment></comment></comment></comment></comment><comment><USER28> > 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!

<comment><USER29> Yeah I don't get this part and it has nothing to do with Meteor, just that new users find it hard to do anything beyond Todos. But that also makes no sense. So it's hard for the user to not do something very simple? Maybe the user should take the time to learn what they don't understand.

</comment></comment><comment><USER30> Give me a box of boards and nails any day. All my ikea furniture is rickety and much of it is starting to look dated.

I just spent a good amount of time over the last few months building a prototype for an application in Meteor and it has been a joy.

Out of the box I got happy, grokable app/server communication, I got sane user account tools and I got a build process that works well enough that I haven't thought about it at all. I almost never need to look at documentation, I just build features. I've only needed a few community packages, and the ones I have used have been working pretty well for me.

I feel like I've been living the dream. So much ceremony and overhead just melted away.

I'd be curious to hear what kind of issues people have hit with blaze/meteor package management/etc that make them want to swap in react/npm/etc. (I spent the better part of 2015 with react/flux and it would take a lot to get me to switch back).

<comment><USER31> > Give me a box of boards and nails any day. All my ikea furniture is rickety > and much of it is starting to look dated.

This seems to contradict the rest of your post where you go on to talk up the plug and playness of meteor. That's much more like ikea furniture than a board and nails. The board and nails approach requires you to do all the planning that meteor gives you out of the box.

<comment><USER30> I guess I think those things to be the building materials, and folder structure/routing/etc to be the stuff I don't mind making my self. I get how this might be opposite for others though.

</comment></comment></comment><comment><USER32> I like Meteor and am using it for my current project, but I architected it in a way to stay away from their pub/sub model where you publish partial data sets to the client. I believe this only has utility where you have a feed of data that you want to filter or sort on a lot of different attributes.

Instead, I just utilize `Meteor.Methods` for all client/server interaction. I actually think it's pretty nice because you define the method on the client as a "stub" that gets called as it waits on the server response. I think the tutorials and guides focus too heavily on their fancy client/server mongo magic.

Though something that is a bit frustrating reading this is that I left React. I found it overly-complicated for my product and preferred architecting everything in terms of templates. Blaze is threatened by React? How? I like React, but I can't exactly get behind writing HTML components in javascript because whoa man, a diff engine & "look ma! I'm being functional!" I realize the benefits of uni-directional flow, but all it really did was add a lot more conceptual weight to a pretty simple interface.

So I said, this is pointless let's just simplify things with Meteor + Blaze. Now Meteor says, it's "threatened" by React?

</comment><comment><USER33> 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 behind meteor trying to make it THE framework, instead of just being a framework that excels at a single purpose.

<comment><USER34> 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.

</comment></comment><comment><USER35> I loved meteor. Was committed to it for 6/7 months while still learning JS (and working on ember and rails projects with others). I knew it was a risky decision, but it seemed like a good choice for making it as a one-man dev agency. For me, there's no stack selection problem, for me, the main problem is the co$t of launching a working demo-app or a prototype. The only thing i wanted was a simpler/cheaper way of deploying apps. I knew there was something coming, since the beginning i heard about galaxy, an MDG developed deploying solution, which i thought was the solution for all my problems. But then, then came the galaxy launch and its price ($495/mo). At that price I felt betrayed, misrepresented. (still waiting for the individual price several months after)

The big problem i see with meteor for the future, is that MDG has/will have to answer to its shareholders rather than its community.

<comment><USER36> In regards to cost of launching a working demo-app or prototype my solutions was a Digital Ocean $5/month box + Dokku

[https://github.com/dokku/dokku](https://github.com/dokku/dokku)

<comment><USER35> Didn't know about Dokku, thanks!

Worth mentioning that there are many more solutions now than there were a year ago, when i was facing this challenge.

</comment></comment></comment><comment><USER37> As long as there is no direct PostgreSQL support, Meteor is no viable option anyways.

</comment><comment><USER38> 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 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).

SailJS vs TrailJS, ExpressJS is dying, NodeJS vs io.js, StrongLoop+IBM fiasco (and SL reputation), now MeteorJS!. I had high hopes that MeteorJS can be one of the premier NodeJS frameworks (Rod Johnson, who created Spring Framework, invested in the company. I hope they listen to him...).

I love to see competition in NodeJS ecosystem and hopefully sooner than later, a few solid options emerged because right now, everything is not a good option except barebone NodeJS and roll-your-own-framework.

<comment><USER34> > 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 javascript on the backend. I feel like people think that just because Node is associated with Javascript that its inherently bad.

<comment><USER38> 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.

</comment></comment></comment><comment><USER39> Anything that implies the lock-up unless everything is rewritten completely is not a viable choice for me.

I'm wary of anything (especially JavaScript as trends change there faster than one can read the articles) no matter how praised it is. Sometimes things just do break in the most bizarre manner when you already have everything set up. If components are modular enough, you can swap them, or at least patch a completely new piece over the old one, to handle the problematic cases.

When I once had to replace a very old legacy system (non-web, but it still holds) I've just slapped a dummy do-nothing proxy-like system in the front and gradually did stuff piece-by-piece. Then threw out the old garbage when it wasn't doing anything anymore.

But from what little I understood about Meteor from the tutorials and examples, there's one single giant system, that you either use or don't. This means, if one hits some bug or - worse - architectural limitation, they're going to have really tough time.

</comment><comment><USER40> When I saw MongoDB, Meteor got put on a "check back some day" list. Phoenix is way more interesting: it's built on some very solid foundations.

<comment><USER41> Phoenix the Elixir framework? Or something else?

<comment><USER40> Yes, that Phoenix. Granted, it's much newer than Meteor, but it builds on such a great base that it really is standing on the shoulders of giants.

</comment></comment></comment><comment><USER42> The challenges discussed by the OP apply to _any_ large-scale complex project and are not limited to developing in Meteor. True, some are specific to Meteor (besides the challenges that go with all NoSQL architectures), as is the case with any tech stack. IMO it's quite unfair to obsess about the cons only (especially if they are the kind of "problems" _you_ can't tackle), and to take the pros for granted.

Routing in Meteor, for one, is trivial (esp. with Flow Router). Subscription management and caching are solvable problems too (esp. if you refrain from doing subscriptions during routing, but instead declare your dependencies where you are really are dependent on your data: in the UI components).

What's the problem with using NPM packages inside Meteor, exactly? The fact that you must write a single additional line in a package? Well, if you're not used to organize your code in re-usable Meteor packages, then, I guess, it's more _your_ problem, than it is a problem with Meteor.

Meteor does not scale well? How is that? Any Meteor app can scale, as can every application that has been set up with a well engineered architecture: implement you logic in micro-services and your Meteor app will scale smoothly, horizontally, until your _database_ (and not your app layer, that is!) becomes the bottleneck.

Most of the comments here, seem to emanate from me the degree of freedom that comes with Meteor (platform vs. framework). If you can't architect, then, obviously, Meteor won't save your day and do your engineering for you.

I put up some slides with Meteor best-practices for building large-scale apps: [http://meteor.redandivory.com/](http://meteor.redandivory.com/) The presentation is almost two years old, but most of the guidelines still hold.

tl;dr — It's not the framework's job to do your architecting. Don't blame the tool if you don't read the manual.

</comment><comment><USER43> I built an app with Meteor right around when 1.0 was released. The absolute worst part for me was attempting to shim what should have been a relational database design into the default NOSQL mongoDb (you pretty much had no choice).

</comment><comment><USER44> I tried out Meteor this past spring. I started with a simple Trello clone, which I got working in a couple hours, including learning time. It was good enough at that point that my brother started using it at work. I was pretty impressed.

So I got to work on some more advanced features I'd been thinking about. And at some point, Meteor started throwing an error from somewhere in its innards, and for the life of me I couldn't figure it out. Some kind of problem mapping data to UI, I don't remember the exact message.

I decided I needed to know the guts of Meteor to be able to debug problems like this, and put the whole project aside to wait for the _Meteor in Action_ book. But now I'm onto other things.

</comment><comment><USER45> Seems like a good analysis of Meteor's shortcomings.

I did some research on related areas a few months ago. My ideal stack at the moment would involve:

* redux or cerebral with immutable model

* react

* css modules

* webpack

* a realtime-enabled version of falcor, which doesn't exist yet.

The last bit is still the missing piece for realtime, as far as i'm aware. Neither GraphQL not Falcor seem to been designed with realtime model updates (via websocket) in mind.

<comment><USER46> Aside from Falcor, this is exactly my current stack and my preferred as well. React + Redux + Webpack + Immutablejs + Bootstrap/Less. I'd be interested to hear your thoughts on Falcor or Relay/GraphQL and see what it can offer. For my backend I run some minimal node webservices. I've recently started making all my stuff "pre-rendered" by statically generating my files (react renderToString -> Mustache -> create a file) , with all my needed data in a json file, and only access the webservices when absolutely needed.

</comment></comment><comment><USER47> Honestly, I used meteor and tried pretty hard, I went to their hackathons, etc...

I just don't think it's as good as the other options technically (does not scale well as a server, which is a problem for most applications).

More importantly, as a developer, I do not believe VC money should be bringing opinions to the open source community (which is what this is) is a bad idea. The whole point of open source projects is to have natural selection happen. Meteor having VC money allows them to get it wrong but still market it etc... Which just seems like a poor idea.

<comment><USER48> How would you like ambitious projects to be funded instead?

<comment><USER47> I think the idea is good, but in this case the funding happened too early.

I think open source should have a VC mechanism going on, but first you have to prove your worth to the community.

</comment></comment></comment><comment><USER49> I did a little project with meteor in its early (pre 0.5) days. At some point internal errors I could not understand started cropping up. Nobody in the community at the time could help. In the end I wrote the app in go and angular. The idea of meteor seemed nice at the time but in practice it wasn't fun. The all in approach means you should also understand what goes on under the hood because when the engine fails and nobody knows why, you are stuck.

</comment><comment><USER50> This article is really great. Yes, Meteor is still one of my favorite platforms, but every library / framework / platform always comes with its pain points. I have had a great experience with it so far and I have to admit, I did get to a point recently where I was having trouble recommending it to other people and companies due to the various points stated in the post.

But, having said that, there is still a very bright future ahead for Meteor. The people at Meteor Development Group have identified these pain points and have plans to improve some of it. There are various tasks that they are working on now that will change Meteor a bit, but also make it a better platform (in my opinion). Things such as better NPM / module support, support for multiple different types of databases, faster build times, better testing support, etc.

The platform has been around for awhile and I still think that it can reach the goal of being the go-to JS platform for building cross-platform applications.

</comment><comment><USER51> The major benefit of Meteor (at least for me) always was its quick bootstrap. So you want start coding or work on a mock-up? Just _meteor create myapp_ and start. No boilerplate. No script and style tags. Heck, add bootstrap with a single line of command and you start with fine-grained classes! Sure you might need a database... don't worry! No need for schema, modeling, whatever, the server is already there and so the database.

Eventually you might want to scale and then, as in any library/framework/platform things will get a little more complicated. I don't see it as a problem, really.

Meteor always was opinionated and maybe some opinions were unpopular from the beginning (MongoDB, for example). But when you start adding multiciplity (React/Blaze/Angular for the frontend, Iron Router/Flow Router/React Router for routing, Meteor Package System/NPM...) you can lose the track. I'm afraid this is happening now.

<comment><USER52> I concur. The strong part of Meteor is its easy way start (both a project and diving in web dev).

For experienced web developers, or people building bigger projects, easy start (and whole magics) is incompatible with high modularization and ability to easily tweak anything.

</comment></comment><comment><USER53> 'All happy families are alike; each unhappy family is unhappy in its own way.' -Tolstoy

It seems that many people are unhappy with Meteor in its own way. It takes 375 factors to make a 'Rails' and Meteor has 370 for each person, but each person is missing a different five.

</comment><comment><USER54> As a newcomer to Javascript frameworks I totally love Meteor JS. I come from Java backend programming and My Job/Client always worked on proven not so recent frameworks like Spring etc. I always wanted to learn the Javascript frameworks but the vast options there are made it very difficult. Too many JS frameworks, Too many choices. I started learning Angular and they decided to do a makeover which requires learning from start. Even React isn't something quick to master.

But Meteor, it just made my move into Javascript webapps so easier. I'm seeing results instead of that paralysis of am I learning the right framework. I'm also almost 80% done with my niche Classified ads site.

Meteor JS is best thing I picked up In 2015.

</comment><comment><USER55> So, Meteor is going to turn into what SocketStream was, five years ago, before it was completely eclipsed by Meteor's marketing steamroller.

</comment><comment><USER56> Meteor is easily the most productive webstack I've ever tried (couple of years ago) including learning, app setup, configuration etc vs some of other popular choices. I hope at least some of that carries over to what ever is coming out next.

</comment><comment><USER57> 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 collections well.

[https://atmospherejs.com/patmoore/meteor-collection- manageme...](https://atmospherejs.com/patmoore/meteor-collection-management)

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

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

</comment></comment></comment><comment><USER59> The reason I picked firebase over meteor was ember support. Ember and ember data on top of meteor would be a killer combo for me.

</comment><comment><USER60> This is a little worrying; after much research I'm starting a new project for a startup using the meteor stack.

<comment><USER2> Why worry? Does it solve your problem today? Don't fall into the same trap that so many people fall into who worry far too much about how popular the tools they use today will be 3 years from now. Focus on what makes you productive _now_. Your startup has a far greater chance of failing than Meteor.

<comment><USER61> and if it takes longer to get what you need to do done with meteor your startup might have a far greater chance of failing because of meteor.

</comment></comment></comment><comment><USER62> So, full disclosure: I recently co-authored a book on Meteor which comes out in a few months[1]. I don't think Meteor is a cure-all panacea or that it's the Best Framework Ever®. I've come to Meteor with a fair bit of experience (Play 1.0/2.0, Sails.js, Flask, etc.) and a fair bit of skepticism. However, I really don't think much went wrong with Meteor. In fact, it treads some of the same ground as its predecessors. As far as OP's article is concerned, I have some very specific squabbles with it:

> This creates a bigger barrier to entry compared to front-end frameworks like > React and Angular, or server languages like Go or Elixir.

Okay, Meteor has an arguably bigger barrier to entry than React or Angular (maybe), but definitely 100% _not_ Go or Elixir. I think this is just disingenuous.

> I believe some of Meteor's early choices may have ended up handicapping it. > For example, Meteor's focus on real-time applications makes them a lot > easier to build compared to any other platform out there. But it does also > come at the cost of hidden complexity, and potential performance problems > down the road.

This is the #1 problem of every framework, ever. Mr. Greif is not saying much, if anything at all.

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

Here, he's conflating things that are easy (routing and pagination) with things that are hard (subscription caching), so it's hard to see exactly what the criticism is here. Not to mention that Iron Router are pretty mature. I haven't run into a routing issue yet that it couldn't solve. As far as joins and caching, etc., these are definitely difficult things. I don't think _any_ framework out there completely (and in the general case) solves these out-of- the-box. Maybe someone could introduce me to one.

> The result of all this is that Meteor has ended up in an awkward place.

I think it just ended up where almost all other frameworks end up: useful, but not completely generalized. In fact, I think striving for a very high degree generality might be a mistake, lest we want to end up with something like Hibernate.

[1] [http://www.amazon.com/Introducing-Meteor-Josh- Robinson/dp/14...](http://www.amazon.com/Introducing-Meteor-Josh- Robinson/dp/1430268360)

</comment><comment><USER63> In my experience, the best part of Meteor is its tightly couple stack so that I can developer very smoothly. But the worst part is also its tightly couple stack when my web/app grows. Really hope that it would be easier to decouple some important package like tracker or minimongo

</comment><comment><USER64> Lots of fear mongering here and as you'll notice, a lot of voice from inexperience with meteor itself.

We bet on Meteor and it's doing phenomenal. The development experience is great. I haven't been this happy and impressed since rails .9 ripping me a new case of programming love.

Look, meteor has it's downfalls but so does any stack. There's nothing working against you, it's all just code. There's no magic. You don't understand subscriptions, merge box, and how to handle joins? Level up a little bit. It's not a hard thing to figure out. Open source code makes it easy to dig in.

Yes, mongo is looked at in bad light, it's also incredibly powerful when used right. The trick is to not be oblivious to the tools you use and work around it when it matters.

The most important thing for a product, startup, and company is the ability to make the right calls and grow at the right time and then be able to handle and accommodate problematic areas when you need to.

Does meteor scale? Yes. Does it have a theoretical limit? Yes. The trick there is to be cognizant of the limit and plan around it when you are approaching.

It's all just JavaScript at the end of the day.

Oh you want to scale out your processing? Easy. Fan out some back end nodes in whatever language you want. Pull from mongo, do your crunching, and then feed it back in. Then meteor will sync it to all clients. This is pretty powerful. You can completely swap out and fan pieces out with meteor.

We have a massive app in meteor. It's also architected to be modular if we have to break it up.

The isomorphic nature of the code base has created pleasant APIs on both the front end and back end and has drastically simplified a real time app experience. Meteor sets a new standard for web applications and demands new perspectives. When you embrace it you get an ecosystem that is quite revolutionary to work with. Everything from the web-app, latency compensation, pub/sub, down to Cordova builds.

Overall, we are very happy. Yes things can be better, and we are looking forward to seeing meteor evolve.

Meteor shouldn't focus on supporting new view frameworks like blaze vs react. Just focus on adopting the tools out there and making it better. That's why meteor doesn't need blaze. Meteor doesn't need a router. Meteor should pick the best open source versions of that in the Js community and make it easy to work with inline with the "vision". Meteor should focus on the developer UX. This is their power. An opinionated framework that removes the stress of configuration and has tools that fit really well together to allow an individual, team, and company to focus on building what matters: features.

The vision is grand and I believe it in and I'm also not worried about scale. People said the same shit about rails, and x, y, z. Scale is a good problem to have and when you have that problem you'll figure out what you have to do.

If anyone has any questions about meteor architecture feel free to ping me.

\---

</comment><comment><USER65> Another place I'd love to see Meteor move towards the (future) standards would be an eventual replacement of Fibers with async/await throughout, which to me is more explicit and intuitive.

</comment><comment><USER66> I think the problem with Meteor is that it's not meaty enough...

[https://github.com/mattkrick/meatier](https://github.com/mattkrick/meatier)

</comment><comment><USER67> "Project Foo: The Greatest Thing Ever". What is that? I should look into that.

A year or two later. "Project Foo: Total Crap". Glad I didn't look into that.

<comment><USER68> Meteor is different. It's been over 4 years. It's not going anywhere. It has more stars on GitHub than Rails.

If you haven't looked into it, and you're in a remotely adjacent field, you're behind. Even if you don't decide to use it. The ideas underpinning the framework are very progressive and sure to continue in some form even if Meteor itself ultimately doesn't.

With all that said, I think Meteor is simply going through some growing pains. Given how ambitious its vision is, it simply _can 't_ avoid them. I look forward to Sacha's next, hopefully more optimistic, post!

<comment><USER69> There are too many JS frameworks/platforms/libraries to keep up with. I can't spend my time investigating them all. I've heard of Meteor several times but in my mind it was associated with (a) real-time apps, and (b) not free. I'm guessing that was because it is the free alternative to a paid thing? Anyway, that's what stuck in my head so I've ignored this one.

Is looking at GitHub stars a recommended way to find the best frameworks? Or what would you suggest for that?

I recently started looking at Nodal since it was mentioned here on HN a couple weeks ago. It looks pretty cool at first glance but I haven't tried building anything with it yet. (I don't have infinite time.)

I remember when there was Prototype.js vs jQuery vs Yahoo's library vs MooTools vs fill-in-the-blank. I only switched to jQuery when virtually everyone else had. Until then I stuck with Prototype because its the one I already knew (because I tried it first), even though I _had_ played with jQuery a little bit.

So, again I say there are just too many frameworks to keep up with. (And ask if anyone has a good site / method for dealing with this.)

<comment><USER68> There's nothing (I know of) with a more radical approach to the full-stack web than Meteor.

No one's saying you need to keep up with _all_ the JS frameworks, but if I were hiring a JS dev, I'd expect the person to understand the pros and cons of the most important ones. Meteor is categorically one of the most important JS frameworks out there.

I'm not sure about a way to determine the "best" or "most important" frameworks. Perhaps number of appearance on the HN front page could be a heuristic?

"Not free" is not quite right. The software is open-source & MIT licensed. The entity is for-profit, as it intends to sell services adjacent to the software, not unlike Acquia & Drupal.

</comment></comment></comment></comment><comment><USER70> > The recent Blaze/React debate

Can someone point to the backstory here?

<comment><USER71> I was curious too, found this: [https://www.discovermeteor.com/blog/blaze- react-meteor/](https://www.discovermeteor.com/blog/blaze-react-meteor/)

</comment></comment><comment><USER72> I was turned off to Meteor when one of the initial releases was touting being able to use the browser console as a Mongo shell. Never took it seriously since.

<comment><USER73> I think it is for development only.

<comment><USER74> The intended use doesn't matter. That's a huge potential exploit. I would never deploy an application based on a framework where database access from the browser is baked in.

<comment><USER75> Database access from the browser is not baked in. This is a misunderstanding. Meteor has a browser cache that mimics a subset of Mongo commands, and auto- syncs with the back-end based on security rules you define.

<comment><USER74> Thanks for the clarity. That will teach about commenting during the morning commute.

</comment></comment></comment></comment></comment><comment><USER76> I can sympathize greatly. I played around a bit creating an isomorphic "framework for frameworks" to explore some techniques I didn't get to use in my day-to-day. There is a constant tension between leaky abstractions and expressing functionality meant to run in very different environments that I personally am taking years to fully grok [0]. Of course, unlike the meteor folks, I'm doing it for fun, so there is no pressure to make any money doing it on my end.

[0] for instance, I made it trivial to invoke client functions asynchronously from server code using normal call syntax. Now how to deal with timeouts? The syntax doesn't permit much without leaking, destroying the original point.

<comment><USER77> Off topic but is there a reason I keep seeing this word 'grok' used all over HN? Just say 'understand' unless there's a reason to sound like you have aspergers.

And 'fully grok' is redundant anyhow - grok implies a full and deep low level understanding with no lapses, you cannot partially grok something. It's dissapointing to see uncommon words used in poor ways, I'm seeing this word misused all over HN as if its now a cult jargon.

<comment><USER78> jargonfile or gtfo

There's nothing wrong with saying "grok."

<comment><USER77> "Grok" in is original use is something more like a deep and complete understanding. Here is Heinlein's explanation from "Stranger in a Strange Land": "Grok means to understand so thoroughly that the observer becomes a part of the observed—to merge, blend, intermarry, lose identity in group experience. It means almost everything that we mean by religion, philosophy, and science—and it means as little to us (because of our Earthling assumptions) as color means to a blind man."

But 'grok' is supposed to mean something more like understand various arbitrary things at a low and intimate level, not at a high level.

</comment></comment></comment></comment><comment><USER79> Meteor is great and Im optimistic what 1.3 will bring with better NPM support.

</comment><comment><USER80> I'm sorry, but how are you in a lead position but somehow didn't understand a timeless principle of software development?

<comment><USER81> I'm sorry... Literally your entire posting history is negative without adding any value. Why is that?

I personally enjoy seeing people voice their mistakes in a honest way so the rest of us can learn.

Edit *your

<comment><USER80> Where do you see negativity? How is his comment adding any value? "We chose a stack we didn't fully understand after trying it for less than a week and it turns out we didn't know everything about it!"

Also it's "your", not "you're."

<comment><USER82> > Where do you see negativity?

The same place you saw the negativity, which is why you prefaced the sentence with "I'm sorry."

One should not assume someone's technical prowess based on one poor decision (a decision they've recognized as suboptimal). Also, they still shipped.

<comment><USER80> That's a ridiculous statement. "I'm sorry" is not an indication of negativity. Nor is it indicative of my posting history. Apparently criticism is simply not allowed. Sorry to poke the fluff that is somehow being perceived as value.

You most definitely can judge someone's technical prowess as well based on their decisions. I am not sure how you're going to grey-wash this into some kind of innocent mistake. The decision that was made reeks of novice motivations and perspectives.

I asked a very blatant question, if one is going to go off of titles, how does a CTO and lead engineer (or anyone leading any kind of project) make such a novice mistake, together nonetheless. My apologies for not echoing commendations.

<comment><USER83> > Apparently criticism is simply not allowed. Sorry to poke the fluff that is > somehow being perceived as value.

Your original comment suggested this person mis-understood a foundational principle of software development. I, and I suppose many others, have been reading Hacker news since before we were senior engineers. So its not being "perceived" as having value; by your own admission, it is full of value (for a large portion of hacker news). While criticism is indeed tolerated, it must provide some value to the discussion. your original comment effectively read: "You are so incompetent, how did you ever get hired". That is not conducive to discussion; hence the down votes.

<comment><USER80> I like how a very forthright question has been met with utterly ridiculous characterizations of what was stated. I didn't say "how did you ever get hired." I specifically mentioned the lead/CTO aspect. It's a crudely constructed sentence that should result in a struggle to interpret any other way.

My comment then was meet with trivialities, outlandish statements, and generally nitpicking of tiny parts of my posts. And it appears that because they simply took a position seemingly contradictory (in the lightest sense of the word) to mine, they have been spared any amount of criticism despite significantly diminishing any hope of constructive conversation. Quite honestly, if I had simply ignored these responses there'd be far less noise and general non-sense. My question was not a top level post, it was specific to what was stated and based on one other comment the OP made in the same thread. It's not complicated to respond to nor to understand the motivations of.

Based on his comments, both the lead of the project and the CTO chose an entire stack for their product after seemingly one hackathon, maybe even hosted by Meteor itself.

I am sure the industry doesn't need to have a conversation about how huge amounts of capital are being used at various companies, with people who lack the experience (or sometimes, and not necessarily in this case, intelligence) to make such decisions, all while giving marching orders to who knows how many engineers under them. And again, this type of problem and others like it are something that the industry as a whole has plenty of talent do deal with and appropriately handle. So, how did this non-sense of picking this shiny new toy come about? How did he become lead? Which is why my question was asked. This isn't some isolated incident. I see it far too often, especially professionally.

Oh and let's not forget this is all on a post about the schism between development motivations in the Meteor community.

Calling me a troll for not using an endearing tone and having a question that is part of a larger conversation on the state of the tech industry is maddening. That being said, this is clearly not the right audience, especially using the responses as benchmark, so I'm dropping it and sticking with "just ignore everyone but OP" after this.</comment></comment></comment></comment></comment></comment></comment>


Install Linux from a running Windows system, without need for a live USB - <AUTHOR> https://github.com/mikeslattery/tunic <comment><USER2> The project description ("Install Linux over or alongside an existing Windows install, straight from Windows, without requiring to boot from external media like a flash drive or making BIOS configuration changes") reminded me of the old BeOS 5 Personal Edition installer which "installs from within Windows _without partitioning_ " and "kicks Windows out of memory and boots BeOS in its place."[1]

In the same review, Scot went on to say: "I tested the Windows installer on several machines, and was amazed. Not only did everything work as advertised -- it worked better than I dreamed possible. BeOS has always been the easiest OS on the planet to install, bar none, but this is ridiculous. BeOS is up and running in five minutes or less, and everything is totally painless. Linux distributors should be taking notes." Sounds like someone did! ;-)

[1] [https://birdhouse.org/beos/byte/13-beos_5/](https://birdhouse.org/beos/byte/13-beos_5/)

<comment><USER3> Loadlin did something similar, but with msdos and linux: [https://en.wikipedia.org/wiki/Loadlin](https://en.wikipedia.org/wiki/Loadlin)

<comment><USER4> I did horrible things with a parallel-port ZIP drive. Had to start loadlin with the kernel parameters to load the appropriate module for it to continue booting...

Side note, running with your root filesystem on a ZIP disk is not performant.

</comment></comment></comment><comment><USER5> But where is the joy? The best part of installing linux on a windows machine is killing windows. Bypassing the normal boot process. Deleting the partitions. Pealing off those little windows stickers and seeing them on the trash heap is only reason anyone installs linux. I wish windows still came with installation CDs. I need more coasters.

<comment><USER6> I would like to do that, but Linux still has not mastered the arcane art of scrolling a webpage without tearing.

<comment><USER7> I guess adding one command to your autostart list is too much to ask these days :(

<comment><USER6> Which one?

<comment><USER7> "picom" or "compton" is all it takes

</comment></comment></comment></comment></comment><comment><USER8> Man, I'm trying real hard to make my dad to use linux, I spent 3 hours last weekend formatting and setting up his computer with ubuntu, but developers are letting new users down.

He is familiar with chrome, so after the installation he downloaded chrome. At this point I was hoping that he would be able to just double click the .deb file and install with no hassle, but he couldn't. I don't know if was the package manager fault or google's... All I now is as long as people have to use the terminal to do basic things, windows users won't be able to make te switch.

Nice job though, we need more projects like this.

<comment><USER9> > double click the .deb file and install with no hassle

That sounds like a great way to finally introduce the concept of trojan-horse malware to the consumer Linux ecosystem.

You should almost never be installing a raw .deb, anyway, because packages form networks of requirements/versions/etc. It's probably outdated, and might even be for the wrong version of the OS—or even for the wrong distro!

The proper GUI workflow, I think, would be for third-parties like Google to offer for download some sort of file representing _just_ an apt PGP-code- signing-identity + source list; and then double-clicking it would open it in Software Center or the like to do the GUI equivalent of apt-add-repository: asking you if you want to trust $ORG and follow the [http://org.example.com](http://org.example.com) apt repo. You'd say yes, and then `apt update` would get triggered, and new packages would appear (hopefully highlighted as such) in the Software Center list.

I'm kind of surprised things don't already work this way. I think it's because—other than Chrome—there's pretty much nothing _consumers_ want to install on Linux that isn't best installed from the distro's first-party package repo. For Debian/Ubuntu at least, I can't think of a single PPA or vendor apt host—other than Chrome's—that solves a consumer (rather than developer/administrator) use-case.

<comment><USER10> What you have described basically _is_ how you install Chrome and a lot of other commercially developed apps (e.g. MS Teams). At least it is in the RPM world and I thought it was for deb too.

You download the RPM and click it to 'execute' in your downloads. It opens in software Centre. That package sets up an extra repo and then installs the program you want from that repo.

<comment><USER11> and this is ine of the reasons linux is a dud as a desktop os. there is no 'malware' here. the guy went to the company's official site. downloaded their official installer. running that should now do the install and figure out whatever else it needs. like it does on windows.

yes, if you download and install malware that's bad. no one asked you to be the nanny -just di what you were asked.

<comment><USER12> You _can_ download the official installer and install it.

That's just not what happens by default when you click on it, because that's not how you get 99% of software on Linux. So if you're doing it that way it's either because you know what you're doing, in which case you know what to do with the .deb, or you don't know what you're doing, in which case you ought not to be installing random binaries from the web.

All you have to do on Ubuntu is right click on it and choose "Open With Other Application" and then choose "Software Install". But that friction is intentional. It makes you pause and ask why that software isn't in the package manager. And then whether you really need a browser with a proprietary license and closed source components instead of using Firefox or installing Chromium, which is in the package manager.

<comment><USER6> That doesn'work in latest Ubuntu. You have to use dpkg from terminal

<comment><USER12> I just tried it in Ubuntu 20.04 and it worked. Software Install can open a .deb, it's just not associated with them by default to keep novices from shooting themselves in the foot.

<comment><USER6> When I tried a couple weeks ago it didn't.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> Debian has supported this for a while using a thing called "win32-loader":

[https://deb.debian.org/debian/tools/win32-loader/stable/win3...](https://deb.debian.org/debian/tools/win32-loader/stable/win32-loader.txt) (txt)

[https://deb.debian.org/debian/tools/win32-loader/stable/win3...](https://deb.debian.org/debian/tools/win32-loader/stable/win32-loader.exe) (exe)

<comment><USER14> It's been around since 13 years at least. I remember a website [1] that offered such installer.

[1] [https://web.archive.org/web/20160523181321/http://goodbye- mi...](https://web.archive.org/web/20160523181321/http://goodbye- microsoft.com/)

</comment></comment><comment><USER15> Win32-loader [https://salsa.debian.org/installer- team/win32-loader](https://salsa.debian.org/installer-team/win32-loader) can do this from Windows 9x up to Windows 7 and possibly later. The author of this may want to work with that project, which is well maintained as part of Debian. It might be a lifesaver for devices that can't read external USB at boot.

</comment><comment><USER16> In a similar vein, wubi-uefi[0] is a fork of the original Wubi project, made to be compatible with newer versions of Ubuntu-based distros and newer versions of Windows. Upside is that it uses the built in Windows bootloader, so you don't have to rebuild it if you want to get rid of Linux. It's incompatible with Bitlocker though.

[0]: [https://github.com/hakuna-m/wubiuefi](https://github.com/hakuna-m/wubiuefi)

<comment><USER17> I remember loopback mounting always gave errors on shutdown when the file system was being unmounted. It seemed to me that it would unmount before caches were flushed, resulting in a need for fsck later (and possibly resulting in corruption or data loss). Do you know if there's been any attempt to address issues like these?

</comment></comment><comment><USER18> Has anyone tried it? I see the repo owner created an issue for success stories from users but it's empty.

If it works, it's very awesome!

</comment><comment><USER19> The scariest Linux installation I'd ever done was by creating a Vitual Disk for an existing partition (you can map a disk to a virtual disk) on VirtualBox as a VMDK file, then mounting that as the root partition for a VM that booted from an SamuraiLinux ISO and installed it on the root partition. Very surprisingly, it worked without breaking anything.

[0]: [https://askubuntu.com/a/47122/11736](https://askubuntu.com/a/47122/11736)

<comment><USER17> Fun fact: you can do that for Windows too. It also works fine... assuming you can even boot it. :-) You need to make sure Windows is booting from something it sees as _disk_ rather than a _partition_ (i.e. include an MBR or something before it). The main caveat is preventing the host from mounting the volume, otherwise the guest can't write to it. But I've managed to do this (yes it's painful) and it's great.

Pro tip: You can even make an immutable disk representing your _entire disk_ and then boot the _very same OS_ that is running VirtualBox from it. It's an awesome way to test changes you want to make to your system that you're unsure about.

<comment><USER20> Windows can also boot from a VHDX directly, which is pretty nice. (having a VM both as a VM and a boot option)

<comment><USER17> Yeah, though one issue with that is that expanding or shrinking it is so much more painful.

</comment></comment></comment></comment><comment><USER21> This reminds me of a "Remote Install Party" I did some Debian versions ago. Basically the same, but on a computer in another contry: [https://w4eg.de/code/rip/](https://w4eg.de/code/rip/)

</comment><comment><USER22> A tangentially related, but cool AF project [1].

[1] [https://en.wikipedia.org/wiki/Blue_Pill_%28software%29](https://en.wikipedia.org/wiki/Blue_Pill_%28software%29)

</comment><comment><USER23> So, there are no success stories so far?

[https://github.com/mikeslattery/tunic/issues/12](https://github.com/mikeslattery/tunic/issues/12)

</comment><comment><USER24> Awesome, thank you. I am always looking for methods with the least friction to win people over to using Linux.

</comment><comment><USER25> Wow, has anyone tried it? I really want it to work as expected. This could really help adoption.

</comment><comment><USER26> This may become legendary.

</comment><comment><USER27> Procedural UI written in PowerShell!

</comment><comment><USER28> This reminds me of the old depenguinator.

[http://www.daemonology.net/depenguinator/](http://www.daemonology.net/depenguinator/)

<comment><USER29> Nice! Reminds me of when people used to call scraping Windows off a computer "defenestrating" it.</comment></comment>


Michael Moritz: SV firms will lose out to China because of employee expectations - <AUTHOR> http://www.businessinsider.com/sequoia-partner-michael-moritz-paternity-leave-unhinged-2018-1 <comment><USER2> Duplicate of [https://news.ycombinator.com/item?id=16186461](https://news.ycombinator.com/item?id=16186461)

</comment><comment><AUTHOR> Original title was too long: "An influential Silicon Valley investor said that talking about paternity leave is a sign that society is becoming 'unhinged'"</comment>


Ubuntu to consider replacing Firefox with Chromium - <AUTHOR> http://www.phoronix.com/scan.php?page=news_item&px=MTM3Mjk

<comment><USER2> Canonical seems to distance itself from anything that looks like GPL and similar licences, it would not surprise me if in a few years they want to change Ubuntu into a propritary OS.

</comment><comment><USER3> Last time I checked there wasn't any NoScript equivalent for Chromium and by design there can't be.</comment>


PatentGate — Apple responded,  resolved amicably - <AUTHOR> http://www.futuretap.com/blog/patentgate-apple-responded/

<comment><USER2> A tip for crazy people on the Internet: If the worst you can say about something is that it "ignited a true blogosphere frenzy" it probably doesn't deserve the "Gate" suffix.

<comment><USER3> Honestly, I wish we could enact a moratorium on using the -gate suffix. Things that'd warrant it would be rare enough that we could make exceptions as they arose.

Also, I'd like a pony. And free money.

<comment><USER4> Is this the beginning of pony-moneygate? or has it been going on for a long time?

</comment></comment></comment><comment><USER5> If they had contacted their patent lawyer earlier than they had, they might have avoided jumping the gun with their first blog post and their only blog post might have been explaining why the twittersphere and blogosphere were overreacting.

</comment><comment><USER6> Hmmm, wonder if Bruce Sewell, apples new counsel, who left Intel is attempting to claim he resolved the REAL PATENTGATE. Whose trying to steal my moniker of Patentgate otherwise. Right prior to Sewell's jumping from Intel, Sewell was notified of his involvement in the REAL PATENTGATE unfolding for a Trillion Dollar Heist of Intellectual Property from Iviewit Technologies and me, inventor, Eliot Bernstein. See [http://www.brucesewell.com/2010/03/eliot- bernstein-of-iviewi...](http://www.brucesewell.com/2010/03/eliot-bernstein-of- iviewit-technologies_16.html)

and

SEC Complaint @

<https://docs.google.com/View?id=dgvpzjzw_9ghxg4km9>

Apple too owes massive royalties to the iviewit inventors.

Eliot I. Bernstein Inventor Iviewit Holdings, Inc. – DL Iviewit Holdings, Inc. – DL (yes, two identically named) Iviewit Holdings, Inc. – FL Iviewit Technologies, Inc. – DL Uviewit Holdings, Inc. - DL Uview.com, Inc. – DL Iviewit.com, Inc. – FL Iviewit.com, Inc. – DL I.C., Inc. – FL Iviewit.com LLC – DL Iviewit LLC – DL Iviewit Corporation – FL Iviewit, Inc. – FL Iviewit, Inc. – DL Iviewit Corporation 2753 N.W. 34th St. Boca Raton, Florida 33434-3459 (561) 245.8588 (o) (561) 886.7628 (c) (561) 245-8644 (f) firstname.lastname@example.com <http://www.iviewit.tv> <http://iviewit.tv/wordpress> <http://iviewit.tv/wordpresseliot>

Other Websites I like: <http://www.deniedpatent.com> <http://exposecorruptcourts.blogspot.com> <http://www.judgewatch.org/index.html> <http://www.enddiscriminationnow.com> <http://www.corruptcourts.org> <http://www.changecourtsnow.com> <http://www.makeourofficialsaccountable.com> <http://www.parentadvocates.org> <http://www.newyorkcourtcorruption.blogspot.com> <http://cuomotarp.blogspot.com> <http://www.disbarthefloridabar.com> <http://www.VoteForGreg.us> Greg Fischer <http://www.liberty- candidates.org/greg-fischer/> <http://www.facebook.com/pages/Vote-For- Greg/111952178833067> <http://www.killallthelawyers.ws/law> (The Shakespearean Solution)

</comment><comment><USER7> This is the story of the non-story.

I'm not sure whether to flag, laugh, or cry.

<comment><AUTHOR> It is but since the first part of the story was submitted n-times over (including comments proclaiming Apple turning evil because of the patent) I thought is was only appropriate to submit the conclusion, too.

<comment><USER7> You're right -- and that's why I didn't flag.

I really wish somebody could manage to write an article that explains to folks how to read patents. I know it's boring, and we definitely need some kind of reform, but the ignorance and misinformation out there is incredible.</comment></comment></comment>