I’m Joining LinkedIn

And so we'd put another ad somewhere on the page to increase revenue, instead of decreasing the page load time down from 5-10 seconds with some truly trivial low-hanging fruit type adjustments (lazy-loading anything but the 'core' images, etc.). Or we'd do another redesign. Or add a widget somewhere.

What bothers me most is that these kinds of jobs were generally the highest paying and lowest in stress and 'friction' with the client. And I'd do them, telling myself that with the money I was 'saving up future time', all the while feeling incredibly depressed whenever I came home from work or had a moment to think about the current state of my life.

I always pitied the (shockingly high) number of employees in these companies, predominantly managers, who absolutely hated their jobs and constantly talked about 'one day I'll quit and do ' while never doing it because, well, the money and stability. Ever since I realized I was basically doing the vey same thing, I've been trying a little harder to find a balance between 'saving up'/stability and enjoying my day to day. And in my field that should be possible.

Many frameworks deeply affect how the code is written and have very specific boilerplate, custom templating and such. And some frameworks simply offer means of doing some things in an easier, usually specific, way with the relevant language.

In my experience it is also highly relevant how your thoughts on architecture match up to the framework's. I'd say you can happen to have a solid affinity for the way a framework is thought out. But in general, I'd agree, overnight is generally not sufficient for anything proper :)

I use the site but I'm deeply skeptical of the way their business tactics appear in my interactions with the site.

Edit: I would probably meet them for an interview to get a feeling for the company and team, but as a company they start on the minus side for me.

I've only worked on a few SPA's in the past years and every single one of them had some unique fundamental demands that led to some equally unique and fundamental differences in how the app was built.

Maybe I'm just not creative enough, but I find it difficult to come up with one Rails-size solution that would've been useful for all of these apps.

On the other hand, I remember when Rails took off, it seemed like an obvious batteries-included solution to a whole set of rather typical CRUD websites.

Few random thoughts of things that make SPA's less 'standardized' and perhaps, at this time, less likely to benefit from Rails-size frameworks:

- with SPA's you often have to work with the back-end that is provided to you. That's usually not an issue with Rails. - since the significant logic is now client-side (routing, etc), you have a large number of possible ways to synchronize server-side routing with client-side routing. - code size is an issue, so in some cases choosing a simpler solution for one part of the stack is necessary, plus for anything big you need to deal with code splitting and all that this entails. - performance is an issue so we can't just re-render the entire page. React and similar solutions have been one of the best improvements in this regard and take out a bunch of complexity (but add some of their own). With a non-SPA solution this is just not an issue. - browser compatibility is still an issue. With an SPA solution you need to consider all the same stuff as with a non-SPA framework, but now you also have to deal with things like javascript version support, event handling inconsistencies, local storage, animations, multiple forms of interaction (slide, drag&drop, etc.), loading indicators and potentially a whole bunch of async stuff.

But perhaps most fundamentally: in a 'typical' Rails setup, the basic form of interaction is basically url -> page. It's turning one string into a bigger string. But in a typical SPA, there are tons of different types of interactions that lead to tons of different results. Any interaction with the page can mean: change state, send or retrieve something to or from server, save something in a cookie, go to a different page, load a different piece of content without changing the route, load content and animate to it (so simply navigating to a different route is not enough), and that's just off the top of my head.

And you generally still need some kind of back-end on top of that with its own complexities and odd ways of interacting with your client-side code.

I've been writing native (or python) stuff for a long while, and I've come to rely on the assumptions the code makes being roughly constant (from the point of view of the language definition.)

My brain recoils at the idea of targeting a large number of different systems at once, like browsers and their versions, and then have the same code run on the huge set of future versions...

If your code behaves differently under a new GCC, it indicates a bug in your code. If your javascript behaves differently in the latest Chrome, that's just life.