The Case for ‘Developer Experience’
future.a16z.com
future.a16z.com
The much better solution, SSR first with optional client hydration, takes more developer work and more cognitive overhead. It's much easier to write a React application and not worry about server side specific data fetching to do universal rendering, even though that's the strongest option for performance. Next.js is bringing us closer to the DX of enabling SSR first by default, but it's not there yet and many people use Next.js only for SPAs or static rendering, and miss the point that its main power is universal/SSR.
My main takeaway is that DX is important when it introduces the right abstractions that are also end user focused.
I spend a lot of time optimizing performance at work, both for UX and DX. It is common on HN to bash on large bundle sizes of SPAs, but in reality this not a problem unless users are on IE. At work, I often work tirelessly to reduce the amount of dependencies and bundle size, but I know that this would not make things faster, just more maintainable.
For UX perf killers are IMO:
- rendering large number of deeply nested dom nodes and doing repaints and reflows.
- large data fetches and storing huge number of objects in memory.
- slow/flaky APIs, in many cases slow backend is main bottleneck, JS is plenty fast
- silly animations, bad design that force clicking and multi stage workflows.
- micro-something. Micro services/frontend in organistions without deep pockets.
- special snowflakes internal abandoned framework that only two people in company know
- lack of dedicated people for tooling and dev infrastructure
- lava layer design pattern, multiple competing technologies used within same codebase/product.This is dangerously wrong. Large bundle sizes are a huge problem on slow Android phones (and almost all Android phones in real-world use are slow).
Even in the US, if you walk into a cellular store and ask for an affordable phone, they're going to give you a device that will take 7-10s to download, parse, and execute a 3MB JS bundle, even over wifi. (The parsing alone will kill you!)
(And if you're in a developing economy? That "affordable" phone is the best phone you can reasonably buy with a month's wages. The median phone is even slower!)
Browsers would cache parsed javascript. More likly loading images will be slower.
There are use cases that general perfomance matter a lot but people are obsesing on js bundle size too much.
First load is important for any public facing site. A 7-10s delay on first load means you’ve lost the game no matter what happens on a second load, because there often won’t be one.
> more likely loading images will be slower
True, but images do not block interaction with your site. In most SPA situations JS will.
I hear this said a lot, but have never quite understood it myself.
What industries have pages that are hit by new customers and need to be a big complicated SPA?
Any SaaS can have a landing page/login page which it can use to background load assets needed for the service itself. And if someone already knows of and wants to use your service they'll wait a few seconds.
Online shops maybe?
And remember that today’s darling framework all the internets are raving about is a special snowflake abandoned framework tomorrow that no one gives a damn about anymore.
The corollary to this is that the spice must flow, and the wheels must keep spinning, thus the hamsters^Wdevelopers must keep rewriting everything using the current darling languages, frameworks, and paradigms, restlessly contributing to the ever growing carbon footprint as CI/CD pipelines keep chugging away at each oneliner commit!
I would argue it takes less developer work and cognitive overhead if you're doing traditional SSR.
ReScript (https://rescript-lang.org/) is trying to take another approach, which is being a different language, way simple and easier to use and in my opinion better than TS, but the price is that integration with JS is harder. The community is also small compared to TS. But you can leverage some work already done, as it can consume TS types. This may be what you asked for, as you can still use the ecosystem.
This is a confusing statement. Pre-rendering is a core principle of "Jamstack". To quote the site[1]:
> With Jamstack, the entire front end is prebuilt into highly optimized static pages and assets during a build process.
That seems the complete opposite of what you're saying the default is.
I know much of the HN crowd loves to hate on bloated SPA applications (and not for good reason, we all deserve better perf), but this comment makes no sense. You can have a fast website with no loading spinners, pre-rendering, static HTML and optional/client hydration running on Jamstack infra.
It's misleading to suggest Jamstack = complicated/slow/bloated and SSR = fast/simple/good ux. Please take time to understand your tools. You can build a brittle/slow/poor ux website with SSR if you don't know what you're doing and/or don't care.
I'd advise others to not worship one technique over another. Choose a stack that solves a problem for your users, demonstrate empathy, evaluate tradeoffs and things will be fine.
For some libraries that are very large, like Threejs or a charting library, or any tech that draws to a Canvas which probably can't be SSR'd, it's probably best to detect if you're on the server or the client in your React code (which is usually done by injecting some env variable into your bundle), and render an empty <div> on the server, and when the client hydrates, it will download the large library and create the chart.
For other data, the trick is to create an API that works on both the server and the client. So `getPosts()` on the server will call to your internal API, and when that same function is executed on the client, it calls out to GraphQL. Then you switch out your API client on the server vs client bundle. In this way, your app is "universal," you can do a blocking fetch of posts on the server and render server side HTML, and on the client you can still call `getPosts()` on button clicks or whatever to fetch new posts. And API calls are much faster on your server side because you're in the same VPC, they don't go out over the public internet, and you might not even need TLS for them.
For most SSR apps with hydration, the entire app is downloaded again on the front-end. What I want to see is selective hydration first. For example, you define your entire app in React, and things that don't change, like the header and the footer, are only rendered on the server, and the JS React code is never sent to the client. For things that need interactivity, like dropdowns, the React code is sent to the client only needed for the dropdown to make it interactive. I think selective/partial hydration should be the default behavior for webapps, only deviating if you have things like large JS libraries as mentioned above, or maybe applications that you always keep open in a single tab, like an email client.
These same principles apply to CSS rendering too. CSS should always be extracted to a static stylesheet and sent as a <style> tag. If you have to download JS, parse JS, run JS, and then get a stylesheet injected into the DOM, it's also a bad performance hit. Browsers will always be faster than us at showing vanilla CSS and HTML to users as fast as possible, which is what we want. The most important consideration of CSS libraries is whether or not they can produce static stylesheets. It's mystifying to me that none of the CSS-in-JS libraries mention if they can/can't do this as part of their landing pages. If users have to execute JS before CSS starts styling the page, you've lost the performance game.
That means building out an application and experience that has the following:
* a substantial education component. You are an expert in X, so educate developers so they can get better at X
* meets developers where they are (in terms of languages and tooling)
* allows both high and low levels of abstraction (including a well documented and consistent API)
* free to start (even though we all have to eat, developers want to kick tires with minimal effort)
* encapsulated functionality that does a few things and a few things well. The RDBMS is a model here.
* an open feedback loop, typically on GitHub or in public. (Slack is a bit of an anti-pattern here.)
For another smart, if different take, read this: https://redmonk.com/jgovernor/2020/11/26/addressing-the-deve...
The post talks about tooling and a cohesive structure as the next great opportunity.
If we really want a better DX paradigm, we need to figure out another way of working that isn’t agile, either with a big A or a little a. I don’t know what that is yet, but doing anything less will just be the equivalent of making a better Jira.
Isn't devops the next generation? (I mean devops as promulgated by Accelerate: https://www.amazon.com/Accelerate-Software-Performing-Techno... , not 'smoosh the devs and ops teams together, add Jenkins and hope for the best'.)
So at that point, the balance becomes “ok, if less than 1% of requests come from this browser, we don’t explicitly support it.”
How soon can we drop support for Android OS #? Because # doesn't have the easier to use animation API, or because we'll need to display an extra modal, or some such.
Eg Netflix doesn’t care about ads - they care about supporting their customers whereever they happen to be. Supporting (or not) Firefox is still a business decision of course, but it has nothing to do with ad-blocking.
It still seems to download a fair bit of Javascript so I guess a developer had to write it at some point.
Disclaimer: I work for a company whose main product ships as an electron app, although I don't work on that part of the product specifically.
Edit: I also said it was easier to hire. Which IMO is an organizational anti pattern. Look at all the talks of Clojure shops, who despite having a small hiring pool, usually find passionate, practical developers who quickly pick up the language.
Electron allows you to hire devs who prefer code aesthetics over what the thing actually does to/on your computer.
It can be done poorly, and there are plenty of examples of that, but it's not a universal rule and the trade-off gives real benefits. At the end of the day you do need to ship and maintain _something_, and maintaining one thing is better than maintaining Web, MacOS Desktop, Windows Desktop, Linux Desktop, iPhone and Android.
"Taylor Swift as classic programming textbooks, a thread."
https://twitter.com/jeanqasaur/status/1290883041418649600?s=...
The excuse was DX. How can we test it and use storybook if we don’t use react and generate a giant dingus of a bundle?
Edit: so don’t just trust “engineers”.
On the frontend, observability and transparency are the main reasons why I still use Redux and its dev tool. It's like live logs on steroids. Not only do you see the chain of actions that led to a certain outcome, you see the state at each step. This makes the reasoning about the bugs much easier. There was a tool on Show HN a few days ago that does exactly this but on the browser level[0].
And DX in general? Well, this is how it's stacked in today's startups
https://pbs.twimg.com/media/FAIZRuaVQAEGwGU?format=jpg&name=...
I will say design is useful - the AOL graph was mostly hub and spoke. App Routers -> domain specific orchestrators -> single coarse grained functional API. Paypal was more poi;t to point to point. AOL encouraged devs to take some time just mulling over a new problem or new servers until a sensible approach seemed feasible. Few weeks for a 3 month project, few months for a year long project.
and in the 90s good software had observability. Metrics and logs and tracing, all on the fly to enable or disable prospective msgs (you had to turn off a certain log msg on the fly when a dev accidentally left would should be a tracing level msg at like an always log level).
https://www.swyx.io/js-third-age/
> Collapsed Layers (One thing doing many things well instead of many things doing one thing well)
Developers are in a run-away-train kind of situation, where they think that more libraries, more frameworks, more tools, more languages, more abstractions, etc. is the key to a better developer experience. In reality, this is the exact thing that is making development and developers miserable. The whole `is_even` fiasco [0] should have been a wake up call.
The plain fact of software development is that there is going to be complexity, and there is going to be some point where adding features or fixing things is going to become a slog. The choice where do you want that to happen? With the never-ending reliance on libraries, frameworks, tools, etc. the difficulties has been shifted towards the latter half of development, "we'll worry about that later". Sure, the share holders and the angel investors are stoked when a team can get an app running in a few months. But guess what, down the road when it comes time to add more features, make it fast, to flesh out the app into its full potential...it will end up in a nightmare of trying to wrestle the code and the barely comprehensible infrastructure to get it to do what they want. Good luck trying to figure out what is making the app slow in that rainforest.
The best thing I ever did for my mental health when working on hobby projects was to keep it simple stupid. In the case of C++ and games, I do everything in my own code maybe using Sean Barret's header files or GLFW for Window and input. Use a .bat file to build the code, rather than some overly complicated build tool so that it can build in 2 seconds rather than 5 minutes giving me very fast iteration speed. The Vulkan rendering code, the math, system level stuff like memory and file IO is all my own. For web stuff, I wrote a production web app for an internal team in a single PHP file with only a templating library. Going this route has undoubtedly doubled my productivity. Static site generator? I'd rather write one in Python than try to figure out some complex dependency ridden mess of an open source tool that never does what I want it to do.
The pain of developer experience is self inflicted. In an effort to reduce friction in development, a system of increasingly worse friction has been introduced. Programmers need to stop being afraid of writing code, and, dare I say stop being lazy. Developers could be just as productive, if not more productive, if they would just write the code.
[0] https://qz.com/646467/how-one-programmer-broke-the-internet-...
Surely the best outcome.
Just put code comments above everything and describe what happens below.
I think that's not the right way to look at it. It's just that a task that's automated no longer needs a dev. Thus we only work on things not (yet) automated.
As a corollary, easy-to-replace parts inevitably become replaced with hard-to-replace parts, because those are the ones that stay.
I still see it as an emerging field with more work done to synthesize under a single umbrella of being able to communicate abstraction levels, concept understanding, adding explainability to decision models and of course tailored for the skill tree at where the target developer today is at.
I know this is Silicon Valley gospel but just because technology is a critical part of many if not most companies' operations today doesn't mean that those companies are "technology companies."
Slogan: Shell is the Language of Heterogeneity and Diversity
https://www.oilshell.org/blog/2021/07/blog-backlog-1.html
To be concrete, a "monoglot" lives in a world where the language's package manager is responsible for integrating different pieces of software.
In contrast, a polyglot uses multiple languages, and the package managerS (plural) are just tools, not the world, and they're called from shell scripts! (Or something morally equivalent, like a Makefile or Dockerfile)
The future is more polyglot, e.g. your Rust or Zig code will coexist with a lot of C and C++ code. Sometimes they will be linked into the same process, but often they'll live in different processes and you'll use various forms of IPC.
Does this count the 6 people I interviewed this year that couldn't fizzbuz?
Yes. The bell curve for software developers is very wide. The 10x developers are real, they're way out there - maybe 2 standard deviations from average. The "can't fizzbuzz" crowd is large, probably only 1 standard deviation (or less) below average.
Looks like it depends on how "EDC’s proprietary global developer population model" works.
No, but it does count the 1 guy who started a Shopify store and has made 6 figures selling "Do u even fizzbuzz bro?" t-shirts.