[HN Gopher] Thoughts on the Resiliency of Web Projects
___________________________________________________________________
Thoughts on the Resiliency of Web Projects
Author : mooreds
Score : 65 points
Date : 2024-11-10 16:53 UTC (6 hours ago)
(HTM) web link (aaronparecki.com)
(TXT) w3m dump (aaronparecki.com)
| mg wrote:
| The one thing I learned from running https://www.gnod.com (20
| years) and https://www.productchart.com (10 years):
|
| Keep your stack flat.
|
| Most projects of my web developer friends died after months or a
| few years. None survived for decades. And the reason was always
| stack rot.
|
| Multiple parts of their stack became outdated and so hard to
| update that they quit.
| mooreds wrote:
| Yeah, I've had this happen to me. I wrote a directory in
| cakephp and neglected to update it. Eventually the ROI to me of
| updating it wasn't worth the hassle.
|
| The one exception is if you outsource the stack updating. For
| example, https://letterstoanewdeveloper.com/ runs on
| wordpress.com. In this case, I don't have to worry about
| stackrot, I just have to pay the bill. If/when the bill becomes
| too much, then I'll convert it to HTML and host it somewhere.
| (And yes, if I'd done it as HTML first, I wouldn't have to make
| the effort.)
| mg wrote:
| WordPress might indeed be a good choice for a CMS.
|
| How well does self-hosted WordPress (without plugins) behave
| when updating? I would think that even major releases can be
| updated with a simple click and don't break anything?
| mooreds wrote:
| In my limited experience self-hosted wordpress is pretty
| good about upgrades. But if you pay for hosting (like I
| do), you won't have to worry about OS upgrades either.
| lemonberry wrote:
| WordPress offers automatic core and plugin updates now.
| This is rarely an issue with a site that has few plugins
| and customizations. That said, it's a really good idea to
| have regular offsite backups.
| WorldWideWebb wrote:
| With all the drama in the platform right now (caused by one
| of the creators), I would suggest that anyone that isn't
| already deeply invested in it for whatever reason to not
| start now. Its future is a big question mark right now and
| I'm unable to recommend it as a stable solution to anyone
| anymore.
| nox101 wrote:
| this!!! I have a site I personally use daily. it's using react
| 17 and is built with node 16. upgrading either breaks it and I
| don't have the time to fix the issues. It's got 3 components
| that break as well. And the CRA build script breaks if you
| update it as well.
|
| I've spent several hours trying 3 different times to upgrade it
| but I run out of time and give up. So I limp along with tiny
| changes now and then. I don't know at what point it will become
| unmaintainable
|
| I have a similar problem with an electron app. it's super
| frustrating.
|
| I kind of wish the upstream devs got billed for all the extra
| work they cause. Then maybe they'll take the pain they create a
| little more seriously.
|
| The latest is eslint which recently broke everything and now 15
| or so projects I run will need several hours of maintenance
| each. work I'd like to put into new features but instead I have
| to waste on refactoring configuration
| syx wrote:
| I'm having the same issue as you but for a React 16 Node 12
| web app. Building it was great and good fun but after
| neglecting updating the dependencies it has become almost
| impossible to upgrade after 5 years. I really wish developer
| put more effort into developing web tech that would last more
| in time.
| johnchristopher wrote:
| Can't linting just be disabled ?
| burnished wrote:
| I think that is one of the steps towards tacitly admitting
| the project is no longer maintained/maintainable
| heavyset_go wrote:
| I've been passing on clients' projects that use old versions
| of React/Node/etc.
|
| Maybe someone enjoys fixing breaking changes in layers of
| dependencies, but it isn't me.
| btbuildem wrote:
| I've spun up an old ubuntu laptop recently for.. reasons. I
| think the last time that machine was in use was in the late
| 2000s. Poking around on it, I was blown away how simple and
| resilient the infrastructure of some of my old projects was.
| Things just build, things just work -- after over a decade of
| being mothballed.
| AznHisoka wrote:
| Did the projects work in just the laptops? Or did they work
| elsewhere also? I think its fairly easy for existing old
| projects to work, as long as the hardware it lived in is
| easily replicated. Not so if you have to port it to modern
| hardware
| AndrewStephens wrote:
| This is a problem for any project, and yet another reason to
| prefer static files for as much as your stack as possible and do
| not follow the latest tech-stack trends too closely. It is called
| the bleeding edge because it is covered in the blood of dead
| projects that cannot be maintained.
|
| My advice is to use as few technologies in your stack as
| possible. Sure, your project might work best with a relational db
| and a dedicated document store but it might be less ongoing
| effort to emulate one with the other.
|
| And freeze (or at least document) the versions of any
| dependencies for release. Your project runs fine with
| CoolTech.1.4 now but in 5 years when you come to rebuild you will
| find that the interface to CoolTech.6.44 is completely different.
|
| And even then things might fail. 20+ years ago I made some Java
| applets that were well received and useful. Technically they
| still work (I think) but nobody runs Java in the browser so those
| projects have been unusable for years. We can be smug about our
| pure HTML5 static sites now but who knows what the browser
| landscape will be like in 2050.
| anon7725 wrote:
| > We can be smug about our pure HTML5 static sites now but who
| knows what the browser landscape will be like in 2050.
|
| Pure HTML probably has the best chance of surviving.
| eMPee584 wrote:
| Regarding them java applets, it seems it's possible to make
| them run using webassembly or a "google web toolkit" (what the
| fabulous https://github.com/pfalstad/circuitjs1 simulator
| uses)..
| rozenmd wrote:
| I've been running a project for almost four years now, and have
| been vendoring/killing as many dependencies as I can.
|
| Core functionality now relies on no libraries, and increasingly
| moving off Next.js towards more open frameworks like Remix.
|
| At it's core it's React + JavaScript + SQL, aiming to run this
| thing for decades.
| quantadev wrote:
| This happens to every developer once we get over like 20yrs
| experience doing side projects. Invariably the dependencies and
| technologies of any app become obsolete over time, and you either
| do a massive rewrite or else give it up.
|
| I've always had one primary side project of my own that's
| consumed 95% of all my time over the years, and so I've rewritten
| it from scratch at least 5 times as technologies (libraries,
| databases, languages, etc) have evolved. Not many people are
| lucky enough to love one app so much you'll do this, so your
| other side projects just die off, because they're not worth a
| rewrite.
| bilater wrote:
| I have more than 50 projects and find myself often bogged down by
| fixes and updates. This can creep up on you. Going back to older
| code bases (even ones you wrote) can be daunting and annoying.
| One customer email can ruin the whole day. AI has definitely made
| this easier but it's still challenging.
|
| I've now started to be more ruthless in cutting older projects
| that aren't going anywhere (or are not 100% automated) and I also
| try and consolidate new project ideas as a features to existing
| products.
|
| Still its hard and everything is a balance. Some of my projects
| in case anyone's interested: https://www.hackyexperiments.com
| pkossum wrote:
| This comment section has been extremely valuable. Htmx for the
| win?
| marcosdumay wrote:
| Oh, anything that you can just include with a <script> tag and
| move on.
|
| JQuery is also that way, Vue used to be usable that way...
| tylerchurch wrote:
| Vue still is usable that way!
|
| It's my favorite way to slowly add some order to legacy apps
| that have been overcome by jQuery soup.
| c0nfused wrote:
| I generally agree with the thesis here.
|
| Adjacent points: I also think that selecting mature projects for
| your dependencies matters significantly. My old couchdb or early
| node work is generally defunct. On the other hand, I have some
| dotnet projects that are still functional with zero updates from
| a decade or more ago.
|
| Additionally, it's reasonable to keep a copy of your dependencies
| somewhere in case the vendor dies, the licensing changes, or
| something else catastrophic happens. Even if you just image dev's
| machines when they offboard. There have been a few times this has
| prevented permanent project death or rewrite emergencies for me.
| breadchris wrote:
| this post is great, my mental flowchart is similar to this.
| Content like this reminds me of this post
| https://sive.rs/plaintext
___________________________________________________________________
(page generated 2024-11-10 23:00 UTC)