Hacker News new | past | comments | ask | show | jobs | submit login

IT is like the fashion industry. every few years, you get a new shiny new tech or old tech with new bottle and for some reason what work for Google. we must use it for our organization regardless if it make sense or not.



I mean look at the rise of things like Hotwire. We are seeing developers go away from JSON everything to let me just send an HTML partial over the wire instead, that and things like Phoenix Liveview: let me send what needs to be changed in the DOM as a websocket message and save on data.

I don't mind the idea for a SPA for a big social media type of site, but for ordinary sites, I feel like it's overkill in most cases. If you enjoy it and it works best with your team and workflow I'm not trying to knock on you. I just prefer not to add more layers and points of failure to my web application.


I chuckle cynically how simple things come back with fancy names - Server Side Rendering (SSR), Hotwire


Server Side Rendering annoyed me the most because I kind of like the idea of components for front-end code, but I don't want to host yet another thing when I could of at that point used a server side template engine for my back-end web framework.


That's the operational problem. However, I'm more amused at how similar this is to fashions clothes fashions. Those usually change often for frivolous reasons or plain boredom. This feels quite similar.


It only appears this way because you are not aware of the nature of the cycles, and what causes them.


I assume it's various things. I think for me at least React and other SPA frameworks fixed a different problem I think most could agree with: reusable web components. I don't think anything like that existed before on the front-end, and by making it a front-end specific solution, it is fluid enough to transcend back-end languages, but then it became bloated.

I love back-end work and I prefer front-end code to be as vanilla as can be. If I want a UI I pull in Bootstrap or some CSS framework because I'm not a designer.


I totally understand. They are just discovering the basics, and slapping fancy names to it.


There's really just LiveView and a lot of less capable copies. In order to do what Phoenix LiveView can do effectively, a number of specific elements must to exist in your runtime as well as your language. Anybody can send HTML changes over a websocket, but there's so much more than that happening.

It's one of the great show pieces for what the Elixir makes possible.


I think it is partly because it is shiny new ... but also sometimes it seems promising, you have to try to really figure out what works about it, and then you understand it better and its use case is more nuanced.


I think it's mostly because the new tech Solves-A-Problem-That-I-Recognize, and developers mislead themselves into thinking the new tech is does everything old tech does, plus this, and they downplay the trade-offs being made (or they aren't experienced enough to recognize the tradeoffs).


Or even more simply:

These solutions are often solved in environments that are running at a scale not most companies operate at, BUT think they will, so they invest in them early for future, potential, needs. It's no surprise many of the core contributors / founders comes from Facebook/Google/etc.


I'm not even sure they need to assume. So much programming is by organizational design task by task problem solving that people get lead into making one off decisions and really don't have time to explore otherwise.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: