Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Search - "components"
Fuck the memes.
Fuck the framework battles.
Fuck the language battles.
Fuck the titles.
Anybody who has been in this field long enough knows that it doesn't matter if your linus fucking torvalds, there is no human who has lived or ever will live that simultaneously understands, knows, and remembers how to implement, in multiple languages, the following:
- jest mocks for complex React components (partial mocks, full mocks, no mocks at all!)
- token cancellation for asynchronous Tasks in C#
- fullstack CRUD, REST, and websocket communication (throw in gRPC for bonus points)
- database query optimization, seeding, and design
- nginx routing, https redirection
- build automation with full test coverage and environment consideration
- docker container versioning, restoration, and cleanup
- internationalization on both the front AND backends
- secret storage, security audits
- package management, maintenence, and deprecation reviews
- integrating with dozens of APIs
- fucking how to center a div
and that's a _comically_ incomplete list; barely scratches the surface of the full range of what a dev can encounter in a given day of writing software
have many of us probably done one or even all of these at different times? surely.
but does that mean we are supposed to draw that up at a moment's notice some cookie-cutter solution like a fucking robot and spit out an answer on a fax sheet?
recruiters, if you read this site (perhaps only the good ones do anyway so its wasted oxygen), just know that whoever you hire its literally the luck of the draw of how well they perform during the interview. sure, perhaps some perform better, but you can never know how good someone is until they literally start working at your org, so... have fun with that.
Oh and I almost forgot, again for you recruiters, on top of that list which you probably won't ever understand for the entirety of your lives, you can also add writing documentation, backup scripts, and orchestrating / administrating fucking JIRA or actually any somewhat technical dashboard like a CMS or website, because once again, the devs are the only truly competent ones - and i don't even mean in a technical sense, i mean in a HUMAN sense of GETTING SHIT DONE IN GENERAL.
There's literally 2 types of people in the world: those who sit around drawing flow charts and talking on the phone all day, and those WHO LITERALLY FUCKING BUILD THE WORLD
why don't i just run the whole fucking company at this point? you guys are "celebrating" that you made literally $5 dollars from a single customer and i'm just sitting here coding 12 hours a day like all is fine and well
i'm so ANGRY its always the same no matter where i go, non-technical people have just no clue, even when you implore them how long things take, they just nod and smile and say "we'll do it the MVP way". sure, fine, you can do that like 2 or 3 times, but not for 6 fucking months until you have a stack of "MVPs" that come toppling down like the garbage they are.
How do expect to keep the "momentum" of your customers and sales (I hope you can hear the hatred of each of these market words as I type them) if the entire system is glued together with ducktape because YOU wanted to expedite the feature by doing it the EASY way instead of the RIGHT way. god, just forget it, nobody is going to listen anyway, its like the 5th time a row in my life
we NEED tests!
we NEED to know our code coverage!
we NEED to design our system to handle large amounts of traffic!
we NEED detailed logging!
we NEED to start building an exception database!
BILBO BAGGINS! I'm not trying to hurt you! I'm trying to help you!
Don't really know what this rant was, I'm just raging and all over the place at the universe. I'm going to bed.20
The brief history of Facebook open source:
- FB releases React under an oppressive licence that tells "woopsie, can't sue FB if you use React"
- a lot of money goes into making React popular to gain leverage from mass adoption
- VMware bans React in their company
- FB releases Flux to bring state management. It flops. Replaced by what some Russian student wrote in several evenings (Redux)
- Preact is released. It's faster than React, and it has MIT licence. Vue beats React in GitHub stars.
- Under mass pressure, FB changes React's licence to MIT. Initial plan to gain leverage fails spectacularly.
- FB releases Flow Types. It flops. Replaced by TypeScript.
- FB releases their own app market for React Native. It flops.
- FB releases Relay. It flops. Replaced by Apollo.
- FB tries to push React.Suspense for the whole JS landscape to obey and comply to how it works. Community says "Fuck You".
- FB releases react-native-web. It flops.
- Web Components are out in all browsers, adopted as a standard. React doesn't support them.
- Google releases Lit, a virtual DOM framework on top of Web Components to fuck with React. It's a massive success.
- React 18 is out. Still no Web Components support.
- (you are here)16
Current work project is microservices architecture out of 4 - 8 components.
It is fully Infrastructure as a Code automatized. I just change somewhere code, git pushing
And it automatically invokes Gitlab CI, terraform, ansible, kubernetes helm charts.
Auto checking itself with unit and integration tests in autoredeployed staging env. Then it saves tested results to docker registry and asks for one button verificating click to be rereleased to prod.
I just go for drink or eat food. While all the stuff is happening.
And I am proud that all the infrastructure, backend and frontend I made on my own.
I don't need to remember how to Deploy it. It is all automatized3
Next year I will strive to achieve the best test coverage on all our components and design all our new features using best-practice agile methodology with a realtime user involvement.
Reverend on 7 January: Fuck that, we need to ship this shit to production now.
Salesforce lightning web components have such bullshit limitations that they claim is because of security but it's just because it's overengineered garbage.
Want to use web components? Nope.
Want to pass in a value to a function in a click listener expression? Nope.
Want to use scss? Nope, compile it to css yourself.
Want to use the fucking document object? Guess what it's overridden except for very specific third party frameworks.
Who in the fuck thought it was a good idea to override the document object? Your app isn't more secure, literally the entire internet uses the document object and it still becomes available in runtime anyway so what the fuck??
LWC is the biggest garbage I've ever seen, you know a framework's a big red flag when there are developers solely for the framework.
There is a new security release coming out that apparently removes some of these nuances (understatement) so there might be some light at the end of the tunnel.4
Joined a new project. The codebase is… Jesus Christ Vampire Hunter, is there ANY decent project in vue which has an hint of readibility in this damn world?
Every single time anyone talks about vue I roll my eyes “no I swear we managed it well!” 600 lines of code components. Is there even a good way to structure it for big apps?9
i had an epiphany today, in a discussion with the software architect of our new project.
i'm having the epic job to design & implement a prototype for a C++ library in a new software project and collected some inspiration in our "old" software, where i'm maintaining the module that fulfills the same functionality (i thought). i've been maintaining this module for around a year now. i analyzed the different features and stuff to consider and created a partial model of the new library.
when i showed it to the architect today, he was like "oh my god, no no no, you don't need all this functionality, this shall not be part of the new library!"
this was the moment when i realized how deeply fucked up the code base of the old module is.
imagine it like this:
you want to automate the process of making yourself a good ol' cup of coffee.
the reasonable thing would be to have
- a smart water boiler where you set parameters water temperature and amount of water to be fetched from the water supply
- a smart coffee bean grinder where you can set type of beans, amount of beans and grinding fineness
- a component where water and ground coffee are joined to brew the coffee, where parameters like duration, pressure etc. are set
- a milk tank where amount of milk, desired temperature and duration / speed of foaming can be set
- a sugar dispenser where amount of applied sugar can be set
- optionally, additional modules with spices, syrup, ice cubes, whatever for your very personal coffee experience
on requesting a coffee, you would then configure and orchestrate all components to your wishes to make you a fine cup of coffee. you can also add routines like "makeCappucchino()", "makeEspresso()", or whatever.
our software is not like this.
it is like this:
- a smart water boiler consisting of submodules that know how to cook water for e.g. "cappucchino with sugar" or for "espresso without sugar, but with milk and ice cubes"
- 5 smart bean grinders that know how to grind beans for e.g. cappucchino, espresso, latte macchiato and for 73ml of water preheated to 82°C
- a very smart sugar dispenser that knows how to add sugar to 95, 98 and 100°C coffee and to coffee made of BOTH coffee arabica AND coffee robusta beans.
etc. etc., i think you're getting the gist.
when i realized this, it was like, right in front of my eyes, this terrible pattern emerged like a foul, corrupted caleidoscope of chaos, through the whole code base of this module.
i've already known how rotten from the core this code base is, but today i've actually identified a really bad pattern that i hadn't realized before. the whole architecture is so bloated that it is hard to have an overview of the whole thing. and it would require a LOT of refactoring to repair this pattern.
but i guess it would also be infinitely satisfying because i could probably reduce the code base for 30% or something...
but unfortunately, this is never going to happen, because screw refactoring.
it's a great feeling to start this new library from scratch, tho...6
The day I realised There is an AngularJS before Angular 2
In our t ch stack, we have multiple components, most of them are backend, but 2 of them are fronnt end.
The first one is a straight Angular 4 application, and it has the normal angular structure, a ts file, a css file, a js file.
The other component, has a very weird structure I don't understand to this day.
It has a mix of js and html files, sometimes one inside another.
The js file has some "angular.core.shit" and I thought it should be Angular, but nothing in it resembles any angular project.
After much confusion, I finally came across an AngularJS website which is supposed to be deprecated last year.
Then I came to know of the story of Google taking ove rAngular and releasing Angular 2.1
AI is this huge scam to me. People keep saying it will take over everything and replace everything: jobs, people, etc. It is so over hyped by people who don't understand how it actually works.
I will wonder if AI can take over everything when they can build an AI that can weed a garden.
- no chemicals, too much is used and poisons everything.
- the garden cannot be specifically designed to be weed by machine.
- the AI must differentiate between weeds and non-weeds.
- the robotic system employed must not destroy everything else while weeding.
- the AI should know when it finds random objects like gloves, or shorts, cigarettes, or electrical components that they need attention or actually pick them up. Yes, I have found these.
- it should be quick and energy efficient and not require an entire nuclear plant to run the AI. What is the point of AI powered by a server somewhere if it pollutes from afar rather than local.
I just don't see this happening in my lifetime.21
I’m so sorry if this is the place for questions. I’m terrified of stack overflow and have been searching for a week for a solution and can’t find one. This is for React.js people.
I was tasked to create a webpage with react. The limitation is, they did not wanna adopt the node.js dependency. I said ok, I’ll figure it out. You can inject react, material UI, and babel with script tags in HTML, then put ur lil components in it. I did that and it works beautifully.
However, now I have to write tests for this. I think it’s actually impossible without a way to render React, so I have to use the browser, or node, right? I convinced my boss to allow me to use a node.js container just for testing, which I thought would make my life easier.
I don’t know how to render this thing with node. It’s just an HTML file that pulls react via script tags, and idk how to serve html with node. Additionally, none of the React testing libraries seem to support testing a system that wasn’t designed to be served with node, at least not easily. My gut tells me that the complication with how things are imported contributes at least a little to this (dependencies pulled via script tags in the HTML file and made available to react through global const variables).
I could be wrong about any of this — im fairly new. But how tf do I go about testing these react components? For reference, if you go to Reacts docs, there’s a section called “add react to a page in one minute” that’s pretty much what I did.20
So Im planning to build a pc, which i will mainly use it for dev and gaming in free time, my main components will be:
CPU: INTEL 8700K
GPU: GTX 1080 msi or gigabyte?
SSD: 860 EVO
RAM: 16GB 3200MHZ
MOTHERBOARD: should i go with msi or gigabyte whixh one is better?
PSU: 650W or 700W deepcooler?
Also for the cpu cooler do i get water colling or a standard cpu fan?
P.S: i plan to overclock the cpu and gpu at some point.
Also whats your opinion on the rgb lightning gpu and motherboard, and is there point in getting a mobo with sli support (is it work buying second gpu at some point or better upgrade the existing)4
In most businesses, self-proclaimed full-stack teams are usually more back-end leaning as historically the need to use JS more extensively has imposed itself on back-end-only teams (that used to handle some basic HTML/CSS/JS/bootstrap on the side). This is something I witnessed over the years in 4 projects.
Back-end developers looking for a good JS framework will inevitably land on the triad of Vue, React and Angular, elegant solutions for SPA's. These frameworks are way more permissive than traditional back-end MVC frameworks (Dotnet core, Symfony, Spring boot), meaning it is easy to get something that looks like it's working even when it is not "right" (=idiomatic, unit-testable, maintainable).
They then use components as if they were simple HTML elements injecting the initial state via attributes (props), skip event handling and immediately add state store libraries (Vuex, Redux). They aren't aware that updating a single prop in an object with 1000 keys passed as prop will be nefarious for rendering performance. They also read something about SSR and immediately add Next.js or Nuxt.js, a custom Node express.js proxy and npm install a ton of "ecosystem" modules like webpack loaders that will become abandonware in a year.
After 6 months you get: 3 basic forms with a few fields, regressions, 2MB of JS, missing basic a11y, unmaintainable translation files & business logic scattered across components, an "outdated" stack that logs 20 deprecation notices on npm install, a component library that is hard to unit-test, validate and update, completely vendor-& version locked in and hundreds of thousands of wasted dollars.
I empathize with the back-end devs: JS frameworks should not brand themselves as "simple" or "one-size-fits-all" solutions. They should not treat their audience as if it were fully aware and able to use concepts of composition, immutability, and custom "hooks" paired with the quirks of JS, and especially WHEN they are a good fit.
Why the fuck do consultants / noob types LOVE using fucking props in react components. This app is complex, just make a fucking redux slice and use that. I'm not passing 23904 props to a component to get it to render. God13
Design team loves to use any in their components. I just love having to dig through multiple nested components to find out what i should put as input or console loging to found out the outputs. Whats the point of using typescript at that point. It costs nothing to write a single interface..1
The Node and its magic tricks never cease to surprise me.
I created several new components and tried to compile them for verification. Then this big fat error popped up.
I commented out all the newly created code (didn't remove any files, just did ^A^/). Recompiled. This big fat error again.
Undid modifications I made to the files that existed there before. Recompiled. This big fat error again.
Moved the newly created files outside of the project scope (mv app/<...>/featureX/ ../bkup/). Recompiled. SUCCESS.
Moved all of those files back (mv ../bkup/featureX app/<...>/). Recompiled. SUCCESS.
That feeling when you get the job because of the JS but most of the work is fixing server side xml to play nicely with several vuejs components on the client side.
Or vice versa. Probably the vice versa.2
I implore ANYONE... please...
Have you EVER written a SINGLE Jest test that didn't have some sort of bullshit spewing stuff like this:
"ReferenceError: You are trying to `import` a file after the Jest environment has been torn down."
"Warning: React.createElement: type is invalid -- expected a string (for built-in components) or a class/function (for composite components) but got: object. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports."
and yet running on a device, features work flawlessly and quite well, no errors or even warnings in sight logged
This is the most fragile pile of garbage I have ever seen.
I hate this.
inb4 your stupid ass todo boilerplate garbage you wrote tests for in freshman year. i'm talking about a REAL app with HUNDREDS of components.
where the grownup testing tools at? it's a question I've still not answered after a year of fucking around with this framework2
It’s a huge nightmare to develop a React front-end when:
- you have to adapt Bootstrap 3/jQuery based components to React
- the “back-end” is a sparse collection of micro services with cryptic URLs and finding the correct name means searching on a laggy WSO2 API manager
- the documentation of said micro services can be outdated and that means wasting a lot of time trying requests on cURL rather than in doing actual development and continuously breaking your concentration
- sometimes the micro services just become unavailable altogether
- the back-end shuts down at
6PM everyday, usually when after I finally achieved a flow and I’m doing meaningful progress2
What's the worst part about testing React components? Using the equivalent of fucking stone tools to do your component integration tests! We got errors with no context and errors with no stack trace, just spewing out bullshit! A sample:
The classic "Can't access .root on unmounted test renderer"
The unforgettable and ALWAYS visible "Warning: An update to YourShittyComponent inside a test was not wrapped in act(...)."
We do love it!