[HN Gopher] How the fuck did we get here? A small rant on the "m...
___________________________________________________________________
How the fuck did we get here? A small rant on the "modern" front-
end
Author : fagnerbrack
Score : 43 points
Date : 2023-04-07 21:17 UTC (1 hours ago)
(HTM) web link (fagnerbrack.com)
(TXT) w3m dump (fagnerbrack.com)
| jonny_eh wrote:
| Are you upset that free (as in beer) software isn't being
| actively maintained over a long time frame? Or is it annoyance
| that Semver doesn't deliver on its promise?
| slowmovintarget wrote:
| How? SemVer.
|
| Semantic Versioning is permission to break things. As Rich Hickey
| would say, just use a new name [1].
|
| [1] Rich Hickey - Spec-ulation:
| https://www.youtube.com/watch?v=oyLBGkS5ICk
| jonny_eh wrote:
| It's the opposite, it's the promise that minor version bumps do
| NOT break things.
| wahern wrote:
| One of the problems here is recursive cross dependencies--
| libfoo switches to a major upgrade of libacme 2.x, while
| libbar remains with 1.x. Even in a language or environment
| where 1.x and 2.x could in theory coexist, the potential for
| bugs is often significantly increased.
|
| Ideally, before someone decides to inflict their open source
| code upon the world, they should at least nominally commit to
| 100% backwards API compatibility. That sets the correct frame
| of mind, both as a maintainer but also wrt designing and
| implementing your API. For example, these days all new
| syscalls on Linux are expected to have a flags argument and
| strictly reject undefined combinations of flags and
| arguments. There are exceptions, but that's the baseline
| expectation; even when excepted, those expectations help
| steer the conversation to expose potential compatibility
| traps. And they do this because Linux nominally promises 100%
| backward compatibility, regardless of versioning; though it
| took them many years to appreciate the need for those
| particular technical guard rails.
|
| If and when you need to break your promise of 100% backward
| compatibility (as even Linux occasionally does), then use
| Semantic Versioning to help smooth the way and set
| expectations. (I'm agnostic, but certainly semantic
| versioning was normative long before "Semantic Versioning"
| existed.) But if your answer to API compatibility starts with
| Semantic Versioning, then I wouldn't want to have anything to
| do with your library. It's like asking a bank what their
| approach to risk management will be and they answer,
| "following regulatory guidelines". It's not actually a
| substantive answer to the question, and suggests that one
| should avoid that bank.
| thaumasiotes wrote:
| slowmovintarget is right. The default expectation was that
| things didn't break. Version numbers increased on release.
|
| Semantic versioning said to stop basing version numbers on
| what version of the software you're talking about, and
| instead use them to indicate that you just broke everything.
| This only makes sense if it becomes OK to break things. That
| was an assumption that semantic versioning brought us.
| slowmovintarget wrote:
| We're getting downvoted, not because we're wrong, but
| because SemVer doesn't deliver in practice what the
| documentation claims it provides on paper.
|
| What it actually delivers:
|
| - 1.2. _changed_ - > don't care
|
| - 1. _changed_.0 - > don't care (at least I'm not supposed
| to have to care)
|
| - _changed_.0.0 - > you're screwed (maybe, on you to check)
|
| SemVer is an agreed upon way to ship breakage.
| happytoexplain wrote:
| I assume the parent's point is that without an agreement
| similar to SemVer, you _never_ have permission to break
| things, but of course people break things anyway because APIs
| must evolve. Something like SemVer allows you to _clearly
| separate_ things that are and are not "broken", thus in a
| sense giving you permission to break things.
| lewhoo wrote:
| Yeah, you watch a tutorial, it's 3 months old - nothing works.
| GulpGulp wrote:
| Dependency hell is a very old phenomenon. We've been here for a
| long time.
| chankstein38 wrote:
| Man I haven't played with Linux for a while but back in the
| early 00s it was a dumpster fire of dependency hell!
| crabmusket wrote:
| I'm trying to help update a Drupal site from 7 to 9. There are
| 95 installed plugins that need to be replaced due to not being
| updated for new versions of Drupal. That's just what happens
| when you rely on community maintenance over years and major
| version changes.
| jleyank wrote:
| Why was this flagged? Language? It seems to address a problem in
| how Foss hangs together...
| commandlinefan wrote:
| > How did we get here
|
| By not paying people to maintain critical infrastructure?
| recursivedoubts wrote:
| can't have your dependencies break if you don't have any
| dependencies...
|
| https://bundlephobia.com/package/htmx.org
|
| roll safe, kids
| chiefalchemist wrote:
| How? Simple. It's all about the short term. It's all about the
| immediate. It's all about now.
|
| Maintainablity? Sustainability? Fergetaboutit.
| usefulcat wrote:
| Not sure why the author seems so surprised.. more dependencies ==
| more dependency hell.
| meindnoch wrote:
| Who told you to install any of those frameworks?
|
| Vanilla JS have been perfectly tenable for a while now. No, you
| don't need to use React.
| dredmorbius wrote:
| Not sure if it's my own config or not (heavily ad/privacy-
| configured), but the story is 404 for me. Alts include:
|
| Archive Today: <https://archive.is/QZ3AO> (I'd submitted that,
| which suggests that the problem is in my own Web configs...)
|
| Wayback / IA:
| <https://web.archive.org/web/20230407211857/https://fagnerbra...>
|
| Google Cache:
| <https://webcache.googleusercontent.com/search?q=cache:https:...>
| janci wrote:
| We got here by making it so easy to use 3rd party libraries and
| also making it easy to create and publish them regardless of
| quality. I do not think it is a bad thing. But if it's easy and
| fast people will do it more often and we end up with projects
| with ton of dependencies that are ever evolving.
|
| I also think "not invented here syndrome" is not (always) bad. A
| piece of your own codebase instead of a 3rd party library can
| have less maintenance cost even if it's a often reused piece of
| functionality. I always deliberate on adding just another library
| even if it's just one npm install away.
| jollyllama wrote:
| The state of front-end dev can only be explained by madness or
| intentionally creating barriers to entry and hedging for job
| security.
| janci wrote:
| Never attribute to malice...
|
| I actually always tought of web frontend to be the easiest to
| start with. But that only applies to starting a very simple
| project from scratch without external dependencies. Afterwards
| the complexity grows very, very steeply.
|
| Starting new fully featured web project takes me whole day. And
| if I want to use recent version of the stack, everytime I have
| to forget everything I knew and start again, because everything
| changed totally since I did it last time.
| jollyllama wrote:
| Very accurate. At first, it's all fun and games and you're
| adding this and that npm dependency. The crying comes later.
| moonchrome wrote:
| I'd say it's lack of barriers to entry, boot camp ninjas that
| maintain dozens of packages.
|
| The fact that some newbie would upload is-odd[1] to npm doesn't
| surprise me. The fact that it has half a million weekly
| downloads - it's blind leading the blind.
|
| And framework complexity - I find that consistent with mid
| level programmers being fascinated by complex solutions and top
| scale teams needing to deal with the pile of shit they are
| building on (DOM/JS)
|
| [1] https://www.npmjs.com/package/is-odd
| lern_too_spel wrote:
| Because nobody got around to fixing it yet. Infrastructure can be
| built to keep these packages' dependencies up-to-date by default.
| If they break on dependency update, the maintainer should be
| alerted, and the package should no longer be recommended until it
| is fixed. Relying on individual maintainers to do everything
| correctly themselves has never worked.
| phailhaus wrote:
| > The number of broken packages that don't adapt to newer
| versions of other packages or that don't work anymore by doing
| nothing is absolutely unbelievable.
|
| No it's not. It costs nothing to not write defensively,
| especially in an untyped language. This can easily be an article
| about Python as well.
| Gehinnn wrote:
| I'd say its less about writing defensively (protecting yourself
| against libraries who don't deliver what they promised) and
| more about users making stronger assumptions than what the
| library promised (eg assuming json string literals contain no
| escaped characters so that a simple ". *?" to match the value
| is fine, that some value is always defined or generally that a
| behavior observed two out of two times must be the rule).
| chankstein38 wrote:
| While the author isn't wrong, is it just me or does this article
| come off as the author just whining that they used a bunch of
| libraries that they didn't research well enough first and they
| went out of support?
|
| This is the price you pay for the convenience of not having to
| write all the stuff. Yeah updates suck and it sucks people don't
| maintain their libraries better or write them better to begin
| with but people have lives and may be doing this stuff on their
| own isn't sustainable beyond a point.
|
| The solution could be "less people make libraries" or it could be
| "more people make libraries and more people help maintain them"
| or it could be that people who make apps stop using libraries and
| write the code themselves.
|
| You can't force people to maintain every piece of code they put
| online just in case someone uses them in one of their apps then a
| year later wants to update their app. What if the end user wanted
| a different specific version?
|
| This stuff annoys me as much as anybody but whining and posting
| it to hackernews is just self-flagellation.
| asmor wrote:
| It's a problem you can't really evade if you're on the modern
| JS stack train. A lot of that has to do with frameworks running
| into the same issue. Some part of the build stack retires an
| old version unannounced, and now you have an entire cascade of
| rushed out updates.
___________________________________________________________________
(page generated 2023-04-07 23:01 UTC)