ReactJs is a great way to write software. I'm far too time poor to waste my time on "being cool". I choose best of breed development tools that are well supported and allow me to be highly productive.
Only a fool would suggest that ReactJs is simply a hype trend like s new hairstyle.
Same here, we investigate literally everything from Angular (1,2), React, Vue, hell even using just pure JS for a month and settled on React. We never looked back. Developers are happy, CTO is happy, client is happy.
I guess this article is trying point out how people chose things based on hype but fails to understand the difference between choosing X because of hype vs. choosing X because it suits your needs.
You can substitute react with php, Ruby on Rails, angular, meteor.
They are just hype cycle that periodically bubble up.
This doesn't mean that in a lot of use cases they are the right choice, but denying the hype is like saying that the sky is not blue.
I don't know your use case, but my experience tells me that people uses react in places where it is absolutely not necessary.
Having state both in the front-end and in the back-end multiplies the complexity of any project, and the gains are only worth if you are (or you have) a good UI designer.
For the rest, the good'ol Rails + Turbolinks, jQuery and SJR can do a fantastic job, without having to think about synchronizing several sources of truth.
With time the tools are getting better, and while rewriting existing projects is definitely a time sink, using new tools in greenfield projects is definitely beneficial.
Although it is true that microservices approach is flawed if it doesn't feet the organizational structure. But the same applies for the different new tools. Do the due diligence and figure out whether it fits before jumping straight into development.
I some months ago, they asked me to join a new team because they needed help with React and, although my main technology is RoR, I quite like JavaScript.
What I found is that the last developer shoved 2500 lines React, Redux and Typescript in a Rails application just to make a sortable and filterable table!! Apparently, after perpetrating this atrocity, he updated his resumée and found a job in another company.
I really think that it is good to have a grumpy senior developer in each team stopping those things from happening.
Some of this is due to the immaturity of our industry. Even the most grizzled, experienced web developers typically have about 20-30 years experience. Most have fewer than 10. So we make mistakes out of immaturity and inexperience, rather like the junior blacksmith taking over the forge because there's no one else to do it.
Developers want to do new things, partly out of boredom, partly out of fear of becoming stale. Non-technical business managers have no idea of the consequences of "using Elixir instead of Java" or "Microservices instead of Monoliths" so they just nod and go along with it.
Eventually, developers get tired of having to pull all-nighters that could have been avoided by using more simple solutions. Then you have a bigger pool of 'experienced developers' who prioritise stability over fashion.
So the industry is becoming more stable and less hype-driven, but it will take a long time to get there. We need to learn lessons from other crafts and industries, like factory production and carpentry.
I have been programming since the '80s and I disagree that the industry becoming more stable or that the prime cause is immaturity.
IMHO the ultimate source of instability is that we deal with pure thought-stuff that has very little internal constraint except at the interfaces. Other engineering is quickly constrained by materials, biology and physics but for us, any idle thought can become our reality. The faster we can communicate and the faster we can build, the faster the iteration.
We can achieve much the same ends in any number of different styles and paradigms. The primitives for a programmer have more to do with poetry, memes, fashion and the creative end of pure math than physical systems. There can be no assumption of convergence. The pull of a social group will crush the technical excellence of an out group.
We face a lot of those constraints as well - money, time, computing power, knowledge, politics. In the short term, a social group may dominate and push a company in the wrong direction. In the long term, that company will lose out to the one that chooses the right direction, because of those constraints. ('Company' is a loose term here - it could be a department, a team, etc.)
Those constraints are incomparably looser than those encountered in a "stable" engineering discipline e.g. you can't build a driveshaft out of wood but you could write paxos in brainfuck.
The use of physical material with hard constraints means there are "few good solutions" hence the disciplines converge and stabilise. Our thought-stuff just doesn't have that property. Even a hard real-time constraint does not strongly dictate many of our design and implementation choices of the written code, only the final behaviour.
The argument is that the lack of constraint means that social forces are allowed to dominate, such as hype, fashion etc. Its not causal, its vulnerability. Any human endeavour similarly unconstrained will see similar dynamics when popularity, status, boredom and novelty run free.
I've rarely met devs with more than 20 years of experience that would buy into any hype. OTOH it the most hype-y conferences I've been to the average level of experience seemed to be... between 0 and 2 years.
There is always the wandering circus, a rainshower raising flowers in the dessert. Wether the resulting bloom and dust leaves behind working affordable ecosystems- can be often determined by looking at similar situations previously down the line. Ask a old coder near you, what companys came to be from when he last saw thee - Enter Hype here -
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.
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 ?
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.
> 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.
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.
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.
"staying with the herd" (i.e: use technologies that are in active use/high demand) helps recruiting and retention, as well as benefiting from the collective work of the community around a technology.
"The big rewrite" is usually a response to technical bankruptcy, which is when technical debt and interest is too high to be repaid.
Many points in this blog post are spot on, The moral of the story is: There is no perfect tech stack or architecture, only pros and cons. The sooner you learn this, the better you become at making decisions.
I don't think microservices, react, functional programming or no sql are examples of 'hype'; I think those are good engineering decisions (depending on the problem domain).
I also completely disagree that hackathons are good places to try out new technologies to see what's good for good engineering decisions; hackathons let you dip your fingers in the water and see the shiny cool bits and pieces without having to suffer through any of the long term maintenance or scale issues with the technologies. If you're looking for a bad decision, picking something to run with that 'seems pretty good' after a 2 day hackathon <--- that's your bad decision right there.
I mean, I get what the article is saying, yeah yeah, avoid the hype, don't drink the 'webscale' cool-aid...
...but hey, the internet is full of really talented smart people who do excellent engineering work.
You'd be stupid to not look at what the best and most successful companies in the world are doing with their engineering teams and take note of it.
Even if it means picking up new technology: that's not bowing to the hype; it's being pragmatic.
Still, it's super easy to cherry pick some things and go, oh hey, this is a bad idea. Much more interesting would be some examples of good engineering choices.
> I think those are good engineering decisions (depending on the problem domain).
The "depending on the problem domain" seems another variant of "choose the right tool for the right job". One could probably add "for the right reason" on the end of that instruction too, and it wouldn't hurt.
The problem is the ability to determine "the right tool" and "the right job" - many people simply don't have it. You only get that ability through experience. With new tools few people - even older folks - have enough experience with the tool in question to make accurate/useful assessments.
> but hey, the internet is full of really talented smart people who do excellent engineering work.
And it's full of even more people who aren't really capable of making those assessments accurately.
> You'd be stupid to not look at what the best and most successful companies in the world are doing with their engineering teams and take note of it.
You'd be stupid to think that because "Facebook" (or "Amazon" or "Google" or "MS") is using a particular tech stack (which, likely, teams of internal people contributed to for months), it's a great fit for your problem, or your skills, or your team's skills, or your project's timeline, or its budget. Few people have the problems or demands that Facebook/Amazon/Google/etc have. It's great that they share some of their internal tech, but that sharing isn't an automatic determination that their solutions are appropriate fits for your problems.
What if your development team is made up of mediocre programmers? What works for the most talented programmers isn't necessarily going to work for your team.
In my experience the choice of the right tech is primarily a business decision rather than a technical one. By that I mean it should be based on a number of factors external to the technology. Once you have clearly identified the business problem you are trying to solve, you have to think of the solution in terms of risk. For example, what is the up-front development risk? What are the maintenance risks?
Every project exists within a certain environment with its own set of constraints. Picking the right solution means understanding these and doing so from the point of view of the business.
If you understand the risks and constraints, and you put the needs of your end-users, the systems administrators, the testers, and the business first you will rarely go off-track.
Not that I really disagree with you, but I find that "risks", "constraints", "end-users", "systems administrators", "testers", and "the business" are six separate forces, each pulling in their own direction, and you can't put them all first.
Find myself in agreement with both of you. As you say you can't put them all first, however I've found anecdotally that risk and constraints are disproportionally placed last in many orgs.
Of course, there's the opposite extreme too, where long time team members and management ivory-tower themselves to micromanage every tech choice and then prescribe it throughout an organisation without much input.
>Ok, if what the smartest and best people are doing isnt the right solution for my problem, what is?
Obviously only what "the smartest and best people are doing" to solve problems that are isomorphic to yours.
But first you also need to identify those people: who said those in the big companies (or smaller with better bloggers) are the "smartest and best people"? Just because they belong to a succesful company? And because they have degrees from some top-tier university?
The company could be succesful despite of its technology, on the business value alone (which usually is how it is), and the people with "good degrees" could just be architecture astronauts or fresh amateurs who re-invent long buried concepts because they don't know better.
There's a whole long distance between what the current industry champions as "best minds" (some 20 year old with 2 years of JS that created the framework du jour) and people like Knuth, Alan Kay, Kernighan, Richie, Bill Joy, and the like...
Facebook is the world's largest PHP shop. Does that mean that everyone should use PHP?
As it turns out, moving fast and breaking things isn't all that conducive to quality engineering[1][2]. Facebook has a massive legacy code base maintained by an enormous team that is under pressure to iterate quickly while supporting what is arguably the world's largest user base. They are dealing with extremely specialized constraints that most of us will never encounter. Many of the trade-offs they consider acceptable aren't trade-offs that make sense elsewhere.
And that's exactly what the blog post is getting at. A lot of these emerging technologies are situationally useful in a particular set of scenarios and environments, but developers with cargo cult mentality convince themselves that these things will solve all of their problems if they use them everywhere. When the disappointment sets in and they figure out that isn't the case, yesterday's darling stack becomes the subject of today's "considered harmful" essays and everybody moves on to the next shiny thing.
The point here is that maybe you should make a sober assessment of new technologies and objectively evaluate whether they are actually practical for your usage scenario rather than just blindly jumping on the bandwagon and using something.
The examples from the blog post are totally on point. I previously worked at a company that built a NoSQL database and I have great affinity for the technology, but there's no question that too many people adopted NoSQL databases without really understanding the trade offs. People want to be "web scale" so they go straight to using databases that are designed for high-availability clustering even when they are building applications that would be perfectly fine running forever on a single postgres instance.
I agree with the general sentiment, but, to nitpick, Facebook uses/is transitioning to http://hacklang.org/ to avoid PHP. They literally wrote a whole new language and built a VM to do JIT compilation of that new lang just to not have to continue using PHP.
> I don't think microservices, react, functional programming or no sql are examples of 'hype'; I think those are good engineering decisions (depending on the problem domain).
Hype does not mean that a popular technology should never be used. It's when people overrate and overuse it and try to apply it to the wrong domain.
Yes. Google and Facebook who pioneered NoSQL with BigTable, HBase, Cassandra etc have no idea about relational databases. Likewise all of the enterprise companies who have spent tens of millions on relational EDW systems and are adopting NoSQL in droves also don't understand what they are doing.
But thankfully we have some no-name developer to save us from all of these mistakes. No use cases for NoSQL. Give us a break.
They didn't say the technology itself was poor, but that people have misused it.
>we have some no-name developer to save us from all of these mistakes.
Both rude and fallacious. Do you presume that every employee at a successful firm is a wunderkind? Do you actually know the level of talent of every HN poster?
Relational databases have their advantages and disadvantages just like NoSQL. They both make tradeoffs. Taking the trouble to understand which is the right tool for the job instead of following the latest fashion trend is what the article is about.
> I don't think microservices, react, functional programming or no sql are examples of 'hype'; I think those are good engineering decisions (depending on the problem domain).
> I mean, I get what the article is saying, yeah yeah, avoid the hype, don't drink the 'webscale' cool-aid...
I feel like you're shooting right past the author's point here. What he's saying is that hype, as in the shared excitement, obscures the actual tradeoffs involved in adopting the new technology, and makes it harder to make good engineering decisions.
I'd like to add that it also obscures the available alternatives - simple and straightforward ways to configure / extend existing technologies to have the same behavior / features as that shiny new thing.
And it's not even about what you know ahead of time. I was actually thinking about this earlier today: I often recognize some of the tradeoffs of adopting a new tech early on, but my judgement still often ends up clouded by enthusiasm.
A common pattern of rationalization I often have goes like this:
"Sure this old thing can be used to do the same as this new thing by using functions X,Y,Z, but this new thing lets you do it with just one function. I mean sure, I could write that function myself in about 10 lines, and I only need to do this once for each project, but this is just easier."
I'm not saying that this reasoning is wrong, only that it is biased.
Tradeoffs of a technology, and therefore knowing in which problem domain they are most appropriate, consist of both pros and cons.
The problem with hype isn't that the technology being hyped is not excellent in its own way, the problem is that (psychologically) hype leads us to ignore the cons, to rationalize them away - and this means we're not really fairly considering the tradeoffs.
The author isn't saying that microservices, react, Elixir, NoSQL, etc don't have upsides, but only that (if we are not extra careful) we might not be considering the tradeoffs and alternatives as pragmatically as we think we do.
These are perfect examples of cargo cult and your comment confirms it.
Just because some successful company adopts a technology it doesn't mean that it suits your needs.
You could have completely different problems and adopting those solutions can be in the very best case useless and in all the other cases harmful.
You need to adopt a solution because it fits your problem, not because "the most successful companies in the world" are using it.
It's always a good thing to know that these technologies exists and what are they used for, but jumping on the hype wagon without understanding deeply the original problem that they solve, how the solution works, and most importantly if it applies to your use case trying it with some representative, real work in your project, it is a sure recipe for failure.
It would be one thing if we just knew these companies used these technologies, and that was it. Instead, we have conference talks, testimonials, and evidence that they are working well for them.
Obviously you should not use a technology without understanding it. Does this really require a discussion? No one is on the other side. But going "Well that technology is just hype" isn't understanding it, it's dismissing it.
Conference talks, testimonials, etc are often biased towards the positive. It drives me nuts when someone tells me why I should use some technology, without telling me why I shouldn't use it, and what its constraints and limitations are. Those are equally as important as the features. Project documentation are the worst at this, painting a rosy picture of how the tech will solve the world's problems, without telling you the practical realities of using it.
Right, because there isn't a litany for what could go wrong with every single technology mentioned in this article already...
Let's not pretend like there's a single technology out there that isn't constantly under fire.
If you strip out the strawman argument against each technology ("Let me tell you a story about how this technology didn't work in my imagination") you end up with one single premise - do research before adopting tech. Did you need to be told that? I think if one single person is making tech stack decisions in production and no one is going "uh can you justify this" you have far more serious issues.
No I don't need to be told that. That's my point. Most tech products make it difficult for me to do my up-front research, because they want to paint a rosy picture of their product to drive adoption. But I'm less likely to adopt it if I can't easily understand its constraints, failure scenarios, scaling bottlenecks, maintenance headaches, leaky abstractions, etc.
The React and Redux devs engage in more self-critique, and are more honest and open in the shortcomings of their approaches, than just about anyone I know of in web development.
This is not charitable to the comment you replied to. That comment suggested that looking at what companies have had success with is a no-brainer, and you interred they were suggesting "jumping on the hype wagon without understanding deeply the original problem that they solve". Here, I'll quote:
> You'd be stupid to not look at what the best and most successful companies in the world are doing with their engineering teams and take note of it.
I think you're both saying the same thing. People should look at what others are doing, and analyze the suitability to their own use case. I think this is exactly what people do. I've never seen a tool choice postmortem that concluded, "well we only chose it for hype, and that was stupid". It's always a specific thing that you thought would work better than it did.
For example, I came away from a project quite burned by Angular 1.x. It wasn't that we chose it because of hype that it was a poor choice, it was that the directive system did not make it as easy to build modular components as initial prototypes suggested it would be. React was then interesting to us (though we never pursued it on that project), not because of upvotes on HN, but because it scratched that itch better.
I guess I just don't see this wild hype cycle that everyone complains about - I just see people trying to scratch itches they have, sometimes making the right choice, and sometimes making the wrong choice.
>I don't think microservices, react, functional programming or no sql are examples of 'hype'; I think those are good engineering decisions (depending on the problem domain).
The two are orthogonal. Hype is a marketing force which can be used to tout good and bad stuff.
Teams can just as well adopt a good product if its hyped. That doesn't mean their adoption process was based on a "good engineering decision". Just that they lucked onto making one.
That said, I find "microservices" or "no sql" as more hype than substance in the domains that most teams apply them. They just reimplement (poorly) a ton of stuff that a monolith or sql would already have, and don't really need either for their use case.
I've definitely seen overuse of React, microservices, and NoSQL databases before it makes sense or when it's actually a detriment to complexity.
This point from the article however, I agree is a bad example.
> Example 2: TDD is dead by DHH
The 37signals guys if anything are some of the realest in terms of low fidelity tools and sensible abstractions and building things simply. They've even written two books about their approach to business and web app development (Rework, Getting Reals). Maybe there is concentrated hype around Rails but in general their stuff is well informed and well thought out.
The guy uses contradictory examples to share his opinion. The second one, TDD, someone could do the same saying that it was hype. And then some maniacs will come to say it was not hype.
Hype is worse that what people think: it create bubbles where constructive disagreement and criticism are quickly shunned.
Amazon has (or had) a culture of encouraging criticism (as long as it's supported by reasonable explanations) to the point of harshness and this was quite effective at stopping hype.
> Hype is worse that what people think: it create bubbles where constructive disagreement and criticism are quickly shunned.
And sometimes constructive criticism is mistaken for hype and shunned by the management, you would hear: we always done it this way, why choose this new technology that might break things; so you have companies that are still using COBOL on the mainframes and don't see anything wrong with it, as well as store user passwords unencrypted.
"Loudest guy driven decisions — is when one guy is talking all the time about this new framework/lib/tech’s that he has no experience with, but talks about it all the time and finally the team decides to use it."
Except that this is how new technologies get introduced and tried. It's a completely normal process. The only thing to pay attention to is the track record of these guys -- if they're mostly right, then they might have a good intuition when it comes to new tech.
I worked with one of those, pushing Silverlight non-stop, it was like a year after it had been announced MS was dropping support for it. He was baffled when I told him.
I know many more examples of decade-old, poorly designed not-invented-here-driven projects slowing velocity to a crawl. Teams adapting tools that are considered state-of-the-art in their field saves you from that road. Obviously you still have to make sane architectural decisions. The author misses the point, it's not at all about hype, it's about making uninformed decisions. They can be made about new or old technology.
It's not about hype, it's about understanding how stuff works.
True, you often see people jump into a new technology without understanding the tradeoffs and the implications.
However, a lot of people don't have a deep understanding of the non-hype systems either. Seems to me everybody expects SQL dbs to guarantee serializable isolation every time and everywhere, for example.
So many small/medium sized companies are obsessed with re-writing everything without even realizing that re-writing something from scratch is probably the worst business decision that can be made.
I think all of this serves to highlight how valuable information technology is right now. People can get away with massive inefficiencies, producing tons of garbage code, not-invented-here habits, horrible performance, and still run a profitable company. I agree that hype-driven development is bad, but instead of complaining about it, just don't do it. Run circles around those who do.
I have my own theory about why hype-driven development is prevailing: it's social signaling. Probably none of the hyped up stuff is as good as they claim, but nothing is cool without hype. It's a good way to attract younger developers in job postings, who lack the experience to evaluate their own career decisions.
I'm also not sure about the solutions proposed. Spikes and hackathons are useless if it's already determined that a hyped technology will be used, then it just serves as a training exercise. A strong technical background and experience comes with age, and this industry is heavily biased against older programmers.
> This is absurd. Do you do everything your boss tells you to?
Ultimately, if I want to keep collecting paychecks, I kind of have to. You can only push back on dumb ideas so much, sometimes you have to let some of the less dangerous ones through, or you get labeled as the cranky pessimist douche.
Because old solutions are so old and boring. I've built programs with J2EE, I wrote those XML files. Nothing wrong with that, this stuff works. But it's so much better to write 2 lines of Kotlin code running a top of Netty instead. Yes, it's very immature and new. But having fun is essential in my work. If I'm getting bored, I won't work, simple as that. I could be a uber driver, if I wanted boring work. Some people are just boring money makers without any passion. Nothing wrong with that, but not everyone is like this.
> If I'm getting bored, I won't work, simple as that. I could be a uber driver, if I wanted boring work.
This is big problem in the "new economy" of automation. Some people want "boring" jobs and those are disappearing, some people want "stimulating" jobs and there's not enough of them or at least the threshold is too high to get such jobs.
I think all he's saying is that there are jobs that you can solve either with JEE & XML or with Kotlin, and that for those choosing Kotlin is often the more efficient thing to do.
I'm more in the Spring camp, but most of JEE is annotations based. You can put a Betty backing under it without much problem. Spring Boot does it even more readily.
I'm not saying that Kotlin is bad, but most things are now pretty equal. Java 8 has functional/OO hybrid. It has annotations. It has modern tooling that converts the boiler plat into a few keystrokes.
Fair enough. I've been absent from the Java ecosystem for quite a while, so have no opinion or anecdata to share. It's good to hear though that there are multiple, sane options available to get stuff done.
So true. Add Angular to the list. I would say, as a rule of thumb, if your team is not 5+ developers, don't bother using a framework. Because small team usually get small projects.
From the average HN stories and comments over the last few years, this was the common path, and migration steps.
So I agree with the blog post in general (not the details). Instead of running from one hyped tech next and rewrite your stack constantly as a side-effect.
I value educated decisions and more long term thinking. Using Javascript and copy&pasting some functions from JQuery and other libraries to build one own/company little library/framework that suits the task might be a better idea. In the end the tech behind popular framewoks is often pretty simple and just a few lines of code. The hundreds of opinionated API corset around is what makes it hard to refactor and migrate later.
There's one more and one much bigger: we need to scale our database horizontally and it's bastard cousin, we need the cloud to scale. Truth is, most applications are fine with a single box (OK, two because of HA but the second is just a hot spare). Remember https://twitter.com/garybernhardt/status/600783770925420546
> Consulting service: you bring your big data problems to me, I say "your data set fits in RAM", you pay me $10,000 for saving you $500,000.
Today it costs less than $600 a month to rent a 256GB dedicated box w/ 2x450GB NVMe disks and a 10 gbit private connection. And, of course, there are ways to go higher but it's very likely it'll be a bit more expensive per terabyte RAM but you'd be surprised (or not) at just how many problems actually fit in a quarter terabyte of RAM.
Yes, I was thinking of OVH, specifically https://www.ovh.com/us/dedicated-servers/infrastructure/170e... this one. Hetzner has one much, much cheaper https://www.hetzner.de/ot/hosting/produkte_rootserver/px121s... . But if you want to get feature parity, you'll need to factor in the additional 10 gbit card cost for 45.38 EUR arriving to a 174 USD monthly cost and the once off cost of a 12 port 10 gbit switch for 839.50 EUR. In five months the Hetzner server will be cheaper and keep going and also adding web frontends is cheaper there as well, the old but totally servicable Intel Xeon E3-1245 V2 16GB servers are below 35EUR.. But, I didn't want to get into that much detail.
Well at least some time ago this site ran on a single box.
My company has a Magento webshop. The amount of money thrown at it to keep it 'fast' is amazing.
Wish they trew it at me to build a fast webshop. Unfortunately they think Magento is the standard.
No, I mean only the database. You might or might not get away with the app also running there but most of the time some load balanced 2-3 small frontends will give you much better buck for your money.
My manager told us $200/month was too expensive, so we micromanaged those $10 VPSs. We've reached the limits of that in some way. Instead of testing my original suggestion, my manager wanted to contract a company to move us to AWS. Our first AWS bill, for effectively zero usage and just a dev environment, includes $500/month for "NAT Gateway Hours".
My fundamental problem with this is that the steps he outlines are identical to the steps involved in successful adoption of game-changing technology, until we hit the "It's too late" phase. Indeed, whilst sometimes a technology just plain isn't ready for prime time, sometimes it's just the wrong tool for the job.
135 comments
[ 3.2 ms ] story [ 181 ms ] threadReactJs is a great way to write software. I'm far too time poor to waste my time on "being cool". I choose best of breed development tools that are well supported and allow me to be highly productive.
Only a fool would suggest that ReactJs is simply a hype trend like s new hairstyle.
I guess this article is trying point out how people chose things based on hype but fails to understand the difference between choosing X because of hype vs. choosing X because it suits your needs.
Having state both in the front-end and in the back-end multiplies the complexity of any project, and the gains are only worth if you are (or you have) a good UI designer.
For the rest, the good'ol Rails + Turbolinks, jQuery and SJR can do a fantastic job, without having to think about synchronizing several sources of truth.
To paraphrase Peter Hellier: if you stopped using extra words when one will suffice, maybe you wouldn't be.
Although it is true that microservices approach is flawed if it doesn't feet the organizational structure. But the same applies for the different new tools. Do the due diligence and figure out whether it fits before jumping straight into development.
I some months ago, they asked me to join a new team because they needed help with React and, although my main technology is RoR, I quite like JavaScript.
What I found is that the last developer shoved 2500 lines React, Redux and Typescript in a Rails application just to make a sortable and filterable table!! Apparently, after perpetrating this atrocity, he updated his resumée and found a job in another company.
I really think that it is good to have a grumpy senior developer in each team stopping those things from happening.
Developers want to do new things, partly out of boredom, partly out of fear of becoming stale. Non-technical business managers have no idea of the consequences of "using Elixir instead of Java" or "Microservices instead of Monoliths" so they just nod and go along with it.
Eventually, developers get tired of having to pull all-nighters that could have been avoided by using more simple solutions. Then you have a bigger pool of 'experienced developers' who prioritise stability over fashion.
So the industry is becoming more stable and less hype-driven, but it will take a long time to get there. We need to learn lessons from other crafts and industries, like factory production and carpentry.
IMHO the ultimate source of instability is that we deal with pure thought-stuff that has very little internal constraint except at the interfaces. Other engineering is quickly constrained by materials, biology and physics but for us, any idle thought can become our reality. The faster we can communicate and the faster we can build, the faster the iteration.
We can achieve much the same ends in any number of different styles and paradigms. The primitives for a programmer have more to do with poetry, memes, fashion and the creative end of pure math than physical systems. There can be no assumption of convergence. The pull of a social group will crush the technical excellence of an out group.
I've rarely met devs with more than 20 years of experience that would buy into any hype. OTOH it the most hype-y conferences I've been to the average level of experience seemed to be... between 0 and 2 years.
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.
But people need to stop posting this garbage and dismissing their legitimate choices as "hype".
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.
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.
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.
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.
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.
If the state of art of your development cycle is refreshing the browser, check out hot reload.
[0] Should not.
That's exactly what hype is: not using enough critical thinking and trusting developers of popular technologies.
"The big rewrite" is usually a response to technical bankruptcy, which is when technical debt and interest is too high to be repaid.
I don't think microservices, react, functional programming or no sql are examples of 'hype'; I think those are good engineering decisions (depending on the problem domain).
I also completely disagree that hackathons are good places to try out new technologies to see what's good for good engineering decisions; hackathons let you dip your fingers in the water and see the shiny cool bits and pieces without having to suffer through any of the long term maintenance or scale issues with the technologies. If you're looking for a bad decision, picking something to run with that 'seems pretty good' after a 2 day hackathon <--- that's your bad decision right there.
I mean, I get what the article is saying, yeah yeah, avoid the hype, don't drink the 'webscale' cool-aid...
...but hey, the internet is full of really talented smart people who do excellent engineering work.
You'd be stupid to not look at what the best and most successful companies in the world are doing with their engineering teams and take note of it.
Even if it means picking up new technology: that's not bowing to the hype; it's being pragmatic.
Still, it's super easy to cherry pick some things and go, oh hey, this is a bad idea. Much more interesting would be some examples of good engineering choices.
The "depending on the problem domain" seems another variant of "choose the right tool for the right job". One could probably add "for the right reason" on the end of that instruction too, and it wouldn't hurt.
The problem is the ability to determine "the right tool" and "the right job" - many people simply don't have it. You only get that ability through experience. With new tools few people - even older folks - have enough experience with the tool in question to make accurate/useful assessments.
> but hey, the internet is full of really talented smart people who do excellent engineering work.
And it's full of even more people who aren't really capable of making those assessments accurately.
> You'd be stupid to not look at what the best and most successful companies in the world are doing with their engineering teams and take note of it.
You'd be stupid to think that because "Facebook" (or "Amazon" or "Google" or "MS") is using a particular tech stack (which, likely, teams of internal people contributed to for months), it's a great fit for your problem, or your skills, or your team's skills, or your project's timeline, or its budget. Few people have the problems or demands that Facebook/Amazon/Google/etc have. It's great that they share some of their internal tech, but that sharing isn't an automatic determination that their solutions are appropriate fits for your problems.
Ok, if what the smartest and best people are doing isnt the right solution for my problem, what is?
Come on; enough vague hand waving. How do you pick the right tech to use then?
In my experience the choice of the right tech is primarily a business decision rather than a technical one. By that I mean it should be based on a number of factors external to the technology. Once you have clearly identified the business problem you are trying to solve, you have to think of the solution in terms of risk. For example, what is the up-front development risk? What are the maintenance risks?
Every project exists within a certain environment with its own set of constraints. Picking the right solution means understanding these and doing so from the point of view of the business.
If you understand the risks and constraints, and you put the needs of your end-users, the systems administrators, the testers, and the business first you will rarely go off-track.
Of course, there's the opposite extreme too, where long time team members and management ivory-tower themselves to micromanage every tech choice and then prescribe it throughout an organisation without much input.
Obviously only what "the smartest and best people are doing" to solve problems that are isomorphic to yours.
But first you also need to identify those people: who said those in the big companies (or smaller with better bloggers) are the "smartest and best people"? Just because they belong to a succesful company? And because they have degrees from some top-tier university?
The company could be succesful despite of its technology, on the business value alone (which usually is how it is), and the people with "good degrees" could just be architecture astronauts or fresh amateurs who re-invent long buried concepts because they don't know better.
There's a whole long distance between what the current industry champions as "best minds" (some 20 year old with 2 years of JS that created the framework du jour) and people like Knuth, Alan Kay, Kernighan, Richie, Bill Joy, and the like...
As it turns out, moving fast and breaking things isn't all that conducive to quality engineering[1][2]. Facebook has a massive legacy code base maintained by an enormous team that is under pressure to iterate quickly while supporting what is arguably the world's largest user base. They are dealing with extremely specialized constraints that most of us will never encounter. Many of the trade-offs they consider acceptable aren't trade-offs that make sense elsewhere.
And that's exactly what the blog post is getting at. A lot of these emerging technologies are situationally useful in a particular set of scenarios and environments, but developers with cargo cult mentality convince themselves that these things will solve all of their problems if they use them everywhere. When the disappointment sets in and they figure out that isn't the case, yesterday's darling stack becomes the subject of today's "considered harmful" essays and everybody moves on to the next shiny thing.
The point here is that maybe you should make a sober assessment of new technologies and objectively evaluate whether they are actually practical for your usage scenario rather than just blindly jumping on the bandwagon and using something.
The examples from the blog post are totally on point. I previously worked at a company that built a NoSQL database and I have great affinity for the technology, but there's no question that too many people adopted NoSQL databases without really understanding the trade offs. People want to be "web scale" so they go straight to using databases that are designed for high-availability clustering even when they are building applications that would be perfectly fine running forever on a single postgres instance.
[1] https://www.darkcoding.net/software/facebooks-code-quality-p... [2] http://blog.timac.org/?p=1707
Hype does not mean that a popular technology should never be used. It's when people overrate and overuse it and try to apply it to the wrong domain.
The examples are spot on.
Ppl had no idea about relational databases and thought that's a good case for not using them.
But thankfully we have some no-name developer to save us from all of these mistakes. No use cases for NoSQL. Give us a break.
>we have some no-name developer to save us from all of these mistakes.
Both rude and fallacious. Do you presume that every employee at a successful firm is a wunderkind? Do you actually know the level of talent of every HN poster?
> I mean, I get what the article is saying, yeah yeah, avoid the hype, don't drink the 'webscale' cool-aid...
I feel like you're shooting right past the author's point here. What he's saying is that hype, as in the shared excitement, obscures the actual tradeoffs involved in adopting the new technology, and makes it harder to make good engineering decisions.
I'd like to add that it also obscures the available alternatives - simple and straightforward ways to configure / extend existing technologies to have the same behavior / features as that shiny new thing.
And it's not even about what you know ahead of time. I was actually thinking about this earlier today: I often recognize some of the tradeoffs of adopting a new tech early on, but my judgement still often ends up clouded by enthusiasm.
A common pattern of rationalization I often have goes like this:
"Sure this old thing can be used to do the same as this new thing by using functions X,Y,Z, but this new thing lets you do it with just one function. I mean sure, I could write that function myself in about 10 lines, and I only need to do this once for each project, but this is just easier."
I'm not saying that this reasoning is wrong, only that it is biased.
Tradeoffs of a technology, and therefore knowing in which problem domain they are most appropriate, consist of both pros and cons.
The problem with hype isn't that the technology being hyped is not excellent in its own way, the problem is that (psychologically) hype leads us to ignore the cons, to rationalize them away - and this means we're not really fairly considering the tradeoffs.
The author isn't saying that microservices, react, Elixir, NoSQL, etc don't have upsides, but only that (if we are not extra careful) we might not be considering the tradeoffs and alternatives as pragmatically as we think we do.
Obviously you should not use a technology without understanding it. Does this really require a discussion? No one is on the other side. But going "Well that technology is just hype" isn't understanding it, it's dismissing it.
Let's not pretend like there's a single technology out there that isn't constantly under fire.
If you strip out the strawman argument against each technology ("Let me tell you a story about how this technology didn't work in my imagination") you end up with one single premise - do research before adopting tech. Did you need to be told that? I think if one single person is making tech stack decisions in production and no one is going "uh can you justify this" you have far more serious issues.
From the author of Redux: https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
From the official React docs: https://facebook.github.io/react/contributing/design-princip...
> You'd be stupid to not look at what the best and most successful companies in the world are doing with their engineering teams and take note of it.
I think you're both saying the same thing. People should look at what others are doing, and analyze the suitability to their own use case. I think this is exactly what people do. I've never seen a tool choice postmortem that concluded, "well we only chose it for hype, and that was stupid". It's always a specific thing that you thought would work better than it did.
For example, I came away from a project quite burned by Angular 1.x. It wasn't that we chose it because of hype that it was a poor choice, it was that the directive system did not make it as easy to build modular components as initial prototypes suggested it would be. React was then interesting to us (though we never pursued it on that project), not because of upvotes on HN, but because it scratched that itch better.
I guess I just don't see this wild hype cycle that everyone complains about - I just see people trying to scratch itches they have, sometimes making the right choice, and sometimes making the wrong choice.
It's actually not. It's full of average people who do mediocre engineering.
The two are orthogonal. Hype is a marketing force which can be used to tout good and bad stuff.
Teams can just as well adopt a good product if its hyped. That doesn't mean their adoption process was based on a "good engineering decision". Just that they lucked onto making one.
That said, I find "microservices" or "no sql" as more hype than substance in the domains that most teams apply them. They just reimplement (poorly) a ton of stuff that a monolith or sql would already have, and don't really need either for their use case.
This point from the article however, I agree is a bad example.
> Example 2: TDD is dead by DHH
The 37signals guys if anything are some of the realest in terms of low fidelity tools and sensible abstractions and building things simply. They've even written two books about their approach to business and web app development (Rework, Getting Reals). Maybe there is concentrated hype around Rails but in general their stuff is well informed and well thought out.
Amazon has (or had) a culture of encouraging criticism (as long as it's supported by reasonable explanations) to the point of harshness and this was quite effective at stopping hype.
Grumpy engineers loved it, starry-eyed ones got hired elsewhere.
And sometimes constructive criticism is mistaken for hype and shunned by the management, you would hear: we always done it this way, why choose this new technology that might break things; so you have companies that are still using COBOL on the mainframes and don't see anything wrong with it, as well as store user passwords unencrypted.
Except that this is how new technologies get introduced and tried. It's a completely normal process. The only thing to pay attention to is the track record of these guys -- if they're mostly right, then they might have a good intuition when it comes to new tech.
True, you often see people jump into a new technology without understanding the tradeoffs and the implications.
However, a lot of people don't have a deep understanding of the non-hype systems either. Seems to me everybody expects SQL dbs to guarantee serializable isolation every time and everywhere, for example.
So many small/medium sized companies are obsessed with re-writing everything without even realizing that re-writing something from scratch is probably the worst business decision that can be made.
Everything old is bad.
Finding the middle way is hard and makes you sad.
I have my own theory about why hype-driven development is prevailing: it's social signaling. Probably none of the hyped up stuff is as good as they claim, but nothing is cool without hype. It's a good way to attract younger developers in job postings, who lack the experience to evaluate their own career decisions.
I'm also not sure about the solutions proposed. Spikes and hackathons are useless if it's already determined that a hyped technology will be used, then it just serves as a training exercise. A strong technical background and experience comes with age, and this industry is heavily biased against older programmers.
...until employers start asking you to work on every buzzword of the month.
> A strong technical background and experience comes with age
No. You can be aware or unaware of hype at any age and experience.
This is absurd. Do you do everything your boss tells you to?
It's incredible that some employers survive long enough to chase the next fads, which only proves my point.
Ultimately, if I want to keep collecting paychecks, I kind of have to. You can only push back on dumb ideas so much, sometimes you have to let some of the less dangerous ones through, or you get labeled as the cranky pessimist douche.
This is big problem in the "new economy" of automation. Some people want "boring" jobs and those are disappearing, some people want "stimulating" jobs and there's not enough of them or at least the threshold is too high to get such jobs.
I'm not saying that Kotlin is bad, but most things are now pretty equal. Java 8 has functional/OO hybrid. It has annotations. It has modern tooling that converts the boiler plat into a few keystrokes.
1) JQuery/JqueryUI
2) handlebars/mustache
3) Ember/Angular v1
4) React/Vue/Angular v2
From the average HN stories and comments over the last few years, this was the common path, and migration steps.
So I agree with the blog post in general (not the details). Instead of running from one hyped tech next and rewrite your stack constantly as a side-effect.
I value educated decisions and more long term thinking. Using Javascript and copy&pasting some functions from JQuery and other libraries to build one own/company little library/framework that suits the task might be a better idea. In the end the tech behind popular framewoks is often pretty simple and just a few lines of code. The hundreds of opinionated API corset around is what makes it hard to refactor and migrate later.
> Consulting service: you bring your big data problems to me, I say "your data set fits in RAM", you pay me $10,000 for saving you $500,000.
Today it costs less than $600 a month to rent a 256GB dedicated box w/ 2x450GB NVMe disks and a 10 gbit private connection. And, of course, there are ways to go higher but it's very likely it'll be a bit more expensive per terabyte RAM but you'd be surprised (or not) at just how many problems actually fit in a quarter terabyte of RAM.
Any recommendations on how you'd go about that? I'm currently paying Digital Ocean that much for a way crappier instance...
Well at least some time ago this site ran on a single box.
My company has a Magento webshop. The amount of money thrown at it to keep it 'fast' is amazing. Wish they trew it at me to build a fast webshop. Unfortunately they think Magento is the standard.