agmcleod

For sure. I've found getting that to work with a rails stack & webpack setup to be rather challenging. react_rails is pretty straight forward, but then you have a lot of global react components, and it gets trickier to leverage NPM. With webpack there's react_on_rails which is a sizable & complex gem, but it does work.

While I wouldn't use vanilla rails & UJS much today, I still think it has value in getting things going.

I agree it's not the complete solution, but I think rails does a pretty good job at providing tools for making a progressive webapp. Many of us see the apps that have a blank page until data is loaded and the front end JS then renders. It's just a yuck experience. I dislike the fact that it happens in one of my own projects. While I find the concept of turbo links weird with pulling raw html over XHR and then rendering it, it does essentially just speed up a non-js capable website.

In time rails will need to replace this out, as the JS tooling keeps evolving, better solutions will arise.

I have the DK2, doesn't work with my glasses :(. Admittedly i didn't try with a CV unit I got to check out, but my brother did and it worked for him. Might just vary depending on frames.

I agree you're getting the most accessibility by making a blog that renders on the server. But rendering front ends with javascript shouldn't be considered breaking the web. It's a tool that's available in the browser, and many use it to try and make a better experience for their overall users. I think it's a shame we have the "first load no content" problem, but developers are doing this with good intentions. Making UIs respond faster, reducing back & forth network requests, and trying to make more interactive content on the web.

There are some warts we need to sort out and get better at, but I still see it as progress.

Nice! I did my own clone as well, just containing the 3 boards of todo inprogress & complete. Made it to learn react, and react native (for the mobile version). I mostly use trello now, as they've just managed to make a much stronger web client than I can. I still like my own mobile client better though.

Also the fact their app works completely offline for a while now is rather handy.

Interesting point. I find I can be pretty okay jumping onto a rails project, as I know a lot of the conventions. Where to look to see how things are connected. Admittedly, it's taken me sometime to learn how a multi architecture go project using thrift is setup :)

I agree with this quite a bit. Even in my own projects, I love using Rails for web stuff, but I would never use Ruby for games. It's a pain to distribute working binaries, and really is not an ideal language for games.

In 2012, I went camping in mt tremblant mid september with my brother and his friends. The night we got there it rained hard. Saturday during the day was okay, but that night got super cold, around -1 degrees celsius. Plus we could hear wolves howling across the lake. Not the best of nights sleep.

I do tend to get nervous of nature at night when I'm camping, but love my experiences during the day.

So yeah I completely understand what you mean :)

Ah interesting. I have to admit I thought the C++ dominance had been around for longer than that.

I find this a lot more encouraging to read. Most gamedevs I see talking about C++ mention to avoid boost & templating, how STL is bad, etc. How they have to write their own more efficient version of vectorm or their own allocator. There are things I like things about C. I find malloc & free fairly understandable, where as a lot of the newer pointer arithmetic in C++11 can be a bit overwhelming.

That said as someone who hasnt done a lot of C or C++, i'd like to think learning the new way is best, otherwise it's hard to know where to start.

I just also want to make the argument that github is a walled garden, so is google code. They're proprietary systems that we're able to use and take advantage of. I use github and I love it, but it can still have the same potential issues as slack.

whiteboarding helps me think. Such a click-baity title ;)

Was thinking the same. Even when ajax was getting big, i still recall using a lot of the same programs i did then. A text editor/ide, a browser, desktop games, ms word, etc.

Since it is code that just translates to javascript, it's nice because you can have onClick handlers and such right inline, without having the downsides of inline javascript. You build reusable components that are self contained with their content and their logic. So you know when you use a component, the logic comes with it. You don't miss out on important bindings.

Also i've never really gotten into all the string magic that angular templates use. ng-click="myEvent()", vs passing the event to the component as a property feels.

I've been using a homerbrew "Framework" or sleuth of classes & singletons with handle bar templates and jquery. It performs fine for a desktop app, i re-render things as it changes. But React & flux would be a way nicer way to go about organizing the code and building it. Plus all the stuff i'm re-rendering, the diffing react would give me would make that more performant.

I think though examples like this are good to show you shouldn't always use a framework.

Furthermore with mobile, i've used ES6 classes, handlebars for templates, jquery to drop the html in, and do event bindings. It runs decently well in a cordova app, but i do find somethings lag. I've done a bit with react in cordova as well and found similar problems. Getting a speedy mobile app built with html5 is hard. I really think for a proper experience native is the way to go. I've been liking react native for a side project of mine, but i'm starting to consider using Swift instead.

Comes down to preference. I still use sublime for opening really large files. But otherwise i stick with Atom. I've found when using linters, typescript compile checking and such Atom is just better. The notifications built in and such are great, where as the bottom bar for listing that kind of stuff in sublime feels archaic.

I completely agree. Trying out react and learning how to structure things with it. It all just felt natural.

I had been using reflux when trying out react native. This actually looks nicer than reflux, i think i'll check it out :)

Agreed. I'd love to have a living situation where a tesla or electric vehicle was realistic for me. They're just better pieces of engineering. But sadly due to renting an apartment, parking underground, and so forth, it's not a life style I can change to.

> I'm not even talking "nested-hell", i'm simply referring to the mental overhead that i apparently use when using any JavaScript function. It's not difficult.. it's just not enjoyable. It's.. tiresome for me.

Pretty much why i never got into node development.

I thought the APIs would still be different though. Maybe not. Either way, I think it's great for people who do use native to try new tools. But yeah I can accept that they will probably miss certain features.

I think these are fair concerns, but it also sounds like this person comes from a more iOS native development background. Why not stick with that? I like the idea of react native as i use react more and more in the browser, and I enjoy the workflow.

Man i'd love to do that. Explore game dev with different languages. Try and code a fresh web game engine purely using webgl. Naturally i get busy with other things :)

Fair enough.

Any idea if that would mean auto compilation for your own files in a project? Or is it more for plugins and such?

I didn't read it through & through, but i think the benefits of going to mars over venus is longevity. As the idea would be (provided we last long enough) that when the earth starts to swell, earth will get too hot to live on, and therefore so would venus. We'd still have time on mars before having to move further away.

Really? i find that odd considering they said it's not a cross platform tool really, you will still have to write platform specific apps. Just have a mostly one way to do it.

Ah thanks :)

> but the second was when V8 committed an incremental collector

Did the chrome developers have to fix v8 for that one?

I use MelonJS personally. Phaser is also pretty good, quite a bit bigger in size. That's for 2d. If you want to look at 3d, checkout three.js or babylonjs. I find three.js has a larger community, and is easier to find stuff on stack overflow. But i had issues with PhysiJS plugin performance on mobile. Babylon's physics works pretty well.