feedjoelpie

Ha, so mere days after I told you it's stable I had to ship a fix to make sure that it was serving precompiled assets when they are available. We had never noticed because our server-side assets had never gotten large enough to go over Heroku's 60-second boot time limit. So anyway, if you're trying this out, please upgrade execjs-rails now. We cut our app's production boot time by roughly 80% by doing so.

Very, actually. It's about time I add more tests, maybe remove its opinion about what view context to dump to JavaScript (leave that to the end dev), and version it as 1.0. I think it's had one significant bug in almost a year and no problem issues in the past 6 months.

I have it figured out. A long-winded explanation:

Honestly I hate the react-rails gem. Whoever was maintaining it kept doing things at the whims of issue requestors. I remember one instance where they broke our apps with an upgrade because someone decided it would be a good idea to shim a definition for `window` into server prerenders. All because an issue creator who didn't really know what they were doing supposedly "needed" that to get browserify-rails working.

So we made this: https://github.com/revelrylabs/execjs-rails. That handles the server-side rendering for us. We only use react-rails for its assets, never for its helpers.

And here's our own (always-evolving) layer on top of execjs-rails: http://toolkit.revelry.co/pages/core.

Examples are written in dusty JavaScript, but we've successfully used revelry_core with sprockets-es6 several times now.

EDIT: Still no modules yet. It doesn't help that Josh Peek deleted the old sprockets-es6 repo and all its issues before passing off maintenance to someone else.)

I sort of agree with both of you. Yes, you can do it in a small shop, and my company does. A lot, actually. But I wouldn't say we exactly allocate time to innovation. It's more about taking a long view and integrating the long view mentality into projects with tight deadlines and immediate needs.

It takes a lot of work, and it feels quite different than the luxury of overt R&D and an emphasis on creating tools. We still mostly have to keep the development of tools to an as-needed basis and just take those opportunities to put an eye on the future. It's a delicate balance.

So to me the GP is not wrong when saying that these companies like Facebook have a serious luxury. That's the luxury to repeatedly experiment and fail with little relative consequence to the business. The rest of us can't afford to spend nearly as much time or make nearly as many mistakes.

Postgres provides really nice features for non-relational data these days, though. JSON columns are nice. Hstore is fantastic. And you can even do pubsub. All without introducing another database system into your stack. Is it perfect for all software? I'm sure not. But 99% of everything I ever need can be had with Postgres + Elasticsearch.

Much of this is no longer true because, as I understand it, it didn't really scale.

PHP has a huge developer base, and Hack is wonderful. The OSS ecosystem for it hasn't really developed in a significant way. So I'm not nearly as optimistic as you are that Swift will do better.

I am 100% serious, by the way. People have the most ridiculous ideas about why things failed and how it will totally work next time. If they just follow these ego-comforting steps that don't even begin to address the problem.

My top at-a-glance eye-roller says "technical co-founder quit & pulled the code out from under me".

So completely neglectful of basic business structuring that the tech co-founder could just walk away with the code, to which you don't have copyright claim? If a non-technical co-founder can't even bring responsible management to the table, why are they at the table?

Article goes on to suggest that if the non-technical co-founder had learned to code so as to not feel so helpless, things would have gone better. Just wow.

Easy. Just build more unsuccessful businesses.

Can we vote on which ones accurately assess their failings and which ones still harbor serious delusions about them?

Chrome is doing nothing with my right clicks. I'm doing two-finger click on a Mac trackpad in case that matters in your debugging process.

I guess the point I'm getting at is that the virtual DOM's speed is really just the answer to the question "But isn't re-rendering the whole world over and over really slow?" Which is the first thing anyone deeply familiar with web UIs would ask.

It's the solution to a problem that arises when you move to this programming model. It's the programming model that's the real advantage. The virtual DOM's speed is worth mentioning because it remedies what would otherwise make React completely impractical in the real world.

> Blog posts are somewhat meaningless, arguing specific nuances back and forth.

I disagree. Your "Bloop" blog post about React with its game loop analogy totally opened my eyes. That's the first time I really "got it". Moved my org to React for all new development and haven't looked back. So thank you for your "somewhat meaningless" blog post!

React.js is actually just really pleasant to work in and easy to reason about, and the virtual DOM is what makes that all possible without it becoming unacceptably slow. DOM diffing isn't there to make React faster than everything else ever imagined. It's there to let you stop thinking about the DOM and focus on the world state of your frontend instead.

