Then in 2006–2010? jquery was all the rage for most of the applications. And with jQuery’s dominance it seemed that $.post and AJAX was the way that you built your frontend. Now applications can pull more data with JSON from your backend in pieces! Yay, we are winning! But over a few years of using jQuery you realized that your code looks like garabage and is quite unmaintainable.
Finally in 2015 is where I was introduced with React while working on uptime.com. Barak was my co-worker who implemented all the initial react architecture and he and I worked on some projects with this new library, my life will never be the same. I remember still trying to understand the lifecycle functions and how render really worked, but it was an amazing year for learning it. Now I don’t think I will never use or write another application that does not have react at my disposal.
By 2016, I started working for Atlona. I began an opportunity with my brother (Daniel Renne) a journey that has led to the release of our first major project we collaborated on with the release of Velocity control system! I was adamant from day one to setup and write an entire application using react. I setup the webpack dependencies and build process and thankfully chose a great start of react UI components and CSS foundations (mostly using the react material UI components from google). There were several developers on our team who had never used react yet or even ES6 (I had not as well truly got to know React intimately) so we all learned a lot together. I explicitly chose not to use FLUX, react router or redux because I did not want to overcomplicate the learning curve for our entire team (especially with redux reducers which I still dont like because it fundamentally is so different than what I am used to). It’s okay just to use react to start and learn state/props/components. We just launched our generally available product yesterday and the front-end we put together looks so amazing and sleek and intuitive. It is my best work to date. Here’s a little teaser of the system.
Many applications we had worked on in the past developers would construct many requests for page JSON and only send pieces of information relevant to whatever ajax request the developer is working on. This sometimes led to some nasty front and backend code I thought because there is no consistency between data fetched for a page and data pushed back up, so we went with a viewModel struct in golang for each page which constructs and loads the JSON with your get or post controller on what you think you need for the page. Once the JSON is fetched from the front-end it loads the object into a window variable to hold page state. Our router also has generic state of the app in a window variable where you would hold generic application state. These two state variables in conjunction with two variables for english translations fetched from the backend pretty much run every single page’s visible english translated content and application data.
Gone are the days where some python script or php script would return some random key value pair back to the front-end (whatever joe developer felt like doing that day) inconsistently because the golang structs will always have a predefined JSON structure you can always rely on. If there is 1 row of data, it will certainly have all the keys you expect in the object definition filled in with nulls/data. Anyway, we had a great experience building this bridge from the front-end to the back-end and our application is very easy to maintain and make adjustments. My point to this is to not just rely on other libraries to handle all the communication from your front-end to the back-end, you might really enjoy it if you come up with your own system for constructing pages across your entire application. It’s nice to have a maintainable solution that is simple to code and interface with new or existing pages. Our UPS truck always hauls the entire computer and monitors to Dell for the destination. Sometimes its a very heavy request and can be burdensome for performance depending on the situation, but on the other hand, all or most of the data is at your disposal on the front-end. But for an application running on a LAN, this is perfectly acceptable to have the pipe be slightly more congested with packets on each request when you are on a gigabit switch. We love it and only a few times did we find the payloads on posts or gets were too large where performance was hindered on the front-end.
Your reputation of how good your backend is, is all reflected on how your front-end is setup. Users of most applications do not use command line flags to run your amazing tool. They must see it and you must provide transparency of all the inputs and outputs of your program through your UI. And like I have said before, it starts by stopping what you are doing and install react/ES6/Material UI. Many web developer jobs are shifting to this type of stack where the center of all things UI is React.
We're in this together
Level up every day