Hi, I am a Javascript apprentice. Can you help me with my project?

- Sure! What do you need?

Oh, it’s very simple, I just want to make a static webpage that shows a clock with the real time.

- Wait, why static? Why not dynamic?

I don’t know, I guess it’ll be easier.

- Well, maybe, but that’s boring, and if that’s boring you are not going to put in time, and if you’re not going to put in time, it’s going to be harder; so it’s better to start with something harder in order to make it easier.

You know that doesn’t make sense right?

- When you learn Javascript you’ll get it.

Okay, so I want to parse this date first to make the clock be universal for all the regions.

- You’re not going to do that by yourself right? You know what they say, don’t repeat yourself!

But it’s just two lines.

- Don’t reinvent the wheel!

Literally, Javascript has a built in library for t...

- One component per file!

I’m lost.

- It happens, and you’ll get lost managing your files as well. You should use Webpack or Browserify for managing your modules.

Doesn’t Javascript include that already?

- Yes, but some people still have previous versions of ECMAScript, so it wouldn’t be compatible.

What’s ECMAScript?

- Javascript

Why is it called ECMAScript then?

- It’s called both ways. Anyways, after you install Webpack to manage your modules, you still need a module and dependency manager, such as bower, or node package manager or yarn.

What does that have to do with my page?

- So you can install AngularJS.

What’s AngularJS?

- A Javascript framework that allows you to do complex stuff easily, such as two way data binding!

Oh, that’s great, so if I modify one sentence on a part of the page, it will automatically refresh the other part of the page which is related to the first one and viceversa?

- Exactly! Except two way data binding is not recommended, since you don’t want child components to edit the parent components of your app.

Then why make two way data binding in the first place?

- It’s backed up by Google. You just don’t get it do you?

I have installed AngularJS now, but it seems I have to redefine something called a... directive?

- AngularJS is old now, you should start using Angular, aka Angular 2.

But it’s the same name... wtf! Only 3 minutes have passed since we started talking, how are they in Angular 2 already?

- You mean 3.

2.

- 3.

4?

- 5.

6?

- Exactly.

Okay, I now know Angular 6.0, and use a component based architecture using only a one way data binding, I have read and started using the Design Patterns already described to solve my problem without reinventing the wheel using libraries such as lodash and D3 for a world map visualization of my clock as well as moment to parse the dates correctly. I also used ECMAScript 6 with Babel to secure backwards compatibility.

- That’s good.

Really?

- Yes, except you didn’t concatenate your html into templates that can be under a super Javascript file which can, then, be concatenated along all your Javascript files and finally be minimized in order to reduce latency. And automate all that process using Gulp while testing every single unit of your code using Jasmine or protractor or just the Angular built in unit tester.

I did.

- But did you use TypeScript?

You know who sucks at developing APIs?

Facebook.

I mean, how are so high paid guys with so great ideas manage to come up with apis THAT shitty?

Let's have a look. They took MVC and invented flux. It was so complicated that there were so many overhyped articles that stated "Flux is just X", "Flux is just Y", and exactly when Redux comes to the stage, flux is forgotten. Nobody uses it anymore.

They took declarative cursors and created Relay, but again, Apollo GraphQL comes and relay just goes away. When i tried just to get started with relay, it seemed so complicated that i just closed the tab. I mean, i get the idea, it's simple yet brilliant, but the api...

Immutable.js. Shitload of fuck. Explain WHY should i mess with shit like getIn(path: Iterable<string | number>): any and class List<T> { push(value: T): this }? Clojurescript offers Om, the React wrapper that works about three times faster! How is it even possible? Clojure's immutable data structures! They're even opensourced as standalone library, Mori js, and api is great! Just use it! Why reinvent the wheel?

It seems like when i just need to develop a simple react app, i should configure webpack (huge fuckload of work by itself) to get hot reload, modern es and jsx to work, then add redux, redux-saga, redux-thunk, react-redux and immutable.js, and if i just want my simple component to communicate with state, i need to define a component, a container, fucking mapStateToProps and mapDispatchToProps, and that's all just for "hello world" to pop out. And make sure you didn't forget to type that this.handler = this.handler.bind(this) for every handler function. Or use ev closure fucked up hack that requires just a bit more webpack tweaks. We haven't even started to communicate to the server! Fuck!

I bet there is savage ass overengineer sitting there at facebook, and he of course knows everything about how good api should look, and he also has huge ass ego and he just allowed to ban everything that he doesn't like. And he just bans everything with good simple api because it "isn't flexible enough".

