I'm not sure what you've come up with, since your post was deleted, but I'm looking forward to it!
I also home brewed a system very similar to what I described at my previous job. With the current information out there, it looked almost the same as relay, except without GraphQL. We implemented our own query/synchronization mechanism.
Especially excited at the idea of a single store. I've always had a little bit of a beef with Flux when it came to interdependencies within stores.
I feel like one of the problems with react that is currently not well solved is the integration of a client and server side router for a truly isomorphic application. There have been quite a few implementations that rely on a single om-like state that they serialize and deserialize to the client. Relay feels like it would fit extremely well into this paradigm.
Shameless plug, the company I (just started) working at connects producers with consumers. We handle the logistics of getting the fantastic products from our producers to you.
If you are in the sf bay, nola, la, or nyc, check it out at http://goodeggs.com
Here is the SF egg section (we deliver to sf, east bay, and the peninsula)
I'm not trying to be negative in any way, because this is awesome. I really believe there are so many ways to interact with machines that we haven't figured out yet.
But ... can't you achieve this level of efficiency, maybe even better with a combination of auto completion and snippets?
With python and vim, I use jedi-vim[0] and neosnippet[1] for textmate compatible snippet completion.
It would be cool to see a video demonstrating this using the same snippet of code! If you decide to make one, let me know, and I'll link it on the Plover blog.
Bravo man, I tried to make the switch from vim to emacs evil and failed horribly. I would eventually throw emacs into a state where it wasn't in any of the evil modes, then bash my keyboard with C-X C-C. Is it possible to use emacs+evil without knowing emacs inside and out?
Emacs with evil, without a doubt, runs so much smoother while editing large projects. The biggest point is that asynchronous operations are a lot easier to perform in emacs. You can get close to it with plugins like vim-dispatch or vimproc, but they always felt like a second class solution to me.
You get cool stuff like search/replace preview and super smooth async operations in the background (like on the fly linting with flycheck).
In the end, I'm still using vim. Unite with vimproc is "good enough" for me. For me, the only real place where async operation is a huge problem is with file search operations. Every few months I try to use emacs for a day, maybe next time it will stick :)
>> I would eventually throw emacs into a state where
>> it wasn't in any of the evil modes, then
>> bash my keyboard with C-X C-C.
I think the snippet of code in linked article in section 'Escape . . . escapes things' fixes most of the situations where you'd get stuck in a non-Evil mode in Emacs. It's a must have for me, otherwise I too got frustrated with getting stuck in Emacs minibuffer/command line and <esc> not getting me back to Evil-mode in main buffer. I also turned off the bell in Emacs, which helped psychologically.
I think the main problem is that in vim everything works like a buffer. When I browse files or any sort of search results, I can use the standard vim key bindings to navigate through or even dismiss the window.
With emacs, it seems like I have to learn the system to even use some plugins like projectile effectively.
Next time this happens try running evil-emacs-state. (Its bound to C-z ...I think that is the default binding that the evil install setup)
EDIT: just realized I posted this without saying why to do this. This command will put you into evil-mode even if the major mode doesn't start off in it for some reason. I use it all the time to navigate and search the output from package-list-packages for example.
It is possible to use Emacs + evil without knowing Emacs inside-out, but you do need some basic Emacs knowledge. If you had to do C-x C-c when entering a non-evil mode, you did not have that basic knowledge :-)
The least you should do is the tutorial that's presented on the startup screen or "M-x help-with-tutorial".
The customer support goes up with the bill. You can't ask the same support for a 3e/month server and a 100e/month.
> Seemingly better network and infrastructure than hetzner too?
Yes. Ovh is one of the main Isp actor in Europe at the Wan level. Moreover Ovh is full ipv6 compliant, unlike hertzner, and bandwidth is totally free without quota.
Ah, and Ovh building itself their servers, they are the biggest PC manufacturer in EU. They don't even play on the same field.
It looks like the bits to import/export the fonts in a portable format (json) are already in place. You could literally run a git repo with the font files and serve it up to a web interface. That would be awesome :D
Have you tried react.js [1] ? If you use node to serve your content, you can pre-render the initial state of your app. When everything loads up, react will take a checksum of the rendered portions to ensure that it doesn't re-render the same DOM. This should come close to solving your SEO/test issues with minimal work.
In my opinion, a setup like this is close to what the next big wave of frameworks will use.
You can break your layout up into parts and have a site that is partially dynamic and partially static. You just pass the html that react renders to your templating engine.
Getting everything setup correctly can be a little hassle, but gulp is fast enough when doing a watch on the compilation step. Of course, because everything is javascript you share the exact same component code between client and server.
Haven't tried it, but I heard great things about it from bradfitz, who uses it on http://camlistore.org/ (and whose opinion definitely deserves respect). Is React an all-or-nothing thing, or can you sprinkle it in certain places on your site without needing to make the whole site in React?
> you can pre-render the initial state of your app
This, I think, is the killer feature of Node, and the reason I'm slowly transitioning from Python for new web projects. You can reuse your server-side templates client-side (without worrying about, say, reimplementing Handlebars Helpers in your server-side language), and can easily render full HTML templates for the client that get enhanced when the client-side JS loads. This also solves UI nuisances -- like your server's markdown renderer being different to your client-side preview (grr).
Meteor and Derby are obviously heading down this path, and while I'm not sold on the rest of Node and the general JS style, having the same language in the browser and the server is too much to pass up.
I also home brewed a system very similar to what I described at my previous job. With the current information out there, it looked almost the same as relay, except without GraphQL. We implemented our own query/synchronization mechanism.