Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "too-many-libs"
-
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.17 -
So I made an android app for a client. It's a newspaper type of app for the clients webpage, as he has a lot of traffic on it and about 50-51% is from mobile. Which is all good an everything.
And so I've been working on it for a while now as it wasn't a primary focus, more of a like side project.
I was able to make full working build (publish ready) and sent it to the client for a review.
After about an hour I received an email saying that the app is requesting too many permissions from the user. So I started looking trough my manifest file and all of the 3rd party libs to see what were those permissions.
Well, when I finally installed the app on a physical device and looked trough the permissions in the settings all I found were permissions for the internet and prevent the phone from sleeping.
After asking the client to tell me in detail which permissions raised concerns he told me it were those 2 and if they could be removed.
So I just wasted an hour of my life trying to explain why the app that is losing content from the internet needs internet permissions.
Fml and ignorant people who think they know everything and won't accept anything else.
And all of this because he read on some click bait website how a "real" app doesn't need any permissions and every other is just trying to steal all of your data and money.
2 -
Saucenao back then was in our scope, we wanted to use it for something cool, sadly, the Node.js library for it was really really fucking shit. Being the honorary idiot not realizing there's too many JS libs, I started a initiative to create a new saucenao library which is more modern, and more cleaner to work on.
My friend apprently jumped the train and started to implement more stuff until we reached the point where it's state became desirable. The library itself wasn't a seperate library and was a part of a larger project. But then, I realized a lot of people would find use for it so I released it seperate of that project. I ran out or proper nouns to give the library so I went with the meme character of 2017, which is Sagiri of Eromanga-sensei. Unfortunately, the name was taken and had to publish under my username scope. Then my friend contacted NPM so we can steal it (because apparently it wasn't even used). And fast forward to today, Sagiri became the most downloaded saucenao library that is published on NPM, with over 197 downloads per month.
I can't say I'm either proud or disappointed, but I think I fullfilled a need.2 -
What a vast and great eco-system we have (refering to js and npm) almost every time I am trying to use two libs and combine them to work together some shit happens.
So I wanted to have lean and good written code without introducing unnecessary renders and logic.
Ended up doing just that because 'we know about issue with our library, many users told us that, too bad we wont fix that shit', so I feel like a 'workaround' developer at some hackathon right now! -
Sydochen has posted a rant where he is nt really sure why people hate Java, and I decided to publicly post my explanation of this phenomenon, please, from my point of view.
So there is this quite large domain, on which one or two academical studies are built, such as business informatics and applied system engineering which I find extremely interesting and fun, that is called, ironically, SAD. And then there are videos on youtube, by programmers who just can't settle the fuck down. Those videos I am talking about are rants about OOP in general, which, as we all know, is a huge part of studies in the aforementioned domain. What these people are even talking about?
Absolutely obvious, there is no sense in making a software in a linear pattern. Since Bikelsoft has conveniently patched consumers up with GUI based software, the core concept of which is EDP (event driven programming or alternatively, at least OS events queue-ing), the completely functional, linear approach in such environment does not make much sense in terms of the maintainability of the software. Uhm, raise your hand if you ever tried to linearly build a complex GUI system in a single function call on GTK, which does allow you to disregard any responsibility separation pattern of SAD, such as long loved MVC...
Additionally, OOP is mandatory in business because it does allow us to mount abstraction levels and encapsulate actual dataflow behind them, which, of course, lowers the costs of the development.
What happy programmers are talking about usually is the complexity of the task of doing the OOP right in the sense of an overflow of straight composition classes (that do nothing but forward data from lower to upper abstraction levels and vice versa) and the situation of responsibility chain break (this is when a class from lower level directly!! notifies a class of a higher level about something ignoring the fact that there is a chain of other classes between them). And that's it. These guys also do vouch for functional programming, and it's a completely different argument, and there is no reason not to do it in algorithmical, implementational part of the project, of course, but yeah...
So where does Java kick in you think?
Well, guess what language popularized programming in general and OOP in particular. Java is doing a lot of things in a modern way. Of course, if it's 1995 outside *lenny face*. Yeah, fuck AOT, fuck memory management responsibility, all to the maximum towards solving the real applicative tasks.
Have you ever tried to learn to apply Text Watchers in Android with Java? Then you know about inline overloading and inline abstract class implementation. This is not right. This reduces readability and reusability.
Have you ever used Volley on Android? Newbies to Android programming surely should have. Quite verbose boilerplate in google docs, huh?
Have you seen intents? The Android API is, little said, messy with all the support libs and Context class ancestors. Remember how many times the language has helped you to properly orient in all of this hierarchy, when overloading method declaration requires you to use 2 lines instead of 1. Too verbose, too hesitant, distracting - that's what the lang and the api is. Fucking toString() is hilarious. Reference comparison is unintuitive. Obviously poor practices are not banned. Ancient tools. Import hell. Slow evolution.
C# has ripped Java off like an utter cunt, yet it's a piece of cake to maintain a solid patternization and structure, and keep your code clean and readable. Yet, Cs6 already was okay featuring optionally nullable fields and safe optional dereferencing, while we get finally get lambda expressions in J8, in 20-fucking-14.
Java did good back then, but when we joke about dumb indian developers, they are coding it in Java. So yeah.
To sum up, it's easy to make code unreadable with Java, and Java is a tool with which developers usually disregard the patterns of SAD.

