It's extremely nice! Coming from the React and Next.js world there is very little that I miss. I prefer to obsess over tests, business logic, scale and maintainability, but the price I pay is that I am no longer able to obsess over frontend micro-interactions.
Not the right platform for every product obviously, but I am starting to believe it is a very good choice for most.
I've abandoned Next.js and React for Elixir / Phoenix. I am able to build a perfectly pleasant user experience with just a sprinkle of vanilla JS via Phoenix hooks.
The fact that I have been able to build a multi-user collaborative editor experience without a single additional dependency is incredible. I previously worked for a well-established and well-funded React team who had this feature on their roadmap for half a decade but still find it too daunting to implement.
Phoenix was a great reminder that a lot of the "frontend engineering" we find ourselves doing as React developers just isn't necessary with the right backend. It's HORRIFIC to look back at all the yakshaving I've done in my career already. Wrangling types (GraphQL, codegen libraries), wrangling queries and data-fetching (react-query, SWR, server components), fiddling with middleware (serverless functions, getStaticProps, CDNs). I've seen teams outright abandon testing because the hours they invested just weren't catching any of the bugs that mattered.
I'm not doing any of that anymore. I'm spending that time refining the core data model, improving test coverage, thinking about go-to-market and making money.
Phoenix may not be a good choice if your product has reached that level of maturity and product-market fit where you really should care about "microinteractions", fine-tuned animations, or advanced use-cases for an SPA like offline support and highly-optimistic UI. But I would argue that even mature products don't truly need these things. Just look at the GitHub UI. I've spent a truly astronomical number of hours in that UI and never wished I had WYSIWYG text editing, or animated skeleton UIs, or the dozen other things that the React community tells us we need.
They're probably using some features of LiveView; I'm not too familiar with how HTMX works, but with LiveView you can define all of your logic and state handling on the _backend_, with page diffs pushed to the client over a websocket channel (all handled out of the box).
It comes with some tradeoffs compared to fully client-side state, but it's a really comfortable paradigm to program in, especially if you're not from a frontend background, and really clicks with the wider Elixir/Erlang problem solving approach.
Hooks let you do things like have your DOM update live, but then layer on some JS in response.
For example you could define a custom `<chart>` component, which is inserted into the DOM with `data-points=[...]`, and have a hook then 'hydrate' it with e.g. a D3 or VegaLite plot.
Since Phoenix/LiveView is handling the state, your JS needs only be concerned about that last-mile JS integration; no need to pair it with another virtual DOM / state management system.
The big win for me has been the built-in PubSub primitives plus LiveView. Since the backend is already maintaining a WebSocket connection with every client, it's trivial to push updates.
Here is an example. Imagine something like a multiplayer Google Forms editor that renders a list of drag-droppable cards. Below is a complete LiveView module that renders the cards, and subscribes to "card was deleted" and "cards were reordered" events.
```
defmodule MyApp.ProjectLive.Edit do
use MyApp, :live_view
import MyApp.Components.Editor.Card
def mount(%{"project_id" => id}, _session, socket) do
# Subscribe view to project events
Phoenix.PubSub.subscribe(MyApp.PubSub, "project:#{id}")
project = MyApp.Projects.get_project(id)
socket =
socket
|> assign(:project, project)
|> assign(:cards_drag_handle_class, "CARD_DRAG_HANDLE")
{:ok, socket}
end
def handle_info({:cards, :deleted, card_id}, socket) do
# handle project events matching signature: `{:cards, :deleted, payload}`
cards = Enum.reject(socket.assigns.project.cards, fn card -> card.id == card_id end)
project = %{socket.assigns.project | cards: cards}
socket = assign(socket, :project, project)
# LiveView will diff and re-render automatically
{:noreply, socket}
end
def handle_info({:cards, :reordered, card_change_list}, socket) do
# omitted for brevity, same concept as above
{:noreply, socket}
end
def render(assigns) do
~H"""
<div>
<h1>{@project.name}</h1>
<div
id="cards-drag-manager"
phx-hook="DragDropMulti"
data-handle-class-name={@cards_drag_handle_class}
data-drop-event-name="reorder_cards"
data-container-ids="cards-container"
/>
<div class="space-y-4" id="cards-container">
<.card
:for={card <- @project.cards}
card={card}
cards_drag_handle_class={@cards_drag_handle_class}
/>
</div>
</div>
"""
end
end
```
What would this take in a React SPA? Well of course there are tons of great tools out there, like Cloud Firestore, Supabase Realtime, etc. But my app is just a vanilla postgres + phoenix monolith! And it's so much easier to test. Again, just using the built-in testing libraries.
For rich drag-drop (with drop shadows, auto-scroll, etc.) I inlined DragulaJS[1] which is ~1000 lines of vanilla .js. As a React dev I might have been tempted to `npm install` something like `react-beautiful-dnd`, which is 6-10x larger, (and is, I just learned, now deprecated by the maintainers!!)
The important question is, what have I sacrificed? The primary tradeoff is that the 'read your own writes' experience can feel sluggish if you are used to optimistic UI via React setState(). This is a hard one to stomach as a react dev. But Phoenix comes with GitHub-style viewport loading bars which is enough user enough feedback to be passable.
p.s. guess what Supabase Realtime is using under the hood[2] ;-)
I’m a huge fan of Eurogames but I regret buying Wingspan, it is an absolute bore. After 5 or 6 games it became kindof a meme in my family. “What shall we do now? A round of bird game?”
Beautiful packaging and pieces though! And it’s very cool that it works single player and two player. But nothing eventful at all happens, and nobody feels any compelling reason to rack up points.
It's one of my favorite board games, probably for the same reason you hate it. What's the reason to play a board game? To give a bunch of people sitting around a table something to do while having a drink and a chat. Bird game is great for that; it's got stuff to talk about and to think about, but it doesn't swallow up the whole conversation like Pandemic would.
The compelling reason to rack up points, if you're playing seriously, is to see if your engine works --- just like Race For The Galaxy, or games like that.
I agree with on the basegame. It was fun the first few games, becomes kinda boring when you don't play with a large group as the bird cards don't change often.
The expansions changed the game completely for me, it's more strategic and you're interacting with other player more (i.e. in-between round activation, end of round powers, more steal resource from other players, etc).
I personally love that the game play is very fast, as you have limited number of moves every round.
The Oceania expansion with the nectar tokens and new board really let you do more in the game.
I would give it another try with the expansions, it's truly a different game.
Since I assume some Framework product people are in here— my framework won’t go to sleep which is an absolute dealbreaker. Dead battery every time unless I fully shut it down. Forums are no help. Advice?
I’d love to support your mission and recommend this laptop to others, but you need to get the fundamentals working!
See my comment history for other similar reports from other (former) Framework owners.
You might need to set your system to hibernate instead of sleep. Modern x86 laptops lack proper standby power states — they only have a low power "darkwake" state in which they're able to do things like periodically check email, and instantly "wake up" from. Microsoft bills this as "modern standby".
That's nice in concept, but it rarely if ever works as it's supposed to, especially under Linux. I had to set my Lenovo ThinkPad X1 Nano up so after being closed while unplugged for an hour or so it automatically hibernates, because otherwise it'll never properly sleep and Windows will drain its battery.
It's stupid but the only machines that reliably sleep these days are MacBooks.
I'm almost ready to sell my DIY Windows framework and go back to mac. It won't go to sleep-- fans always spin unless I shut down completely. Forums aren't any help. Anyone have this issue? Other commenters have similar complaints here https://news.ycombinator.com/item?id=31433556
I really wanted to support this company because I believe in repairability! But repairability is meaningless the software doesn't work... I'm not a 16 year old enthusiast anymore, I don't have the time or patience to troubleshoot drivers, firmware, devices etc. etc. :(
> I'm almost ready to sell my DIY Windows framework and go back to mac.
If you do so make sure to buy the longest extended warranty you can, covering the slightest tiny thing that can happen to your M1 Mac. Mine was a fine machine, zero bug, while the screen worked. These M1 Mac laptops have brittle porcelain screens. As someone put it here: it's the bend-gate all over again. FWIW I've got both a 2013 and a 2014 MacBook Air as well as a 4 years old (?) LG Gram laptop. They all have their screens still working fine and I'm pretty sure I know how to handle a laptop: these new M1 laptops are just fragile.
I suspected there would be a catch preventing me from buying a MacBook.
I damaged the screen in every laptop that I ever owned - either by creating pressure marks or - like in the most recent one - somehow stretching(either via temperature or flexing the surprisingly flimsy cover) the adhesive which kept all the LCD layers in place, creating a diagonal clouding pattern in the process.
My next laptop will be a framework because then at least I will be able to easily replace the screen once the inevitable happens.
After hearing about this issue I went to the Apple store and tried to intentionally crack the screens on the display units. Closed the lids on several units with items between the screen and keyboard. Flexed the screen in several directions. Nothing.
You need to do this several thousand times. Let's say you use your laptop 300 day a year and that you close the screen about 4 times a day. If the laptop is designed to withstand 2000 closes then your laptop will break after less than two years.
The reports were spontaneous cracks after only days or weeks. And the tolerances were blamed because small debris caught under the screen would allegedly put undue pressure on the screen.
As the context of this topic is Australia, this isn't necessary. Warranties don't add much value compared to consumer law, which the vendor must comply with in Australia.
Anything I've ever had a fault not caused by me with has been replaced free of charge years after I bought it, including from large American companies like Amazon and Apple.
I returned my 12th gen Framework and purchased an M1 Pro MBP. It was absolutely the right decision. I just wasn’t ready to accept the lower quality product for such a premium price as much as I wanted to support the company.
Same here, I ditched mac for Framework, tried Windows, nope, fans always on, Ubuntu, battery died when lid closed in < 2 hours and fingerprint scanner didn't work. Fedora, same issue. I sold it and bought an M1 Pro. Nothing wrong with it so far. OK it was 3 times the price, but you get what you pay for.
It's really... not. I've used MBPs for years (three generations of them) and they've literally (like, literally literally) Just Worked.
But I'm sure you'll find stats and horror stories that say otherwise, as if, somehow, Apple (or anyone) is capable of producing hardware and software that's impossible to break, never fails, and lasts forever.
I've been using Apple for a decade now and my experiences with the Apple Silicon machines reminded me of the Windows 95 -> Windows 2000 transition only with no way of actually getting things to work.
It does a lot of things right - especially sleep - however I'm constantly running into problems with buggy software which is unfixable because Apple don't do compatibility.
Also not having a battery which can be replaced or storage which can be user-upgraded is absolute garbage in 2022.
EDIT: if I was still a gamer I'd be laughing the MacBook out of the room.
> my experiences with the Apple Silicon machines ... however I'm constantly running into problems with buggy software which is unfixable because Apple don't do compatibility.
You're aware that the compatibility of any software (that's not Apple software) is the responsibility of the software vendor with regards to making it work on Silicon? Have I misunderstood you here? You can't actually expect Apple to just magically make code designed for one CPU architecture just work on another? There's kernel level translations you can do between opcodes, but that can't be expected to be perfect. The perfect solution is the vendor updates their software.
That's the attitude of Apple and the reason why you should never use Apple for anything mission-critical.
Microsoft on the other hand: Windows is literally full of work-arounds they added to ensure that new releases did not break existing software.
Apple at this point is FAR larger company than Microsoft was in the early 2000s. They're a goliath and should be more than capable of doing what Microsoft did.
I feel like then you are just not the target audience. I haven't had the need to replace storage or battery for a decade. In the early MBP it was nice to change the battery as they degraded quickly but now it just doesn't happen any more and even my old 2015 MBP is still working fine.
2014 MBP: worked well for a couple of years, then developed a fault where it randomly half comes out of sleep, then gets very hot, even when closed in a bag.
2018 MBP: randomly completely crashes, with no warning whatsoever, roughly once a day.
2022 m1 macbook pro here - and i have one from work too. never had either crash, haven't plugged this one in for literally days, and right now i have an ide, vscode, ableton, slack, chrome with like 400 tabs in multiple windows and it's cool to the touch.
Paying with ETH is the easy part— few lines of javascript using Ethers.js
The hard part is managing wallet connections, and then automating what happens after payment is complete.
For wallet connections I use web3modal.
For reconciling the purchase after payment, no clue. I use coingate for crypto checkouts for this reason. There are probably backend libraries out there to help you track and respond to transaction events on a given address. Let me know what you find!
I'm on my second team that's tried and failed to implement this (well, I consider the current setup a failure, the leads apparently don't?).
Extra work for no benefit, broken builds, type and lint ignores everywhere, demos always out of date or incomplete.
If your designers are skilled and organized, you don't need this. "But my team doesn't have skilled or organized designers!" ... well then you probably have bigger problems, messing with Storybook is the last thing you want.
I came late to the software and web development game. I just wanted to prototype a tool I needed and ended up becoming a full time developer.
After grasping HTML and CSS basics, prototyping my heavily interactive tool seemed impossible with JS alone, until I learned React. React solved real problems for me. Create-react-app with a firebase backend got me VERY far with zero formal education.
But I struggled with SEO, load times, and needed a sprinkle of server-side logic. Next.js solved those problems, and more.
As my prototypes grew into products, complexity was hard to manage. Refactors were impossible, even with small, modular components and well tested functions. Enter TypeScript. The single most important tool in my toolbelt. I refuse to work in plain JS now.
I'm several years in now, at my 2nd full-time dev gig and working on my 3rd side-business. My stack is Typescript, Next, vercel, firebase. Both at work and at home. Hardly any third-party dependencies needed beyond these (stripe, coingate, mapbox). I write most my CSS by hand with css grid because its the least verbose way I've found so far. I auto-format with Prettier.
I can use types and tests across my stack, I can enforce bespoke auth/permissions behavior, all kinds of queries, media upload, pretty much everything I'll ever need outside of real-time collaboration. I can build and maintain profitable products by myself. I've done it.
This also happens to be a very popular stack. What's insane about it? Every alternative I've looked at looks way less sane. Multiple languages and repos for one app? No thanks. Managing server instances and databases migrations myself? I hope I never have to. Software is fun, but I like making products more. JavaScript just happens to be the best way I've found so far.
It's very reasonable for someone new. It's batshit insane for anyone who's been in the industry for about 20 years. But that doesn't matter. The only thing that does matter is finding tech that you're productive with, and you've found it, so everyone else's input is pretty moot. In addition, it sounds like you've found the right idea anyway which is: avoid complicating work.
It's a real tangible accomplishment to find a tech stack you're productive with and don't have to change or update frequently. So, congratulations!
The last major real revolution on the backend in my eyes was Sinatra, not for Sinatra itself, but how it changed how everyone wrote web servers. The last real revolution on the front end was Angular.js (v1.x) and then shortly after, React.
There's a lot of change year after year in the real world, but a majority of it you can ignore.
It is really sad but in my experience the only improvement provided.bybthese tools are regarding developer experience (and some times, not even that!). We're trading our own dev experience and sacrificing our user's. For proof, look at the new reddit, and so many other react apps which even with modern macs feel terribly slow and clunky
I was finally able to load the modern web as quickly as the old web once I got a laptop with one of those newish Ryzen chips. I expect complexity to grow quickly past the performance gains, but it's a nice reprieve.
I ditched firebase cloud functions for Next's /api/ functions. I put all the db stuff and checkout and webhook stuff behind those endpoints. At first I just loaded the entire firestore library on the client and did authenticated reads/writes directly... But I wouldn't do that again, made my app too heavily intertwined with firestore's api.
reply