[HN Gopher] React created roadblocks in our enterprise app
___________________________________________________________________
React created roadblocks in our enterprise app
Author : andreiursan
Score : 145 points
Date : 2021-01-22 17:50 UTC (5 hours ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| mattgreenrocks wrote:
| Unsatisfying read. It wasn't React's fault. PM was looking for
| blood. Dumping a bunch of devs who have little experience with
| the tech onto the project. Little notion of process and
| conventions for the app. Only reason I'm commenting is that the
| three questions posed by the CTO are entirely valid questions and
| I wished they'd been answered.
| yummybear wrote:
| It does sound to my like all of these issues would be the same no
| matter what library/framework you chose. Working "against the
| grain", choosing third party libraries, managing coding
| conventions and dealing with code bloat is common to all
| technologies. Unless all these points are adressed, you're
| unlikely to achieve success with any platform.
| cratermoon wrote:
| I agree. This story could have been written any time in the
| last couple of decades, but replace React and .NET with any two
| wildly divergent software development
| ecosystems/paradigms/communities. I could tell you stories
| about an insurance company where I worked and how Java on
| Solaris (or was it z/OS?) and VB on Windows 95 fought to the
| death in a cage match. The were many programmer casualties.
| cccc4all wrote:
| Just reading the initial scope of the requirements. This project
| was guaranteed to fail, no matter what tech stack was utilized.
|
| There's no future proofing in Software Development. As soon as an
| application is deployed to prod, it's obsolete. It must be on
| constant maintenance/upgrade schedule. And, the replacement
| project must be scoped out quickly.
| sergiotapia wrote:
| I don't agree that React is not enterprise ready. The mistake OP
| made was reaching for Redux for some weird reason. Redux-saga,
| _thunks_? I guarantee this project used thunks of some kind
| because some blogger posted about it and it was popular and
| trendy.
|
| Pick boring tech that's objectively simple and not an exercise in
| genius. mobx, today: apollo-client (if you have a graphql api).
|
| I've never seen any other project stain a framework as much as
| Redux has done.
|
| Also, he had a ton of organizational issues that have nothing to
| do with the tech.
| legerdemain wrote:
| Given the choice of MobX vs Redux, I don't understand how a
| library with one ninth the number of downloads on NPM is the
| more "boring" one.
| sergiotapia wrote:
| use it, you'll know why it's qualified as "boring".
| zumu wrote:
| > I've never seen any other project stain a framework as much
| as Redux has done.
|
| Is there a good article that would summarize the backlash
| against Redux?
|
| While I don't do front-end much anymore, Redux was such a
| productive tool for me when I was a contractor. I found it
| incredibly powerful and easy to work with, if cerebral for the
| uninitiated.
|
| Meanwhile, I had the exact opposite experience with apollo-
| client and the apollo framework--very easy to get up and
| running, but a giant pita for doing anything complex.
| nawgz wrote:
| It sounds like GP drank the mobx juice to me.
|
| Honestly, after using mobx, it's almost impossible to
| understand why Redux is popular. MobX is more concise, more
| performant, has a crazy amount of built-in optimizations, and
| lets you forget about tracing your crazy graph of
| relationships just to update some view.
|
| Of course, mobx had "bad" (read: used decorators) syntax for
| a while, and only with MobX 6 did they clean it up, but boy
| oh boy is it clean now
| chociej wrote:
| That was a very interesting read and described a lot of
| interesting, very valid, and very realistic challenges that I
| could see myself running into in a similar situation. However I
| don't agree with the conclusion that React shouldn't be
| recommended for enterprise... instead I found myself thinking,
| gee, there just happen to be other mindsets, skillsets,
| management styles, and general ways of doing things, and they
| collided poorly here. Enjoyed reading this but a bit offput by
| the FUDdy punchline.
| erlich wrote:
| I feel your pain. It was really too early for React until 2 years
| or so ago. Since hooks, things have calmed down a bit. I would be
| interested to hear from people who successfully navigated that
| past 5 years in JS world. I feel I would have been happier just
| being forced to use Ember or something until hooks came out. A
| ridiculous amount of time was spent on tooling, perf
| optimizations, and huge amounts of code is just going to go into
| the bin one day.
|
| I have this feeling that 2010+ has been this massive story arc
| and one day we will end up very close to where we started, back
| to something similar to jquery and vanilla JS because the
| platform improved. Just like how a React platform feature like
| context hooks deprecated Redux.
|
| For frontend, if Typescript is standardized and shipped with
| browsers...see ya later beefy compiler toolchains.
|
| For backend, Deno.
|
| That Typescript with its current popularity is not shipped in
| browsers within 10 years seems super unlikely.
|
| The funny thing with TS is that to get good typing, you start to
| write everything similar to Java/.NET with dependency injection
| etc. I resisted it for such a long time, but when you realize you
| want things typed, classes and all those patterns become
| necessary - see Nest.js/TypeORM for an example. It just makes
| everything cleaner and is easier to standardize patterns.
|
| The post seems to have a bit of a "holier than thou" when dealing
| with naive .NET developers. I think that .NET devs living outside
| of our JS bubble probably have a lot of interesting criticism to
| offer. The retort that pops in your mind is "you just don't
| understand...this is how its done", but if they critiqued any
| number of the features that have been deprecated in React - they
| would have been right and us wrong. And even the creator of React
| said that moving away from classes made it to difficult and would
| have preferred not to have done it. My point is that JS is a
| bubble and we shouldn't be so sure of ourselves.
|
| Also the fact that Apollo is the top API library at the moment,
| and doing optimistic updates and working with the cache is
| insanely complicated when ultimately you just want something like
| ActiveRecord on the client like how we use to do it with Backbone
| models. Redux and friends is also extremely verbose and
| complicated for no gain. I miss the simple mental model of
| Backbone - yeh there were problems, but at the end of the day I
| just want to write `User.getPosts()` and `User.setPost()` and be
| done with it. 90% of the time I don't actually need GraphQL
| selective querying and such, its just got such a big momentum and
| community behind it that I use it. And REST with `react-query`
| and `swr` is still extremely complicated. Sorry for the rant.
|
| So I wonder if anyone has taken the time to predict when all the
| tools we use today will eventually be deprecated.
| ourcat wrote:
| AngularJS was indeed a bit of a pain when we switched to Angular
| 2+ and beyond, but it was so worth it.
|
| I chose it because of the skillset that our current (small) team
| has. There's no way our 'designer' (more an HTML/CSS guy) could
| have wrapped his head around JSX, the way it mixes scripts with
| layout markup.
|
| The way Angular separates concerns for us is great. And the
| components are extremely flexible and reactive and useful for
| iteration. And lazy-loaded routings? Yes please.
|
| And with the Angular CLI and TypeScript typings and using VSCode
| it's an absolute joy to build sites with.
| swsieber wrote:
| Oof. I work on an angular app and the build is slow as molasses
| because it's big. And we of course don't want to move away from
| the official build tool because build time improvements are
| always "right around the corner".
| nkw wrote:
| You might consider NX if build times are an issue. It is
| monorepo based and includes computation caching[2] and
| incremental builds, but under the hood uses the angular build
| tools. We've found it pleasant to work with.
|
| [1] https://nx.dev/latest/angular/core-concepts/computation-
| cach...
| ourcat wrote:
| True. The build times are slow.
|
| But the recent versions (and updating is also a breeze -
| mostly) should be faster. And particularly if you drop
| support for ES5 browsers.
| nickthemagicman wrote:
| JSX always seemed like a red flag to me. It was redesigning
| something that already exists to make it so that it uses non
| native browser functionality? Also the portability looked like
| an issue from it. I don't understand the use case for it. Vue
| and apparently Angular use basic browser friendly components.
| nawgz wrote:
| How is magically hydrating a DSL extension of HTML any better
| than using JSX? Arguing about "non-native browser
| functionality" doesn't make any sense to me, your Angular app
| doesn't work until it's com-trans-piled into the same
| HTML/CSS/JS output that JSX produces...
| nickthemagicman wrote:
| Oh I agree. It's all insane. Ready for native web
| components and/or web assembly to become mature and get rid
| of this JS framework, 5 layers of transpilation, nonsense.
|
| But to address your point, you're locked into JSX a lot
| more than someone writing in native browser code that
| doesn't need transpilation and can be ported between other
| frameworks at the end of the day.
| nawgz wrote:
| I really can't understand what your objective is here.
| Frameworks are going to exist in every single language.
| Do Python developers say "I cant wait til Pandas isn't
| part of my workflow"?
|
| I also will challenge your sentiment that JSX locks you
| more into a framework than writing DSL extensions of
| HTML. JSX is supported by quite a lot of frameworks, so
| you aren't locked into React; additionally, React is the
| best UI library; additionally, JSX is pretty semantically
| clear with what HTML elements your functions are binding
| to and what events they're paired to, so in either case
| you have to rewrite code for your new DSL. Going between
| Vue and Angular isn't going to be simple.
| nickthemagicman wrote:
| "JSX is supported by quite a lot of frameworks, so you
| aren't locked into React"
|
| Just not the browser natively....
|
| Most backend frameworks don't need numerous layers of
| transpilation because they're on an actual OS and arent
| trying to work around an insane environment like the
| browser that's full of warts and incompatibilities.
|
| What's the churn on Pandas? It's been around over a
| decade. And it can probably be reliably counted on to be
| around a decade more.
|
| It will be surprising if React is around in 5 more years
| and hasn't been replaced by something else.
|
| Is EmberJS still around? How much longer will webpack be
| around?
|
| Stability in the browser ecosystem starts with stability
| in the browser.
|
| I think instead of investing all this energy into browser
| frameworks we need to be devoting energy into making the
| browser do what we want it to do natively.
|
| And as web assembly matures that's where I think this is
| headed.
| WorldMaker wrote:
| > "JSX is supported by quite a lot of frameworks, so you
| aren't locked into React"
|
| > Just not the browser natively....
|
| Angular's *directive and [weird] (binding) [(choices)]
| will never be supported by the browser natively either.
| The fact that Angular uses an HTML file extension is a
| delusion (they really should have picked a different
| extension, it's such an ugly lie) that the templates will
| ever be more portable than they currently are. Sure, you
| generally have better raw copy/paste behavior of real
| HTML into Angular's templates than JSX, but if you think
| the mess that is the average Angular template will ever
| be portable to "native browser functionality", I may have
| a bridge to sell you.
| nawgz wrote:
| > Just not the browser
|
| Most backend frameworks need literal compilation - all
| that's different here is that the target is a specific JS
| version, not machine code. Additionally, there's a bit of
| "naivety" here - browser vendors are the ones that
| implement native features, and that's clearly not a
| domain that a random developer can impact. Instead it's
| JS frameworks and associated tooling, which is all very
| strong now. The idea that Angular or Vue are somehow
| going to work in the browser directly is, once again,
| absurd, and please stop saying it.
|
| > What's the churn on Pandas
|
| I find it silly that you'll cite Pandas as not having
| churn when its parent language just underwent a large,
| painful, poorly received transition.
|
| > It will be surprising if React is around in 5 more
| years
|
| You are saying the same things people said 5 years ago
| about React. My React code from 2016 still compiles
| against the newest version of React, and works correctly.
|
| Honestly, you're a classic example of this - you started
| developing not in JS, you felt some warts of JS, and now
| you hate JS and are ready to throw the baby out with the
| bathwater.
|
| I'll be more surprised if "native web components" or
| "webassembly" are actually supporting production use
| cases in 5 years than if React is.
| bluefirebrand wrote:
| Why does it really matter if the code you write is browser
| friendly or not? Everything is transpiled to browser code
| anyways, that includes Vue and Angular and JSX.
|
| None of the code you write is ever really touched by a
| browser anymore. At the very least it's minified.
| nickthemagicman wrote:
| Agree completely!
|
| I think the whole ecosystem is insane!
|
| Something that needs 3 or more layers of transpilation...is
| not right. Typescript to Babylon to JS. Sass to css.
|
| These are workarounds for native JS warts.
|
| That's why Im excited about NATIVE web components and
| future releases of JavaScript becoming sophisticated enough
| that we can ignore all of this framework insanity.
|
| Or even better...web assembly somehow taking over and
| making all of this pointless. Native Typescript. Yes
| please.
|
| But to address your point, you're locked into JSX a lot
| more than someone writing in native browser code that
| doesn't need transpilation and can be ported between other
| frameworks at the end of the day.
| bluefirebrand wrote:
| > But to address your point, you're locked into JSX a lot
| more than someone writing in native browser code that
| doesn't need transpilation and can be ported between
| other frameworks at the end of the day
|
| Not really, because at the end of the day you still have
| to write the HTML and CSS and everything to render
| anything in a browser, the JSX really just gives you a
| new way to compose it. Now if you're using other styling
| frameworks that provide their own components, you might
| not have access to that HTML but that's not a JSX problem
| that's a "you are too reliant on outside dependency"
| problem.
|
| Also, transforming code into a runnable form has been a
| part of programming since we first invented compiled
| languages. Your comments about transpilation seem really
| bizarre with that in mind.
| WorldMaker wrote:
| > And lazy-loaded routings? Yes please.
|
| All the React routers I know of support lazy-loading well.
|
| I'd argue far better than Angular handles it. React components
| tree shake extremely well out of the box and I've rarely had to
| worry about bundle size when lazy-loading in React. Whereas
| Angular's dependency injection framework and its "modules", in
| addition to being irritating busy work as soon as you realize
| you can't trust the CLI's scaffolding, do nothing but get in
| the way of proper tree-shaking and good webpack chunks/bundles.
| mpolichette wrote:
| I don't think React is the problem here. I think communication
| and leadership is where fault lies.
|
| 1. Why hire a team of non-webdevs to do webdev. (on 2nd read, it
| appears they wanted to use the same team from the WPF app...
| -\\_(tsu)_/-)
|
| 2. If you build and treat React components and their APIs as the
| abstraction layer, then they're just components... who cares how
| they're implemented.
|
| 3. Just because the existing project is big, doesn't mean your
| new one has to be... split it up!
|
| 4. Redux... the root "technical problem"
|
| My hot take is that the authors technical issues probably come
| from Redux and not React. Using redux as the core of your
| application is like pouring glue on a lego set. In an ideal world
| this is great because everything is strong and well defined. In
| reality, it prevents flexibility and applies hard constraints to
| the entire system.
|
| That one choice of using redux effects the decisions you make in
| every component. You lose flexibility to encapsulate features and
| experiments. You're forced to bend over backwards to do things in
| specific ways.
|
| Redux is the JS equivalent of the Windows Registry.
| erlich wrote:
| > Redux is the JS equivalent of the Windows Registry.
|
| Love it.
|
| I find Dan Abramov a great guy, but it was he who brought us
| Redux and rose to such fame because of it, and its now
| considered a bad way of doing things (or maybe just a
| ridiculously verbose api) and caused a huge amount of pain for
| a lot of people (I am not blaming him tho!)
|
| Now we have hooks as a collaborative effort involving the same
| guy, but they feel hacky in a way, and almost like they will
| not last either.
|
| It really feels like this reinvention for the sake of
| reinvention. I can easily imagine the API I would like for
| managing my data layer, but its seems like we are trying to
| shoe-horn something into the React way when maybe it isn't the
| right fit and we need something else.
| Matthias247 wrote:
| I don't think 1) is any issue. I worked on desktop apps as well
| as web apps, and overall I think it's mostly the same. You have
| some widgets, state, actions, etc - and need to connect all
| things together.
|
| However I could totally imagine that a team which is familiar
| with advanced patterns for "connecting everything together" are
| unhappy with the bare minimum Redux approach. MVVM can be
| pleasant to work with, and isn't necessarily as much of a
| ceremony and chore as the redux stuff.
|
| Angular 2 (or whatever version number it is now on) might
| indeed have made them happier.
| _coveredInBees wrote:
| I read the comments here first before reading the blog post, and
| I was expecting a very different type of (and lacking) blog post
| based on the combination of dismissive and defensive attitude
| permeating a lot of the comments here.
|
| To be honest, there isn't a lot the author is wrong about. Sure,
| having a .NET team adapting to React is harder but nothing seemed
| egregious in the way they tackled things. The point about React
| including so little that you become reliant on a ton of external
| dependencies that see even more churn than the usual JS framework
| landscape is a very valid pain point, especially when you are
| building a very large application for the long-term. Granted, a
| lot of that criticism holds true for the entire JS scene where
| the churn is simply ridiculous and you have to cross all your
| appendages and hope for the best before you try to build a year
| old project. But React is especially problematic in that regard
| only because there are so few batteries included (which is great
| for small/mid sized projects, but the opposite if you are looking
| for stability).
|
| Ultimately though, I just shudder to think about writing large,
| complex, enterprise Apps in the latest and greatest JS/front-end
| frameworks due to the crazy levels of churn in frameworks,
| libraries and APIs. React now looks completely different from
| React from 1-2 years ago. Libraries fall in and out of favor.
| Some keep up with the ever changing API of the parent frameworks,
| others die off. It's like an entire ecosystem that has ADHD and
| as someone who has built several small to mid-size React and
| React + Electron apps in the past, that ultimately turned me off
| the entire endeavor (I'm an ML Engineer, but I love software
| engineering and building stuff for fun). I would much rather take
| "boring", stable languages and frameworks and spend my time
| honing skills that actually matter and help me as a software
| engineer throughout my career, rather than spend a week trying to
| get webpack figured out, till the next big webpack update when
| I'd start over from scratch again.
| arcticfox wrote:
| > React now looks completely different from React from 1-2
| years ago. Libraries fall in and out of favor.
|
| Is that true? Can you give me an example of what you're
| thinking of? I've used React since pretty much the beginning
| and the only "completely different" looks I can recall is
| class-based components -> functional components + hooks. And
| even that evolution was pretty comfortable and backwards-
| compatible.
| _coveredInBees wrote:
| I think the large things in my admittedly limited experience
| were hooks and context API. Which in a sense isn't a massive
| change, but the problem is that just like the author of this
| article mentions, now there are more ways for things to be
| done, and moreover, because React is a small framework
| itself, all your 20+ dependency libs have probably moved on
| and implemented everything with hooks. So now you pretty much
| need to learn hooks, the context API and throw out your prior
| domain knowledge from 2018 because whether you like it or
| not, you gotta still adapt to hooks, because that is the new
| thing now and the libraries you rely on are now using the new
| API and approach.
|
| If I was a full-time web-developer, I'd maybe be willing to
| live with the churn of the JS ecosystem, but as someone who
| enjoys software engineering and building fun projects, the
| churn is simply exhausting and a big turn-off. I spent a year
| doing a lot of intensive React + Electron + D3 + MobX and all
| the associated stuff (webpack, npm, node, etc) in 2018, and
| then at some point I realized its like being on a hamster
| wheel and you gotta keep going frantically just to stay up to
| date with the newest libs and toys and APIs and current group
| think. Meanwhile, a year spent just writing and learning good
| software in Python (for example), gains me so much more
| transferable skills to anything I touch as a software
| engineer in the future.
|
| I still like the power of being able to make user-interfaces
| easily and there are plenty of things I enjoyed about
| developing web/electron-apps, but ultimately I was just
| turned off by how much continuing investment of your time it
| requires just to stay relevant in the field without imho
| adding any real value to actual software engineering skills.
| nawgz wrote:
| >I spent a yea rdoing a lot of intensive React + Electron +
| D3 + MobX in 2018
|
| Right, and that code still runs and compiles exactly as it
| did then, correct?
|
| The fact that other tools move on doesn't mean you have to.
| Actually, out of what you just said, D3, MobX, and React
| all have not removed any of the APIs you could've used back
| in 2018. Did people maybe rewrite some tools to support
| hooks, and in doing so find that hooks were a more concise
| and readable solution? Yeah, they did, so we moved to
| hooks.
|
| > a year spent just writing and learning good software in
| Python gains me so much more transferable skills to
| anything I touch as a software engineer in the future
|
| How so? This is a complete non-sequitur. If you consider
| data science / ML to be the entirety of software
| engineering, then maybe you have a point, but since you
| even put (for example) beside Python it just looks to me
| like you hate JS and will pretend it's not software
| engineering so you can avoid it. Any time you've spent
| tweaking build systems or updating libraries for no reason
| is on you, not on JS.
| interlocutor wrote:
| > _I would much rather take "boring", stable languages and
| frameworks_
|
| I would argue that you don't need a heavy framework to make
| maintainable JavaScript application. For large enterprise
| applications that must last a decade or more you want to use
| standards (such as Web Components) implemented by the web
| browser itself instead of third-party libs such as React.
| nicoburns wrote:
| I suspect React has a much greater chance of being around in
| 10 years time than web components. Simply because there are a
| _lot_ more people using React than web components. React _is_
| a boring, stable framework at this point.
| flowerlad wrote:
| > _Simply because there are a lot more people using React
| than web components._
|
| Couldn't you have said that about React vs Angular 5 years
| ago?
|
| > _React is a boring, stable framework at this point._
|
| And that's why it won't be the most popular framework in 10
| years time. React started off as a simple and
| straightforward library. The React team didn't want to
| stand still, so they improved it. The "improvements" are
| making React big, fat, bloated and complex, and failures
| and perf issues harder to debug
| protonimitate wrote:
| > The point about React including so little that you become
| reliant on a ton of external dependencies that see even more
| churn than the usual JS framework landscape is a very valid
| pain point, especially when you are building a very large
| application for the long-term.
|
| It's a feature, not a bug. Not understanding this is a red flag
| that you're going to run into problems.
|
| > React now looks completely different from React from 1-2
| years ago.
|
| Does it? I've worked in React, at enterprise levels, for close
| to 3 years now. Except for the addition of hooks, there hasn't
| been a whole lot of churn. React today is still the react of
| yesteryear, but with extras.
|
| Imo the biggest failure of the author was to jump headfirst
| into a stack they weren't familiar with it, and then blame it
| on the stack.
|
| I know it's en vogue to hate npm/react/js "because the
| ecosystem", but at this point, picking the ecosystem and then
| blaming it is a self inflicted wound that I don't really have
| patience for.
| _coveredInBees wrote:
| This is again so dismissive of the author. He seems to have a
| substantial amount of experience with React. He isn't just
| some noob who jumped on some bandwagon and picked the latest
| sexiest thing for reasons. If anything, the entire team
| seemed to do far more due diligence in decision making than
| pretty much 90% of the move-fast and break things (TM) SV
| startups.
|
| > It's a feature, not a bug.
|
| Yes, a small, light-weight framework can be a good thing. No
| one called it a bug. But like everything in life, there are
| trade-offs involved. And I'm not entirely convinced that it
| is a good tradeoff in the crazy JS ecosystem where everything
| is changing and breaking all the time, especially if you are
| building more complex things and don't have an army of web-
| devs to keep the house of cards from falling down.
| protonimitate wrote:
| > If anything, the entire team seemed to do far more due
| diligence in decision making than pretty much 90% of the
| move-fast and break things (TM) SV startups.
|
| Right, but this still isn't the fault of React. My gripe
| with this article, and view points like this, is that
| instead of taking ownership it's again the tool that gets
| blame and just further perpetuates the "js bad" meme.
|
| > And I'm not entirely convinced that it is a good tradeoff
| in the crazy JS ecosystem where everything is changing and
| breaking all the time, especially if you are building more
| complex things.
|
| Right, and if that's your opinion (and a perfectly valid
| one!) then don't pick the JS ecosystem and cry when it
| bites you.
| ralmidani wrote:
| I agree people should take ownership over their
| decisions, but it's more nuanced than "don't cry": if
| someone makes a mistake/bad decision, shouldn't they warn
| others so they don't do the same?
|
| And frankly, let's stop pretending the JS ecosystem is
| not problematic. Can anyone in good faith argue for a JS
| project which offers the stability, refinement, and
| elegance of projects available for Ruby (Rails), Python
| (Django), Elixir (Phoenix), etc? Even micro-frameworks
| like Flask, which don't include tons of batteries, are
| still much more dev-friendly than Node/Express/React/etc.
| nawgz wrote:
| >frankly, let's stop pretending the JS ecosystem is not
| problematic. Can anyone in good faith argue for a Node
| project
|
| React is a node project, so I can do so trivially. React
| is a top tier library when it comes to key features like
| stability, documentation, backwards compatibility, and
| extensibility / usability.
|
| I can also say TypeScript is one of the most amazing
| projects of all time.
|
| Last but not least - express is super easy to use. I
| don't know what "dev-friendly" means, as a criteria
| though. Keep in mind, though, since it's JS, it's really
| easy to wrap and extend. To me, you have to justify how
| Flask is superior to Express; I think you just like
| Python more.
| ralmidani wrote:
| React is stable? React.createElement -> Sub-classing the
| Component class -> "just use hooks everywhere" in the
| span of a few years? Sure, Django went from function-
| based to class-based views, but the change was far less
| abrupt, and you can still use functional views if you
| want to.
|
| As for TypeScript, I agree it's amazing, but it's neither
| a framework nor a library for building web applications.
| It's more of a superset/transpiler. It makes working with
| Node/React/Express better, but it doesn't replace them.
|
| With regard to Express, it's decent, but e.g. do we
| really need to torture newcomers by expecting them to
| know they'll need to also include/install and require
| body-parser? I mean, why would I be using a web
| framework, even a micro-one, if I'm expected to bring in
| a separate tool just for parsing requests?
|
| Regarding the suggestion that I like Python more, I would
| gladly choose TypeScript over Python (the typing tools
| there are still immature) if there was less churn in the
| JS ecosystem. Deno is promising. :)
| nawgz wrote:
| >React is stable?
|
| Yes. Despite what you're trying to imply about them
| "updating" too often, my code from 2016 still works
| correctly against the newest versions of React. That's
| pretty much the definition of stability to me.
|
| > the change was far less abrupt, and you can still use
| functional views if you want to
|
| So you are hating on React because you don't know this,
| but this exact optional progression has always been how
| they have introduced new features into React. Again - old
| code works with new React versions.
|
| > do we really need to ... expect them to know
|
| True, this is a weakness, but the documentation is pretty
| explicit on this front. It's not like there isn't a big
| community around the library to address this.
|
| Anyhow, I respect your points here, and concede that
| writing server-side code in Node is probably not what you
| want to do; I reach for tools like Hasura in this case
| regardless. With low-code backend tooling and React, I
| can promise you I can make a better website than with
| just Python no matter how much Django template wizardry
| one can muster.
| ralmidani wrote:
| Stability is not just about backward-compatibility; it
| also means promoting concepts/idioms which are consistent
| and long-lived. Django has been around for about 3 times
| as long as React, but has not undergone the same amount
| of churn that React has. If someone wrote React code in
| 2016 and left the scene for a couple of years, can they
| come back and build new React projects without
| significant re-training?
|
| Regarding Django templates, I know how they work, but
| actually prefer building an API with Django, and
| connecting to that with an SPA (preferably one built with
| Ember since, as you can probably tell, I prefer
| batteries-included frameworks).
|
| I'm really not as anti-JS as my initial post implied, but
| saying the ecosystem is not problematic makes it harder
| for it to get better.
| worik wrote:
| "my code from 2016 still works correctly"
|
| That is no time at all in "enterprise level software",
| being software with investment counted in millions of
| dollars.
|
| What about your code from 1996? Will your React code word
| in thirty years?
| davorak wrote:
| > If anything, the entire team seemed to do far more due
| diligence in decision making than pretty much 90% of the
| move-fast and break things (TM) SV startups.
|
| The author did not convince me that they had above average
| due diligence. It's common to go through the motions of
| required processes/procedures like:
|
| "create decision criteria, do research, validate findings
| by creating a proof of concept, present findings, document
| everything in the decision log"
|
| and not generate much value from the process as a result.
| bitstan wrote:
| There's so much cargo-cult mentality in react that it's
| difficult to perform DD and predict the technical
| landscape _years_ into the future. So perhaps we 're in
| agreement the author should have picked another
| technology.
|
| Personally I think the author's original architecture was
| most likely satisfactory, but there should've been design
| guidelines to enforce a single coding style. You don't
| have to re architect your app because dan abramov tweeted
| something.
|
| If there was no value added in adopting hooks then the
| architect shouldn't have wasted energy adopting it. And
| let's be real, there was no value added in adopting hooks
| lol.
| lhorie wrote:
| > It's a feature, not a bug. Not understanding this is a red
| flag that you're going to run into problems.
|
| This attitude smells of "you're attacking my way of doing
| things, therefore you're wrong". While there's truth in both
| your claims and the GP's, there _is_ churn and there _is_ a
| ton of garbage in the ecosystem, that much is very true.
|
| The nuance is that the distribution is not uniform: lodash
| has been stable for ages, axios is perfectly fine for HTTP
| requests, etc. Where it gets sketchy is when you get to the
| fringes of what a framework is expected to do. But at that
| point, not even Angular or Ember can save you.
|
| As for framework-specific churn, React itself is not the only
| cog in the equation. As part of my job, I see a lot of React
| codebases from various periods in time and honestly, yes,
| there's a lot of churn. Looking only at React's API churn, we
| have code using hooks, class components, HOCs, render props,
| heck even React.createClass.
|
| And then there's hipster libraries that willy-nilly break
| APIs to match each new React idiom, libraries that just can't
| make their minds about what their API looks like, abandoned
| libraries that uses the old Context API, libraries that
| depend on componentWillUpdate, libraries that read the shape
| of the virtual dom node, libraries that depend on those
| libraries, and on and on goes the rabbit hole. React Router,
| for example, is both extremely popular and notorious for
| having given people migration headaches.
|
| On top of that, there is of course the self-inflicted pain:
| redux-saga messes that no one wants to go near, misguided
| attempts at "functional programming" and other forms of over-
| engineering, etc.
|
| But here's the rub: Angular _has_ idioms for forms. You don't
| wrangle w/ random breaking changes in react-form there.
| Angular has a router. No need to worry if your favorite
| router lib will break APIs when Suspense comes along. Angular
| has HTTP requesting. No bikeshedding over axios vs
| isomorphic-fetch or whatever. Angular has state management
| idioms; no fussing over where async stuff goes in redux
| (assuming you're not still arguing redux vs mobx).
| Pluralization? Hope what you picked is maintained. CSP
| support? Yeah, go google that, I can wait. Etc.
|
| You can definitely become a competent React dev and spend
| many years on good, well maintained projects in React-land,
| but that doesn't mean there aren't problems directly
| attributable to the React's limited scope as far as
| "frameworks" go.
| worik wrote:
| "Does it? I've worked in React, at enterprise levels, for
| close to 3 years now..."
|
| So you are a beginner.
| commandlinefan wrote:
| > It's a feature, not a bug
|
| I'm not that familiar with React (although I have had the
| misfortune of working with Angular), but I've seen the
| horrific Spring "framework" defended that way: it doesn't
| actually include any functionality because it's designed to
| be open ended! What it turns out to be is the most useless
| thing that ever happened to programming: it's pure overhead,
| undocumented (surprising) behavior, unwanted defaults that
| you have to spend time working around without the benefit of
| actually simplifying anything. Not saying React is the same
| (like I said, haven't really spent much time looking at it),
| but it's adherents defend it the same way Spring's adherents
| defend _it_.
| crooked-v wrote:
| In React's case, it's meant to pretty much entirely focus
| on the process of (input data -> output DOM nodes), plus
| the minimal set of wrapper functionality needed to handle
| user input and general asynchronous data loading (class-
| based component state, context loading, and most recently
| hooks). It intentionally doesn't handle a lot of stuff like
| dependencies (that's a job for your bundler), the actual
| data fetching, the actual specifics of your UI, centralized
| global data management, etc.
| nawgz wrote:
| As a React dev for half a decade, I strongly disagree with many
| of your points.
|
| > React [includes] so little that you become reliant on a ton
| of external dependencies
|
| React, since hooks, includes a full state management solution -
| Context, Provider, and hooks.
|
| Second, even if you want an actual state management library,
| both mobx and Redux are quite stable. Applications I have built
| in 2016 are still running and building with no pain points
| today, except maybe that the tooling is way better now.
|
| Third, all this noise about "the JS scene has so much churn" is
| kind of crazy. I don't know what kind of library evaluation
| techniques everyone else has, but React is backwards compatible
| with techniques they've been saying they'll deprecate for
| years, version pinning works perfectly fine, and with
| TypeScript there's less and less churn and mystery than ever
| before.
|
| > Ultimately though, I just shudder to think about writing
| large, complex enterprise Apps in the latest and greatest
|
| This is a comical take. Facebook is powered by React. Large,
| complex, enterprise, and fully powered by the cutting edge of
| JS frameworks.
|
| > React now looks completely different from React 1-2 years ago
|
| But still fully supports the previous way of working, meaning
| not only has none of your knowledge been invalidated, but you
| have additional tools at your disposal.
|
| > Libraries fall in and out of favor
|
| react-router-dom has been my goto for quite some time, as has
| mobx. Again, you can version pin and stick with any solution as
| long as you want to - my things powered by react-router 3 are
| fine still.
|
| > I would much rather take "boring", stable languages and
| frameworks
|
| > I'm an ML Engineer
|
| Is it not true the entire ML ecosystem has been reinvented in
| the last 5 years? My React code still builds & runs from 2016.
| I really feel like this is a case of "external person
| overestimates complexity in external domain, underestimates
| complexity in internal domain" because everything you're saying
| sounds like you dipped your toes, and didn't actually build
| applications.
|
| Final thoughts: you don't need to update Webpack to resume
| building your old project. Your build scripts work just fine.
| Better yet, don't eject from Create-React-App or some other
| build provider and you never even need to think about this
| stuff. React is boring and stable, speaking as someone who has
| used it for half a decade and sees no reason why that won't
| just become a full decade.
| _coveredInBees wrote:
| > React, since hooks, includes a full state management
| solution - Context, Provider, and hooks.
|
| Sure, but that hasn't been around even 2 years. Prior to
| that, there was a different approach and philosophy to doing
| things. I remember when higher order components were all the
| rage till suddenly they weren't.
|
| I'm not advocating for stagnation, but at the same time,
| everything in JS land feels experimental, even in established
| frameworks, and the entire community keeps marching along as
| things keep changing. Which if you are a full-time developer
| doing that, is fine I guess, but it is not the norm compared
| to pretty much any other software engineering field.
|
| > Second, even if you want an actual state management
| library, both mobx and Redux are quite stable
|
| I cannot say enough nice things about MobX (although I was
| using it back when it didn't use Proxies so you had to deal
| with a lot of cloning back to native JS objects which got a
| bit ugly at times), and I don't disagree with you on this
| point for state management, although I personally could not
| stand redux despite 90% of the community vehemently singing
| its praise.
|
| > This is a comical take. Facebook is powered by React.
| Large, complex, enterprise, and fully powered by the cutting
| edge of JS frameworks.
|
| I should have perhaps qualified that better. Yes, I know
| there are people writing complex apps, but I was viewing it
| from the POV of a non FAANG type place with tons of engineers
| to throw at a problem. If I was a single person or a very
| small team trying to develop something complex, I would place
| a much higher emphasis on a more stable development
| environment/language/framework.
|
| > Is it not true the entire ML ecosystem has been reinvented
| in the last 5 years? My React code still builds & runs from
| 2016. I really feel like this is a case of "external person
| overestimates complexity in external domain, underestimates
| complexity in internal domain" because everything you're
| saying sounds like you dipped your toes, and didn't actually
| build applications.
|
| Let's take Pytorch as a comparison framework. It's had tons
| of releases, but at a fundamental level, the core API has
| stayed the same. I've ported 3 year old code to the latest
| version with pretty much negligible effort. And at its heart,
| it is because APIs are kept very stable and people aren't
| deciding each year that they need an entirely new way of
| doing ML or performing automatic gradient estimations, etc.
|
| Similarly with Python... there have been a bunch of Python 3
| releases in the past few years but they each add new things
| that are useful without making big changes that suddenly
| change how everyone would tackle building a new piece of
| software.
|
| On the other hand, porting a 2+ year old React app to the
| latest version of React (along with bringing dependencies
| along) would be a very painful process. I know this, because
| we've done this at the company I work at.
|
| There is also this implicit assumption in JS/React land that
| you are going to come marching along with all the latest
| changes. Heck, less than 2 years back, their documentation
| site wouldn't even let you view older versions of React
| documentation, so the moment they released a new version of
| React, the docs would only ever show you the new docs. What's
| funny, is that today they supposedly have links to their
| older docs...but every fucking link is broken :-/
|
| example: https://reactjs.org/version/16.8
|
| And nobody probably even knows that, because there is a
| general expectation in the field that everyone just keeps
| staying up to date with the latest and greatest and deals
| with whatever pain points come along with that and no one has
| probably even tried to access older documentations or raise
| issues about it. Which is fine, like I've said many times
| before if you've made your peace with it and that is your
| full-time job, but it is not the expectation or norm in most
| other fields.
|
| Finally, I should state for the record (because you stated
| otherwise in another reply to me), that I actually love
| javascript...well at least ES6+ JS. I greatly enjoy(ed) JS,
| JSX, developing in VsCode, and even building things with
| React, Mobx, etc. I'm not a software engineering snob who
| looks down on JS and the ecosystem. But I also have a more
| diverse viewpoint because I work at a small company and get
| to wear many hats and have been able to do lots of different
| things (ML Engineer, Front-end work, write and deploy pretty
| complex software, etc.). And while I have a lot of fun doing
| front-end stuff, It still feels like there is a lot of
| constant overhead to it, and that is pretty unique to this
| one field compared to most everything else.
| worik wrote:
| Five years is not long.
|
| "Facebook is powered by React. Large, complex, enterprise,
| and fully powered by the cutting edge of JS frameworks"
|
| A very bad example. Most software of significant cost and
| size is serving a industry, and not the industry itself.
|
| Facebook can break things. If your insurance company or bank
| break things... Get my point?
| worik wrote:
| "the entire ML ecosystem has been reinvented in the last 5
| years"
|
| Fifteen years, maybe, but because of new technology. Actual
| physical machines that did not exist earlier.
|
| The churn in JS frame works is because because because, no
| better reason.
| midrus wrote:
| > Context, Provider, and hooks
|
| Which is the biggest foot gun I've seen in my life.
|
| There is a surprisingly high number of developer that still
| don't get it and will make those beautiful applications
| where, thanks to a naive usage of this, will create
| applications that rerender the entire application on every
| keystroke.
| nawgz wrote:
| Yes, which you can fix by moving a singular key of the
| context to component state. The beauty of hooks.
| cratermoon wrote:
| You probably don't want to know about MEAN
| (https://en.wikipedia.org/wiki/MEAN_(solution_stack)) then.
| firebaze wrote:
| This is the most upvoted controversial, and in my eyes,
| trolling post i ever saw on HN. I'd at least expect a look-
| forward element, like "use Svelte" or whatever. But a simple
| and pure (and from my point of view totally wrong) flame just
| against React without mentioning any of the competing
| frameworks feels simply awkward.
|
| One could substitute React with almost anything js-related, and
| the post would still incite flame.
| mmmeff wrote:
| I prefer the criticism raw and plain. No need to muddy the
| waters with a biased recommendation. The author's criticism
| stands on its own.
| firebaze wrote:
| Fair enough. The js ecosystem has quite some room for
| improvement, this is what I definitely agree on.
| worik wrote:
| Most criticism I see here is of the JS frame works generally,
| rather than React in particular.
|
| I, for one, am glad to see the push back against the mad
| craziness that has dominated the Node.js/Framework word.
|
| It is easier to speak than listen, easier to write than read,
| and easier to build than test... Hence Node.js, and JS
| Frameworks.
|
| I do love programming in Javascript, have not done it for a
| while, as I cannot abide the ignorance and arrogance that
| goes with the ecosystem.
|
| I love plain old vanilla JS....
| unphased wrote:
| To pile onto your point, webpack is clearly on its way out,
| it's all about snowpack now (afaik). I never got a chance to
| get into learning webpack, and I'm glad now. _Throws hands up_
| postalrat wrote:
| Just recently I had to switch a project from snowpack to
| webpack because adding the features I needed to snowpack
| added up to too much additional work.
|
| Like parcel snowpack works great when you can use it. Hoping
| it catches on because I really loved how fast it was.
| flyinglizard wrote:
| First you made a bad choice by using React, then you made a bad
| choice by publishing on Medium which does not allow anonymous
| reading.
| poulsbohemian wrote:
| I'm not really a React fan, but you could have encountered all of
| these problems regardless of what you'd chosen to use. Sounds
| like the writer had good intentions and worked hard to do the
| right things, but that there were fundamental misalignments
| beyond the technology. Could they have planned ahead for those
| conflicts? Maybe. But, as noted in one of the paragraphs,
| enterprise type projects have a way of taking on a life of their
| own even when all parties have the best of intensions - and in
| many projects, not all parties actually have the best intensions.
| Heck, I've seen projects get started and deliberately set up to
| fail as a counterbalance to some other project. Live and learn.
| renewiltord wrote:
| Is there a Rails for React? I use React+Redux+Typescript and it's
| nice but I always have trouble setting up a new project.
|
| Rails is magic in that it's all ready. React+Redux+Typescript is
| great. I just don't want to make decisions here. I want to just
| make a web app. Like how Rails defaults to ActiveRecord and
| friends, is there something like that for
| Rails+React+Redux+Typescript?
|
| I'm looking for:
|
| * Few decisions for me to make
|
| * It's relatively popular enough that there is a community around
| the whole thing
|
| It's a huge productivity enhancer with Rails to be able to google
| "Rails do x" and someone has an answer to that. If I had to
| google "Ruby with X library and Y other library" I think I might
| commit suicide because the Rust experience is like that: "Use
| actix-web". Ah, and how do I use that with this other tokio based
| library. Oh you can't, because you need to make sure the runtimes
| are compatible.
|
| I don't want all that.
| crooked-v wrote:
| Take a look at Next.js, which incorporates a general-purpose
| router, does all the Webpack stuff for you, has generally
| painless server side rendering support (but you can also build
| a purely client-side bundle), and has direct support for a long
| list of popular libraries.
|
| It doesn't handle global state, but has tested examples for
| Redux[1] and various other libs that incorporate the server-
| side rendering and static site generation functionality that
| Next.js has.
|
| [1]:
| https://github.com/vercel/next.js/tree/master/examples/with-...
| renewiltord wrote:
| Thanks for the tip! Also appreciate you had your BTC link up
| in your keybase :)
| [deleted]
| iamsb wrote:
| As a counter point, I was almost fired for not choosing to build
| a SPA for an internal app which was going to be used by 3-5
| people, 5-10 times a month, if that many.
|
| I worked at large accounting software provider, and internal
| billing system used static pricing which was changed once a year.
| The company wanted to move to a more flexible system where
| pricing can be setup based on few rules like customer type. For
| this the ui and backend system needed to be developed. Design I
| proposed was a single "monolithic" service which did everything
| including UI and UI was supposed to be a old style mustache
| templates and some minor jquery. Instead they went with pub-sub
| systems, 4 different microservices, a react based UI, api which
| used json-schema, even to send data back to UI. When I left a
| team of 6-7 people was working full time on this and they were
| about 20% done.
| mixmastamyk wrote:
| "old style" from the horse-and-buggy-olden-days of 2010+ :D.
| worik wrote:
| https://youtu.be/ljPFZrRD3J8
| khalilravanna wrote:
| come hop up on the horse with yer pappy and let me tell you
| about the days of server-siiiide renderin' _child's eyes
| widen in wonder_
| marcosdumay wrote:
| It feels like a millennium if you have the attention span of
| a goldfish.
| UseStrict wrote:
| Are you me? We had an (admittedly more complex) monolith
| application for customer contracts and billing. It wasn't
| ideal, and was getting long in the tooth (think Perl Catalyst
| and jQuery), so the powers that be wanted to build a new
| service. But instead of decomposing the monolith into a few
| more loosely integrated services, they went way overboard with
| 20+ microservices, every DB technology imagineable (Oracle
| RDBMS, Mongo, MariaDB), a full message bus via RabbitMQ, and
| some crazy AWS orchestration to manage it all.
|
| What could've been an effort to split the existing service into
| manageable smaller services and rewrite components as needed
| turned into a multi-year ground-up effort. When I left they
| were no where near production ready, with significant technical
| debt and code rot from already years out of date libraries and
| practices.
| bpodgursky wrote:
| IMO the real failure here was not having an internal
| administration website with all the auth and API plumbing
| already set up, which you could tack a new page onto with
| minimal fuss, and a backend to tack a new API endpoint onto
| with no hassle.
|
| If you're building a new internal webapp from scratch for a
| small internal use-case, you just end up with a hundred
| different poorly-maintained apps.
|
| But in the situation where you're adding a page to an internal
| app, it's trivial to make that new page a SPA React app, since
| the framework is already there waiting for a new component.
| hertzrat wrote:
| There are a variety of clips of Jonathan blows twitch stream
| where he talks about web development. He feels that it has gotten
| so inefficient and complicated that it now takes 20x as long to
| create something as it needs to. He suggested that it would be
| faster for most teams to create their tech stacks utterly from
| scratch. He further argued that once this efficiency problem gets
| figured out, most web jobs will disappear. This is coming from a
| guy who is creating his own programming language for his next
| game though, and who makes his own game engines
|
| Eg, here's one example clip: https://youtu.be/yodWEPgn8NA
| stupidcar wrote:
| I watched it. It was dumb. A textbook example of some major
| fallacies:
|
| The first is mistaking your level of desire for something to
| happen with the actual probability of it happening. It's clear
| he doesn't just _think_ web programming is going to collapse,
| he _wants_ it to happen. And it 's distorted his estimation of
| its likelihood. I'm sure in 2030 he'll be making videos
| confidently predicting the collapse of web programming by 2040.
|
| The second is where an expert in one domain considers its
| complexity to be inherent and unavoidable, while assuming other
| domains, of which they are ignorant, are inherently simple.
| Then when they try to engage with those domains, they run into
| significant complexity and experience the uncomfortable and
| unfamiliar sensation of being an amateur again. Since the
| unfamiliar domain is, by their estimation, simple, they
| conclude that the complexity they've encountered is unnecessary
| -- a result of people working in that domain being too stupid
| or inventing busywork.
|
| The third is the mistaken belief that our means will improve,
| but that our desires will remain the same. So, right now we
| have certain requirements, and in order to meet them requires
| us to do a lot of complicated, cutting edge stuff. But soon all
| that complexity will get figured out, the cowpaths will get
| paved etc., and we'll happily just pushing a single button to
| do everything we need. The reality is, of course, that our
| requirements will just get more complicated as well. Human
| civilisation has been on this treadmill since time immemorial.
| cratermoon wrote:
| > an expert in one domain considers its complexity to be
| inherent and unavoidable, while assuming other domains, of
| which they are ignorant, are inherently simple
|
| Like the data science guy I worked with who complained we
| were making authentication and access control complicated.
| hertzrat wrote:
| While I like your argument about requirements getting more
| complex in the future, if we are speaking of fallacies, the
| much of what you said is an ad hominem and mind reading.
|
| The argument basically comes down to whether web development
| is or isn't slower than it should be, and whether it will
| become dramatically faster to do in the future
| commandlinefan wrote:
| > it would be faster for most teams to create their tech stacks
| utterly from scratch
|
| I actually agree, but maybe not for the same reasons he gives.
| The problem with modern tech stacks is that, yes, they're
| insanely complex, and each of the dozen or so individual
| components has dozens if not hundreds of its own hidden
| expectations about what should be where and what it should look
| like. As long as you meet all of those expectations, everything
| works magically like it should, but as soon as you miss one,
| you'll be lucky if you even get an error message that you can
| google the solution for.
|
| There are two efficient ways to solve this: 1) no dependencies,
| build everything from first principles that you already
| understand. Then, although there will be plenty of assumptions
| baked into the code, you'll know what they are and how to deal
| with them because you put them there. 2) take advantage of pre-
| built solutions, but actually read and understand the docs
| before you rely on them.
|
| The second solution depends on two rarely present
| preconditions: one, the docs actually exist. Two, management
| understands that it takes more than twenty minutes to
| realistically absorb 500 pages of dense technical
| documentation.
|
| What we end up doing as a workaround is using the off-the-shelf
| stuff without really understanding what it's doing (or are you
| telling me that you understand the 9000 files that are
| installed by NPM? I'm not exaggerating, BTW, go take a peek).
| We cross our fingers and hope that we got all the assumptions
| right, cut-and-paste solutions from stackoverflow, and let the
| horrifically inefficient solution take the place of actual
| engineering because the "timelines are aggressive".
| throwanem wrote:
| Not to be overly dismissive, but I'm not all that worried about
| the opinions of a guy who works in a totally different branch
| of the discipline and also releases one product per decade.
| dntrkv wrote:
| He sounds like someone that hasn't done any web dev at large
| scale. 90% of the web devs at my place of work just fulfill
| business needs day in and day out. Around 10% actually spend
| any time messing with the tooling. Sure, when you don't know
| what you're doing and you're working on a smaller project, you
| can get bogged down with the tooling aspect. But in every job
| I've worked with a healthy engineering culture, the tooling
| side of web dev is invisible to most of the devs to the point
| where they wouldn't know how to make a config change if they
| wanted. They just build shit.
| djcollier wrote:
| The web is just a way of delivering software to users. I think
| the person speaking in the video is worrying way too much about
| putting developers into boxes. At the end of the day, there are
| many problems in the world that can be solved with software.
|
| > What most web developers spend their time doing is useless
| busy work that is not actually objectively necessary in order
| to create the functionality. It's just dealing with a bunch of
| weird conventions by some other software that they are trying
| to use that are there because some other other weird
| conventions by some other software that they are trying to use.
| If you just strip all that crap out, you can be tremendously
| more efficient.
|
| Not only is this a very arrogant sentiment, but his reduction
| of all web development down to manipulating "weird conventions"
| doesn't fit with my experience. I don't sit around all day
| messing around with Webpack configurations or leaning new
| frameworks. I deliver software that addresses business needs,
| that happens to be accessed via a web browser.
|
| He also says that jobs with the title "frontend", "backend" and
| "fullstack" for the web are not safe jobs. Many game
| developers, operating system designers, and large desktop
| applications will also have "frontend" and "backend"
| separations of responsibility as well, because they often
| involve different skill sets or knowledge.
| serpix wrote:
| You just got steamrolled by .NET OOP dinosaurs, React played no
| part in it.
| rafaelturk wrote:
| This is also my understanding. Like most Enterprise projects
| front-end is the one to blame for problems that are actually in
| the backend.
| sergiotapia wrote:
| The virgin javascript v8let vs the chad dotnet core injector
| worik wrote:
| The experienced .NET development team got blind-sided by a
| script kiddy with a Java Script package fetish.
| dumbfoundded wrote:
| The best choice is always what the team has the most
| confidence with their skill set on delivering. Your framing
| is unhelpful. You can build amazing things with both React
| and .Net patterns. If you're on a deadline, you should
| probably stick with what you know. Every language and
| framework has different tradeoffs.
| worik wrote:
| True. My framing is unhelpful.
|
| I was reacting, emotionally, to the blaming of the old
| guard.
|
| I do think that Java Script frameworks would be great if
| they were stable. And for enterprise software - for any
| sensible definition - stability is a very important
| criterion.
|
| But it is easier to write than it is to read so they keep
| reinventing the wheel, keep making new, not better, things.
| hyperpape wrote:
| One thing that I realized recently is that if you have a mantra
| of making "data-driven decisions", then you have raised the cost
| of making a decision. What you then need is a tool that minimizes
| the number of decisions you have to make. Gartner, Rails, Spring,
| each try to do some of that in their own ways.
|
| That's where his 3 weeks of decisions about libraries reveals a
| real mismatch between React and the enterprise way of doing
| things. React requires a lot of decision making, and enterprises
| are bad at making decisions.
|
| Ultimately, the fault is with the enterprise. Sometimes you don't
| need official data, you just need someone with good taste to make
| a decision (and if your developers cannot usually "disagree and
| commit", that's a people problem). Save the data for the big
| picture stuff.
| drinkcocacola wrote:
| Absolutely. Think about iOS or Android (native) development.
| Sure, the ecosystem is quite big, however you do not have the
| level of flexibility that the web has. You are limited not only
| in terms of languages, but also certain architectural decisions
| are bounded by the limits imposed by Framework (the Android or
| iOS SDK), so there are many decisions that _are already taken_,
| and for better or worse you have to live with it.
|
| That is probably what I hate the most of front-end development
| compared with back-end or Mobile. There are too many options,
| and that certainly does not promote consistency within the
| project.
| Spivak wrote:
| I'm surprised that you didn't pin and vendor your dependencies at
| the start of the project and declare that any additional
| dependencies must be compatible with them.
|
| Enterprise applications are behemoths that without question will
| take longer to develop than the current webdev lifecycle and the
| most important thing for developers writing business logic is
| structure. Coding against a moving target is a recipe for
| failure.
| andrewstuart wrote:
| One of the core reasons software projects run into problems is
| politics - and this article is about politics.
|
| What should have happened ideally is that the blog post author
| would have said to the CTO:
|
| - we're going with React
|
| - you've chosen us to guide you in this
|
| - you now need to trust that my advice on standards and approach
| is correct
|
| - you need to get your developers to do it the way I say
|
| - if you don't, then we will be building a frankenstein React
| project which is built like a .NET application
|
| - the success of the project is at risk
|
| And the CTO would have been wise enough to agree and pull his
| people into line and give the blog post author the authority to
| demand things be done as he says they should be done.
|
| But that's politics and hard to do.
| scsilver wrote:
| Politics is the game of making incremental progress and always
| feeling like you left something on the table, its such and
| opposite skill of engineering, and yet it is the most important
| skill in engineering useful systems.
| worik wrote:
| "- you need to get your developers to do it the way I say"
|
| You have a team of developers that have a collective experience
| of perhaps eighty years in your organisation.
|
| Do as I say, me who just popped in and afterwards will pop out
| again....
|
| That is how millions and millions of dollars are lost in this
| business.
| recursivedoubts wrote:
| It's funny, react reminds me a lot of J2EE (and other enterprise
| frameworks) in many ways. A very large and complex framework,
| with lots of moving parts and additional stuff that needs to be
| glued in to make it all work.
|
| There is a reaction against this happening right now. You can see
| it in hotwire from 37signals, Alpine.js and my own response to
| it: https://htmx.org
|
| "Simplicity is prerequisite for reliability"
| lostcolony wrote:
| React feels more like the Spring Boot response to Angular's
| J2EE.
|
| But yes, I prefer the microframework approach.
| recursivedoubts wrote:
| Yeah, that's a better comparison.
| commandlinefan wrote:
| > the new technology's way of doing things
|
| what I find, with virtually every "new technology" that's come
| out in the past 20 years is that the "way of doing things" is not
| only completely undocumented, but also not agreed on by any two
| people. I can't remember the last time I found technical
| documentation that even bothered to describe what problem the
| technology was actually designed to solve in the first place - or
| was even written by somebody who seemed to understand why that
| would be important.
| samcgraw wrote:
| > And I am not even considering the time that each developer
| spends on learning all those third-party libraries. I never saw
| two React projects with the same dependencies, project structure,
| and guidelines. This means the knowledge is not transferable from
| project to project, as can be the case in Angular or Vue.
|
| For a developer just looking to make the thing their design team
| sent them as quickly as possible, this makes good sense to me.
| And I get that project/file structures can be wildly jarring to
| an uninitiated dev - I remember looking through a Java repo for
| the first time :shudders:
|
| But! Isn't there a necessary step of understanding why decisions
| were made the way they were? In my experience as a front-end eng,
| even if a previous project involves other-worldly dependencies or
| FS compared to the one I'm on now, if I understand the trade-offs
| of the approaches for the previous project, no amount of
| knowledge is untransferable.
| earthboundkid wrote:
| Technology problems are usually just human problems behind a
| mask. In this case, the real problem was a poorly skilled team
| with bad leadership, and React just exacerbated the problems by
| giving the team enough rope to hang itself.
| darth_avocado wrote:
| Well said. I went through the whole article and it just seems
| to me that instead of asking .NET devs to build a react app,
| you could have just hired react devs and none of the problems
| would've existed. Or have the entire team go through a proper
| react bootcamp. As a dev, I can say for sure, devs not learning
| new things and keeping up to date are the worst. The ones you
| need are the ones who try new things and then create solutions
| that are best fit for the problem with a rational mindset.
| Pretty much everything else will slow your development
| eventually, be it react or something else.
| cratermoon wrote:
| Bootcamps are just ways to extract money from the pockets of
| Enterprises with more money than sense. I worked on a project
| with some COBOL programmers who went to through a "Java in 21
| Days" program. They were decent COBOL programmers, I actually
| learned some useful things about that language and the IBM
| environment. But Java programmers they were NOT.
| https://thedailywtf.com/articles/The_Brillant_Paula_Bean
| cosmotic wrote:
| At some point one has to see the trend of all these people
| hanging themselves with this one platform and maybe there's
| something to the platform, ecosystem, or community that is
| lending itself to the hangings.
| itisit wrote:
| "The major problems of our work are not so much technological
| as sociological in nature."
|
| -- Peopleware (1987) by Tom DeMarco & Timothy Lister
| bluefirebrand wrote:
| 100% this. The moment you allowed the .NET devs to bring their
| mindset into a fundamentally different space you were going in
| the wrong direction.
| Spivak wrote:
| I mean for a greenfield project sure but a port of an
| existing large application that is already coded in a
| specific style you likely want to preserve as much of that as
| possible to make the translation more mechanical.
| bluefirebrand wrote:
| If you're aiming for code reuse don't rewrite. Refactor.
| majormajor wrote:
| If you're porting between two languages/frameworks with
| radically different approaches, preserving the original
| project's approach in the new code is going to give you
| something that's probably _worse_ than the original!
|
| Now when you hire someone new you're going to be looking
| for React experience but then having to re-train them to
| think in .NET, or looking for .NET experience but training
| them to write React... and any time you have dependency
| upgrades, you're gonna be fighting more impedance
| mismatches.
|
| Most tech debt that slows down feature development has more
| to do with the code structure than with the language or
| framework, so if you're intent on preserving the structure
| and style I don't know that you should be doing a rewrite
| at all!
| cratermoon wrote:
| As the old saying goes, you can write FORTRAN in any
| programming language: https://blog.codinghorror.com/you-
| can-write-fortran-in-any-l...
| munchbunny wrote:
| I've worked on stacks with .NET backends and React frontends,
| and there's a ton of truth to this. You can't use .NET
| concepts to bridge into an understanding of React. If you
| need to carry over .NET's paradigms, don't pick React.
|
| Personally, I think if you want a deep understanding of React
| you need to first get in a few cycles of working with DOM,
| JS, CSS, etc. directly. Maybe throw in a functional
| programming language too. _Then_ try to pick up React.
| bluefirebrand wrote:
| This really does nail it. Despite React having a somewhat
| OOP approach to a lot of things (and Class Components being
| the de facto for years), React best practices have evolved
| to be a very functional approach.
|
| .NET wakes up every morning to have OOP pancakes OOP eggs
| and OOP coffee and it can't possibly allow even a hint of
| that beatnik functional style near it.
| munchbunny wrote:
| > .NET wakes up every morning to have OOP pancakes OOP
| eggs and OOP coffee and it can't possibly allow even a
| hint of that beatnik functional style near it.
|
| I agree for the most part. More specifically you're not
| going to write functional code in C# and feel
| particularly good about what comes out. F# is a different
| story.
|
| Speaking from experience a .NET (C#) backend and a React
| frontend is perfectly viable. The key is to keep the
| paradigms in their respective lanes, and if you're going
| to write code for both, get used to switching your
| mindset instead of converging the tools.
| zmmmmm wrote:
| I'm still kind of stuck on the fact that they brought a team
| of .NET devs on to do a React project. What did they think
| was doing to happen when they used a team with no experience
| in the technology stack chosen? The conversation should have
| started with "What skills do the implementation team have?"
| before tech was chosen.
| bluefirebrand wrote:
| Yes, or at the very least "Does the team have interest in
| learning this new tech or are they going to force their own
| notions onto it"
| abhijitramesh wrote:
| Totally agree with this
| racl101 wrote:
| Have to agree with this.
| rdgthree wrote:
| Well said. It was frustrating how little he talked about the
| actual problems with the codebase, instead choosing to handwave
| and blame it all on React. The dig on the React team in
| particular was bizarre:
|
| > React's team enjoy experimenting with new ideas, but this is
| killing the ecosystem! They should be brave and take the blame
| for it!
|
| Have to make a lot of assumptions with this sort of thing, but
| I can't imagine that attitude results in high quality
| engineering work.
| __s wrote:
| React's blogs show great care for backwards compatibility.
| Just look how long they've taken to get rid of string refs
|
| https://reactjs.org/blog/2015/02/24/streamlining-react-
| eleme...
| dfsegoat wrote:
| > They should be brave and take the blame for it!
|
| Projection if I've ever seen it.
|
| https://en.wikipedia.org/wiki/Psychological_projection
| vinceguidry wrote:
| You're just making the author's point for them. A more
| opinionated framework that matched the team that was supposed
| to code with it would have worked better for them over the
| lifecycle of the project.
|
| Most enterprise teams are poorly skilled with bad leadership.
| Modern frameworks and coding paradigms are a bad fit.
| interlocutor wrote:
| > _A more opinionated framework that matched the team that
| was supposed to code with it would have worked better for
| them over the lifecycle of the project._
|
| No it wouldn't, not for an enterprise application that is
| supposed to last a decade or more. Instead you want to use
| standards such as Web Components that will last essentially
| forever.
| jt2190 wrote:
| > ... the real problem was a poorly skilled team with bad
| leadership...
|
| Given this kind of team and leadership, why does that still
| make React the best choice for them?
| hospadar wrote:
| AMEN!
|
| Maybe the team is a bunch of n00bs, so what? Wouldn't the
| perfect framework/language make it hard[er] to screw things
| up regardless of the lack of dev skill? For a big multi-year
| project it often strikes me that the best tools are those
| which are old, boring, and unlikely to change.
|
| That being said, huge-multi-year development in _any_ js
| framework seems terrifying to me because of the churn in the
| general js/browser environment.
|
| Also: I think the author doesn't cover this a lot, but it
| sounds like they REALLY saved their bacon by doing the boring
| due-diligence of carefully documenting the decision process
| behind all the choices they made. They probably would have
| had slowdowns and surprises and roadblocks no matter what,
| but someone's still got a job because they took time to get
| it in writing.
| polote wrote:
| Not everything is a problem. If you design a language and only
| one human in the world it able to learn it. Then this is not a
| people problem but a language problem ! You can't control the
| skill of the team, this can't be the problem this is a fact.
| akamaka wrote:
| I've built successful large enterprise apps in React, and would
| recommend it.
|
| Here's how we avoided some of his pitfalls:
|
| * Small team of talented developers who didn't always agree on
| libraries and methodology, but worked through disagreements to
| reach a consensus
|
| * Recognizing that libraries would change over a two year
| project, and being ready for major library migration and
| refactoring
|
| * Writing our own state management tools when needed. Redux is a
| tiny library. On a two year project, why not create your own
| custom state management system from scratch, one which makes the
| .NET people comfortable and has the features that match your
| project's needs? It boggles my mind that many devs consider state
| management libraries to be something sacred, like a compiler,
| which you would never consider reimplementing yourself on an
| enterprise project.
| rafaelturk wrote:
| This very misleading. Looks like .NET and OOP dinosaurs are the
| real culprit in your project.
| flowerlad wrote:
| > _So I am not afraid of getting into a debate about why those
| are unusual patterns for React._
|
| I have seen some developers follow patterns just because they are
| patterns. Once the community starts doing things one way that's
| it, even if it is a dumb way, the herd mentality causes the dumb
| way to become established. Redux is one of those dumb ways.
|
| > _Because 30% of the business logic was inside Redux-Saga, I
| marked it as a high risk._
|
| Business logic should be written in POJO. Plain Old JavaScript
| Objects. Using a library such as Redux is a dumb way, but this is
| the community-embraced, herd-mentality way.
|
| > _I will not encourage using it for enterprise applications._
|
| Use Web Components. Using the flavor-of-the-month JavaScript libs
| for a large application that must live years or decades is not
| justifiable.
| Gaelan wrote:
| > Business logic should be written in POJO. Plain Old
| JavaScript Objects. Using a library such as Redux is a dumb
| way, but this is the community-embraced, herd-mentality way.
|
| Redux is really just a pattern for business logic using POJO -
| you have a function that takes an update and returns the new
| state. The library itself is about a hundred lines.
|
| > Use Web Components. Using the flavor-of-the-month JavaScript
| libs for a large application that must live years or decades is
| not justifiable.
|
| How is web components not just another flavor-of-the-month
| JavaScript library, and an unpopular one at that? Sure, it's
| part of the browser instead of something you load externally,
| but I'm not sure that changes things in any meaningful way.
| You're still tightly binding your code to something which may
| or may not remain popular.
| TheCoelacanth wrote:
| True of vanilla redux, but people using redux-thunk or redux-
| saga tend to bake it deep into their business logic.
| maxfurman wrote:
| This mirrors my own experience with React. The core library
| itself is fine, and I love the way it bridges functional
| paradigms without forcing a ton of functional vocabulary on the
| team, but the ecosystem is a mess. And, because the React core is
| so minimal, eventually you need to interact with that ecosystem.
| JS dependency hell is real, and it's worse with React than any
| other framework that I've worked with.
| nawgz wrote:
| I don't really understand what users are doing when they say
| things like this. What kind of features are you trying to
| implement?
|
| As a React dev since 2015, things were pretty bad initially in
| this way - but now you can literally build complete
| applications with React, react-router-dom (clearly the winner
| in this regard), and your choice of state management (mobx 6
| is, to me, the best). Redux is king and MobX is the slightly
| more adventurous challenger.
|
| I have built an absolute plethora of applications and I do not
| have any external dependencies beyond those two, TypeScript,
| D3, and the occasional helper library (date formatting, deep-
| equals, etc).
|
| Speaking to some other points as well, the React core is not
| really minimal at all anymore, since the advent of hooks you
| can actually completely bypass external state management and
| just use hooks and your own context. I've done this on a couple
| smaller applications lately and the hooks `useState` and
| `useEffect` are actually insanely powerful.
|
| Last but not least, React has insanely strong error messages
| and linting warnings. Things like non-unique key errors, debug
| symbols knowing the actual source of errors, stack traces
| enumerating thru the actual React tree so you can see your
| error, dependency array validation for useEffect, and more that
| I can't recall at the moment - it's the top library for UI for
| a lot of reasons and I think your opinion sounds a few years
| old.
| predaking wrote:
| So many things here indicating both a strategic problem in the
| org and some issues with the approach. Context: I've used both
| React and Angular extensively on a variety of applications, for
| startups and the most "enterprisey" of entities claiming to be
| enterprisey (the government) _and_ came from a .NET background
| prior.
|
| First - GRRR. What defined this as an "enterprise" app? Facebook
| is an enterprise app, dude, with millions of transactions a day.
| Just because an app is big doesn't make it an "enterprise" app.
|
| architect was hired from outside to create a proposal for a team
| that had no one capable of operating in that role (and apparently
| the CTO as well)
|
| "He already has a development partner in India, but they lack
| experience in building web applications." - this is a massive red
| flag
|
| architect was sent away to do proposals without anyone talking to
| the development team to get _any_ buy-in
|
| architect got the background of the dev team from the CTO but
| neither architect or CTO talked to the development team (who
| would be implementing) prior to doing a proposal
|
| "the technical lead ambushes me" - this is the first time the
| tech lead and the "architect" interacted. There's no "ambush"
| here; it's a failing on the CTO+architect's part to communicate
| to the team in advance, and perhaps at least involve the team
| lead
|
| CTO is against angular but his outsourced team is familiar with
| .NET and Java; why is there even a need for an "outside
| architect" to make this choice when it's only between React and
| Angular?
|
| "the CTO is backing his team, which is normal. He had known me
| for just two months, while he had been working with his team for
| many years." - Why is no one on the CTO's team, after many years,
| capable of investigating and making these decisions? Why did they
| need to go outside? If the plan was to continue using this
| outsourced team, why didn't anyone invest in their training to be
| self-sufficient vs a direction from on high? Why was there zero
| training plan?
|
| "And that's how we end up with three ways of doing things. There
| is no consistency anymore." Where is the CTO during all of this?
| TheCoelacanth wrote:
| I wouldn't consider Facebook an enterprise app in the
| slightest. It's a consumer app.
|
| Enterprise apps tend to have much lower volume of users but a
| ridiculously long checklist of features.
| cratermoon wrote:
| The quintessential Enterprise app is SAP.
| predaking wrote:
| Adding to my comment: no mention of any sort of design system
| for a component based library (kind of key in either Angular or
| React or any other component-based UI framework), no mention of
| the CTO _or_ the architect _or_ the dev team establishing
| consistent standards and being responsible about their
| use...anyway, not every problem is "technical" in nature.
| Sounds like this project (and company) had a lot of issues
| going well beyond the tech.
| iagorodriguez wrote:
| The problem is not about react or not react, the problem is how
| to align big team to create an application. If a big team is
| going to be working on it you need some strong opinions around
| it. Do not mess with the package.json. I cant stress this enough.
| Actually, the most important file in your whole application is
| the package.json. Almost nobody should be allowed to add
| additional dependencies because is the main point to generate
| chaos and problems in the long term.
|
| Also, the design system matters a lot. Have a small team working
| on the UI components to tailor and extend the design system. Dont
| allow the rest of the teams to extend the ui components with new
| libraries. Stick with the design system as much as you can. The
| rest of the teams should minimize the amount of CSS they have to
| write to components placement.
|
| Usually the datagrid is the soul of any enterprise application.
| Choose it wisely and be sure it covers as much functionality as
| you can and also that it is customizable on an "easy" way. There
| is always a team with the need of a datagrid that sorts, groups,
| filters the data with dynamically adjustable cells and multi
| header items without pagination. Welcome to hell.
|
| Use one pattern: hooks, central store, whatever you want. If at
| some point you have to change it you have to know which teams are
| using which one. Dont allow team members of the same team follow
| different patterns. Code reviews must take care of this.
|
| Hope this small tips help one or two teams out there. I have
| worked on the migration of 5 big enterprise applications from
| angularjs to react or from legacy desktop application to react or
| from server pages to react.
|
| I made a lot of mistakes that costed a lot of dollars. I have
| tried to learn from them. Also, dont take me very seriously, I am
| pretty sure I am about to discover another mistake I have made.
| vinceguidry wrote:
| It's been awhile since I've worked with npm, does it still do
| that thing where it changes package.json every time you `npm
| install`? I remember writing a script to discard package.json
| edits because my PR wasn't supposed to upgrade any libraries.
| andybp85 wrote:
| you have to use `npm ci`, which was added a few years ago. my
| team ran into that kind of issue right after `ci` was added,
| thankfully, or we would've had to do something similar.
|
| i now have this aliased to `ni`, so i get to say `ni` to the
| app often.
| firebaze wrote:
| Made my day :) Guess we'll adopt this.
| chairmanmow wrote:
| I never recall it doing that, you may be thinking of the
| `package-lock.json` which does get created still. It
| basically creates/records hashes of the packages that get
| installed when `npm install` runs. Shouldn't always be
| changes there but depending on how version flags are set in
| `package.json` an `npm install` could create new `package-
| lock.json` values if there's a newer version in the repo that
| gets upgraded/installed.
| cratermoon wrote:
| We have a private local package repo at my company. Some
| developers set up their npm registry, or had it set up for
| them, with registry=https://.. Others have
| registry=http://...
|
| Regardless of whether or not Strict-Transport-Security is
| enabled on the server, npm will still record the protocol
| as-is in the package-lock.json file.
|
| Half the time a PR will include a package-lock.json with
| every "resolved" field having the protocol gratuitously
| changed to the other protocol.
| bluefirebrand wrote:
| This seems like a problem that could be solved with one
| email.
| cratermoon wrote:
| I think the story we're all commenting on demonstrates
| how unlikely a single email is going to fix it.
| janaagaard wrote:
| We have a pretty similar issue at work where our package-
| lock file switches URLs between npmjs.com and our own npm
| registry. Can you elaborate a bit on what the issue is
| and how to solve it?
| lhorie wrote:
| The issue is that some developers have configured the
| registry field in their .npmrc file incorrectly. Ideally,
| sending out a memo telling everyone to fix it should do
| it. If not, one way to fix it is to commit the .npmrc
| with the correct configuration (assuming it doesn't
| include secrets). If all else fails, an ugly hack is to
| make a preinstall hook that fixes the .npmrc file.
| twobuy wrote:
| This is likely referring to the .npmrc registry field.
| erlich wrote:
| > Do not mess with the package.json
|
| Use a monorepo with many `package.json` files. Then someone
| working on a data grid component for example can add the
| packages they need for that component and no one else's code
| will depend on it and it won't break anyone else's.
| midrus wrote:
| > If a big team is going to be working on it you need some
| strong opinions around it.
|
| You are just stating the problem the article complains about.
|
| Whose opinions are those? You need to take a lot of decisions.
|
| Moreover, those decisions which seemed good (to you...or the
| one that dictates those strong opinions) at the time you took
| it, are not valid just months or years down the road. So you
| will need to reevaluate them periodically.
|
| Moreover, even if you are happy with your decisions, you might
| be forced to take them again, because the library went out of
| fashion, unmaintained, or the developers just stop responding
| to issues and ignore you completely. This is already happening
| to a project I work with where the react-router developers just
| went to build their own nextjs competitor and stopped
| responding to issues. Same with styled-jsx from the same
| next.js team, not even themselves seem to be using it anymore.
|
| This never happened to me using Rails. True some gem might go
| away, but at least it usually is some helper thing and not the
| core of my f*ng application. Same experience with django and
| many other uncool stacks.
|
| So, yes. React is amazing if you are facebook, google, amazon,
| building a side project or just working for your own resume. It
| is not good for the average business. It is not good for
| enterprise applications.
|
| In my own experience, at least.
| iagorodriguez wrote:
| I am a rails developer myself and I love rails, but this
| applies to rails too. Actually rails lowers this problems a
| little because it is an opinionated framework but you could
| same to Angular for frontend. In react case, you just have to
| build that yourself with the pros and cons.
| gregoriol wrote:
| You are describing a job I really would hate: no inovation, no
| try. If you can't even change the package.json without getting
| everyone angry, it's a horrible team to work in.
| iagorodriguez wrote:
| Innovation doesnt come from adding a library to the package
| json. You are a member of a big team, not a single dev on a
| pet project. Innovation is on the product, not in your
| developer experience (unless you are creating a developer
| tool). Consensus to make big decisions is not the way to
| limit your developer skills is the way to align a team to
| achieve a common goal. :)
| ssijak wrote:
| The tips that parent poster gave hold true in teams working
| with any different tech.
| whimsicalism wrote:
| Unilateralism != innovation.
| Hallucinaut wrote:
| I love this way of phrasing it. I have these types of
| arguments with a particular type of colleague often, and
| this is a missing part of my explanation script.
| hernanba wrote:
| One of the keys for a successful migration is the strategy. It
| doesn't make any sense to re-write the whole platform and
| launch the new one after a year of work or so. Adoption is
| super important so an incremental migration is a key (you start
| coding as other teams get onboard in the migration). A
| microfrontends strategy could be a good idea.
|
| Internal support from eng teams is a must, without that the
| migration won't work.
| bargl wrote:
| This was my biggest take away from this article too.
|
| When you have a big project, you have to keep a consistent
| architecture. You need to keep using the same tools and
| patterns so that you have cohesion in your code base.
|
| The worst thing about new architects on long lived projects is
| you typically get 2-4 ways of doing the same thing. If you're
| going to do that it needs to be so good that you don't mix and
| match.
|
| If you are going to mix and match, you need to have a solid
| approach to splitting your dependencies, one way I'd have
| looked at doing this is by splitting this into multiple sub SPA
| applications and each mini project would be able to conform to
| it's own standard as long as it could interface with the glue
| application, this is by no means foolproof, but it gets you a
| lot closer to a maintainable situation from my experience.
|
| Why I like this approach is that I saw a comment from someone
| saying they'd hate to be on a team with a uniform style. I
| completely get that, innovation is super important, but you
| have to build boundary layers between the different styles so
| you don't end up building such a hodgepodge of dependencies
| that you can't get things to work anymore. It also keeps your
| build times down and reduces time to get started working on
| your module.
|
| Again same comment you made, I've made mistakes, trying to
| learn from them, maybe my current approach is bad too and
| there's a better way.
| prewett wrote:
| 1200 dependencies?! Is this normal in web development? That
| sounds like a nightmare waiting to happen! I'm working with a
| rather large C++ project now, and it only has 40 dependencies,
| which I already consider pretty large.
| drazvan91 wrote:
| Yes, but those 40 dependencies have their own dependencies ...
| Which leads to a few hundreds. Check node_modules
| franklyt wrote:
| The main problem I'm having here is that I can't think of any
| JavaScript framework that has solved this problem.
|
| Angular is just too cumbersome, though it gets an honorable
| mention.
|
| Perhaps there is so much churn here because the correct way
| hasn't been discovered yet?
| nickthemagicman wrote:
| The problem is how broken all of it is trying to work around
| browsers native warts. As future versions of native JS becomes
| better and web assembly takes over, things will probably
| improve massively.
| franklyt wrote:
| To me, it seems like the concept of the DOM might be the
| problem.
| tmpxgdqrcKFuG wrote:
| Why _not_ split the frontend and the backend apps into separate
| applications? That would help with the future proofing since if
| you wanted to switch to another javascript framework, you could
| do that.
|
| EDIT: forgot an important word
| titanomachy wrote:
| The comments about node dependencies exploding and build times
| creeping up over time was painfully familiar. I now work at a
| large company that addresses this with strong library discipline
| and huge investment in build infrastructure, but when I worked on
| teams at small- and medium-sized companies we were always plagued
| by these kind of problems.
| bastawhiz wrote:
| I think some of the points are valid (.Net folks are not going to
| have a great time working on a React codebase). I think some of
| the problems are a result of the decision to use Redux. Redux was
| very much in vogue for a while, but in every project I've used it
| for, it really hampers DX when you start to get stuck in on a
| large project. To do stuff that involves async (read:
| everything), you need helpers (thunks, saga, etc.) which
| introduce their own quirks, and require their own tools. Soon,
| you're up to your eyeballs in boilerplate.
|
| As for the (build-time) performance concerns, I think there's
| some work here. They have a _big app_. And if you're compiling a
| 220 page app in a single build, it's going to get slow. You'd
| have the same problem, though, with a native mobile app or a very
| large C++ app: at some point, you need folks focusing on the
| infrastructure bits part time. With a relatively small number of
| changes, they can probably make some big wins: adding build
| caching for local development, using an NPM proxy (to avoid
| downloading 600MB of deps over the public internet on every
| build), looking at alternative hot reload plugins, etc.
|
| That's not to say React is without problems, but I think it's
| worth considering that _almost any_ technology of the scale of
| React is going to have drawbacks, especially if you don't have
| someone in-house who has really significant experience making it
| work well. Companies like Airbnb, Facebook, Uber, etc. all have
| whole teams ("JS Infra") dedicated to this stuff, in the same way
| there are teams like Ruby Infra, etc.
| jorl17 wrote:
| What do you suggest developers use instead of Redux?
| brlewis wrote:
| Not the OP, but I'd suggest using what's built into React,
| i.e. keeping shared state in a parent component, until you
| hit one of the reasons the Redux docs enumerate for using it:
| https://redux.js.org/faq/general#when-should-i-use-redux
| jeroenhd wrote:
| It all depends on the scope of the project, but if you use
| Redux as a way to keep a cache of backend data so you don't
| need to request everything every again in every component or
| pass everything down in props, then you could consider a
| system like graphql. One project I'm working on part time is
| switching from class based components + Redux to functional
| components + graphql and I must say I'm enjoying graphql a
| lot more than I was writing actions, sagas and reducers.
|
| I don't have any recommendations for pure client side
| applications though, but for those you can probably get away
| with using contexts and hooks for quite a lot of the state
| management.
| bastawhiz wrote:
| For most products, you didn't need anything besides React in
| the first place. It's really only useful when you have a
| single blob of state which is displayed/sliced/etc. in
| different ways across a large number of views. But for the
| most part, many apps are largely read-only (you can use
| `Context`s to push data down your render tree), where
| mutations happen close to where the data is loaded, meaning
| the benefits of redux are lost.
|
| The big pain point of Redux (IMO) is that you do you data
| fetching separately from managing the data in your data
| store. It means that you need to add this glue layer between
| the data that comes back from your API and the redux store--
| you need to re-model everything. Every time you get new data,
| you need to go out of your way to remember to update
| everything that could be affected by that data.
|
| GraphQL (I'm fond of Apollo) gets this more right. You can
| still use REST APIs with GQL (usually not by default, but
| it's possible). What this means is that you model your data
| in the way that the API expresses it. Your back-end folks
| aren't going to be lost when they read your code, because it
| matches the shape of the data they're already familiar with.
| The client-side cache means you don't need to manually fiddle
| with your store to invalidate stale data (I've yet to need to
| manually reach into the cache to perform updates).
|
| That's not to say GQL is without its own issues. It is yet-
| another-thing, but it's one example of a solution which
| doesn't get quite as hairy when you've got 200+ pages in your
| app.
| crooked-v wrote:
| Most cases I've seen are just using Redux as a de facto
| global cache, where it can be easily replaced by a library
| like Apollo or SWR (https://swr.vercel.app) to just have
| every component make whichever requests it needs for data
| directly (and the library then deduplicates requests and
| serves data from cache).
| vajrabum wrote:
| I'm think I'm not able to read this story without paying. Medium
| seems like they are becoming increasingly a pay to read only
| service.
| worik wrote:
| Try private mode....
| [deleted]
| [deleted]
| [deleted]
| mcguire wrote:
| Wouldn't it have been a better idea to break the giant app into
| smaller ones with well-defined interfaces?
| victorbstan wrote:
| Would love see people go back to posting in their own blogs
| instead of Medium. I get paywalled or app walled. Where I have to
| either log in or use the native mobile app to read the article.
| Medium is not a good place to share information.
| franklyt wrote:
| An unopinionated ecosystem will soon become known a mistake in a
| similar vein as dynamic typing was.
| worik wrote:
| I have spent my morning pleasantly reading the comments here
| after reading the article.
|
| I am struck that a lot of us here start the comments with "I have
| been a React developer for [3, 4, 5] years"
|
| I think this illustrates the fundamental weakness in the approach
| of people in the Javascrpt Frameworks world.
|
| Billion dollar organisations build software that will cost tens
| of millions to develop want, or should want, more experience than
| that.
|
| Javascrpit, and "Web 2.0", generally have been around long enough
| to meet the requirements, but this churn in frameworks is enough
| to make anybody with a stake in organisations shake with fear.
|
| IMO plain old vanilla JS with a sprinkling of libraries for
| syntactic sugar (and they can be hand rolled - or use JQuery) is
| a much better proposition than all of these shiny and new stacks
| that keep getting deprecated.
|
| Web front ends are a huge boon, and the settling of basic JS
| syntax and implementations makes some very good things possible
| that were not possible twenty years ago. But the whole industry
| is being held back by allways wanting "better", and not accepting
| "good".
| ficklepickle wrote:
| You might assume that, but operating at the level of DOM
| manipulations is too low-level for a large application.
|
| They are huge productivity boosters. I agree that they are
| often used irresponsibly resulting in poor quality software.
| Poor software isn't limited to the browser, however. A lot of
| commercial software is garbage. Profit incentives seem to
| encourage software that is barely fit for purpose.
| moonbug wrote:
| web tech really is bollocks, isn't it.
| kansface wrote:
| I don't understand this sentiment at all... even approximately.
| I've been doing this for about 15 years now. I started in the
| days of "This website works best in IE5" (read, only works in
| ie5). I wrote _Macromedia_ Flash Apps to make animations,
| because that was the only option. It was awesome! I spent hours
| or even days making rounded corners via chopping up images and
| table hacks, because rounded corners seemed really important.
| Just laying stuff out correctly on the page and stupid browser
| hacks was most of the job.
|
| I personally went from spending probably 60% of my time fixing
| cross compatibility bugs to spending a few hours a year on it.
| We went from manual coding for cross browser support, to
| polyfills, to telling webpack to dynamically include polyfills
| to target the subset of browsers I care about with 2 lines of
| configuration. I can now determine the exact tradeoff between
| file size and audience reach. Yes, that came with some
| complexity. Yes, that tradeoff is 100% worth it. No, you do not
| have to use it.
|
| This is how I feel about React. I've unintentionally built my
| own, shitty version of React at least half a dozen times over
| the last decade. The last time, maybe 4 or 5 years ago now, was
| an online file system browser which could contain tens or
| possibly hundreds of thousands of folders/files. The naive
| implementation wouldn't load. A less naive implementation took
| a few weeks to implement and seconds to load. The React rewrite
| took a day or two to write and loaded in milliseconds. It was
| less code, easier to understand, and a couple of orders of
| magnitude more performant!
|
| Other languages don't have crazy build systems because they
| don't have to run the same code on multiple platforms made by
| multiple competing vendors on multiple operating systems for
| hardware ranging from a M1 to a refrigerator. If that's not
| you, not a problem, you can just write vanilla JS. If you don't
| have thousands of objects that you dynamically load that need
| to be turned into DOM Nodes, don't reach for React... If you
| just want a library that renders some DOM Nodes, thats fine
| too, use React and nothing else - you can even write
| react.createElement by hand and eschew JSX if so desired!
|
| I would not choose to go back to the halcyon days of web dev
| where we didn't have dependencies and dependency management
| because we couldn't. At this point in my career, changing web
| tech has lead to a productivity increase of probably 10000%.
| There are some pain points, but we're working on it! Web tech,
| fuck yeah!
| viburnum wrote:
| 220 pages! That alone makes React a poor choice.
| rafaelturk wrote:
| Not at all, react handles this quite well. Just use code-split
| per route, webpack manages this with a few lines of code
| crooked-v wrote:
| Also, various libraries like Next.js will do this kind of
| code splitting along routes out of the box.
| atum47 wrote:
| well, I'm on the opposite side: I failed two code interviews
| (before the job I have now) because I did not used React. One
| comment I will never forget from the feedback I got back from one
| of the reviewers: JavaScript vanilla is HARD to read. Another one
| was that I used a "global" css file, instead of having CSS in the
| same file as the "component".
| [deleted]
| devmor wrote:
| This had nothing to do with react, and everything to do with you
| rolling over and accepting what other people wanted to do
| differently irrespective of your project guidelines.
|
| You can't expect an application to remain easy to develop when
| people do not adhere to your development protocols.
| joshxyz wrote:
| Honestly my primary source of headaches is also the router, the
| redux, the sagas, the thunks.
|
| It's always the fuckload of third-party libraries we think we
| need.
| renke1 wrote:
| > "Why are file names dash-case when class names are PascalCase?
| It should reflect the class name, so from now on, we will name
| them SomePageComponent.tsx."
|
| That's actually a common practice. Files (modules, that is) are
| usually named after their principal export.
| aeturnum wrote:
| I mean, this feels like a classic example of not choosing the
| best technology for the situation. Picking a more opinionated (or
| more batteries included) framework likely would have streamlined
| a lot of the problems he described. That doesn't reflect badly on
| React - certainly there are teams that could have used it to
| implement a project of this size - but it reflects badly on the
| author.
|
| > I will not encourage using it for enterprise applications.
|
| Almost like large-scale projects have different requirements and
| the tools generally used on large scale projects (like .Net) have
| adapted to reflect those requirements.
| dragonwriter wrote:
| > Quick onboarding for new team members, especially for the .NET
| developers working on the old desktop application.
|
| Yeah, unless you have a sufficient base of React (or at least JS)
| devs to shepherd this, this is obviously going to be a problem
| for choosing anything that isn't .NET, and the further from their
| existing .NET experience it is, the worse it will be.
|
| .NET is a workable web app platform, even for isomorphic apps via
| Blazor. If immediate onboarding of .NET devs was a key
| requirement, .NET was the obvious answer.
| ezzzzz wrote:
| Judging by the article, this project likely started before
| Blazor was released, however, I have to agree that .NET should
| have been the obvious choice. Maybe the author wasn't able to
| decide this, but I wouldn't consider an SPA for an enterprise
| app unless there was a very good reason. Stick to boring stuff
| that works. Leave the bleeding edge stuff for side-projects and
| startups.
___________________________________________________________________
(page generated 2021-01-22 23:01 UTC)