sgdesign

One thing I still don’t quite understand is how a system like this one can develop when the people developing it almost certainly are completely opposed to these ideas on a personal political level.

I almost feel like it was an excess of idealism and belief in “the free market of ideas” -as well as the idea that Facebook should remain a neutral party at all cost- that led to overcompensating in the wrong direction, and the current situation.

I’m also in Japan and finding the right materials can be really tough when you’re mainly learning from US-based makers and woodworkers. The fact that space is also very limited here (no garages or lawns...) also doesn’t help with DIY stuff!

> We believe that most bad things in the world are the product of some form of information failure. From economic collapse and the outbreak of war and disease, to choosing the right life partner or university degree, we’re on a mission to help everybody make the right decisions and overcome information failure

I'm not commenting on the merits of the product itself, but this is exactly the kind of arrogant "make the world a better place" attitude tech could use less of these days.

When you look at how many bad decisions have been taken these past few years despite plenty of access to good information, this sentiment seems pretty out of touch…

Don't worry I added it later on to clarify.

Thanks! Let me know what you think!

(Survey author) yes, it seems like I made a mistake with the different level descriptions. For me knowing how to do things like transitions and animations is comparatively "simpler" than being able to architecture an entire CSS front-end including managing a design systems, naming, specificity, etc. but I guess many respondents didn't see things that way.

(Survey author) The Netherlands doesn't have a large population, so it's never going to show up as a large part of the results. For next time it would be interesting to also let you toggle a relative view of participation vs population though.

Survey author here, it's all the more ironic considering all these 21k responses were collected through a Meteor app ;)

I'm not sure if this really warrants a reply, but I did want to correct the record. Even if you think Meteor "crashed and burned", it was definitely not a flash in the pan. It was launched in 2012 and seven years later there's still a small but active community. Many successful companies have used Meteor at some point, and many still do.

I think that the fact you think it was a "framework du jour" just highlights how much potential –and yes, hype– it had in its heyday. It may not quite have lived up to that hype, but it certainly accomplished more than the vast majority of web frameworks.

All I can say is that I'm glad I don't have a bunch of "orthocode" t-shirts…

Discover Meteor was promoted by MDG because they thought it was a good resource, but it was never part of MDG itself, it was wholly independent even if one of the authors did go on to work for MDG afterwards.

Source: I wrote that book.

I'm not sure what you're talking about, Meteor never sold any PDFs?

It's still small but a "Rails for JavaScript" is exactly what we're trying to build with Vulcan.js: http://vulcanjs.org

Built with Meteor, React, and GraphQL.

This reminds me of the old cliché about advertising. 95% of advertising doesn't work, but the problem is knowing which 95%…

Similarly, even granting the author's point that most UI redesigns are misguided, the fact remains that we do want the products we use to somehow improve over time…

Not really surprised. And I think Meteor got in trouble precisely because it appealed mostly to small teams, so that doesn't seem to be a viable business model.

Next time I think we'll just drop the ES* item altogether and instead ask developers which JS language features they use directly.

In previous surveys we had both Angularjs and Angular, but starting this year we stopped making the distinction. So yes, the "bad" stats include both versions. It's not perfect but we thought it was best to just bite the bullet and combine both going forward.

Thanks, I'll fix that. Regarding Haxe, sadly it didn't get many mentions this year so we probably won't include it as an "official" answer next year. Maybe in 2020 though!

Oh I didn't even see that, thanks for the feedback!

Co-author of the survey here, thanks for posting! Happy to answer any questions :)

(As long as the question is not something along the lines of "My favorite library Foo.js is doing pretty poorly in your survey, surely there must be an issue with your methodology?")

I don't really suffer from back pain myself but in case this helps other, I think the Foundation Training exercises are pretty good: https://www.youtube.com/watch?v=4BOTvaRaDjI

Survey author here. We didn't have the time to correlate device/browser/etc. to other data points last year but we did use the location:

https://2017.stateofjs.com/2017/front-end/worldwide/

Also I'm curious what kind of nefarious "bullshit" you think one can do with browser statistics. Market special weight loss pills uniquely targeted to Safari users?

In order for GraphQL to return a result when you ask for field “foo”, you need to define a resolver function for that field. Whatever that function returns will be returned to the client.

Inside that function you can write any code you’d like, including permissions code.

If you're looking for a full-stack approach, you could check out the Meteor/React/GraphQL framework I've been developing: http://vulcanjs.org/

So would you be happier if only the $39 price point was available, without any of the extra chapters? Then you wouldn't have the other price point to make you feel like you're missing out on something?

If you need more people to talk to you can also join our Hacker News Kansai Slack channel: https://hnkansai-slack.now.sh/

Lots of entrepreneurs and developers in there :)

This is awesome, congrats on the release! Also looking forward to playing with the new --minimal flag which effectively lets you create Meteor apps that have virtually no client-side footprint.

I was talking about this with a friend and he remarked that this could lead to some pretty opaque code where things behave differently from what you'd usually expect. While I think this is a cool feature, I think I agree with him that you probably want to think twice before using Proxies.

You could check out http://vulcanjs.org/, we're trying to get it to be a "Rails for GraphQL/React".

We're building VulcanJS (http://vulcanjs.org) on top of Meteor. I wouldn't say it's dead, just that it's evolving into more of an all-in-one development environment (think Next.js or create-react-app, but more powerful) as opposed to a full-fledged full-stack framework (say that 5 times really fast) like it was originally designed to be.