Comment by threeseed | Hacker News Reader

Comment by threeseed | Hacker News Reader

Parent Full thread

There seems to be this group of developers who love nothing more than to rubbish the design choices of other developers. As though they are in a better position to judge (a) what is risky or not and (b) what is suitable or not. And often those developers are those who haven't really done anything all that impressive and often lack broad experience.

The idea that React is not a suitable choice for front end development is ridiculous. It has a lot of mindshare, is popular and has a major backer. The idea that Microservices demands significant DevOps effort is ridiculous. You can literally just duplicate your Jenkins jobs. The idea that NoSQL has no use case is just laughable given how successful DataStax, Hortonworks, Cloudera, MongoDB etc are all doing. They all serve legitimate use cases at a price infinitely cheaper than Oracle or Teradata.

Before you criticise other developers: STOP. And ask yourself if you are genuinely in a better position to make their decisions for them.

To me it seems even more ridiculous that react is the silver bullet for frontend development. Or even more laughable that microservices don't require a considerable devops effort. Each tool has its use cases. Using react for a small page mostly static or using micro-services for a use case that doesn't require them is just plainly wrong. I don't agree completely with the blog post about HDD (that actually is known as cargo cult), but I completely disagree with you that are trying to sell react and micro services as THE solution to every problem.

> To me it seems even more ridiculous that react is the silver bullet for frontend development.

For me (and other Clojurescript developers) React is one of the best ways to do front end development. Simply because of it's virtual DOM concept, which allows us to hot reload parts of the page as we write new code. Just save the file and the page updates. It's incredibly productive, and a development experience I've not seen replicated elsewhere.

Virtual dom has nothing to do with hot reload. Ages ago (more than 20 years ago) you could do the same while writing HTML and refreshing the browser. And if you used WYSIWYG editors it was even mostly unnecessary.

Hot reload means something different than refreshing the page, automatically or manually.

If the state of art of your development cycle is refreshing the browser, check out hot reload.

Refreshing the page is what you currently have to do with a typical javascript setup, with the main problem being that you lose all your state on the page. For example any form fields you've filled out. With bigger Web apps this can be quite a slow way to develop.

WYSIWYG editors are built very specifically to convert to and from from a particular markup to html, they can't process anything outside of that.

Clojurescript and React allows me to make changes to part of the DOM and only that part of the page updates, maintaining state on the rest of the page. This is made possible because of React's virtual DOM which can run a diff algorithm and only push through the parts that have changed to the actual DOM.

Is it the best for your product or your customers. In your case it may very well be. However, you CANNOT[0] make tech stack decisions solely on how easy it is for YOU.

[0] Should not.

Clojurescript compiles down to regular Javascript, and React is used by Facebook which is in the top 3 most visited sites in the world. So what's your point?

That most developers won't be building a top 3 most visited site in the world. FB's needs are not necessarily everyone else's needs. React may or may not be a good choice for any given project.

I am pretty sure I made my point clear. What is good for a developer isn't always good for the customer.

I have never said those tools are suitable in all situations. I also don't believe that I should be lecturing others about which tools to use. If they think React is better for their use case. Great. If they think Vanilla JS is better for their use case. Great.

But people need to stop posting this garbage and dismissing their legitimate choices as "hype".

You're misreading the blog post. Choosing React because it's a well-engineered solution to a specific type of problem that plagues front-ends is fine. Choosing React because it's currently the most talked-about and blogged-about platform for front-end development is not, and is likely to lead to issues.

Similarly micro-services. If you cannot see the tradeoffs you are making when you choose to use them, you will blindly lose man-years of productivity when you inevitably encounter their rough edges. Prepare for them, and work around problem areas like monitoring and interface complexity, and it may be the right choice.

This is nothing but strawman arguments with zero factual basis.

Who are these mythical developers that are selecting technologies purely for hype ? Are these developers so significant in numbers than it is undermining our industry and causing projects to fail ?

And if choosing a technology because it is talked about and blogged about is bad a thing. Then is choosing an obscure and abandoned technology good ?

So many questions.

There are plenty of blog posts there in the wild about people adopting one hyped technology and after much pain migrating to another one that was a better match for their problems. If you don't know anyone in that situation first hand maybe you didn't change enough jobs or you are very lucky, because I assure you that it is quite easy to know someone with this kind of experience.

There are also plenty of blog posts about people moving from c++ or java to hyped technologies. Or blog posts about people failing horribly with matured technologies. Today's hype seems to be complaining about other people's hyped choices. You can't know all the reasons that made people select a technology unless you were there. Generalizing them into a group of people that make hyped choices they will regret is nonsense. Could have equally happened if they chose a non-hyped technology because most likely you go on incomplete information anyway.

So we can either summarize authors post with "don't make choices without thinking", which is kicking in an open door, or "let's blame people for choosing hyped technologies", which is no better.

> Before you criticise other developers: STOP

That's exactly what hype is: not using enough critical thinking and trusting developers of popular technologies.

Reply on news.ycombinator.com