Some of the performance problems on Windows are related to always-on antivirus. Exclude your project directories from antivirus scan and you'll see the difference. JetBrains IDEs now even have an auto-suggestion and an option to do it directly from the IDE.
React created roadblocks in our enterprise app
251–260 of 298 posts
Re: React created roadblocks in our enterprise app
#252In my opinion you need to have a dedicated Tools engineer in teams above 10 people. Most developers are poorly prepared to debug build/perf issues. A lot of author issues could be reduced by using right tooling.
- eslint for style
- Webpack Externals/Module federation for build times
- Dependabot/renovate for automatic dependacies
- codemon for automated refactors
- WSL2 or vagrant VM + docker-compose for local dev
Re: React created roadblocks in our enterprise app
#253Earlier quoted context omitted.
>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 i…
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 superse…
I really wish I saw what everyone else sees in TypeScript because that language has not sold itself to me at all, even using it professionally for years now. Even using it's primary feature can be a pain because nobody documents their types as far as I've found. It's surprisingly common for me to write code that compiles but crashes at runtime. Other, better JS-targeting languages manage to allow me to retain type-level features at runtime while also outputting leaner, faster, and safer code. The only value prop I really see is the momentum, but it feels like a huge push for the right reasons and in the worst possible direction.
It's not that TypeScript hasn't helped at all, it just doesn't feel like it's this revolutionary thing that people treat it as. And I'm not even going to touch how visually noisy and distracting I find the C#-style type syntax to be.
Re: React created roadblocks in our enterprise app
#254Earlier quoted context omitted.
"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.
“We judge ourselves by our intentions and others by their actions”
Great reply to this mindset. The chance that anyone who makes this claim has actually evaluated enough (or any) JS projects to see why they churn is effectively zero.
We have version pinning for a reason. It lets churn exist without forcing the effects of it onto other developers. I don't care if a library I use gets updated every week or even every day, I'm not installing every new version when it's released, that's silly. Nobody does that in a real project, that's chaos.
Re: React created roadblocks in our enterprise app
#255As 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 thi…
Sounds like my current project. I was tasked to start working on a project and was told I could use "whatever [I] want." So me and the other frontend guy started working using Clojurescript with Reagent and Re-frame (highly recommend). Save for a few hiccups along the way the project was stable and fast.
It went swimmingly right up until QA was more or less told not to file any issues found, and then those issues were used as a reason we needed to use a TypeScript and Material-UI app he wrote over a weekend and said was "almost done." The bugs in question turned out to be minor visual bugs, and like I said, none of them were filed or even mentioned until this replacement got dropped in our lap. In fact, no problems of any kind were reported until this moment.
Instead it took another 6-8 months to get to feature parity with the app we'd already developed and now thrown away (or feature "parody" as my boss put it), it was full of bugs, development is slow and pretty directionless, my boss gets bored and contributes code that runs in the O(n^12) range (yes, really) before languishing in a draft PR for months and then getting dumped on us to actually implement for real, and it's been a year and a half with no end even remotely in sight.
I really want to find somewhere else but that doesn't seem like a realistic goal right now. Not to mention my enjoyment of programming died years ago and I haven't written code for fun in as long as I care to remember.
Re: React created roadblocks in our enterprise app
#256Earlier quoted context omitted.
"old style" from the horse-and-buggy-olden-days of 2010+ :D.
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
Oh the long lost days before "server-side" needed to be added.
Re: React created roadblocks in our enterprise app
#257One 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…
I've had clients where this would get you told (in execuspeak) that the least important part of a project is the engineering and the engineering team. Which is of course why their sales people would answer every question with, "Yep, it does that." Nevermind that some of the things getting promised were not actually possible.
I remember one in particular that would push incredibly tight deadlines for huge features, got frustrated at the pace and hired another dev team, and didn't change the way they set deadlines. This of course fixed nothing. Then the other team they hired pushed a huge change to the repo, almost every file in the codebase was touched. Nearly 70% of which was whitespace changes and the other 30% was unfinished code that did not compile. We later found evidence that they hadn't even run the code before pushing the changes. The client demanded that we merge it, were told it would break the build, got mad when we merged it and the build broke, then tried to use that (and a whole bunch of almost hilarious and similarly-effective arguments) against us in a lawsuit which they lost, and then lost the countersuit.
So yeah, that was a fun time for my liver, to say the least. Especially since the C-levels decided to focus the entire company's output on that lawsuit while the engineering team sat around mostly twiddling their thumbs.
Re: React created roadblocks in our enterprise app
#258Earlier quoted context omitted.
Angular has built in dependency injection, recommends to use services to encapsulate state. Built-in services use RxJs for propagating changes by default, and following that pattern gets you very far. Especially for an enterprise app. https://angular.io/guide/singleton-services
Hm, right, forgot about DI. Still, RxJS is the one thing many of my peers just cannot seem to grasp. So IMHO that's actually a minus.
I'd pick RxJs over Redux, naturally if a team should use whatever they're happy with.
Re: React created roadblocks in our enterprise app
#259Earlier quoted context omitted.
> 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 t…
Curious what’s on your radar for alternatives. Ember?
Not doing an SPA unless it is the last resort. Building google maps or an offline first app.
Re: React created roadblocks in our enterprise app
#260Earlier quoted context omitted.
1. 5 years ago no: React was already the #1 JS frontend framework at that point. In terms of mindshare if not project volume. 2. I think the key difference is that Angular was a nightmare to work with, especially on larger projects. Whereas React is fairly simple, and tends to be easily maintainable over time. > React started off as a simple and straightforward library. It still is. The implementation is kinda comple…
> In terms of mindshare if not project volume. Regardless, you missed the point. Which was that, frameworks come and go. The DOM and other APIs implemented by the browser, on the other hand, are here to stay. Very few things built into the browser have been taken away (such as blink and frameset). > The implementation is kinda complex at this point Right. And that makes failures and perf issues hard to track down. If…
> Regardless, you missed the point. Which was that, frameworks come and go.
Do they? Rails was released in 2005: it's still here. Ditto for Django. It's true that historically frontend frameworks haven't had the same longevity. But nothing in that space had gotten to the same level of momentum as React has. Except jQuery, and that's still here and maintained too.
In contrast, the web component APIs do not have momentum. I would not be entirely surprised if parts of them were removed in future due to lack of use.
> Right. And that makes failures and perf issues hard to track down. > If you know how to program using APIs and components built into the browser, that is easier at this point.
I rather disagree on this point. I've only seen React slow in 2 circumstances:
1. Too many DOM elements for the browser to cope with. At this point you need to start looking into virtualisation solutions, which is easy to do with a library like react-window. And is exactly what you would do with raw DOM APIs.
2. Excessive re-renders. There is excellent documentation on how to avoid this (memoising transformation functions). And a very simple mental model for how it works (following the usual JavaScript === equality rules). Avoiding this in vanilla DOM code is much harder, because you have a choice between re-rendering everything any time anything updates, doing very tricky piecemeal updates which quickly becomes unmaintainable, or re-inventing a react-like diffing system.