Coding controversy

This post is going to be a little different. I’m going to describe my positive and negative impressions about my own OSS library because it’s been a quite interesting psychological debate going on in my mind. So, remember - you’ve been warned. 😀

---

A little background

The story starts with me - self-taught developer - wanting to get a better grasp on regular expressions in JavaScript language. In the beginning, regexps felt a bit like some kind of black magic to me. How in the world am I meant to learn all these possible expressions and patterns? Before this story took place, I was barely creating my own very, very simple regexps in the clumsy way of taking a look at the reference guide again and again. This was nothing more than just painful. For scaffolding, I used the regexr and later regex101 - online editors for creating regexps in JS and multiple other flavors. Now, regex101 has support for a greater variety of flavors and newer JS syntaxes (e.g. ES2018 named groups). Regexr, on the other hand, features better and more readable reference guide IMHO, but only for JS and PCRE flavors. If you haven’t already, consider checking them out. So, I started learning with regexr and its docs. I slowly started to create some regexps of my own but nothing impressive really. Then I bought a book about this particular topic and read it from cover to cover. It hasn’t made me much comfortable with regexps either. I felt a bit tired by this whole situation.

---

The idea… and even bigger background

My whole experience made me wonder - why everyone uses regexps if they’re so hard to understand, read and write? I now know that this wasn’t the right kind of thinking, so before you’ll think anything wrong about me - please remember, this is just my whole story. 😉

At that time I was also doing another side-project of my own - something between app and minesweeper game. By doing this, I wanted to try myself if React is as good as many other people think. A side-note here - I was a big fan of Vue at that time, but its whole another story. For purpose of this project, I also started using Redux. This way, mainly out of curiosity and under the impression of how big the focus on good programming architecture was from the Redux team, I tried to also apply ImmutableJS to this project of mine. Maybe, just maybe it was influenced by me being ”brainwashed” 😀 after the lecture of [Clean Architecture by Uncle Bob](https://www.google.pl/search?q=Clean Architecture Robert C. Martin). In truth, I was impressed with ImmutableJS’ functional API to the point where I really enjoyed using it. My favorite feature was chainability of provided methods. It just made writing the code such a wonderful experience. It had its drawbacks tho. The main ones were disappointing support for TypeScript (which I’m a big fan of) out-of-the-box because of using custom, library-provided data types and my great care about the performance (remember - it was a game-kind-of project). Also, besides great API there was no other reason for me to use ImmutableJS, as one of its main selling-points - predictability - was already provided to be with the use of TS.

Now, leaving this story aside for another time (maybe), I became really impressed with the potential of functional and chainable APIs in JS. This thinking, when combined with the idea above led me to create yet another project…

---

Say hello to ReX.js!

That’s how my first OSS library came to be. During its development, I tried to think of each regex construction as a separate, chainable function. I hoped to provide a functional alternative to all possible combinations/regular expressions. I also wanted to make ReX something more than just that. I thought about expandability and polyfills for features currently unavailable in JS flavor of regexps - such as lookbehinds. This way it became a much harder task to accomplish. This way, after a dozen days of development, I had abandoned this project. I returned to it after around 2 months. I finished the polyfills, but still - they weren’t ideal. Anyway, I’ve decided to give it a shot and published it on GitHub. Then, I shared it on some social platforms. It reached a fine level of interest by achieving 58 points on HackerNews and starting a pretty controversial debate. The most negated aspect was ReX’s API. Many considered it too bloated and hard/not worth learning. Even after reading these comments I didn’t really know what to do. I fixed some of the pointed problems mainly created by me not knowing how to create a good-looking repo, badges and some misread of mine. API remained unchanged. I was thinking about what people said about this, but from my point of view, it was meant to be this way. Sure, API was a bit (😂) bloated but all methods were named mostly after their regexps’ constructions counterparts and TypeScript was meant to provide right coding experience for every developer. So, when Github stars stagnated on the level of 245 I considered it as the end of hype and also as a success - 245 starts for a first OSS library is an impressive score or at least I think so. Sadly, NPM installs weren’t as nice with a drop from around 400 to 10. 😟

---

To the point

So, recently I started the AIM project (new programming language) If you’re interested then I’ve already written something about this topic on this blog. Naturally, for creating a language, you need to do some text processing, (article about that coming soon) and for text processing the best choice is - obviously - regexp. You can think that I just ran to drop in my own library because why not? ⚡ Well, it wasn’t completely like that. 🙃 Yeah, I thought about ReX but I became concerned about performance and additional 4KB of code added without any other reason than making myself feel good. And so I’ve decided to use ReX in this project. How ironical, I’ve created a library that I’ve never truly used. It felt a bit weird actually.

Here comes the fun part - my usage and experience of my own library - mostly unbiased and critical. First impressions were good - it gave me easy ability to chain and reuse matching expressions but it was nothing that can’t be done using JS regexp constructor and strings. But, it goes without saying that it indeed gave me a good feeling when combining separately defined grammar constructs regexps into one big single regexp. Next, the polyfill I’ve written for named groups allowed me to utilize it without any problems - and that was really a great help for me. Sadly, that’s the point where the pros end. As for the cons, there was only one but truly big - boilerplate. Especially when considering small one-liners, when using ReX, then turned into either long, chained and unreadable one-liners or nice looking 3 or 2 lines of code. This struck me. And when it came to a decision, considering performance and code length, I decided to go with clean regexps. As a side-note, I didn’t even think about using clean regexp and use ReX as a binder without its whole API which is totally possible. This was mainly driven by my feelings left hurt by this experience.

---

Rethinking

So, at this point, I consider ReX as both a success and failure. As the success, because it has served its purpose - I finally feel comfortable with writing regexps to the point where I’ve even written a tutorial about them for starters and ones who would like to refresh their knowledge. It really has a great impact on me and my ”relationship” with regexps. Now I truly know that the best way to learn something is by practice (yeah, really discovering 😂). Also, for the first OSS project of mine, I consider it a success, even if its whole popularity may have been driven by controversy. I’m proud of my creation and myself for creating it. With that being said I’ve learned my lesson. Publishing project meant for experimenting and learning purposes as a full-blown library isn’t really a good idea. 😂 If you are just like me and want to create your first OSS library, then make sure that it serves its purpose well. First, make a library that solves your own problem. Then test it (not just with testing framework, which you should also do) in the ”battlefield” by using it to solve your problem and then proceed with making great docs, repo etc. Remember to have everything prepared before you publish it to the world. That was my mistake - making something that I haven’t personally experienced using.

---

What’s next?

Most likely the post about creating lexers! But really, I don’t know. Experience with ReX taught me a lot. When creating next OSS library I’ll definitely make it a little different, a little better. As for ReX, I have plans for maintaining it and most likely to change the polyfills architecture. But I would most likely leave the API alone. Changing it wouldn’t make much sense. It would break other people’s projects (who knows maybe there are some) and make ReX something completely different. Also, remember that you can remove parts of API when using TypeScript and ReX’s extensions. But, for now, I think we’re done here.

---

Thanks for now

So, this post was a little different - a bit more like a story of my own. I just hope you like it and felt just a bit entertained. If you do, then follow me for more interesting stories. That’s all for now. 🎉