I wasn't truly interested in React until I read this, which does a better job of spelling out React's real advantages than I ever could: http://jlongster.com/Removing-User-Interface-Complexity,-or-...

Here's a choice quote:

"Rerendering everything (and only applying it to the DOM when something actually changed) vastly simplifies the architecture of our app. Observables+DOM elements is a leaky abstraction, and as a user I shouldn't need an intimate knowledge of how the UI is kept in sync with my data. This architecture opens up lots of various ways to optimize the rendering, but it's all completely transparent to the user."

I haven't run into this on the interviewee end, but my company has applicants work on real projects, and here's how we deal with it:

Pay them.

OH COME ON, IT WAS A JOKE, MODS.

me too

... :)

Never explain anything to recruiters.

But they're still not going to let you skimp on the calculus classes. I do think 4-year degree programs should offer people more opportunities for the practical aspects. These don't really have to necessarily be part of the curriculum either.

I did two summers in the College of Wooster's Applied Mathematics Research Experience (AMRE) program, where they paid us a small stipend and provided on-campus housing for the summer. It was run as a little faculty-advised math/comp-sci/econ consultancy to help local businesses, and it was possibly the most valuable thing I got out of college.

All without having to skimp on actual computer science and math in the curriculum. These things are supplemental, not exclusive. And of course not everyone needs to go do a full 4-year degree if they just want to get out and make software.

But those people shouldn't be in 4-year computer science degree programs. And we should stop talking about this issue as if it's computer science that needs to change. It's about making people understand their options and what they will and will not get from each. For most quality CS programs, you have to pursue the practical outside the curriculum. For a code school, you might have to do some self-exploration about common problems encountered in computer science.

Everyone needs to find their own correct balance for their personal abilities and goals.

I really don't think so. You might just be underestimating the number of static asset files in a client-heavy web app before concat/minify ever happens. Watching the logs, you could see... each... little... file... take... way too long.

You're using Docker Compose on Mac? I tried when it was still called Fig, and while it was wonderful for simplicity, the filesystem performance for VirtualBox/boot2docker made it brutal to use. My Rails apps in development mode (therefore serving up many individual assets) would take almost a minute to load each page.

Has it gotten better, is there a trick you're using, or am I hitting an edge case you don't have?

Getting paid to write code before you've taken CS 101 seems far preferable to taking out piles of student debt, does it not?

Let's say you were trying to rationalize why a company's "extreme growth hacking coupled with a psychological approach to user acquisition" was actually good for the world. It's usually not that hard if you want it. Company X provides something that is (arguably) important (to someone), and the marketing means help it reach people.

So I tried to put on this hat for a minute, but I cannot for the life of me even intentionally come up with a justification for BuzzFeed.

Even if you believe whole-heartedly in general that the end (company getting its service out there) justifies the means (marketing, manipulation)... with BuzzFeed the end and the means are exactly the same thing.

It's got all of the societal value of the Jerry Springer show: It's garbage for the sake of providing space to sell garbage.

I've noticed our employees who often work from home seem to work more hours in the end. For better or for worse. On the one hand, yay for me. On the other, I imagine it has serious implications for work/life balance when that dividing line isn't there.

I don't know how much this would change, but I keep reading about having teams of volunteers "capture and remove" pythons. Which I just don't understand. It's an invasive species. We outright kill almost every other invasive species. We cull overpopulated native species. Surely it's far more time-consuming to capture and remove vs. kill the pythons.

If the problem is so serious, why isn't it being attacked the same way as any other invasive species problem?

The only thing that would make me interested in yet another flux lib is that it had more useful, complete things built on top of it that are better than the useful, complete things built on something else.

I guess I'm saying that at this point I don't really care about the API of your flux lib. I just want an ecosystem where I don't have to reinvent several wheels to get back to the convenience tools I currently enjoy without flux. First project to give me that and a thriving community around it wins.

>Android using the Linux kernel doesn't make it a Linux distro any more than...

Um, actually that's exactly what makes it a Linux distro. That's the one defining feature of a Linux distro.

It's more like a cultural curiosity. It's an attempt to get a full GNU system on top of a microkernel. Except they've never gotten a particularly complete system working with any acceptable level of performance on any of many microkernels attempted.

It was already a punchline when I started trying to play with it in college circa 2004 or so.

Ah, my mistake. I didn't realize the distinction there. Makes more sense now.