bmpafa

I don't run any OSS projects myself, but I can't imagine anyone would fault you if you called-out people who demonstrate the behavior you're describing. If not a direct response to their rudeness, maybe a request that they comply with some basic guidelines when posting issue (guidelines you'd of course have to post).

I think this gets you unquestionable justification for declining to respond to rude questions, but it also serves as declaring norms for people who may just be ignorant to OSS norms (or even regular social norms).

This is incorrect on several points. Scaphold supports relay and Apollo out of the box and integrates with auth0 (per their docs; I've used neither feature).

Subjectively, having played with both, I chose scaphold (over graph.cool and reindex) for a few reasons:

- pricing model makes a lot more sense to me. Graph.cool tiers their pricing on user counts, which makes very little sense to me for a product the cost drivers of which are storage and throughput. They also apparently count a user once they register, with no clear way of handling inactive users (can't be good for your LTV calcs). Reindex was also suboptimal imo, with steep jumps from free tier to paid. They also charge based on 'operations,' which, while less so, also seems strangely divorced from what I imagine their cost drivers are. Scaphold seems to have taken firebase's pricing model, which was a smart move

- storage. Graph.cool has really low storage per tier. Reindex bills storage separately from 'operations' and only charges in $50 5GB chunks (5.1 GB last month? Sorry!). Scaphold again copies firebase's pricing with small, inexpensive increments.

- ui. I didn't use graph.cool's ui too much, but I'm very happy with scaphold's. Afaik reminded didn't have any ui to speak of--someone correct me here if I'm wrong. You can build your entire schema in scaphold's ui (with very helpful tool tips most of the time) , manage integrations (which, generally, just make certain queries/mutations available), and view some pretty thorough analytics on your app. Coming from firebase, which has been really neglecting web app users in favor of mobile lately (imo), this was really nice.

Lastly, I'm new to graphql, but as I understand it, scaphold has added some nice features on top of the API. It seems to mirror PostgraphQL (a postgres <-> graphql utility), and adds pretty robust support for relationships (1:1,1:many,many:many). My schema is highly relational and, so far, it's a breeze.

I will note that graph.cool seems to have much more newbie-friendly docs, and maybe more comprehensive docs over all. Scaphold's docs are okay: they're wider than they are deep (maybe a paragraph for every feature w/ an uncommented snippet), there are some obvious mistakes, and some parts of the docs are scattered between the docs page and the UI's tool tips. When I had problems, though, their team got back to me w/in minutes (on email and slack).

To be clear, I'm not affiliated w/ any company discussed here--I'm just a user shopping for a firebase replacement.

That said, if you're considering the product, here's a ref link--$10 for you & $25 for me https://scaphold.io/referral?ref=99XXP3

Perfect--now I can bone-up on Russian in time for the inauguration.

> just choosing electron won't make your users happier.

Ah thanks, I lost some clarity in a post-write edit. My point wasn't that choosing electron would do that, it was that we should look more at end-user satisfaction and less at often pedantic technical analyses of solutions.

Re: C++: You may be right, but we can't deny that popularity and cool factor has a significant effect on hard metrics--eg, more frameworks, more libs, more components == faster dev speed & iterations, which I think is a good thing. ex: Mac hasn't been "better for graphics" in over a decade, but the 'cool factor' has made it the de facto choice for designers, which has resulted in a bulk of the latest designer tools being Mac only (a problem which, coincidentally, electron & its ilk aim to solve).

Last: no, it wasn't a joke. I know what the article said. My point was that the point of socioeconomic accessibility was mentioned, as you note, in the last line, but for the most part, the supporting data were more asserted as intrinsically bad. If it was a key argument of the author's, I think the data would've been tied coherently to the conclusion instead of requiring a diligent reader such as yourself to farm & cobble them together into a patchwork argument.

So, if you'll forgive me for borrowing a little of your snark: next time you google a word, for instance, 'skirt', you should probably prefer the first definition ("go around, past the edge of") instead of the fourth definition, as you've done here.

To be clear, my thesis is, in tl;dr form: "Anything that makes reaching users in the environments they prefer easier is probably good, but the extent to which this trades off with accessibility is unclear to me."

This article, like many similar to it, makes the (imo flawed) assumption that a dev tool ought to be evaluated on only a few variables--e.g., code quality, performance, package size.

If writing software is about making users' lives easier, happier, or better, though, I think we ought to optimize for that and that alone.

I say let the market and communities of users decide which software they want to use. I use Nylas b/c I like the UX better than Ubuntu's Evolution, despite its flaws. I use Caret (electron markdown editor) because I wanted a cross-platform tool and I have > 4 gigs of ram. Hell, millions still use the Facebook Android app, despite the fact that it sucks down battery juice like your crazy uncle sucks down Miller Genuine Drafts before lecturing you on how terrible millennials are (happy Thanksgiving, btw).

Of course, it's important we know the trade-offs of the decisions we make, so we need critical pieces like this. But to be as prescriptive as this article is to miss the forest for the trees. Love it or not, JS is a point of entry for a hell of a lot more ppl than C++ is, so expanding its reach into new arenas is not only net-good, but I'd argue also inevitable.

That said, the article does skirt an issue I've thought about a little, and I'm interested to hear others' takes. If software collectively moves more towards higher-end systems, e.g., with SPAs and electron apps and all their cpu-intensive renders, are we further limiting a great web UX to those with the money to afford the latest laptops? We spend a lot of time thinking about accessibility standards for our products (A11Y, etc.), but when should we begin to think about accessibility from a socioeconomic perspective? Or are performant computers now so accessible that we needn't worry?

Scaphold, along with Reindex, are pretty interesting. Don't know a lot about graphql, but it looks like they're both positioning to be firebase competitors. Both would have the distinct advantage (for the user, disadvantage for them) of using regular graphql queries in an app, meaning a project could easily migrate from one graphQL backend to another (whereas Firebase would require significant refactoring).

I use firebase daily for my project. Love these new features in theory, but a little bummed haven't seen analytics or remote config make its way to the web SDK yet (all my projects are webapps).

Framing analytics as the 'heart of firebase' makes me a little worried about the future of firebase for web projects. Is firebase moving away from webapps?

If you use Firefox, that bug won't affect you. But yeah, huge pain, and was difficult to troubleshoot.

I've been building a startup for the last six months or so, and a big part of our research is understanding agents (US only, so far).

I'm not sure if the copy on your landing page reflects your overall marketing strategy, but in my experience, most agents are less interested in products that solve pain points (eg, complex website setup processes), and more interested in products that give them an edge, highlight their personal brand, etc. I've learned a lot about this topic from reading industry news, like 'Inman Select'

Of course I don't mean to suggest that a traction problem can be solved solely with adjustments to copy, but branding, etc, is the lingua franca of the agent community, so even slight miscalibrations could significantly affect adoption.

As to the open sourcing, I personally wouldn't, at least not in a fashion that requires lots of your effort to upkeep. The market is so competitive, I have trouble imagining adoption of an open source kit would be wide enough to justify your effort /sacrificing your IP.

What about other distribution channels? There are a number of sites that act as realtor back-end DBs/CMS. Is it feasible to partner with one of those and serve as the official Wysiwyg of such-and-such MLS/Database?

Would love to learn more about your experiences here, btw, if you're up for a chat--brandon@wayhome.io. It's a difficult and fickle market to serve, so I empathize.

A Windows pc for a Mac price? What's not to like.

Lenovo t4 line for durability, Asus zenbook for power: price

If you get a lappy with a 1080 screen (no higher), you may be surprised how well osx runs in VMware. Higher dpi than that and the ui is too small, though.

And if you're adventurous, you could always convert a pc into a hackintosh. It's usually just fiddling with some drivers and swapping out a WiFi card.

Sierra works alright in VMware, even w/ design apps.

The showstopper for most is that you can't really use anything > a 1080p monitor w/o squinting, b/c of some peculiarity with macOS ui scaling.

Sceen2gif is the best tool I've used for gifts screencasts, hands down. Wish there was a Linux version.

http://screentogif.codeplex.com

If you keep bread in the fridge, it'll keep for quite awhile & be available to eat (unlike freezing it).

I used to live in a country with giant, mean roaches, so I got in the habit of refrigerating everything. Surprised it's not more common to do so w/ bread.