> On Pop! (old thinkpad), typing gives me joy, and I live in the terminal / use vimium browser bindings / snap windows around. I prefer this machine for editing code / hacking.
Same. It's extremely satisfying for keyboard-centric workflow.
Snappier UI and more stability. Has what I need for web dev.
Starbucks wifi did not work out the box but summoning the correct incantation was easy enough. Never completely migrated over (music, photos, keychain) because of laziness. Miss using voice commands on one device and having it sync data with the rest of my devices (Apple TV, Mac, and iPhone). Ideally, I would replace all my devices so I could regain this functionality. Recently came back to Mac OS for work. After about a month, I'm finding myself using my System76 Lemur more and more.
Keyboard seems reliable. The keys are softer than those of an old Macbook, but have slightly more travel and resistance than those of a magic keyboard. The clickity clackity feel is satisfying.
Haven't thought of or used the touchpad much. Limited gestures, adequate size. I don't use it much.
Battery life feels comparable to that of the 2012-2015 Macbook Pros I've used. Can code, browse, and listen to music for maybe 4 hours a charge, and it recharges quickly.
Bootstrapped a fitness app (Bruiserfit - https://bruiserfit.com/) with a friend based on my own measurable high-intensity physical training workouts. We built the first version not really knowing what we were doing, slapped AdWords on it, but users never came. We couldn't get past the activation phase - the initial product wasn't intuitive and compelling people to workout is challenging. Over the past couple years we've iterated on the user experience to an adequate state, but we still lack retention. It seems like the format is still confusing for beginners and that most people simply don't want to train themselves to do tough, fast bodyweight workouts.
On the technical side, we used Rails 5 and followed the Thoughtbot playbook. But neither of us were very experienced in native development, which prevented us from offering many of the bells and whistles that other market offerings provide. If I had to do it all over again I would probably give it a shot with React + Firebase.
Like others have said here, democratically running an equally shared company with friends sounds better on paper than it is. Different personal beliefs and approaches often lead to deadlock. Communication is essential to avoiding resentment. It gets easier with practice, but there was still too much to juggle for us and not enough time, know-how, and motivation.
We still casually hack at the project on the side. My cofounder and his wife swear having the project on his resume landed him his current and very comfy gig. I'm still waiting to see if anything beyond the experience itself comes out of it for me.
To anyone wondering why they should care about Stimulus, I offer this TLDR, straight from DHH himself:
"Above all, it’s a toolkit for small teams who want to compete on fidelity and reach with much larger teams using more laborious, mainstream approaches."
Give it a whirl, I'm sure you'll find it delightful. But if you're looking for the next Big Thing™, I'm afraid you might be sorely disappointed.
Damn, they're actually a lot alike. The differences I see are subtle - Stimulus seems simpler in practice, scopes controllers, state stored in document, uses native APIs, etc. but there's definite overlap.
As a Turbolinks fan, I couldn't be more excited about Stimulus. Sounds like it completes the front-end development story with Rails-like simplicity minus requiring that you know Ruby and Rails.
I started off as a FE dev working on mostly Rails projects. Not knowing Ruby or Rails, I depended on others for updating controllers, debugging Rails errors, etc. I was also commonly frustrated when my teams treated the client as a second-class citizen for no apparent reason besides an aversion to JavaScript. JS' takeoff in the market was actually quite satisfying at first, but the more I worked with Angular, React & company, the more I missed the productivity of server-rendered JS responses, jQuery, and Turbolinks. I doubt Turbolinks + Stimulus wins prom king at JavaScript High next year, and I couldn't care less.
Also, Redux as "self-congratulatory" had me dead. XD
I'm a fan of Turbolinks too (started using it on its day 1 release), but nowdays you don't even need Rails to use it effectively. It integrates with any framework very easily.
For things like auth/signup/forgotten-password flow I'd agree I've been more productive with server-side frameworks than client-side, and the out-of-the-box solutions for those things from Rails/Django feel more solid.
Also basic blog and structured content 'pages' sites.
For building anything that requires complex client-side interaction, i.e. the sort of things that even warrant looking at React (e.g. a calendar app, or a music player app), then you're going to get yourself in a real mess attempting that with 'javascript sprinkles'.
> Also, Redux as "self-congratulatory" had me dead. XD
Also completely wrong if you've ever read/heard anything Dan Abramov has ever written/said [1].
Its something they've been developing internally at Basecamp. DHH sees Turbolinks handling "90%" of front end work related to full page changes. Stimulus (which I think he said they're releasing in another month) will handle on page interaction or as he calls it "Javascript sprinkles". Things like modifying existing elements, adding a new node to the DOM, filtering, etc.
I'm far from an authority to officially say, but this is what I gathered from listening to the podcast:
Stimulus essentially structures DOM manipulation. Whereas other frameworks aim to solve rendering, it seems Stimulus will offer a lo-fi and sane way of making your views dynamic. Restated, it's a framework for managing JS sprinkles aka jQuery spaghetti aka templating logic. I don't think its a component library because DHH explicitly mentioned its not a mechanism designed for handling JSON and similar concerns. It targets the realm of updating element classes and attributes, handling events, etc. It'll also allow you to partially update views with HTML templates sent over the wire.
When combined with Turbolinks, it should elegantly solve all your everyday front-end concerns. There's a lot of helpful context I'm neglecting - check out the podcast, DHH pretty much opens with this topic.
Maybe a typo? A search for 'ruby rails stimulus' brought me right back to the root comment. About to listen to the podcast. Will report back if I learn anything.
Same. It's extremely satisfying for keyboard-centric workflow.