I am going through the same thing myself right now. After eight years of running this small product, I’ve gotten to the point where the revenue hasn’t increased significantly, but the complexity of Admin work has increased exponentially.
I plan to make it this year’s theme to simplify. For me that means:
- automating or delegating all recurring tasks;
- eliminating all processes that have become complex but are not worth it;
Eg:
- I plan to move from Stripe to Paddle (MoR) because I don’t want to deal with EU taxes anymore; we’ve save me a few hours every month + A few hundred dollars on accounting;
- we gave an affiliate program that isn’t working out great; i plan to cut it;
- we have a referral program… same, cut it;
- we have a public email address, cut it;
- etc.
In addition, what’s worked for me so far is day-theming. Mon & Tue are for admin and management. Wed-Fri are creative - I don’t even open my inbox some days. I checked recently, the world is not on fire.
P.S. One of the automation tools I use it https://recurrr.com - saves me a few hours every month. Not a lot. But enough to have kept it alive for the past 7 years (under a different name).
I read it the same way, yes. Good point with the cleanup:
- it’s one thing to need to run build for it to work;
- it’s another thing to run build to make it smaller;
Why? Why does it need to be good for big projects in order to be good practice?
I’m genuinely asking. I never understood this argument that people bring.
In my view, the web is 95% small to medium projects. Most technologies should be focused on that - simple solutions for simple projectS. Add complexity later.
Because in practice there is little value in making easier things easier. While 95% on the web are small projects, 95% of work is done on large projects.
Many developers also dislike using many different frameworks, because that would require more learning. If you have to choose one technology it's better to use one where you can do everything. Not one where you can do 95% really fast, but 5% not at all.
I personally always use "complex" frameworks like Angular or React because sooner or later feature requests come in, where those frameworks pay off. On average it saves time for me to always use those frameworks. That might be different for you depending on the work you do.
Do you have any data to support that 95% claim? As big as FAANG and other huge development teams are, it seems to me it's still only the tip of the pyramid, with the overwhelming majority of people in the industry working full time on small or midsized projects. It'd be interesting to see some concrete info on it.
The point where frameworks like Angular and React pay off and what I think of as complex projects are those where there is a some nontrivial feature. This coukd be a project with 1 developer working on it for 6 months.
For example a static page with a booking process with various entry points on the website, which slightly change the booking logic. Also you can book as a new user, as a logged in user, for somebody else etc. Also the logic is changing at regular intervals, because the business owner is trying different things out.
Using Angular with reactive forms makes this easier to develop, maintain and hand off to other Angular devs.
While it makes writing the static parts of the website more complicated, it makes developing the booking process easier. And overly complicated business processes are what is mentally challenging for me. This is where I want all the help I can get. Writing static pages is something I can do in any framework even when I am tired. Making this part easier or reducing boilerplate is nice but doesn't make me much happier. Being able to build ridiculously complicated forms without my head exploding does :) Of course if you work on projects with relatively straight forward requirements there is 0 advantage in using Angular or React for you. It always depends on the type of work you do.
> a booking process with various entry points on the website, which slightly change the booking logic. Also you can book as a new user, as a logged in user, for somebody else etc. Also the logic is changing at regular intervals
The more complex the business logic, and the more options there are, and the more it is expected to change, the more it benefits the development team to write that code in their language of choice on the backend, close to the data store(s), using native classes/objects -- rather than being forced to write it in JS/TS, serialize everything to/from JSON, reliant on magic under the hood to lay it out in the DOM, with more and more "state" necessary to be managed client-side.
> the more it benefits the development team to write that code in their language of choice on the backend
Why?
TS is maintainable and very pleasant to code in. Most people’s computers are way faster than making round trips to a server. You talk about serializing everything to/from JSON, but my phone can do that in milliseconds (if not faster). Compare that to 100-200ms of latency between a faraway server, and all of a sudden doing things client side makes sense.
Engineering is all about tradeoffs. I’m tired of people trying to make blanket statements like “React is always better”, or “SSR is always better”. It’s not, and we know it’s not. There are several successful, performant, maintainable apps written using React. There are plenty written using a backend framework and SSR too. Heck, there’s successes that use both!
The common denominators in the success stories? Competent engineers. And I expect a competent engineer can analyze requirements and determine what would be the best outcome for their target users. A booking site absolutely benefits from a front end framework that handles client side logic. It probably also benefits from a clever backend for processing the data after the user is finished with it. Let’s not pretend there’s a one sized solution that fits everything, because there isn’t.
A tangential answer (focusing on backend not language) is because I'm (we're) going to have to reproduce much of the fronted complexity of the business logic on the backend to validate what the frontend sends.
I'm mostly agreeing with you. I've built multiple web-platformed insurance systems and booking systems in the last decade and moved from fully server rendered pages to client rendered forms. The complexity increased with that change but as you highlight once it's done the ability to test different frontend flows is great.
But I'd like a way to share more of the business logic rather than writing it twice.
> Compare that to 100-200ms of latency between a faraway server
A complex booking engine like an airline or Stubhub needs constant, almost real-time connectivity with a database, otherwise you risk selling product at a stale price, double-selling, selling to an unauthenticated person, getting taxes and fees wrong, missing custom post-sale add-on opportunities, and lots of other potential problems. The client has to make a lot of network calls, so you're going to deal with latency, there's no client-side solution that avoids it without risking the issues above.
If only they actually worked like this. I’ve experienced, as I’m sure many other people have, problems booking flights, lodging, buying tickets, etc, where when I go to checkout it fails because I was too slow. It’s also much faster to only request smaller pieces of data if you can, instead of resending an entire web page and then re-rendering the whole web page.
All that to say, there are tradeoffs. Finding the solution with the best latency and the best experience requires a careful analysis of all these details and figuring out which approach (or combination of approaches) solves that problem the most efficiently. Of course it’s not easy, but nothing you’ve said here indicates one solution would always outperform another solution.
> problems booking flights, lodging, buying tickets, etc, where when I go to checkout it fails
Because they are typically written using popular heavy frameworks! Big, expert teams of developers can't get it all bug-free and fast and smooth when working with them. Thank you for making my point better than I could.
> only request smaller pieces of data if you can, instead of resending an entire web page and then re-rendering the whole web page
You have revealed by this statement that you have no idea how HTMX works. You are making an argument against something you've clearly never looked at.
I don’t understand why you’re bringing HTMX into this? This is a blog about HTML first, and the comment I originally responded too seemed to imply a more traditional MVC or SSR site was the way to go. It feels like you’re just searching for a “gotcha” argument at this point and not arguing in good faith.
My whole argument can be succinctly summed up by this comment from a different Hacker News user from when React was first announced:
> One of the biggest problems with the web platform is that we've spent the last 20 years trying to shim applications into a document framework. HTML was designed to help academics share research papers, not to replace native thick-client applications, yet that's the direction it's been evolving towards.
> I'm really happy to see Web Components (inc. Polymer, Angular, x-tags, and React) landing into HTML. If we accept that web apps != web pages at a spec level, hopefully we can build an awesome platform on which to create tools that leverage all the great parts of the web (linkable, available, auto-updating, device-agnostic) without the mess that we've made trying to make the web do something it wasn't designed for.[0]
This sentiment, after 10 years, is still spot on. The web isn’t academics sharing research papers anymore. Interactive web apps, whether you like it or not, require a ton of client side state management. React was developed to address concerns with managing that state and improving performance where HTML5 fell short. It still succeeds at that.
Of course, if you have a static site, don’t use React! But let’s not pretend there’s no use case for it either. There’s tradeoffs. And I’ll repeat that til the end of time. No matter what you choose, there’s tradeoffs.
> How are you going to do the updates without FE logic? Refresh the page constantly? The client being able to fetch just updates is a lot more efficient. If you open a web socket the server can even push.
That's exactly why HTMX has gained immediate traction so quickly, it solves many of these exact problems elegantly and easily, much of the time without a single line of JS.
I suspect even at Google a lot more than 5% of effort goes into small to midsized projects. Bazel, ninja, protobuf, grpc, the API documentation website for Gmail, VP9, the Google transcode api, takeout, various corp network tools & services and so on.
The big projects are of course important. But even chrome needs a simple little website with a download link.
That's a good point. I personally always like Angular and React, because even with most simple projects there is this one feature that is so ridiculously complicated that making it slightly easier to develop and maintain is important to me. I'll gladly write thousands of lines of boilerplate just so I make it easier for me to succeed in developing this one endboss feature. If you do not have at least this one insane feature, Angular and React are definitely overkill.
I always see this as a communication/management failure.
Product folks come up with features. They have no idea how hard those features are to implement. Which in a way is a blessing; they'll come up with the best features if they don't have to consider the implementation details. But because there are always trade-offs in implementation they also don't understand those.
A feature that is super difficult to implement, and that therefore has trade-offs on speed, maintainability, etc, should be communicated back to the product folks. If you have to move to a framework just to implement this one feature, then that is either because this one feature is really badly or over-designed, or that one feature is absolutely critical to the entire site, which is stupidly rare and again a symptom that someone hasn't really thought this through enough.
The failure in communication is usually "you're just the nerd pushing the nerd buttons, you don't have valid opinions on product design" which is a cause of so, so many problems in our industry.
> The failure in communication is usually "you're just the nerd pushing the nerd buttons, you don't have valid opinions on product design" which is a cause of so, so many problems in our industry.
But are they that wrong? We compute to, well, do things with our lives. To find out how to go places, to pay bills, to talk with friends, to meet with people, to learn about things. A view that computation should come with technical (e.g. tech bloat) limitations in mind feels important only to technical people and not to actual computing.
If building it one way will take 3 months and involve shipping 500Kb of JS to every user, whereas building it a slightly different way will take 2 weeks and ship only 50Kb of JS, then I think the second option is better, even if it includes a slightly degraded customer experience (though tbh 500Kb of JS is all by itself a degraded customer experience).
Our online lives would be a lot better if the product folks listened to the tech folks a bit more.
I like to draw a parallel to music; if the producer doesn't understand music at all, then maybe they should listen to the musicians a bit when it comes to creating a musical product.
> even if it includes a slightly degraded customer experience (though tbh 500Kb of JS is all by itself a degraded customer experience).
What if people don't use it because of the degraded customer experience? Then does it really help if people who would originally benefit from the computation never compute?
> Our online lives would be a lot better if the product folks listened to the tech folks a bit more.
I mean, according to which metrics? Again this is really popular on HN and other nerd forums but from what I can tell it's just a nerd forum indicator. I think you can make a decent case for involving tech and product together, and I can think of many, but it's a case-by-case basis and has nothing to do with degrading customer experience. This view is popular on HN because we don't actually care here much about actual customers and care more about things like "site payload" and "how much JS is running in my browser". If the argument is that people with older devices won't be able to run the JS like this, I'd argue that your networks have more latency than any bloat you get from JS. Which is why a holistic experience matters more than what your personal tech-experience gets hung up on.
From my experience I don't think product and management folks care much about the user experience either; it seems to be mostly ego and dick-measuring.
My target user is someone running 3G on their phone on the commute home in a crowded train. The designer's sexy animations and carefully coordinated state changes are not worth the extra 100Kb of 3rd-party dependency JS required to get them to work, because the user is not going to see them; they're going to switch away from the app after 10s of staring at a blank page waiting for the JS to download.
Seen too many "perfect" designs on a laptop monitor right next to the router in the dev studio fail completely in the wild. Every Kb matters.
Unless you have anything more than anecdotes and feelings to contribute to this discussion, I don't think there's anything more to discuss. Data makes a more convincing argument for such bold claims, especially when a minority of practitioners claims that their way of doing things is more correct than a much larger majority. I will say, from your maligning of "product and management folks" to your anecdotally-driven interest in page weight, its like every dev stereotype ever.
Are people really struggling at that level, though? It has never been easier to write a complex page with minimal Javascript - there are more and more HTML elements that do what you expect (expandos and modals as some recent examples), Javascript is cleaner and more consistent across browsers (you really don't need jQuery anymore), and CSS is more powerful but also so much simpler (flex+grid solve so many problems).
Then if that's not enough, you've got things like HTMX if you're keen on doing everything in terms of html templating, you've got tools like Svelte if you want an isolated chunk of dynamic UI in a mostly static page, you've got bundlers like Vite that just work without any configuration if you get to the point where you need a build step, and you've got a multitude of lightweight frameworks for the next step.
And on top of that, pretty much all the old ways still work. The browser is an incredibly stable environment! Outside of a handful of security-related removals, if it got into a mainstream browser, without a feature flag or an explicit "experimental" warning, it's pretty much there for life. So if you want to go back to the old ways, there's not much stopping you - but a whole bunch of quality-of-life development improvements along the way to make things even easier than they were back then.
Most professional frontend developers are working on projects that require something more complicated than just the basics, because, well, that's where the complexity lies, and so that's where the work is.
You can still find developers who are using the basics, but mostly they're designing WordPress themes or working for boutique web design agencies, because those are the sorts of problems that are solved with just simple HTML, JS, and CSS.
It's like asking a Java developer when the last time they developed something without maven or gradle is, or Python developer why their first reaction is to use pip. If the majority of problems developers had to solve were simple enough that they didn't need these tools, then there'd be far fewer developers and most of them would still end up working on the 20% of projects where they're necessary. Because, well, that's where the complexity lies.
> Find a professional front-end developer who is willing to use simple HTML, JS & CSS and I'd agree with you.
> It's almost impossible. The first reaction is always `npm init`
Consider a simple case — a static website containing several pages (it's simpler than anything requiring a dynamic server, right?). If you are a professional front-end developer, you are almost certain to prefer some kind of a static-site generator over copy-pasting the html template with repeated elements (header, footer, navigation) multiple times, because you know that copy-pasting will bite you when you need to change something. You could use a static-site generator written in Ruby (but then you would gem install), or in Python (but then you would pip install); or you could use a Hugo binary (I'd love to see anyone call its templating language simple); or, if you are a front-end developer, you might npm init && npm install eleventy. Is this too complex a step?
> or you could use a Hugo binary (I'd love to see anyone call its templating language simple)
I dunno, I'm a Go dev, so it makes sense to me ;)
> Is this too complex a step?
If it just stopped there, sure, that would be fine. But it never does. My experience of front-end devs is that they will do anything to avoid writing any actual code. So there's a tendency to pull in dependencies and bloat the thing until it suffocates in its own complexity. I've seen node_modules with thousands of subdirs, and a build process that takes minutes, for really very simple sites.
I mean, I am a big SPA framework guy. That's pretty much the main thing I use, day-in, day-out, because most of the projects I'm working on are complex enough that simply hand-coding the entire UI will not work.
And, while only a minority of projects are that complex, those projects are the ones most developers are working on. Most other projects are probably better served with a wordpress install and a bit of theme customisation. Which means it's going to be a minority of developers who work with the very minimal things that are sufficient in these sorts of cases.
Are you writing that complex projects need SPA, everything else is better served with Wordpress?
I've used SPA frameworks, but try to avoid it if I can, because most of the logic is in the backend. I don't want to create and sync API interfaces, have 1-2 additional contexts (JS + frontend framework) and debug an extra layer.
With htmx I can now have interactivity via the backend. I use Alpine.js for some interactivity.
> If you have to choose one technology it's better to use one where you can do everything. Not one where you can do 95% really fast, but 5% not at all.
> I personally always use "complex" frameworks like Angular or React because sooner or later feature requests come in, where those frameworks pay off. On average it saves time for me to always use those frameworks.
I wonder whether they ever pay off. First, I don't believe the frameworks you mention really, as you suggest, enable the last 5% of functionality that would otherwise be impossible. No, those frameworks are written in the same language they work in, which means that strictly speaking they do not enable any new functionality.
Second, whatever ease / speed of development you use must be weighed against the additional cost borne by the project's users. The time you save (that you might otherwise spend learning to achieve the same result without the framework) could be less than the time spent collectively by users waiting for the framework to load.
Not at all. There are a lot of frameworks that support static exports and/or pre-rendering. Often those produce incredibly fast results, in many cases faster than hand rolled solutions.
If you use a CMS you have already a templating situation and dynamic content, using a framework, or jamstack like situation is not that different, depending on the specifics it might produce faster results.
You don't need a frontend framework for that. Fuck people who do. They're the reason most websites are slow as molasses on my three year old phone, despite them being very basic sites. Just stuffed to the brim with unnecessary bullshit.
While I agree that there is probably an overuse of frontend rendering when templating in the backend would be fine, I suspect most of the problems you see have nothing to do with that. In my experience, the number one issue with slow sites is an overuse of trackers and advertising that drags everything down.
Precisely. Using libraries / frameworks like React, Vue, Svelte, etc. adds nearly no overhead to the core functionality of whatever it is you're creating, _especially Svelte,_ since it compiles down to the bare minimum necessary to power any dynamic functionality (it doesn't ship with a complete runtime), and supports static templates and markdown out of the box.
I can say with confidence that unless I royally screw something up in my component lifecycles or render loops, everything is just as snappy as ever. No latency. No lag. Just a zippy fast web app with URL/route changes that fly, fetched data populating quickly, and interactions feeling wonderful -- and that's because said apps I'm developing _aren't_ using any heavy tracking libraries.
People are too quick to blame slow performance on modern view libraries, and even likelier: they've never used them before.
If you statically export you won't even notice, and when navigating it will actually be a lot faster when only the content is replaced..
Have you checked this is the reason? not slow network? and not ads/analytics and blocking assets? That's not exclusive to frameworks btw, and probably less likely as most optimize these things for you.
The website that is linked originally has a bunch of blocking assets.. lighthouse score is not amazing either.
Just like the original article, you might want to test your assumptions a bit more.
“95% work is done on large project” this perception might just because you have chosen complex frameworks. Remember google and facebook starts with no frameworks at all. Are they small projects? No.
I'd be more than happy to see small or medium projects and how these tips improved them. Any real world examples would be great.
I would also add that a lot of us do work on the bigger projects, which makes sense as bigger projects require more people. So at least in my life, and I expect many others, it is quite relevant.
I also don't believe the article qualifies that these tips are only for small to medium projects, I'd read it very differently if it did, but I would still like to see some real world examples though.
> In my view, the web is 95% small to medium projects.
I'm not sure that view is correct. For one thing, I'm not sure how you even define this.
As technology has advanced, many of the "small/medium" projects that used to require lots of dev time have turned into fully-built alternatives. The days when you need a dev to setup a blog are gone, as are the days you need one to setup a store, or a simple marketing website.
Are these part of the 95%? In some sense, yes, but in the sense of giving advice on a framework to choose, not at all, because no dev will even be making that choice - it's irrelevant.
As for medium-sized projects, there are tens of thousands of small, internal company tools that aren't even on the open internet. They probably fit your definition of being medium sized, let's say have a few devs working on them for many years, certainly medium sized compared to FB etc - but I'm not sure that whether this approach is right or wrong for them. (Genuinely not sure!)
I'm just saying, you need to much better define what you mean by small and medium sized, because some people might be thinking of my definition, while for some people medium-sized is, idk, AirBNB, which is tiny compared to FB but gigantic compared to most projects out there.
I would say that explaining where guidelines are applicable is on author side.
For text at hand I understand that author expects this way should be “the best” for everyone.
Then author gives examples that even in medium project at first requirement change or first additional non-trivial rule are going to have 2-way bindings plus bunch of other plumbing implemented where “html first” doesn’t have it and someone will have to write some JS monster to handle state etc.
Their second principle, to use inline styling, makes it harder to create a consistent look across the entire website. Defining that in one place and referencing it everywhere is better and easier.
- found a service where in the morning they bring 3 meals + 2 snacks, everything you should eat for the day; especially during stressful times, it's so so good not have to think about food; you just eat what you've been given;
- I no longer trade cryptos myself, I have Shrimpy, HodlBot and Iconomi to do that for me; this may not be "personal" but it saves me at least 10 hours every week, and the performance is a little better than my dumb self;
- I found a shirt I adored, so I bought a bunch of identical ones; this in addition to having identical socks and identical underwear makes it that I only have to choose&match my pants and shoes; and mine kind of all match; saves headspace;
- I never read or watch news; only read headlines in newsletters I trust; saves time and headspace;
- I used Github Probots to automate A LOT of replies issues/PRs; I consider this "personal" because it's tied to my hobby;
In addition, for the past 6 months I've turned a bunch of things I was doing / wanted to do into emails. I've built https://schedulethatemail.com/ for that sole purpose, help me do the stuff I wasn't doing, or that was repetitive (shameless self-promotion, I know). Here are some of the personal things I've automated through email, though some are now canceled:
- I used to forget/postpone seeing some friends I really care about, now I automatically email them to catch up (different intervals 1 month, 2 months, 3 months, 6 months); some have no idea it's automated :-)
- I always wanted to write a journal, but never stuck to it; now I receive an email from myself each day with a few questions, 8/10 times I answer; works because I use my email as my todo list; push notifications don't work for me;
- I have this poem, this mantra, this whatchamacallit that I like to read every day, to remind myself of who I am, my values and principles; especially when I interact with people I don't like, every day, it helps me stay myself, and not change in a bad way; works because I use my email as my todo list;
- I automatically email my landlord, accountant, etc to tell them I've done something, or I'll do something within 24 hours, before they even ask; self-applied peer pressure - I'm on time most months now;
"_Start with what you know_" - amin to that. I also found this is the most important consideration for this decision. I've made the mistake of applying the "_if it fails, at least I used and learnt a new system_" logic, but every time I did that, I still preferred my old stack. So I ended up taking 2x as much time to build, to re-use nothing of the learning (on the development front). I'm now a big believer in the "_build fast, fail fast_" mantra.
My favorite stack: nginx, PostgreSQL/MySQL, PHP 7.1/7.2, Laravel, BackpackForLaravel for admin panels, jQuery/Vue.js
That being said, I'm the creator of BackpackForLaravel. So my productivity is off-the-charts with it, and I'm probably biased towards PHP. I think PHP is underrated, especially in the US & Silicon Valley. It's "cool" to hate on PHP for its past mistakes, and I agreed on many of them, but nowadays, with Laravel...
- it's a joy to work in it (I now like it better than Ruby)
- you get _so much_ done, so fast
- I've been able to easily scale it for millions of users (I've built a social network, a video-on-demand app, an e-learning app - for clients, not myself)
- PHP/Laravel developers are easy to find, all across the world, when you need it
- there's a plethora of good agencies that use it, if you ever want to outsource the entire development team
IMHO, Laravel is here to stay. And with BackpackForLaravel for admin apnels, I hope it'll soon be on par with Django.
Long time reader, but first time poster on Hacker News, so please be gentle :-)
I've built this tool for myself a few months back and it has been so useful to me that I decided to turn it into a product. I would definitely pay for it, so naturally I'm wondering if others might too.
The idea is simple - everything in my life that happens every day/week/month/etc and I can turn into an email, I do it. Meetings, follow-ups, catch-ups, weekly tasks, monthly reminders, etc. Usually I procrastinate this kind of stuff, but I discovered once I send an email to someone, that's basically a promise, so I don't back down. It's replaced a lot of things I kept in Google Calendar, Asana and Todoist and kept postponing, and it makes me look like a productivity machine :-) I've also managed to turn 5-6 short meetings every week into status emails, so I personally save >10 hours/month thanks to my own service :-) Not bad, right?
I run an open-source project and a small web dev company, so the most helpful thing I use it for is to send an email to each client, every 6 months, to ask what's up and "_who do you know who can use my services?_". I knew I was supposed to do that, but I never did. Now I do do it, because it's automated. And the first time the emails got sent, I got 2 new leads. So yeah :-)
Eager to see what you guys like, what you don't, and what emails you decide to automate. Always looking to automate more of my professional life, so looking to you for inspiration.
I plan to make it this year’s theme to simplify. For me that means:
- automating or delegating all recurring tasks;
- eliminating all processes that have become complex but are not worth it;
Eg:
- I plan to move from Stripe to Paddle (MoR) because I don’t want to deal with EU taxes anymore; we’ve save me a few hours every month + A few hundred dollars on accounting;
- we gave an affiliate program that isn’t working out great; i plan to cut it;
- we have a referral program… same, cut it;
- we have a public email address, cut it;
- etc.
In addition, what’s worked for me so far is day-theming. Mon & Tue are for admin and management. Wed-Fri are creative - I don’t even open my inbox some days. I checked recently, the world is not on fire.
P.S. One of the automation tools I use it https://recurrr.com - saves me a few hours every month. Not a lot. But enough to have kept it alive for the past 7 years (under a different name).