[HN Gopher] Why is front-end development so unstable? (2018)
___________________________________________________________________
Why is front-end development so unstable? (2018)
Author : ddtaylor
Score : 82 points
Date : 2022-05-30 18:45 UTC (4 hours ago)
(HTM) web link (www.breck-mckye.com)
(TXT) w3m dump (www.breck-mckye.com)
| shaunxcode wrote:
| Because it is the frontier which by definition is unstable!
| jansan wrote:
| Front end develoment has never been more fun if you can keep up
| with the pace. Finally all major browsers have decent standard
| support (no Internet Explorer anymore), so crutches like jQuery
| are not needed anymore.
|
| Developers constantly find new ways to implement front end apps,
| and they are not afraid to break backwards compatibility. This
| may be bad if you have an old monolith to maintain, but overall
| it's a good thing IMO.
|
| Also, this is not limited to libraries. Have you looked at what
| speed Chrome devs are implementing new APIs? It's insane. And
| great.
| jraph wrote:
| > Have you looked at what speed Chrome devs are implementing
| new APIs? It's insane. And great.
|
| It's not great. It is bad, really. It means no one that hasn't
| dozen millions of dollars can implement or even just maintain a
| viable browser that can keep up. And since we expect browsers
| to be free, that means... "complicated" business models _cough_
| mostly1 relying on ads and tracking _cough_ to maintain the
| Web.
|
| I which it wasn't this way really. There was a time when it was
| possible for a few people to implement a quite good browser
| engine in their free time. KHTML. So good, in fact, that it was
| chosen as the basis of WebKit (and therefore Blink). This does
| not seem possible anymore.
|
| 1. There's Apple maintaining a browser engine without relying
| on ads, but their business model is also questionable.
| daenz wrote:
| Fads are tempered by a community of people anchored in a deep
| understanding of the technology. As talented as many FE engineers
| are, I can count on one hand the number that I've met that have a
| deep understanding of things like await/async + Futures,
| closures, DOM trees, etc. These things are (perhaps
| unfortunately) required to do FE work, yet the engineers using
| them don't fully understand them, so they don't know how to
| discern if helper libraries are actually helpful.
|
| Additionally, I'd argue FE draws more junior people in general,
| because of the theoretical rapid feedback loop, and the fact that
| you can "make something that looks cool" with relatively little
| effort (relative to a BE engineer). These junior people add
| confusion to the chaos of the community because they don't know
| what they don't know, so they're cocksure about their opinions.
| And as long as they've "made something that looks cool", even if
| the architecture behind it is hot garbage, it buys them cred in
| the community.
|
| Somewhat related, I've been using Flutter for a recent FE project
| and I'm in love with it. It's more for webs/mobile applications
| than websites, but the ergonomics of it feel like a coherent
| vision. The people maintaining it (Googlers) are excellent, and
| the Dart library community seems to know what they're doing.
| Furthermore, the FE design choices are based on Material
| Design[0], which is backed by (some informal) research by UI and
| UX professionals, so you don't have to sweat usability quite as
| much as you would starting from scratch.
|
| 0. https://material.io/components?platform=flutter
| randomtwiddler wrote:
| It's interesting how you can look down on front end for being
| new and naive while suggesting that Google is a fine reliable
| tech stack provider.
|
| I'm the opposite of everything about this post. A very
| experienced dev (>20 years professional experience) that has
| moved primarily to the front end recently in my career
| (gradually over 4 years). I won't touch flutter simply because
| the sole vendor and essential dependency is Google.
|
| Fads are present in every corner of development. As is "not
| invented here" or the general draw to green field.
| daenz wrote:
| If you're looking for a response, you're not really giving me
| much to respond to. Why do you think Google doesn't provide a
| "reliable tech stack" ? In any case, I wasn't suggesting that
| specifically (though I tend to agree with it), only that they
| have a coherent ergonomic vision by competent engineers.
| randomtwiddler wrote:
| Google doesn't have a track record of long term support for
| their projects. They readily cancel them when they want to.
|
| I would hate to invest precious years into tech and apps to
| have the rug pulled out from under me because flutter
| entered the Google graveyard.
|
| They do have competent engineers, and if they get
| sufficient community buy-in, I'll be much more open to it.
| daenz wrote:
| That's fair. I feel more confident about Google's OSS
| (like flutter) surviving than I do about Google's
| consumer products. The flutter community is very strong,
| and as far as offerings go, it's (imo) the strongest
| product that abstracts UI/UX development over web and
| mobile, and the demand for that abstraction is very real.
|
| Plus having Dart (which feels a bit like Java, but less
| verbose) as the foundation language raises the bar in
| terms of library code quality (compared to Javascript at
| least)
| blenderdt wrote:
| It also has to do with the low entry level. The same happened to
| PHP. Inexperienced programmers can easily create nice things that
| look great on the outside.
|
| Libs like React and Vue are stable enough but when you throw in a
| lot of other dependencies it is always the question how
| experienced the creators were. And when unstable libs become
| popular bugs and security issues are exposed, pull requests are
| created and before you know it a next version is launched that is
| not backwards compatible.
| [deleted]
| DrFell wrote:
| Because it's all social media trends driven by noobs?
| anyonecancode wrote:
| Maybe I'm the odd one out, but I feel like the instability is
| mostly surface-level and FE is not, actually, so much less stable
| than other areas? I got into tech via web development, migrating
| further into the backend over time, and about four years ago
| became pretty much exclusively backend. Just started a new job
| and I'm back in the front end.
|
| Some things have changed, but not that much.
|
| - Typescript was just getting popular when I left, now it's
| basically a standard, but 1) after having been in javaland for a
| while, adding typing to JS makes a lot of sense to me and 2)
| though it's a change, feels like a change toward more stability,
| not less?
|
| - React was the big framework when I left, still is the dominant
| framework.
|
| - There's still a lot of option -- eg vue, etc. nextjs wasn't a
| thing I knew about that I am starting to learn now. Class syntax
| felt unecessary to me but seems to be de facto these days. But...
| these all feel relatively small?
|
| I started in FE back in the days of IE 6. jQuery was a godsend
| when it arrived, underscore was super helpful. I'll grant the
| shift from "we use JS to add some interaction, form validation,
| and sometimes interact with Flash" to "we use JS to write actual
| programs delivered via your browser" was a huge shift, but since
| we've made that shift it seems most of the "instability" is more
| around FE devs adopting practices already common in the rest of
| the stack.
|
| I think maybe that's where this sense of instability comes from
| -- a focus on the wide array of possible _implementations_ -- but
| I feel the really disruptive shift from "interactive decoration"
| to "web applications" was the really big one, and that's a while
| back now. And even with the dizzying array of possible
| implementations, there's obvious market leaders -- you're not
| going to go wrong by learning React, any more than you're going
| to go wrong by learning Spring Boot. Always good to explore and
| get familiar with other libraries and frameworks, but if one feel
| overwhelmed by options, there's some clear well trodden paths
| that aren't changing _that_ fast.
|
| One thing I will say is that I do think FE is _harder_ than BE,
| because the scope is wider. You need to grasp all the aspects of
| good programming, but _also_ get a decent grounding in design and
| UX, which are their own disciplines. A backend API doesn't have
| to think about things like screen readers or color contrast or
| all the weird ways users will figure out to misunderstand how to
| interact with your GUI widgets. A UI for humans is inherently
| harder than a UI for machines. But that's not the same thing as
| saying that the FE is unstable.
| danenania wrote:
| A lot of it is that UI programming is just difficult and
| inherently complex.
|
| Expectations of users are very high and always shifting.
| Browsers/consumer OSes are constantly moving targets. Mistakes
| and bugs, even small ones, stand out in a glaring way, so there's
| low forgiveness. There are more code paths and they're harder to
| test.
|
| All that means that unless you want to miss your deadline by a
| year or leave a bad impression on users, you will need a lot of
| libraries!
|
| Backend/systems specialists always underestimate how hard UI
| programming is. Then they try their hand at frontend and quickly
| run into a wall. They find they either need to build something
| clunky that users aren't impressed by or else spend a lot of time
| learning new tools and paradigms (and yes, installing lots of
| dependencies /shiver). This is a blow to the ego, so it's better
| to criticize the language, the culture, the "churn"... anything
| to avoid admitting the pixel pushers are solving seriously tough
| problems too :)
| [deleted]
| daenz wrote:
| >anything to avoid admitting the pixel pushers are solving
| seriously tough problems too :)
|
| That's not how I view it, as a SRE/BE-SWE who has done
| substantial visual/FE work. From my perspective, the majority
| of problems in FE are due to extremely poor libraries and
| standards, bolstered by a community where copying and pasting
| large chunks of unknown code is acceptable. Yes, there are
| "seriously tough problems" with trying to develop in that
| world, but they are of a different world than most BE problems,
| from my experience. So they feel comparably difficult, but for
| very different reasons.
| zackify wrote:
| I've been using react for 8 years. In that time I've gone from
| webpack, to vite.
|
| Lately using remix or nextjs. Not that much has had to change in
| that time, it definitely feels more stable in the past 5 years or
| so.
|
| Every new library is using components, just with their own
| preferred syntax.
| taeric wrote:
| I'll agree it feels a little more stable in the past 5 years or
| so. I do have a sense that a lot of the UI libraries we used on
| our project are working fine, but are also deprecated and have
| a doom's day clock on them. Oddly, this is as much from "in
| house" widgets as it is 'in the wild" ones.
|
| Specifically, I know that if we want to bring in some widgets
| that were created this year, we have a massive upgrade task
| ahead of us. :(
| ldjkfkdsjnv wrote:
| Yeah I actually think react is the stability. Its still here,
| still the main choice.
| newbieuser wrote:
| I think we should stop talking about libraries and talk about the
| crap of browser specs. Libraries are just a tool and evolve over
| the years. but browsers are getting worse every year
| eyelidlessness wrote:
| Asking sincerely because this take is surprising to me: which
| specs are you referring to?
|
| From my perspective--started front end, gradually went full
| stack, spent several years fully back end, dove back in a
| couple years ago--quite a lot of the APIs introduced in the
| period I was fully back end (and since) are excellent and
| vastly improve both development experience and the ability to
| deliver a better user experience.
|
| I'm not saying your take is _wrong_ necessarily, I just don't
| immediately relate to it and I'm curious what specifically you
| find objectionable.
| spiffytech wrote:
| > Asking sincerely because this take is surprising to me:
| which specs are you referring to?
|
| I'd like to see the Web Components spec revisited: it has a)
| no API for passing non-string attributes to other web
| components, b) no API for declaratively updating your DOM
| subtree - you either do manual surgical DOM changes, or blow
| away your (potentially stateful) children and recreate them.
|
| Without these, the raw web components API isn't suitable as
| an alternative to React et al. You've got to build a whole
| framework around them (like Lit), and at that point you're
| just using another framework.
| marcosdumay wrote:
| Hum... The Great (Web) Frontend Revamping seems to have passed.
| Nowadays people are still discussing if React or Vue is better,
| with a clear intonation of "whatever works for you, I prefer X".
|
| Looks like the field is maturing.
|
| Either that or we are on a fake calm before we see a lot of
| articles about people migrating into wasm in "whatever language
| has support for it right now" (AFAIK, currently wasm goes with
| rust).
| sircastor wrote:
| This doesn't feel that different to me from ~2010 era jQuery vs
| Prototype vs ...Dojo(?) these things happen in waves. I've
| wondered if the next revolution will be wasm, or another round
| of JS magic... or something different.
| jansan wrote:
| If you started with Vue two years ago, you had to learn Vue 3
| shortly after that. With a new Vuex. Which has been dropped
| since in favor of Pinia. Oh, Vite has been developed since, so
| you may want to add this to your stack, because it makes
| compiling during development so much faster. Also, be aware of
| all the breaking changes that Webpack 5 has introduced.
|
| I hope front end development will be more stable in future, but
| the last two years where full of pretty major changes.
| suction wrote:
| The Vue 3 disaster (in my opinion) shook my trust in the
| framework forever. I immediately knew this is not a framework
| I will spend any more time in. What if I "upgrade" my apps to
| 3 and then Vue 4 comes along with yet another fundamentally
| different concept? This is not acceptable for apps with any
| kind of long time support requirement. Yes I know, Vue 2
| paradigms are still usable in 3 but they feel very
| deprecated.
| gherkinnn wrote:
| Coming from Vue 0.x and 1, Vue 2 felt wrong. It didn't know
| what it wanted. Classes and hooks and decorators and
| options and only some obscure combination offered
| acceptable TS support.
|
| Having only read the docs, Vue redeemed itself with version
| 3.
|
| There's the options API we know and love from v1 and the
| new and intuitive composition API. The docs make it easy to
| decide and not to mix them up. And no useEffect fuckery.
| KaoruAoiShiho wrote:
| Don't think Vue 2 to Vue 3 is that bad, certainly nothing
| like AngularJS to Angular. You can still conservatively
| upgrade piecemeal elements of your stack and most of the
| code still just works.
| darepublic wrote:
| Don't worry, view layer may be stabilizing but what about
|
| Managing backend requests is too complicated!(react-query)
|
| You *need* gql don't you?
|
| Don't forget forms. Super hard to do right. react-final form,
| react form hook, etc
|
| We need a monorepo framework! Nx, turbo, rush, pnpm (too low
| level), Lerna (too old and unmaintained)
|
| What about bundlers huh? Vite, esbuild, rollup, webpack
|
| I still see plenty of opportunity for teams to ignore
| persistent issues and just diagnose a new framework without
| analyzing their current woes. Silver bullets for everyone!
| nicoburns wrote:
| The difference is that's all ignorable. If you want to
| standard React with classes, redux, npm and webpack like it's
| 2017 then you absolutely can, and it's still a maintained and
| supported solution.
|
| That's very different to say the evolution from JQuery to
| Backbone to AngularJS to React where you ended up being on an
| increasingly unsupported platform if you didn't upgrade.
| darepublic wrote:
| It's not really ignorable, these frameworks come ready made
| with converts seeking to spread the good news to every
| codebase they find. Understanding, let alone improving,
| legacy code is a total waste of their awesome powers. It's
| raze the city and build paradise from scratch. Using shiny
| new framework (tm).
| nicoburns wrote:
| That's what tech leads are for. To be the person with
| experience and judgement who has the authority to set the
| rules for the rest of the team on these kind of
| questions. If you're having problems with this I'd
| suggest you have more of a hiring problem than a
| framework problem.
| darepublic wrote:
| you might be right on the money with that. I mean it also
| reflects badly on me in regards sort of jobs I find
| myself in where this is a recurring problem. But.. I feel
| like it may be more widespread problem than most people
| admit.
| [deleted]
| Atheros wrote:
| UI/UX is a fundamentally flawed field for a number of
| intersecting reasons, most of which boil down to not really
| distinguishing between when it's doing engineering, when it's
| doing psychology, and when it's doing fashion. And these days, on
| web apps and mobile apps, it mostly does fashion. Fashion must
| change for the sake of change. To more easily support these
| frequent changes, more libraries get invented to make doing new
| things easier. After that, everything in the article makes sense.
| sjtindell wrote:
| I'm not sure fashion feels like the right term. People just
| assume newer equals better. So they want to use the latest and
| "greatest".
| azemetre wrote:
| This sounds exactly like fashion to me. One just has to look
| at how often design has changed over the last decade with the
| many fads and worst UX.
|
| I feel like when you have an org of designers they will
| justify in wanting to redesign everything because why else do
| you need them? The same can be said for some POs and devs as
| well IMO.
| fny wrote:
| Yup. The most brutal environments I've ever worked in
| canned design folk very quickly once a cost crunch arrived.
| Some startups would even can designers first to save cash.
| [deleted]
| csande17 wrote:
| > Fashion must change for the sake of change. To more easily
| support these frequent changes, more libraries get invented to
| make doing new things easier.
|
| The frontend "ecosystem" libraries discussed in the article are
| _also_ subject to a fashion hype cycle, independently of UI /UX
| design trends. A lot of them don't actually make anything
| easier, or don't make rapid design iteration easier at least.
| [deleted]
| HidyBush wrote:
| The old saying goes like this: "if you want freedom on one layer
| you need stability on the layer below"
|
| My guess is that since frontend web development is at the top of
| the stack it has an incredible amount of freedom so everything
| changes every minute. You don't see too many people wanting to
| subvert HTTP making a billion homemade alternatives
| capableweb wrote:
| > You don't see too many people wanting to subvert HTTP making
| a billion homemade alternatives
|
| No? I constantly come across new protocols, promising
| improvements compared to it. Some even become relatively
| popular and are included in browsers by default. Just some
| examples are WebSockets, WebRTC and QUIC. I expect we'll see
| more of them in the future as specific use cases requires more
| specific protocols.
| ezsmi wrote:
| I think you make a fair point but on the other hand I don't
| see many "top 20 alternatives to http in 2022" articles
| (which implies there are more than 20 alternatives) like we
| have for front end technologies.
|
| I.e. https://www.netguru.com/blog/front-end-technologies
| bobthepanda wrote:
| I think part of it is also level of effort.
|
| You could right click "inspect element" in any browser and
| mess around in the html or the JS console and see things
| happening live. This is an extremely low barrier to entry.
|
| Low barriers to entry are good, our profession is very well
| compensated and developed economies could certainly use low
| effort ways to get people from lower compensated jobs into
| higher compensated jobs* but that also means that there are
| _a lot_ of cooks in the kitchen.
|
| ---
|
| * yes, tech isn't for everyone (what job is?), and when I
| say low barrier to entry I mean you don't really need to
| subject yourself to what could easily be 5-10 years of
| schooling in medicine or law or engineering.
| HidyBush wrote:
| the level of effort is determined by how deep in the
| stack you are. if you make a new JS framework every
| single browser will run it, if you make a new web
| scripting language good luck getting support from even
| one browser
| dgb23 wrote:
| Those are orthogonal choices though.
| jokethrowaway wrote:
| Frontend is the entry level field for all those people who were
| not developers but wanted a slice of the salary pie. Designers,
| architect, lawyers. I've seen everything.
|
| I know a few React engineers in my company who can make
| components and be productive - but they don't know JavaScript and
| they get stuck when something is slightly different from what
| they're expecting.
|
| Similarly I'm mentoring a few engineers who started with react
| and are trying to learn backend and other languages.
|
| Being the field where all the least developer figures start means
| you'll have tons of people, tons of visibility, tons of cargo
| culting and tons of crap being built just to make you look
| cooler. I'm guilty of this as well, I have my frontend framework
| on GitHub and it's quite useless - even if it's a nice idea.
|
| Of course nobody bothers to maintain stuff and everything is
| trying to make money on their junior devs fanboys.
| spion wrote:
| Lack of standardization is the primary reason we have this
| problem in the JS ecosystem.
|
| "Productive" ecosystems (e.g. Rails, Elixir) usually have one
| central framework that provides the standard basics. Libraries,
| tools and other extensions are built on top of the framework to
| enhance the feature set. Everything typically works well
| together.
|
| JavaScript has multiple frameworks to implement components,
| multiple tools to implement bundling, multiple tools to implement
| modular/extensible stylesheets, multiple package managers with
| somewhat different features (e.g. when it comes to monorepo
| support), and multiple libraries to implement basic standard
| functions.
|
| Many of these are not compatible with each other. Compatibility
| is a combinatorial explosion problem that cannot be solved
| without standardization. Without it, you need to have m*n modules
| to have m things talk to n other things. Extensions to the
| ecosystem therefore typically have partial compatibility with all
| the tools, which further widens the breadth of the problem.
|
| There's been very little effort in the community to standardize
| interfaces and protocols: but for the few things where it has
| been successful (e.g. see package.json) we've seen much nicer and
| smoother interop/tool interchangeability. We need more of this,
| especially when it comes to open-ended "plugin" style stuff (e.g.
| bundler plugins/extensions, component interfaces, monorepo
| structures)
| sbf501 wrote:
| Here's an unpopular opinion: it is unstable because we don't know
| what exactly "front-end" means. First it was static HTML pages,
| then it was CGI, then it was PHP, then it was Rails, then it was
| Node, then it was React, Angular, Vue...
|
| Those aren't random progressions. On the contrary, they are
| front-end devs responding to needs of the UX moreso than the UI.
| There have been major efforts to make reactivity match what the
| user is trying to do, but we're still in unstable-land because
| we're building the bridge while we cross (I hate that analogy but
| it is true).
|
| Just my $0.01.
| truthwhisperer wrote:
| heseyin wrote:
| moonchrome wrote:
| Saying React support libraries are at fault here is not fair -
| React basically reimagined itself over the years and went from OO
| and class based components to hooks and functions. The fact that
| you can still do OO isn't really helping it since it adds to the
| complexity of things you need to learn to grasp the ecosystem.
|
| But that's honestly missing the forest for the trees - JavaScript
| itself went from asynchronous callback pyramid of doom, to
| promises and callback chaining, to async/await. The community
| went through multiple half-assed module
| approaches/specifications. Several FOTM bundlers with extreme
| complexity and various tradeoffs. Various build systems.
|
| Features like hot reloading, transpiling, source mapping,
| shimming are table stakes for any frontend framework and involve
| _a lot_ of complexity and tooling - because the entire ecosystem
| is built on a foundation of shit that is JS and the browsers.
|
| So frontend frameworks are the least relevant part here - it's
| everything that makes them tick that's the problem.
| holoduke wrote:
| I don't know one single UI/UX development environment which is
| elegant and nice. From Android to iOS to Linux to Linux and
| Windows to browser UI kits. They are all complex and require
| constant searching for answers. The libraries are very big and
| require a complex tooling setup. You can never be an expert in
| all of them. At least not me.
| api wrote:
| My pet hypothesis for years has been that developers always
| vastly underestimate the difficulty of doing a UI framework
| or environment. They think it'll just be a matter of painting
| widgets and presenting data. As a result they under-build the
| foundation. The insufficient structure is then released out
| to the world for everyone else to build upon.
|
| Once people realize the soul devouring chthonic difficulty of
| doing good modern UI, they've already built on a shit
| foundation and been forced to realize the full system with a
| heap of ugly hacks and workarounds.
|
| Then someone thinks "wow, this is way too complex! All I need
| is a simple UI." Then history repeats.
|
| You can see this with immediate mode clean simple GUI library
| of the week. They all stagnate after getting all the basics
| working, and there's a reason for this.
|
| A good mature modern UI is at least on par with a high-end
| game engine like Unity in terms of feature surface area and
| difficulty. In some ways it's worse because while the breadth
| and size of the problem domain is similar the problems you
| encounter in a game engine are probably a lot more fun. UI is
| a hell of incredibly hairy state management and a really long
| tail of edge cases.
| cloogshicer wrote:
| I think you're spot on.
|
| My hypothesis has been for a while: UIs essentially _are_
| video games. They have animations and interactions that
| rival the complexity of video games. Sometimes they even
| have sounds too. The rendering is not quite as complex
| (usually!), but everything else definitely is.
|
| I'd like to see a UI system that is built by experienced
| game devs, who _also_ are good at and understand
| interaction design.
| jwatte wrote:
| This is probably a better comparison than one might at
| first think.
|
| A game engine has a second, hidden, part of the iceberg:
| The production pipeline for all the 3D world/art assets.
|
| That's actually where most of the work goes -- hundreds
| of artists go into a AAA game, and all the art they
| produce must be technically excellent along a bunch of
| dimensions that have nothing to do with what it looks
| like (and in fact, generally make it harder to achieve
| the look you want.)
|
| Game engines that can wire physics simulation to 3D
| rendering to window abstractions are easy-ish to make,
| similar to how web UI frameworks are easy-ish to make.
|
| All the production pipeline stuff is where the real meat
| is, similar to how in WebUI and, package management and
| transpiling and bundling and deploying is a hard problem.
| I think the game side has it even harder than the web
| side, though, although they usually have the benefit of
| only needing to work on a defined set of platforms,
| rather than in "the" browser.
| [deleted]
| moonchrome wrote:
| Pretty much anything after C/C++ era comes with a usable
| build system, modules and a package manager. JS is really
| stuck dealing with insanely low level issues in shit ways for
| various historic reasons.
|
| As shitty as Android support matrix can be - it doesn't
| compare to IE6 web days (at least in terms of UI development,
| stuff like OS services is entirely next level - but you can't
| even start doing that in JS so it's not really a fair
| comparison) - and we're still paying for the technical
| decisions made in that era (how many people are polyfiling
| all the way back to stone age and including hundreds of KB of
| useless shit ?).
| jhgb wrote:
| > Pretty much anything after C/C++ era comes with a usable
| build system, modules and a package manager. JS is really
| stuck dealing with insanely low level issues in shit ways
| for various historic reasons.
|
| But of course JS needs neither a build system (runs from
| source files) nor a package manager (runs from URLs) and
| recently even plugged the "no modules" hole.
| irrational wrote:
| > recently even plugged the "no modules" hole
|
| I haven't heard about this. Do you have a link so I can
| read more?
| jhgb wrote:
| Well, they added modules some time ago and now they're
| widely supported. Not quite sure what more there is to
| say about that. Aside from botched variable scoping, that
| was probably my biggest grip with JS (but `let` fixed
| scoping many years ago as well).
| moonchrome wrote:
| Majority of people using JS with these frameworks are
| using package management and bundling - and suffering
| because the ecosystem has such shitty tools for dealing
| with it.
|
| If you're linking jquery from your favorite CDN and
| writing your code inside of <script> tags you're not
| dealing with the issues this article is describing.
| jhgb wrote:
| Right. But that's their choice. I actually really like
| what Mithril.js did, regarding decisions on size,
| complexity, distribution as a single file, etc. Pretty
| much the only thing I'd like more would be if some
| similar library targeted both HTML5 web and Sciter (since
| Sciter does some things in its own -- and very efficient
| -- way and it would be interesting if something filled in
| the details in the web platform that web omits but Sciter
| does not to come up with something Mithil.js-like but
| also usable on desktop).
| contingencies wrote:
| This. Use what works and is stable. I strongly dislike JS
| (PTSD, perhaps) but when it comes to minimal code to get
| the job done, jQuery is where it's at: the _perl_ of JS
| frameworks.
| chrisco255 wrote:
| Very few websites/frameworks/libraries support IE nowadays.
| And Edge being Chromium-based, means most of the polyfill
| issues have been resolved. You can reach 99+% of browsers
| by writing in modern web standards (HTML5/CSS3) without
| having to worry much. Web dev is probably nicer than it's
| ever been.
| hkon wrote:
| I think WPF is nice and elegant. Although complex.
| avens19 wrote:
| Was going to reply with WPF. The best I've used for UX dev
| [deleted]
| bigmattystyles wrote:
| I think that if you want a page to impress or make a splash then
| sure, you always have to move to the next greatest thing,
| however, I don't work for them but I've paid for Telerik Kendo
| Controls (the react ones specifically)since they were released,
| before then, the AngularJs ones and it's been great - it keeps my
| (albeit internal app) UI development stable, fast and looks great
| with minimal fussing about. It's been years now and it feels very
| stable and quick. The switch from AngularJs to React was the only
| unstable part, but it was at an inflection point in the number of
| apps I had to support and develop, so the change was actually
| welcome. YMMV (edit - I just realized I spent the weekend
| experimenting with MAUI, so I'm full of it)
| Etheryte wrote:
| I had to read your comment twice to be sure we're talking about
| the same Kendo. I've consulted for a number of companies over
| the years who have used it (or tried to use it), ever since the
| jQuery version to up until now, and it's always been pure pain.
| I understand how their components work, I understand the
| underlying architecture because I've stepped through it too
| many times with a debugger, and I still always fail to
| understand how they have any happy customers. Perhaps there is
| a good experience to be had if you only use the components
| exactly the way the documentation examples use them, but the
| moment you step outside that narrow path, things fall apart.
| Never mind custom code, simply using two different components
| from their library together doesn't even always work.
|
| The first time I had a bout with Kendo was some odd ten years
| ago, and then I was sure it was simply me not understanding the
| framework. After all, every component library has its own kinks
| and it takes a while to get up to speed. After seeing them
| again and again many times over the years, I've changed my
| opinion. In my eyes, Kendo is what I like to call an MBA trap.
| It ticks all the boxes that an MBA manager going by a feature
| checklist is looking for, but under the hood it's garbage
| software. I'm glad you've had a good experience, at the same
| time I don't think I will ever stop recommending everyone to
| stay away from Kendo.
| bigmattystyles wrote:
| I don't agree with you but I don't disagree either. Our use
| cases are very vanilla, and now that I have quite a bit of
| sway in my team, when people deviate from the showcased Kendo
| way, I push back and see if the desired way deviating from
| Kendo is a necessity or a nice to have. If it's the former,
| we sometimes have the experience you described, though I've
| often be helped by stackoverflow, their forums or Kendo's
| support team. (We pay for the 24 hour tier). If it's the
| latter then I force the Kendo way. FWIW, their ODATA v4
| support OOTB with dotnetcore webapi with its ODATA v4 out of
| the box with an EF model is the perfect pattern for most of
| our use cases. But again, I don't disagree with you either -
| but I would stress that any alternatives I've seen have their
| same range of issues.
| dang wrote:
| Discussed at the time:
|
| _Why Is Front-End Development So Unstable?_ -
| https://news.ycombinator.com/item?id=17190992 - May 2018 (354
| comments)
|
| _Why Is Front-End Development So Unstable? A Perspective_ -
| https://news.ycombinator.com/item?id=17182748 - May 2018 (5
| comments)
| lopatin wrote:
| The article starts off with an outdated take on the space:
|
| "We all know the meme: by the time you've learned one front-end
| technology, another three have just been released. Also, that one
| you just learned? It's deprecated."
|
| Maybe it's because the article is 4 years old. I just don't think
| it's true anymore. Ok there's React and Vue and others, but
| that's fine. It's basically the same tech, but they have
| DX/cosmetic differences. It's not like we're still arguing
| whether or not VDOM is a good thing.
|
| That said, the "Imagine being a junior developer" section sounds
| spot on still. Maybe it's because those articles that use
| dogmatic arguments to recommend inferior technologies are still
| on the internet, and they are not going anywhere.
| croes wrote:
| I thought VDom is old school since Svelte and such?
|
| https://news.ycombinator.com/item?id=19950253
| lopatin wrote:
| I was waiting for someone to mention Svelte :)
|
| I think it's is very possible that it's the next evolution of
| innovation in the space. It _might_ actually be a Backbone -
| > React style quantum leap in terms of tech and adoption. The
| thing is, that won't happen for another 10 years, if it does
| at all. It could very well turn out to be a niche technology
| for most people, with minimal real-life benefits compared to
| the drawbacks of moving off the mainstream.
|
| Every space has new innovative technologies that risk
| upsetting the status quo. I'm not saying things are
| completely boring now. Just that, unlike in the mid 2010s,
| they are actually stable enough.
| runarberg wrote:
| As far as I know most native web components use direct DOM
| manipulations over a virtual DOM. So I think the jury is
| pretty much out on VDOM and we are witnessing it transition
| to a relic of legacy frameworks.
|
| As far as other innovations Svelte has brought, Vue with
| the <script setup> sugar looks quite similar to Svelte, as
| well as compiling to a render function (just like Svelte).
| I'm not super familiar with the intrinsics of Vue but the
| VDOM is starting to feel like a thin MIR of the framework
| which could be swapped out in a future major release,
| rather then something essential to it.
|
| I honestly think that 10 years is a very conservative
| prediction.
| Matumio wrote:
| Ah, the irony. An article arguing about how fast web-dev is
| moving is itself considered outdated just four years later.
| jbreckmckye wrote:
| I'm the author and I agree. Things have slowed down and
| matured. The "JS moves too fast" meme is well out of date, and
| in fact I wrote a comment here a few hours ago bemoaning it
| escape_goat wrote:
| I don't know what it's like these days but I recall
| especially the pernicious 'evangelism'. People on a literal
| salary promoting frameworks like they were from marketing. As
| a bargain basement, self-taught, late web 1.0 dev more
| comfortable on the server side I remember rake-stepping the
| undiscussed limitations of Backbone JS, and then studying the
| ridiculous complexities of Angular 1 while reading post after
| post of Angular doctrine, and then learning that the great
| leap forward for Angular 2 was "yeah we're going to throw all
| that bullshit out we were wrong." By the time I was done I
| genuinely had no interest left in me for another new
| framework, package manager, or library.
| jbreckmckye wrote:
| I'm the author of this piece. I no longer think front-end suffers
| the instability people accuse it of.
|
| I think there are a lot of _vendors_ trying to usher in a
| revolution around their particular products - there's a lot of VC
| funding in JavaScript tooling nowadays - but that's a different
| problem.
| pljung wrote:
| I enjoyed reading your article, thanks for writing it. I think
| your recommendation to new devs to focus on Next.js in 2018 (!)
| was prescient.
|
| > I no longer think front-end suffers the instability people
| accuse it of.
|
| Do you mind elaborating why you believe this is the case?
| dylan604 wrote:
| >to focus on Next.js in 2018 (!) was prescient.
|
| now that it is 2022, what's the new flavor that would be
| prescient? I don't ask to actually know, but to reiterate the
| problem of nothing being solid in this world.
| vosper wrote:
| NextJS is still looking pretty good if you're in React
| land. There's new competition, like Remix, Astro, etc...
| but I don't see any of them putting NextJS to bed. I'm
| starting a new application, and I'm still choosing NextJS.
|
| (Now what you couple with NextJS for data access is an
| interesting question - this is where there's a lot of
| innovation. Personally, I'm going with tRPC. I would look
| at Edge DB, but in this application I'll need a recursive
| CTE and Edge can't do it.)
|
| Edit: I do think Astro might replace NextJS for purely-
| static sites, or ones where the "islands of interactivity"
| pattern is compelling.
| markhesketh wrote:
| I'm not in the JS space, but if my twitter feed is anything
| to go by it'll be https://remix.run/
| Jenk wrote:
| Still next.js, probably. Keep an eye on Svelte.
| dgb23 wrote:
| Some of the vendor backed libraries are among the best. But
| generally I would agree that marketing, especially certain
| types, generates a ton of noise, like you beautifully
| illustrated in your article. I think navigating the web with a
| BS filter on is an important skill to have.
| ricardobeat wrote:
| You covered the frameworks, but a lot of the feeling comes from
| the tooling and library ecosystem. For example, a recap of the
| last 10 years:
|
| - grunt / broccoli / gulp / browserify / webpack / metro /
| esbuild / parcel / swc / turborepo / bun
|
| - flummox / redux / unstated / mobx / mobx-state-tree / xstate
| / apollo / apollo-link-state / swr / react-query / zustand /
| recoil / jotai
|
| And this is just within React, and off the top of my head. Then
| you add all the ECMAScript versions, browser feature churn,
| node.js, npm/yarn, immutability, classes, functional
| components, hooks, fiber, the list goes on and on.
| cehrlich wrote:
| It's true that there are a lot of different ways to do the
| same thing, but the good news is you're doing the same thing
| and the difference is mostly just syntax. Someone who has
| used Redux extensively can get up and running with Zustand in
| no time, and vice versa. Likewise React Query and Apollo
| Client are basically the same thing.
|
| Build tools are a bigger issue, but fortunately most front
| end devs don't actually need to deal with them all that
| often.
| nawgz wrote:
| Webpack has been the de facto build system for react since
| 2017
|
| Competing state libraries is to be expected but picking redux
| or mobx has let you use the same ones since 2017
|
| JS itself has improved but hasn't really ever deprecated
| anything, it just grows and adds terse methods to the
| language
|
| Npm and yarn are among the best package managers
|
| React hooks were the only major change you've touched on but
| even they didn't deprecate class based react or change
| library semantics very significantly
| ricardobeat wrote:
| These are not really counterarguments to the fact that
| things change _a lot_ here, and newcomers and veterans
| alike need to continuously learn, and pick the best. None
| of these started off as the default choice, I remember when
| each and every one of these was the weird / risky option.
| nawgz wrote:
| They are very much counter arguments to the idea that
| there is big churn still happening.
|
| Webpack 2 was in CRA in 2017
|
| Redux and MobX have been the #1 and #2 state managements
| for that whole span, and clearly all the observable libs
| are successors of MobX after Proxy came out
|
| Every language changes, many with breaking version
| changed that JS avoids
|
| I don't know how you'd point at package management as an
| issue in JS land
|
| It's just that every single popular community has massive
| amounts of clones or similar libraries, I don't know how
| that qualifies as "churn" though. I maintain my 2017 apps
| including major version bumps with no issues today, using
| the same libraries and tools. The argument you're making
| was fine in 2016 but is half a decade out of date.
| thepasswordis wrote:
| Just to chime in here for anybody reading along:
|
| I work full time as a software developer _doing react_. I
| have got literally no idea what almost everything you listed
| is.
|
| "Broccoli"?
|
| I have heard: grunt, gulp, webpack, metro, redux, and recoil.
| The rest of those could be sarcasm for all I know.
| ricardobeat wrote:
| These are only the mainstream ones I can remember, there
| have been a ton more! I guess if you've started post-2018
| things have been a bit more stable, but there was quite a
| bit of churn to get here. And it's still happening - no two
| React projects are alike even in the enterprise.
|
| https://github.com/broccolijs/broccoli
| mccorrinall wrote:
| That's because react is a library, and not a framework.
| React doesn't have opinions, that's why you can find 300
| state management libraries and 200 routers which do the
| same thing, just in different ways.
| throw_m239339 wrote:
| > That's because react is a library, and not a framework.
|
| React should be considered a framework.
|
| React absolutely imposes a data model (unidirectional
| workflow) to the developer thus a certain code structure.
| The fact that it is light weight compared to Angular
| doesn't change the fact that React is a front end
| framework. React usage completely replaces the
| traditional way to interact with the DOM and manage DOM
| events, thus abstracting it.
|
| > React doesn't have opinions,
|
| React becomes very hard to use if your data model isn't
| organized to suit React architecture.
|
| It doesn't have opinions about everything (like AJAX or
| SPA routing) but it absolutely has an opinion about how
| you data objects should be structured.
| pojzon wrote:
| Frontend is unstable because it attracts ppl whose attention span
| is often lower than the one of a goldfish.
|
| Every JS frontend dev I met was speedrunning trying to prove
| himself by "inventing something new" which in fact was already a
| state of art.
|
| The amount of rehashing and reinventing the wheel with new catchy
| names in the field is staggering.
|
| TBH, if the field wants to improve -> its time to ditch
| JavaScript and force Browsers to move to something that makes
| more sense.
| tenebrisalietum wrote:
| Does WASM make more sense?
| secondcoming wrote:
| The idea is sound, but it'll just allow mediocre JS devs
| write the same crap but in a multithreaded way.
| lopatin wrote:
| Thank you! Part of the reason that I love these front-end
| threads is because inevitably somebody will make a fool of
| themselves by spouting anti-js-dev "backend master-race"
| nonsense, and this certainly did not let me down.
| pojzon wrote:
| It would be true if I was working in backend development. I
| dont.
|
| JS is just not good enough for what we want it to do.
|
| Someone sooner or later has to make a decision to move
| further.
| doomroot wrote:
| No. JS is here to stay, better get used to it.
| rschachte wrote:
| What is JS not good enough for w.r.t front-end dev in your
| eyes?
| oraphalous wrote:
| So your solution to the problem of the field re-inventing
| itself over and over is for it to... re-invent itself again.
| LoveGracePeace wrote:
| Java would be my strong preference.
| taneq wrote:
| To be slightly more charitable, front end attracts self-taught
| devs because the browser is the default dev environment on
| Windows and on phones/tablets and it's far more accessible a
| new players than any other environment.
|
| It's more fun to write code and make stuff up than to find and
| evaluate libraries (especially when said libraries are written
| by self-taught devs), so people tend to reinvent rather than
| research.
| RcouF1uZ4gsC wrote:
| I think part of the reason is the evolution of common user
| networking.
|
| Initially, users had low bandwidth connections, and web pages
| were mostly static with links.
|
| Then came JavaScript interactivity and AJAX.
|
| As users bandwidth grew, we started having heavier frameworks and
| SPAs.
|
| I believe there is another revolution that is happening now
| because of decreased latency. Recently with protocols such as
| HTTP2, web sockets, and edge computing, round trip latency is
| greatly decreased. This is resulting in UI where more of the
| logic lives on the server and has led to such libraries as htmx
| (client) and Turbo.
|
| It will be interesting to see where this settles out.
| blueslurpee wrote:
| Agreed, very interesting things going on in the "edge" space. I
| personally think this is why HN is so jazzed about things like
| fly.io. Super low latency opens up a whole new category of
| applications, it's a "step function" change in that regard.
| crooked-v wrote:
| React is also pushing in the 'edge computing' direction with
| Suspense and with major libs like Next implementing the idea of
| "server components".
___________________________________________________________________
(page generated 2022-05-30 23:00 UTC)