"React is heavier than preact because we offer isomorphic multiple rendering targets", oh, how hard want i to slap your face, you fuckface. You know what i offered your mom and she agreed?

They even created create-react-app, but state management is still up to you. And react-boierplate is just too complicated.

When i need web app, i type "lein new re-frame", then "lein dev", and boom, live reload server started. No config. Every action is just (dispatch) away, works from any component. State subscription? (subscribe). Isolated side-effects? (reg-fx). Organize files as you want. File size? Around 30k, maybe 60 if you use some clojure libs.

If you don't care about massive market support, just use hyperapp. It's way simpler.

Dear developers, PLEASE, don't forget about api. Take it serious, it's very important. You may even design api first, and only then implement the actual logic. That's even better.

And facebook, sincerelly,

Fuck you.

Boss: I saw that you are using {some JavaScript library}, why?

Me: you asked for this functionality and the library is very good for that

Boss: here at our company we do not use code from other people, we write everything ourselves

Me: but this library is very well built, actively developed and supported

Boss: I don't care, please rewrite this component

Suffice to say, I quit that job asap. Whoever thinks it's a good idea write so much code for a small purpose in an application when there is something available open source to use, is stupid. In most cases it's better to use something which is out there than to waste time writing a hardly stable version of it.

Worst code review experience?

Hard to pick just one, but most were in a big meeting room with 4+ other developers not related to the project and with some playing Monday-Morning-Quarterback instead of offering productive feedback.

In one code review, the department mgr reviewed the code from a third party component library.

<brings up the code on the big screen>
Mgr: "I can't read any of this, its a mix of English and something else."
Me: "Its German."
Mgr: "Then why is 'Button' in English? This code is a mess."
Me: "I'm not exactly sure how I should respond, I mean, I didn't write any of this code."
Mgr: "Yes, but you are using it, so it's fair game for a code review."
Me: "Its not really open source, but we can make requests if you found something that needs to be addressed."
Mgr: "Oh yes, all this...whatever this is..<pointing again to the German>"
Me: "I don't think they will change their code to English just so you can read it."
Mgr: "We paid good money, you bet your ass they'll change it!"
Me: "I think the components were like $30 for the unlimited license. They'll tell us to go to hell first. Is there something about my code you want to talk about?"
Mgr: "<Ugggh>...I guess not, I couldn't get past all that German. Why didn't we go with an American company? Hell, why didn't we just write these components ourselves!?"
Me: "Because you gave a directive that if we found components that saved us time, to put in a request, and you approved the request. The company is American, they probably outsourced or hired German developers. I don't know and not sure why we care."
Mgr: "Security! What if they are sending keystrokes back to their servers!"
Me: "Did you see any http or any network access?"
Mgr: "How could I? The code is in German!"
Monday-Morning-Quarterback1: "If it were me, I would have written the components myself and moved on"
Me: "No, I don't think you could for less than $30"
Monday-Morning-Quarterback2: "Meh...we get paid anyway. Just add the time to the estimate."
Mgr: "Exactly! Why do we even have developers who can't read this mess."
Me: "Oh good Lord! Did anyone review or even look at my code for this review!?"
<silence>
Mgr: "Oh...ok...I guess we're done here. Thanks everyone."
<everyone starts to leave>
Me: "Whoa!...wait a sec..am I supposed to do something?"
Mgr: "Get that company to write their code in English so we can read it. You have their number, call em'...no...wait...give me their number. You keep working, I'll take care of this personally"

In they nicest way possible, the company did tell him to go to hell.

For a project day we had to write a game of our choice in Java.

"You should make this game using the JSwing library and make each component a JComponent"

Later I learned you can simply use a Bitmap as a canvas.

NEVER. EVER. BASE. YOUR. GAME. ON. SWING.
It inefficient to the top of my taskmanager. I had to wrap everything with something like a virtual playground where I had to manage everything myself to not roast my cpu.

I had alot more fun debugging hundred lines of C code with print statements than writing that shit

you fucking idiots

why do you always base your library components on some dumbass clown fixed width / height system?

everything should be flex by default, anything else is absolute amateur clown town pile of dumbass horseshit...

...i'll brawl and take down anyone who says otherwise

you waste my time, you waste other's time, when everyone has to go hunting around for your stupid library's unorthodox way of styling

thanks again for wasting and making my evening a living hell

So a Developer not using a React-native component library because it is backed by Microsoft
This is next level shit

PS:- the library is actually pretty decent

TL;DR: Stop using React for EVERYTHING. It's not the end-all solution to every application need.

My team is staffed about 50/50 with tenured devs, and junior devs who have never written a full application and don't understand the specific benefits of different libraries/framworks. As a result, most of these junior devs have jumped on the React train, and they're under the impression that React is the end-all answer to any possible application need. Doesn't matter what type of app is, what kind of data is going to be flowing through the app, data scale, etc. In their eyes, React is always the answer. Now, while I'm not a big fan of React myself, I will say that it does its job when its tasked with a data-heavy application that needs to be refreshed/re-rendered dynamically and frequently (like Facebook.) However, my main gripe is that some people insist on using it for EVERYTHING. They refuse to acknowledge that there can be better library/framework choices (Angular, Vue, or even straight jQuery,) and they refuse to learn any other frameworks. You can hit them with countless technical reasons as to why React isn't a good choice for a particular application, and they'll just spout off the same tidbits from the "ReactJS Makes My Nips Hard 101" handbook: "React is the future," "Component-based web architecture is the future," (I'm not arguing with that last one) "But...JSX bro.," "Facebook and Netflix use it, so that's how you know it's amazing." They'll use React for a simple app, and make it overly-complex, and take months to write something that should have taken them a week. For example, we have one dev who has never used any other frameworks/libraries apart from React, and he used React (via create-react-app) to write what is effectively a single form and a content widget inside of a bootstrap template. It took him 4 MONTHS to write this, and it still isn't fully functioning. The search functionality doesn't really work (in fact, it's just array filtering,) and wont return any results if you search for the first word in an entry. His repo is a mess, filled with a bunch of useless files that were bootstrap'd in via create-react-app. We've built apps like this in a week in the past using different libraries/frameworks, and he could have done the same if he didn't overly-complicate the project by insisting on using React. If your app is essentially a dynamic form, you don’t need a freaking virtual DOM.

This happens every time a big new framework hits the scene. New young developers get sucked into it, because it's the cool hip new framework (or in React's case, library.) and they use it for everything, even when it's not the best choice. It happened with Angular, Rails, and now it's happening with React.

React has its benefits, but please please please consider which library/framework is the best choice from a technical standpoint before immediately jumping on the React train because "Facebook uses it bro."

Why do people feel so compelled to create their own custom components when the component library you're already using HAS ONE ALREADY?!

You can change the styling and animations using CSS and props. Stop building buggy shit from scratch.

A (work-)project i spent a year on will finally be released soon. That's the perfect opportunity to vent out all the rage i built up during dealing with what is the javascript version of a zodiac letter.

Everything went wrong with the beginning. 3 people were assigned to rewrite an old flash-application. Me, A and B. B suggested a javascript framework, even though me and A never worked with more than jquery. In the end we chose react/redux with rest on the server, a classic.

After some time i got the hang of time, around that time B left and a new guy, C, was hired soon after that. He didn't know about react/redux either. The perfect start off to a burning pile of smelly code.

Today this burning pile turned into a wasteland of code quality, a house of cards with a storm approaching, a rocket with leaks ready to launch, you get the idea.

We got 2 dozen files with 200-500 loc, each in the same directory and each with the same 2 word prefix which makes finding the right one a nightmare on its on. We have an i18n-library used only for ~10 textfields, copy-pasted code you never know if it's used or not, fetch-calls with no error-handling, and many other code smells that turn this fire into a garbage fire. An eternal fire. 3 months ago i reduced the linter-warnings on this project to 1, now i can't keep count anymore.

We use the reactabular-module which gives us headaches because IT DOESN'T DO WHAT IT'S SUPPOSED TO DO AND WE CANT USE IT WELL EITHER. All because the client cant be bothered to have the table header scroll along with the body. We have methods which do two things because passing another callback somehow crashed in the browser. And the only thing about indentation is that it exists. Copy pasting from websites, other files and indentation wars give the files the unique look that make you wonder if some of the devs hides his whitespace code in the files.

All of this is the result of missing time, results over quality and the worst approach of all, used by A: if A wants an ui-component similar to an existing one, he copies the original and edits he copy until it does what he wants. A knows about classes, modules, components, etc. Still, he can't bring himself to spend his time on creating superclasses... his approach gives results much faster

Things got worse when A tried redux, luckily A prefers the components local state. WHICH IS ANOTHER PROBLEM. He doesn't understand redux and loads all of the data directly from the server and puts it into the local state. The point of redux is that you don't have to do this. But there are only 1 or 2 examples of how this practice hurt us yet, so i'm gonna have to let this slide. IF HE AT LEAST WOULD UPDATE THE DATA PROPERLY. Changes are just sent to the server and then all of the data is re-fetched. I programmed the rest-endpoints to return the updated objects for a very reason. But no, fuck me.

I've heard A decided (A is the teamleader) to use less redux on the next project and use a dedicated rest-endpoints for every little comoutation you COULD DO WITH REDUX INSTEAD. My will is broken and just don't want to work with this anymore.

There are still various subpages that cant f5 because the components cant handle an empty redux state in the beginning, but to be honest i don't care anymore. Lets hope the client will never find out, along with the "on error nothing happens"-bugs. The product should've been shipped last week, but thanks to mandatory bugfixes the release was postponed to next week. Then the next project starts...

Please give me some tips to keep up code quality over time, i cant take this once more.
I'm also aware that i could've done more, talking A and C about code style, prettifying the code, etc. Etc. But i was busy putting out my out fires, i couldn't kill much of the other fires which in the end became a burning building (a perfect metaphor for this software)

ECS-Concept - a Entity Component System library in C++17/C++20, for learning purposes.

Oh, as a noob dev my team was using a dropdown library for our filters in the website. The code was messed up cause they kept changing the design halfway through dev and after releases and then finally after some releases, the client wanted multilevel options as a new requirement.
So I scrapped the whole thing and made my own multilevel dropdown component (there were no decent libraries then) and we used that from then on. It has many issues now that I look back (who cares about keyboard interaction right?). But that is a refactor for another day.

Hitting a really deep, deep low in the manic-depressive roller-coaster of the development cycle:

There comes the crunch time. No meeting goes by hearing the odious: "We don't have time for that." - One critical component needs to be finished for Big Sur and instead of addressing the real issues we keep changing design and goal. One main dev already gave up fighting the PO and team lead(!) - and now I'm next. So that dev build this really clean and minimal library as the core part. But now it's just like, yeah, take that nice Porsche engine put it on the old rusty bicycle from the shed,.. but maybe because that's so shitty we need that specially formed exhaust pipe to tune it. Yeah, very 'agile' - Only thinking about it makes me shudder in disbelief and anger. I shouldn't take that shit so serious, be emotional about shit code, I know, but I can't. Let them drive some rounds around the block, if it runs at all,.. because until now we still didn't make it run on the fuckin' street. It's all so insane. Will make some nice fireball, when it goes up in flames.

Well, I have been part of quite some shitty projects. Real suicide commandos set out to fail, and somehow stood them through or made it even "work" though it should never have. But what enrages me here is, that it needn't to be that way. We had plenty of time. Our team was often rowing along in good rhythm. And now I just feel drowned in resignation and sarcasm.

Here is a little story about why I do not like to have to purchase developer tools and libraries..

Long story short it has taken at least 10 people more than 3 months to purchase two licenses of this component library which we still do not yet have licenses for.

It all starts with this guy who works here and has the job title 'solution architect'. He saw an ad on a website about some html component library. Then he asks me and the other developer here to look at it. He is super excited saying things like if we save only x days of time the cost is nothing in comparison to developer time..

The other developer and I both spend a few days reading the docs and trying some sample code. It offers some things we can use but I suggest not bothering with it.

Despite my suggestion he goes to the technical manager and they write up a business case. After about a month our receptionist cc me on an email chain from the it commercial manager who is asking for the licensing information so they can add the component creator as a vendor in the purchasing system. I send them a link to the component website which lists all that.

Jump forward two more months to last week and I got a spam email from the component company saying they have some new version out. I am wondering what has happened so I ask our receptionist she says it is with accounts payable and waiting payment - but it is marked urgent and she will find out.

Today I am cc in an email saying they have paid for it two weeks ago. So where is the license info? Nobody knows.

Context: New to typescript. Writing a thing, doing it for work, good opportunity to stretch my dev legs. Using a propriety lib, alternatives not an option.

Rant begin:
SOOOO, who the fuck thought THIS was a good idea:
1. Lib has minified react in dev (because closed source) meaning no downstream errors AND the entire premise of the lib is that a widget is a react component, so I'm writing typescript react the entire time without downstream errors
2. SHIT docs. By that, I mean there's an API reference page that's so sparse there's literally a set of CRUCIAL interfaces that only say the word 'Interface' on them. That's it. that's what i get. It's an interface. NO FUCKING SHIT SHERLOCK, what the fuck is it though? What's its purpose? Is it an interface for a dog? A dog that has a 'shit' property? or a cat? or a cat eating dog shit? Nobody fucking knows - the docs sure as fuck don't care.
3. No syntax highlighting - editors, IDEs (i've tried a few) can't even find the lib inside this environment, so Code and everything else thinks I'm importing shit that doesn't even exist - so no error prediction, code completion based on syntax of the library, none of that.
4. There are some EXTREMELY basic samples - these samples exclusively use React classes - no function components, no hooks, nada - just classes and even perfect replicas of the sample code display erratic behavior like errors about missing props, so that's mostly FUCKING USELESS
5. And this... this is where the straw breaks the fucking camel's back... there's no... there's no hot reloading... Do you know what that (in conjunction with the previous 4 fuckups) means?

When I write anything or I fuck up (which of course I'm doing every time I write half a line because how the fuck?) I have to restart the client and server EVERY FUCKING TIME and manually test to see if the error (THAT ONLY GETS REPORTED IN THE LOCAL UI) is gone or different.
Then, once I see the error, it isn't an error: it's the minified React error-decoder link and guess what? It isn't really clickable a link OR copyable, meaning that every FUCKING time I get a new error, I have to MANUALLY TYPE A FUCKING 50 CHAR URL TO FIND OUT A GENERIC REACT ERROR MESSAGE WITHOUT A LINE NUMBER OR ANY FUCKING CONTEXT. I HAVE TO DO THIS CONSTANTLY TO SEE IF ANYTHING I'M DOING EVEN WORKS.

6. There's no github to complain to the maintainers or search for issues because it's NOT FUCKING OPEN SOURCE so there is literally nothing to be fucking done about it.

This is due in a week and a half, found out about it last Friday. How's your day going?

PS: good to be back after a long respite from dev ranting.

Today I spent hours trying to figure out how the hell to add a Material-UI tooltip onto the ClearIndicator for a react-select multi-select component to warn the user that it would clear _all_ of their selections. Followed the examples in the react-select docs on how to make use of replaceable components, but all of their examples used a different library for the tooltip component, and there was no way I was going to bring in _another_ library that was going to add even more dependencies to the application.

In the end, my problem was that all of the examples were with components that could carry a ref and the component _I_ was targeting was a <path> element, which apparently can’t.

Solution? Add a div between the tooltip and the component I was replacing.

*facepalm*

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...

I had an interesting mystery the other day. I work in the UK, but I'm working remotely from the US for a while. First day, I made some changes, ran the tests and they failed. Weird part was the failing test was for a component I hadn't touched. I took a closer look, and realized it was a date off by several hours. The test was checking that a passed in date appears in the output. But it was creating the date by parsing a string. The library I was using defaults to local time, but the component uses UTC. So, I had inadvertently created a unit test that only passes when run from UTC. But I had never noticed before because my work is in that timezone. Yikes!

I’m working on a react codebase and company decided to add a new module.
Now im writing markup and css to ensure UX is smooth as designers thought of it.
Imagine my horror when I start to code and find out no matter what HTML tag i use, it’s been FUCKING OVERRIDDEN in the global stylesheet. AND STYLES HAVE BEEN OVERRIDDEN WITH !important

They’re also using Ant design as a component library. Guess what, default ant design classes have been overridden too. So i try to use ant design button or card, and bam, MAGICALLY SOME DESIGN FROM SOME SHITHOLE MODULE DECIDES TO FUCK WITH MY STYLES

On top of that, styles of parts of application has been written in SASS, some part of application uses bootstrap components some use third party components like tables and responsive grids to suit to their preferences. Some parts use handwritten css. Some parts use CSS IN JS and styled components. THE FUCK IS THIS GARBAGE!!!! THE FUCKING CODEBASE HAS A MIND OF ITS OWN!!!!!! YOU NAME A WAY TO ADD STYLES TO A COMPONENT, ITS THERE!!!
And the company’s management thought a “fractal” approach to maintain each individual view is “best” for SCALABILITY!!! HOW THE FUCK DID IT NOT CROSS YOUR DUMB MIND THAT FRACTAL APPROACH ALSO GUIDES TO HAVE ALL COMMON STUFF AT ONE PLACE!!!! THIS CODEBASE HAS DUPLICATE STYLES AND DUPLICATE CODE IN ALMOST EVERY MODULE!!!!

Not to mention every developer choosing to freely decide the way they should write their code without any guidelines.

HOW THE FUCK PEOPLE WRITE THEIR CODE WITHOUT THINKING ABOUT OTHER DEVS!!! SO BASICALLY I AM NOT ONLY CLEANING SOMEONE ELSE’S SHIT BUT ALSO TRY NOT TO SHIT IN THE PROCESS!! FML

!rant

I've tried Ionic in the past, and put off development with it because I couldn't get it to be performant without crosswalk.

In 2015, React Native put an end to the 'Are hybrid apps viable?' argument. It had a much smaller compile size, large component library, and is very reactive.

Ionic recently released news on scaling back their tools to focus on core offerings. I can't help but feel they're flogging a dead horse.

I'm sure the Ionic team has very smart people on board. Can't they see they're about to be 'Parse-ed'?

Can somebody explain to me why developers (especially web) have to micromanage every single thing into it's own f*ing component.

Story time: I have an input form with some tabs. I discovered that the UI Library (Devextreme) has a nice little component that handles forms, (including tabs, groups, etc.). So I make a page, configure tabs, inputs and whatnot.

Now, I already knew that my coworkers can't handle html that is bigger than a page. So instead of putting the configs in the frontend, I made nice files where I store those, to keep them nicely clean and seperated.

Me feeling very good, went off to have a nice lunch break.

I come back read the message from my coworker, asking me to make every tab it's own component and form and load them into a separate Tab-Component, instead of using the built in configuration

......

WHAT?

Like seriously. I have a f*ing library that handles that, why the f*ck do I need to reinvent the wheel here!?

Supposedly it's to make it more maintainable, easier to find bugs, flatten the hierarchy.

Here's a little wake up call you morons: Nesting hundreds of components into each other does *not* help you with that.
It just creates a rabbit-hole of confusing containers that you have to navigate and dissect every time you try to find something.

"Can I fix the bug in the detail Page? Sure I'll tell you tomorrow when I find out which fucking component the bug results from".

Components are there to be *reused*. It's using inheritance for reusing code all over again, but worse.

But maybe I'm just old fashioned, and conservative. Maybe I'm just a really bad software engineer, because nowadays everything seems to result in architectures spreading hundreds of folders, thousands of files with nothing but arbitrary cut-offs with no real benefit, that I don't see the value in.

Im making my first opensource project, it's a web component library, but I find the naming part so difficult..

How do you Guys find good project names? And anything i should consider regarding copyrights/e.t.c ?

Suggestions/you naming methods are welcome 🤌

Spent one hour looking for an error in my PCB only to find that the symbol and the actual component of a part in the parts library differ in terms of pin numbers. The colleague who created the part is already retired.

What do people think of Vue.js over something like Polymer for making Progressive Web Apps?

I've used Polymer a lot (Angular 1 before that) and I'm not a fan of it's data binding. It is using a web standard though, so should have more components available than any library that makes it's own component system (like Vue.js).

So they develop this app. That uses our front end component library. That queries a GraphQL layer developed as NPM package. That uses a data service abstraction NPM package. That uses another NPM package mapper library. That queries an old REST API returning XML.

It takes days to make a newly added XML node in the bottom-most layer available in the app, requiring changes to 4 repositories and 3 NPM releases.
Refactoring is dead, because 1 change will affect all layers. And the worst part is: theres only 1 app using these packages, so no case for re-use. Overzealous separation of concerns I guess?

A year ago I built my first todo, not from a tutorial, but using basic libraries and nw.js, and doing basic dom manipulations.

It had drag n drop, icons, and basic saving and loading. And I was satisfied.

Since then I've been working odd jobs.

And today I've decided to stretch out a bit, and build a basic airtable clone, because I think I can.
And also because I hate anything without an offline option.

First thing I realized was I wasn't about to duplicate all the features of a spreadsheet from scratch. I'd need a base to work from.

I spent about an hour looking.
Core features needed would be trivial serialization or saving/loading.

Proper event support for when a cell, row, or column changed, or was selected. Necessary for triggering validation and serialization/saving.

Custom column types.

Embedding html in cells.

Reorderable columns

Optional but nice to have:

Changeable column width and row height.

Drag and drop on rows and columns.

Right click menu support out of the box.

After that hour I had a few I wanted to test.

And started looking at frameworks to support the SPA aspects.

Both mithril and riot have minimal router support. But theres also a ton of other leightweight frameworks and libraries worthy of prototyping in, solid, marko, svelte, etc.
I didn't want to futz with lots of overhead, babeling/gulping/grunting/webpacking or any complex configuration-over-convention.

Didn't care for dom vs shadow dom. Its a prototype not a startup.

And I didn't care to do it the "right way". Learning curve here was antithesis to experimenting. I was trying to get away from plugin, configuration-over-convention, astronaut architecture, monolithic frameworks, the works.

Could I import the library without five dozen dependancies and learning four different tools before getting to hello world?
"But if you know IJK then its quick to get started!", except I don't, so it won't. I didn't want that.

Could I get cheap component-oriented designs?

Was I managing complex state embedded in a monolith that took over the entire layout and conventions of my code, like the world balanced on the back of a turtle?

Did it obscure the dom and state, and the standard way of doing things or *compliment* those?

As for validation, theres a number of vanilla libraries, one of which treats validation similar to unit testing, which seems kinda novel.

For presentation and backend I could do NW.JS, which would remove some of the complications, by putting everything in one script. Or if I wanted to make it a web backend, and avoid writing it in something that ran like a potato strapped to a nuclear rocket (visual studio), I could skip TS and go with python and quart, an async variation of flask.
This has the advantage that using something thats *not* JS, namely python, for interacting with a proper database, and would allow self-hosting or putting it online so people can share data and access in real time with others.

And because I'm horrible, and do things the wrong way for convenience, I could use tailwind.
Because it pisses people off.

How easy (or hard) would it be to recreate a basic functional clone of the core of airtable?

I don't know, but I have feeling I'm going to find out!

Fuck you android and fuck you material design components. How pale is their elevation shadow? Shadow is so fucking pale that I cannot notice if I don't look very very carefully.

How terribly they designed their app bar component? It is designed so fucking annoyingly that setting app:Elevation doesn't do anything even I have implemented every every solution.

Fuck you material design components that doesn't support material design even you are official library.

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.

So, do any of your poor fuckers have the opportunity - nay, PRIVILEGE of using the absolute clusterfuck piece of shit known as SQL Server Integration Services?

Why do I keep seeing articles about how "powerful" and "fast" it is? Why do people recommend it? Why do some think it's easy to use - or even useful?

It can't report an error to save its life. It's logging is fucked. It's not just that it swallows all exceptions and gives unhelpful error messages with no debugging information attached, its logging API is also fucked. For example, depending on where you want to log a message - it's a totally different API, with a billion parameters most of which you need to supply "-1" or "null" to just to get it do FUCKING DO SOMETHING. Also - you'll only see those messages if you run the job within the context of SQL FUCKING SERVER - good luck developing on your ACTUAL FUCKING MACHINE.

So apart from shitty logging, it has inherited Microsoft's insane need to make everything STATICALLY GODDAMN TYPED. For EVERY FUCKING COMPONENT you need to define the output fields, types and lengths - like this is 1994. Are you consuming a dynamic data structure, perhaps some EAV thing from a sales system? FUCK YOU. Oh - and you can't use any of the advances in .NET in the last 10 years - mainly, NuGet and modern C# language features.

Using a modern C# language feature REMOVES THE ABILITY TO FUCKING DEBUG ANYTHING. THE FUCKER WILL NOT STOP ON YOUR BREAKPOINTS. In addition - need a JSON parsing library? Want to import a SDK specific to what you're doing? Want to use a 3rd party date library? WELL FUCK YOU. YOU HAVE TO INDEPENDENTLY INSTALL THE ASSEMBLIES INTO THE GAC AND MAKE IT CONSISTENT ACROSS ALL YOUR ENVIRONMENTS.

While i'm at it - need to connect to anything? FUCK YOU, WE ONLY INCLUDE THE MOST BASIC DATABASE CONNECTORS. Need to transform anything? FUCK YOU, WRITE A SCRIPT TASK. Ok, i'd like to write a script task please. FUCK YOU IM GOING TO PAUSE FOR THE NEXT 10 MINUTES WHILE I FIRE UP A WHOLE FUCKING NEW INSTANCE OF VISUAL STUDIO JUST TO EDIT THE FUCKING SCRIPT. Heaven forbid you forget to click the "stop" button after running the package and open the script. Those changes you just made? HAHA FUCK YOU I DISCARDED THEM.

I honestly cant understand why anyone uses this shit. I guess I shouldn't really expect anything less from Microsoft - all of their products are average as fuck.

Why do I use this shit? I work for a bunch of fucks that are so far entrenched in Microsoft technologies that they literally cannot see outside of them (and indeed don't want to - because even a cursory look would force them to conclude that they fucked up, and if you're a manager thats something you can never do).

Ok, rant over. Also fuck you SSIS

You work in a team, for a team to move forward successfully the team should work in sync. A team always has a goal and a plan to get to it. There are times when the team needs to take a different direction therefore the set path should always be available for change because our environments dictate it.

We all have different styles of working and different opinions on how things should work. Sometimes one is wrong and the other is right, and sometimes both are wrong, or actually sometimes both are right. However, at the end of it all, the next step is a decision for the team, not an individual, and moving forward means doing it together. #KickAssTeam

The end result can not come in at the beginning but only at the end of an implementation and sometimes if you’re lucky, during implementation you can smell the shit before it hits the fan. So as humans, we will make mistakes at times by using the wrong decisions and when this happens, a strong team will pull things in the right direction quickly and together. #KickAssTeam

Having a team of different opinions does not mean not being able to work together. It actually means a strong team! #kickAssTeam However the challenging part means it can be a challenge. This calls for having processes in place that will allow the team members to be heard and for new knowledge to take lead. This space requires discipline in listening and interrogating opinions without attachment to ideas and always knowing that YOUR opinion is a suggestion, not a solution. Until it is taken on by the team. #KickAssTeam We all love our own thinking. However, learning to re-learn or change opinions when faced with new information should become as easy to take in and use.

Now, I am no expert at this however through my years of development I find this strategy to work in a team of developers. It’s a few questions you ask yourself before every commit, When faced with working in a new team and possibly as a suggestion when trying to align other team members with the team.

The point of this article, the questions to self!

Am I following the formatting standard set?

Is what I have written in line with official documentation?

Is what I am committing a technical conversion of the business requirement?

Have I duplicated functionality the framework already offers?

I have introduced a methodology, library, heavily reusable component to the system, have you had a discussion with the team before implementing?

Are your methods and functions truly responsible for 1 thing?

Will someone you will never get to talk to or your future self have documentation of your work?
Either via point number 2, domain-specific, or business requirements documentation.

Are you future thinking too much in your solution?

Will future proof have a great chance of complicating the current use case?

Remember, you can never write perfect code that cures every future problem, but what you can do perfectly is serve the current business problem you are facing and after doing that for decades, you would have had a perfect line of development success.

So the question is:
is there any better alternative to material ui?

mui is powerful, but I see no good in it in the field of customization.
You can't do shit without searching smth like: "how to remove the ::before in that mui component"
and getting some answer like:
"oh you can't do that with css! you should use that prop and shit or you should config your library in a way which you can remove ::before"

FFS WHAT THE FUCK IS THIS
I JUST WANT TO WRITE MY BORING CSS AGAIN

Why building a library of React component should be this hard: I'm sick of Webpack, Babel, Typescript and all the shit which is duct taped together to build some damn widgets.

OMG! I just realised one new thing about how people implement Entity Component System library... I'm good to start all over again x) well I don't even remember how many time it happened now ^^"

I was looking for a RRule Generator Component in ReactJS because I (a back-end dev) am lazy af to build front-end component. It drains my energy and I stumbled upon "react-rrule-generator". And holy moly. It is no longer maintained, but it has a very beautiful code. Then I thought, I should search more open source projects where code is clean so I can learn more.

So, do any of you know any open source project, library code or whatever that you think has a very clean code?

[opinions welcome]
I'm just furious right now!!!

So I'm on this project where we have to make a whole *very old* website look like it's brand new.

Thing is, the whole point of the project is to make exactly the same pages as on the existing website smh. No UX or UI suggestions.
Just put the navbar in a component that looks like a tab bar, who cares anyway!?

Btw, I'm in charge of the UI.

My colleagues and I (mostly my colleagues) made a react components library and we use it for this project.
Fucking inputs get thrown into tables and all that, but hey, that's what the client asked for.

So here I am with my shiny new page, and I just hand it over to the front-end dev who just arrived.
She's supposed to feed in the data.
I don't give a fuck you use flow or redux or whatever fancy tooling.
Just call your back-end, get the data, format it and feed my damn table with it. That's it.

So today, after 5 weeks she's in, she calls a meeting where she's screening a presentation to the team complaining about how long it took her to understand what I did and change it completely.
Pieces of code on screen, saying it's crap and it shouldn't be like that.

I'm not responsible for inputs in fucking table, the client is!
Of course I have nested components with data passed through all the way: it's a series of fucking radio buttons within a table within a form!

During 5 weeks, yoy didn't even come to me once saying it's not what you expected or you're having trouble with my work!
And there we blaming my job like I'm the bad guy?!

Tonight, everyone's going home thinking I'm no good at what I do and completely lost, all because of her.

If you got this far, I'd like to hear from you on how I should act with her and how to tell her what she did is awfully wrong?