| My comment from the medium post: I think the key takeaway here is: a) requirements suck always, b) figure out what the real problem is that needs to be solved, c) fashion your solution to the unique needs and culture of the team you are a part of. Computers are hard. I’ve been specializing in front end stuff for 4 years and it still took me a month to master the react ecosystem. It’s better than anything that came before it though by a landslide. People whine a lot expecting everything to be easy. There is a laundry list of classic cognitive distortions present in these types of articles. If this is literally your only requirement and no new features will ever be added: “create a page that displays the latest activity from the users, so I just need to get the data from the REST endpoint and display it in some sort of filterable table, and update it if anything changes in the server”. Which I highly doubt, but let’s go with that premise.
What you’d really want is to be step back and look at the needs of the app. The real needs are websockets for real time, and a way to tail the oplog of the database you are using to get the latest data pushed without needing to have the websocket proxy you’ll setup poll on the server side. The front end implementation is fairly irrelevant here, IF nothing ever changes ( yeah right ). If that is truly the case ( it’s not, believe me ), then just use a jquery datatable plugin which updates it’s data when new websocket data comes in. That’s like 100 lines of code, done. If you’re using mongo it’s not too hard server side because you tail the oplog, the way meteor does. If you’re using something else you might have to poll server side to get the new data, which is honestly the hardest part of this problem. The front end of this is not the issue frankly based on the requirements presented. This is IF this is all a one off project that never changes and will never need new features or bugfixes. If it ever needs to be changed, you do benefit a lot from using more modern technologies so instead of a lump of jquery spaghetti you have clean component api boundaries which can be easily unit tested and modified in isolation without breaking other areas of the app. Every situation is different. As presented, this is more of a server side problem than a front end problem. What data stores are you using, how are you going to get that data in real time, how are you going to set up a web socket server, how are you going to scale said web socket server etc. I think that blog post comes off as attacking the wrong problem and complaining that computers are hard. It doesn’t appear the requirements were clearly understood and evaluated. Picking the right tool for the job is really a thing. Dogma is dangerous in software for sure. On that point, I agree. |