I have been hacking and slinging javascript together now for 15 years! I have seen it grow into the huge ecosystem it is now and like it or not your job as a web developer (especially if you call yourself “fullstack”) and your livelyhood depends on it greatly. Users and business people now expect your applications’ front-end to behave like the best web applications out there. So with as frustrating javascript can be at times, it is the only cross platform language that can transform your blank canvas into a masterpiece.

I have witnessed and maintained at least 50 or more web applications over the past 15 years and from all that experience I do know that the javascript stack and architecture is the single most important facet to the success and usability of your application. We all wish just picking an amazing library/framework/design pattern could allow our application we are coding to become amazing. But obviously that is not true. It takes several different libraries and your design of how to construct front-end pages to communicate to your backend consistently and efficiently. Once you setup this foundation for your application, most developers are going to copy and paste the best snippets or pages for when they build the next component. I guess my point here is that if your front-end is just jQuery and some HTML templates like back in 2008 and is “the wild west”, it’s time to modernize your application with React, npm, babel/es6/webpack and possibly my favorite material ui components.

My journey into javascript began with this “document.getElementById”. Back in 2002, this was the single most powerful line of code you could write because it brought me the possibility of using DHTML. Dynamic HTML that allowed a single javascript event of any DOM element to manipulate another part of my webpage that was most likely downloaded as raw text/html. There were no frameworks popular enough back then (or maybe I was a noob… who knows). But I absolutely was fascinated that I could manipulate CSS or add elements to my web page and they show up magically in the browser. I still hated and didnt understand much of javascript back then.

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.

Now for me, from 2010 to 2015 there was a lull in new technologies for me from javascript perspective. I moved from writing PHP for 8 years into learning Ruby on Rails, then Python and now Golang. It was an eye opening experience to learn a new backend language outside of my comfort zone. Now I am very comfortable with “multithreaded gophers” and all the mutex hell/glory the backend might need. I dont think I can go back to a loose duck type language like php or python again. From that time I can remember some angular usage from the general development coworkers but I never really got my feet wet with either angular/ember/knockout/backbone. I guess I never really liked the bidirectional way of coding or the larger javascript frameworks of that time.

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.

My brother Dan and I built our own golang router and react libraries to easily be able to code pages quickly and efficiently. We push down JSON payloads from the backend post/get/puts, we mutate those objects from javascript and we push that same payload back up to the server for validation/processing/saving. We thought of this method originally like a UPS truck hauling dell computers. If you are repairing a computer and its free and cheap to ship, you wont just exclude pieces and parts just because they add weight to the truck. We theorized that maybe you might even want to send the monitor along just incase the issue that the dummy user is having is with the keyboard or monitor or external component needing maintenance from the shop. In this theoretical world you dont call dell to trouble shoot specific things before shipping, in this world you just send your whole office because its free and cheap (in your intranet without bandwidth costs from an ISP or hosting company). Think of the possibilities if logistics (network) were cheap, fast and nearly free.

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.

I originally wrote this blog post with the intent to talk about an analogy about how javascript is like a paintbrush and your backend is like a kind of canvas which comes in many shapes, sizes and various materials. The paint is really nothing on it’s own without a good canvas with the shape you need it for your “studio” or “gallery” showing off your work. The colors of the paint is obviously CSS, but javascript is the glue that binds everything together. It is the lens of a camera in photography, the stage of a play etc etc. Basically and you can make some analogies to javascript being the center. You can mold javascript to handle any input to your beautifully written and efficient backend, but you also must keep your javascript and pages very performant. My point to this for any “backend only engineers” is that you need to find more inspiration and more comfort in the fact that javascript is physically bringing home food on the table for most engineers working on the web. More clients (I can theorize) hire a full stack engineer because they know they can build both important ends of the system. Sure you can seek out backend only jobs doing database only work, but if I meet you in the office I will surely talk to you about stepping out of your comfort zone and out of your left brain and begin feeling and creating something amazing with your right brain. If you are one of those types who is mostly a right brained math person and who is not fully comfortable with front-end design for your backend data, fear not because React/MaterialUI/ES6 is a wonderful way to begin exploring sleek user experience for your application. I have fully witnessed my brother being an amazing backend engineer and writing some absolutely sick front-end stuff now that he is seeing the light. When he started he hated front-end for all the right reasons and really Javascript the language does suck and all front-ends are mostly garbage. But now he is a changed person too thanks to React. The front-end is winning because end-users and your boss and every other business person out there doesnt care or doesnt understand what the backend does or how it operates or what it takes to build a good backend. They only see the data issues from the front-end and the paint on the canvas showing just how bad or good your application is setup. At the end of the day, the front-end mutates your data the most and is what probably inevitably creates the most data issues. It should be every developers mission to everyday think about how to write better and higher quality javascript so your backend feels more stable.

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.

Lets go write some code, kick some ass and make some money for many years to come in your career! If you dont convert to react, you might be out of the job or be so far behind the NPM and javascript revolution. This means you “MCFW’s of the world” (a buddy who went through a similar javascript journey of mine) who might not be fully in love with React yet! Even if Javascript pisses all the developers off at times, it’s our lifeline for money and our only way to express the art and beauty that is front-end web development and programming. Respect it and realize that react fixes front-end’s issues we have all had.