The transition from XMLHttp requests to fetch() requests can be seen as a part of a comprehensive conceptual paradigm shift, the objective being improved user experience, essentially speed. Where React, instead of manipulating HTML, turns websites into fast and flexible JavaScript applications, similarly Fetch API allows us to write code that is not only cleaner, but also considerably faster. The code is cleaner and simpler because we don’t have to create an XHR object, handle the complexity of callback functions that we must pass to the asynchronous functions, and deal with the exposure to all kinds of errors due to all this complexity. A fetch() request also looks more logical and therefore is more readable.
It is a well-known phenomenon that whatever you expect something to be, when you finally encounter it, more often than not it turns out to be something completely unexpected. In this respect React is definitely not an exception. What I expected it to be was something easily comprehensible, highly intuitive and essentially just a library that abstracts away some complexity or another, but I was in for quite a surprise in two different ways. Firstly, to really feel how React components interact with each other, which may be completely subjective on my part, you must be able kind of hang them all in the air in front of you like a complex see-through hologram and actually see them in three dimensions. You can’t really think of props now, then, in a moment, of the local state of a component and then, a few seconds later, of the state of the entire application in Redux – you have to see the spider web of all those connections at the same time, which almost gives the notion of Web Developer a new meaning. Again, this may be strictly subjective, but to me this is something that either makes you or breaks you as a React developer: if you see it, it’s clear, light and bouncy, if you don’t – it’s a jungle. Easily comprehensible it certainly isn’t.
The road to this, already forth in order portfolio project has been extremely interesting because it went through learning an actually new programming language, namely JavaScript. Up to that point Ruby had been the one and only, HTML being a markup and CSS a styling language, but leaning JavaScript was a reminder that there’s actually a lot more out there, and to me it immediately put coding into a multidimensional perspective. In and of itself JavaScript seems to be more controversial subject than extraterrestrial intelligence or life on Mars – there’s a lot of coders who are of the opinion that it shouldn’t even be there in the first place, but, as one of the Technical Coaches put it, it’s not about how difficult or seemingly inconvenient a language is, it’s about what you can actually do with it, and that’s probably exactly the way to approach JavaScript, because even on the jQuery stage it became apparent that with JavaScript pretty much sky is the limit.
It’s fascinating how different people can perceive exactly the same thing in completely different ways, and Rails is definitely no exception. As much as I was looking forward to finally start it and as much as I’d heard about its magical tricks, the actual experience of working on Rails was something different than what I had expected. Sometimes, figuratively speaking, the rails take you into a tunnel with no visible light at the end of it without help from a technical coach, perhaps because the degree of abstraction is very high and the conventions take things out of the realm of your control what feels like unbeknownst to you and against your will. There’s a saying that every good advice calls for ten more good advices on how to actually follow that first one – the same thing with Rails where every abstraction and every convention require deep knowledge of what actually has been abstracted away and why, and why the convention is what it is. But it seems that the longer you work with Rails the more rewarding it becomes, and working on the portfolio project actually helped me realize that with the power of Rails there’s essentially no limits to what you can do.
Picking the right idea for a coding project is actually a project in and of itself, which explains the existence of numerous websites intended to help you or at least give you an idea about what such an idea could be. In my opinion, perhaps the most important selection criterion, as simple as it might seem, is the fact that you actually really love your project idea, because feeling passionate about it is very likely to translate into an interesting application with witty coding solutions – in other words, if you l really love the idea of your project, you are likely to exceed yourself and write a better application than you are in fact even capable of.