And I like that the author picked some favorite frameworks and tools without disparaging the alternatives too much. I disagree with his conclusions about Angular and React, but he didn't get hung on up the criticism - one sentence about each before moving on.
When you have the freedom to choose your entire stack, it's good to pick ones that you enjoy using - so long as they can solve the problem you're working on.
Agreed. I almost didn't read it because I thought "Ugh, one of those flamey everything-sucks posts again". But I was surprised at how positive and short it is.
I mean, I disagree with the authors' conclusions about Angular and React, but he wrote one negative sentence about each and then moved on. I can live with that.
Also, when has this sort of issue ever been an actual material problem? Like, we wrote our app with Django (or whatever) and then got in actual trouble because of it. I find this argument against React very suspicious.
If it's anything like the bigcorps where some of my friends work, or even medium sized companies where I've worked in the past:
The patent clause is the React license probably isn't a problem. Probably. But in a conservative bigcorp, probably isn't good enough. If you're a decision maker, you want to be certain. You want this certainly because you have to cover your ass, because it's your ass that's on the line on the off chance it becomes a problem. Or even if you end up under a manager who dislikes you for some reason, or no reason at all - they might see the license, and question your judgement for exposing the company to potential liability. Or maybe they don't even dislike you, but decide that questioning you would be a good power play that would make them look good to their superiors.
So if you wanted to use React, you have to clear it with the legal department first. And if you're at the kind of bigcorp when you've ended up in this situation, you're at the kind of bigcorp where clearing something like this with legal is a bigger pain than it's worth. And so you just choose Angular, or Vue, or Aurelia. All of which will probably meet your needs.
But the project will still fail because the department you're making the app for gave you terrible specs, and you made what they asked for instead of what they actually needed.
So I'm not a lawyer, but that's a story about how that clause in the React license can be a problem even if it isn't a legal problem.
The “React license” is https://github.com/facebook/react/blob/master/LICENSE
It is ust 3-clause BSD and doesn’t even include the word “patent”. In addition to the license, Facebook also provides a patent grant. Any company or organization could release code under 3-clause BSD and not bother with the additional patent grant. However, Facebook did bother with the additional patent grant, which seems to confuse people.
I just meant that the presence of the PATENTS file is sufficient to cause doubt in the minds of decision makers at certain types of bigcorps. These projects are never going to release their code under any license. They're more concerned about what the patent grant means if they use React at all.
It might not seem entirely rational, but in some circumstances, in risk-averse companies, it's enough to sway the decision away from React.
I don't work at such a company, nor would I choose to! :)
The author advocates "serverless" from the get-go because a "single server is not enough for anything non-trivial these days".
I completely disagree. Servers are beefier than ever and scaling up has never been cheaper.
Look at how StackOverflow operates:
https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar...
They have 4 SQL servers that handle 500 million queries per day. 125 million queries per server. There are a lot of apps that can get by with less than 125 million queries per day :)
Opinion-based, factless essays like this are why webdev is such an unmitigated cesspit. Some random person on Medium proclaims "Angular has already lost to React no matter how hard google tries to hide it, React has a really dangerous license rendering it obsolete for serious enterprises and Vue.js is mainly driven by a single genius developer (high bus factor)", pieces of cargo-cult gossip that mixes half-truths with generous loads of alarmist ignorance, and attempts to distill it down to absolutes under the guise of providing a public service.
By the time we get down to "backend", I have no idea what the author is trying to say, and whether it's actual advice or pent-up frustration bubbling up into resigned cynicism. We namedrop a framework for good measure.
If we collectively chose to interpret articles like this as satire, they'd provide more value by highlighting the fallacies that lead to the propagation of opinionated (but unfounded) information.
I don't mind this one because at least it is clear that it's an opinion piece. Reminds me of the good old days of blogging where writing what you think was what it was all about.
I mostly dislike posts that try to pass off opinion as incontrovertible fact. I disagree with the author's opinion about Angular and React, but I didn't feel as though he was trying hard to persuade me to agree.
"Angular has already lost to React no matter how hard google tries to hide it, React has a really dangerous license rendering it obsolete for serious enterprises and Vue.js is mainly driven by a single genius developer (high bus factor)"
I moved from webdev a couple years ago so this is a helpful article on the current meta, but I disagree with this:
> All this stuff [managed NoSQL document databases] is way easier to grasp than the old days of PHP, MySQL and jQuery plus Linux server management.
Even though you can say "Javascript [is] everywhere", I still think using it for frontend/backend/NoSQL has just as much problematic context switching as the MySQL/PHP/JQuery days.
It's 2017, but I would still not write a backend in JavaScript - nor would I rely on a NoSQL database for all but the simplest of applications (and then I would still use Postgres). I would also contend that MySQL (read: relational databases in general) and even Linux server management are within reach of most good developers.
Which seem to be in a dire need in the face of more and more "entrepreneurs" seeking to "disrupt", "change the world", etc. (read: make quick cash from nothing ideas) and start nonsense start ups based on nonsense ideas. And to add insult to injury, hire talentless hacks for cheap, calls them "developers" and lets them "develop" "apps" for platforms they should have no place at all touching.
> Angular has already lost to React no matter how hard google tries to hide it
Hmmm... really? I've only been out of the web dev game for a couple of years. Angular was alive and well in 2015. I guess 2 years is ancient history in Web.
Alright so, React then?
> I vastly prefer Vue.js, since it feels like the next-generation...
Oh.
I wonder what its like to be a beginner web developer in 2017. It actually seems harder to pick a reliable, maintained, stable framework, than it is to actually develop the software on it.
It's an accepted reality in the web world. Pick currently trending framework X which does [A,B,C] amazingly, write some "app" in it. Then comes framework Y, which reinvents how [B,C] are performed, is so much better and it's now laughable that you are using framework X (to the point web "devs" won't work in your company since you are using _outdated_ 1-2 years old framework X, so you rewrite all of your "app" in framework Y. Then comes framework Z, which reinvents how [A,C] are performed ...
Rinse and repeat.
Web "dev" is such an amazing prospect. Let's use those amazing technologies and mindsets to "develop" mobile and desktop "apps". What could possibly go wrong?
>But one server is barely enough for anything nontrivial nowadays
If I facepalmed any harder, my hand would go through my face. A properly setup server, with caching and a backend not written in node, will go a hell of a long way. You can scale to tens of thousands of concurrent users with a single server.
Spoiler: your startup will most likely not even scale up to that level.
These posts are stuck in a tiny little world, made up of hackernews and what is currently hyped on hackernoon and smashing magazine. In the reality, JS still hasn't won, IIS is still powering half of the servers, and Java is still winning. Javascript has gotten better, and if you use Typescript it even becomes a good language. There are certainly some very good things that came out of it (and some very, very dumb wheel reinvention), and I dare say there is not a single UI toolkit that gets close to Vue/React, thanks to the composability and CSS being good enough for theming. Animations are still a major pain point. Serverless will cost you an awful lot past the beginning point, much more so than renting servers, or even having them on-place and paying sysadmins when you are at that stage between medium and big.
While being optimist and non-flamey, which is a good read, it is also a sad state of affairs. The backend, database and "native" side of things boils down to "I don't understand servers, I don't understand databases, I don't understand that bringing a browser along with my application is a bad thing.". I get it. We are asked to push ot feature after feature after feature. But it is genuinely holding everyone back. It's making our software worse. Electron applications are a 15 years jump back in the past, except that they look pretty.
> A properly setup server, with caching and a backend ...
Which needs a dedicated sysadmin/ops person to maintain and the cost of finding, acquiring, training, and paying their salary and benefits is less than just outsourcing it to AWS.
A single m4.16xlarge on AWS is at the very least $2200 per month. That doesn't even include storage costs. Depending on your country, that definitely pays for an already trained sysadmin. Also, some stuff just cannot be put onto AWS. I worked with financial, medical data, it just doesn't go on AWS. Especially since the datacenters are very likely not in your country.
> Your users nowadays do not accept high loading times, require interactive hand-holding immediately and have quite powerful smartphones to access online stuff instead of desktop computers
Maybe in the valley or half US but the rest of the world we are stuck with bad internet coverage, bad internet speeds and decent but yet not fast ones smartphones since not everyone use iOS, most people have Android based smartphones which are well know to have the worst JS runtime of the ecosystem.
> Also the “App” model is on the decline, since users want to access content immediately without cluttering their phones with apps they never use again. You can already see where this is leading: Single Page Applications (SPAs).
This... come on guys not because "we can" build everything on SPAs means "we must" build everything with it, please don't built SPAs just because its fast but because you actually need to built one, don't be part of the crowd that finds "AMP Optimized page" reasonable.
> Opinionated TL;DR: Just go serverless for your backend needs and be done before others have figured out how to start.
Please don't... don't add monthly infrastructure costs until you actually need to scale, half the projects we built don't get the same traffic as Facebook.
> As a language itself, Javascript used to suck. hard. And today: mostly still sucks
Amen.
> It’s also no coincidence that these “cloud developers” are called “solution architects”, since they’re going straight to solutions instead of circlejerking nerd-porn-topics like scaling, syntax and performance
It's funny because half the article he is talking about how JS-backed tech is better for scaling, has better syntax and performance and now suddenly talking about those topic outside JS m circlejerking, come on...
Basically another "everything sucks except for NodeJS and a JS framework" piece. Reality is that most business stacks these days aren't going to be written in pure JS. If you do see Node or some framework on the frontend it's probably going to be isolated from the really ugly but highly functional backend.
This is truly a shit article, in almost every respect, but especially with the extremely facile analysis of frameworks, languages, server architecture (see Stack Overflow's setup).
The bias the author has as a javascript fanboy / prototyper is very obvious to me.
31 comments
[ 4.2 ms ] story [ 84.6 ms ] threadAnd I like that the author picked some favorite frameworks and tools without disparaging the alternatives too much. I disagree with his conclusions about Angular and React, but he didn't get hung on up the criticism - one sentence about each before moving on.
When you have the freedom to choose your entire stack, it's good to pick ones that you enjoy using - so long as they can solve the problem you're working on.
You may find both helpful.
The patent clause is the React license probably isn't a problem. Probably. But in a conservative bigcorp, probably isn't good enough. If you're a decision maker, you want to be certain. You want this certainly because you have to cover your ass, because it's your ass that's on the line on the off chance it becomes a problem. Or even if you end up under a manager who dislikes you for some reason, or no reason at all - they might see the license, and question your judgement for exposing the company to potential liability. Or maybe they don't even dislike you, but decide that questioning you would be a good power play that would make them look good to their superiors.
So if you wanted to use React, you have to clear it with the legal department first. And if you're at the kind of bigcorp when you've ended up in this situation, you're at the kind of bigcorp where clearing something like this with legal is a bigger pain than it's worth. And so you just choose Angular, or Vue, or Aurelia. All of which will probably meet your needs.
But the project will still fail because the department you're making the app for gave you terrible specs, and you made what they asked for instead of what they actually needed.
So I'm not a lawyer, but that's a story about how that clause in the React license can be a problem even if it isn't a legal problem.
I just meant that the presence of the PATENTS file is sufficient to cause doubt in the minds of decision makers at certain types of bigcorps. These projects are never going to release their code under any license. They're more concerned about what the patent grant means if they use React at all.
It might not seem entirely rational, but in some circumstances, in risk-averse companies, it's enough to sway the decision away from React.
I don't work at such a company, nor would I choose to! :)
They have 4 SQL servers that handle 500 million queries per day. 125 million queries per server. There are a lot of apps that can get by with less than 125 million queries per day :)
By the time we get down to "backend", I have no idea what the author is trying to say, and whether it's actual advice or pent-up frustration bubbling up into resigned cynicism. We namedrop a framework for good measure.
If we collectively chose to interpret articles like this as satire, they'd provide more value by highlighting the fallacies that lead to the propagation of opinionated (but unfounded) information.
I mostly dislike posts that try to pass off opinion as incontrovertible fact. I disagree with the author's opinion about Angular and React, but I didn't feel as though he was trying hard to persuade me to agree.
"Angular has already lost to React no matter how hard google tries to hide it, React has a really dangerous license rendering it obsolete for serious enterprises and Vue.js is mainly driven by a single genius developer (high bus factor)"
> All this stuff [managed NoSQL document databases] is way easier to grasp than the old days of PHP, MySQL and jQuery plus Linux server management.
Even though you can say "Javascript [is] everywhere", I still think using it for frontend/backend/NoSQL has just as much problematic context switching as the MySQL/PHP/JQuery days.
Which seem to be in a dire need in the face of more and more "entrepreneurs" seeking to "disrupt", "change the world", etc. (read: make quick cash from nothing ideas) and start nonsense start ups based on nonsense ideas. And to add insult to injury, hire talentless hacks for cheap, calls them "developers" and lets them "develop" "apps" for platforms they should have no place at all touching.
> Angular has already lost to React no matter how hard google tries to hide it
Hmmm... really? I've only been out of the web dev game for a couple of years. Angular was alive and well in 2015. I guess 2 years is ancient history in Web.
Alright so, React then?
> I vastly prefer Vue.js, since it feels like the next-generation...
Oh.
I wonder what its like to be a beginner web developer in 2017. It actually seems harder to pick a reliable, maintained, stable framework, than it is to actually develop the software on it.
Rinse and repeat.
Web "dev" is such an amazing prospect. Let's use those amazing technologies and mindsets to "develop" mobile and desktop "apps". What could possibly go wrong?
If I facepalmed any harder, my hand would go through my face. A properly setup server, with caching and a backend not written in node, will go a hell of a long way. You can scale to tens of thousands of concurrent users with a single server.
Spoiler: your startup will most likely not even scale up to that level.
These posts are stuck in a tiny little world, made up of hackernews and what is currently hyped on hackernoon and smashing magazine. In the reality, JS still hasn't won, IIS is still powering half of the servers, and Java is still winning. Javascript has gotten better, and if you use Typescript it even becomes a good language. There are certainly some very good things that came out of it (and some very, very dumb wheel reinvention), and I dare say there is not a single UI toolkit that gets close to Vue/React, thanks to the composability and CSS being good enough for theming. Animations are still a major pain point. Serverless will cost you an awful lot past the beginning point, much more so than renting servers, or even having them on-place and paying sysadmins when you are at that stage between medium and big.
While being optimist and non-flamey, which is a good read, it is also a sad state of affairs. The backend, database and "native" side of things boils down to "I don't understand servers, I don't understand databases, I don't understand that bringing a browser along with my application is a bad thing.". I get it. We are asked to push ot feature after feature after feature. But it is genuinely holding everyone back. It's making our software worse. Electron applications are a 15 years jump back in the past, except that they look pretty.
Which needs a dedicated sysadmin/ops person to maintain and the cost of finding, acquiring, training, and paying their salary and benefits is less than just outsourcing it to AWS.
Maybe in the valley or half US but the rest of the world we are stuck with bad internet coverage, bad internet speeds and decent but yet not fast ones smartphones since not everyone use iOS, most people have Android based smartphones which are well know to have the worst JS runtime of the ecosystem.
> Also the “App” model is on the decline, since users want to access content immediately without cluttering their phones with apps they never use again. You can already see where this is leading: Single Page Applications (SPAs).
This... come on guys not because "we can" build everything on SPAs means "we must" build everything with it, please don't built SPAs just because its fast but because you actually need to built one, don't be part of the crowd that finds "AMP Optimized page" reasonable.
> Opinionated TL;DR: Just go serverless for your backend needs and be done before others have figured out how to start.
Please don't... don't add monthly infrastructure costs until you actually need to scale, half the projects we built don't get the same traffic as Facebook.
> As a language itself, Javascript used to suck. hard. And today: mostly still sucks
Amen.
> It’s also no coincidence that these “cloud developers” are called “solution architects”, since they’re going straight to solutions instead of circlejerking nerd-porn-topics like scaling, syntax and performance
It's funny because half the article he is talking about how JS-backed tech is better for scaling, has better syntax and performance and now suddenly talking about those topic outside JS m circlejerking, come on...
The bias the author has as a javascript fanboy / prototyper is very obvious to me.