Why developers need to be able to identify technologies with staying power(medium.com)
medium.com
Why developers need to be able to identify technologies with staying power
https://medium.com/netlify/leveling-up-why-developers-need-to-be-able-to-identify-technologies-with-staying-power-and-how-to-9aa74878fc08
57 comments
You nailed it, I'll pick up the technology, but then get stuck in some silly bug which I can't find the solution to and abandon it after getting frustrated.
But that's actually the work: getting stuck, sticking with it, and reasoning your way out of being stuck. That's programming.
Fair enough if you avoid certain situations because this is where you end up -- I do the same thing -- but the work is the work whether it's a new language or some oddball patch/upgrade that made things act funky in ways they didn't before.
Fair enough if you avoid certain situations because this is where you end up -- I do the same thing -- but the work is the work whether it's a new language or some oddball patch/upgrade that made things act funky in ways they didn't before.
There is a difference between learning a system and getting stuck on some configuration detail. It's very frustrating when you want to understand a system and you're stuck with some error which is not your fault, but it's some bug in the new technology and instead of learning the technology you spend time with hunting some configuration bug.
That won't help you learning the technology, because that bug will be fixed in some configuration script and later users won't even encounter it, because the tooling will generate the proper scripts for the first time. So it's often not that kind of knowledge which proves to be useful later, but some implementation detail which you won't ever encounter again.
That won't help you learning the technology, because that bug will be fixed in some configuration script and later users won't even encounter it, because the tooling will generate the proper scripts for the first time. So it's often not that kind of knowledge which proves to be useful later, but some implementation detail which you won't ever encounter again.
This is roughly my litmus test: Do I see a lot of examples of people running into problems, and the solution turns out to be an obscure configuration (or worse, a case where the default configuration is something that should never be done)? Do I see evidence of a lot of cases where the right way to do things is not the obvious way to do things?
Both of these are red flags. Sure, I can learn how to steer around all the potholes. But so will everyone else who works on the project. Eventually someone will miss some important detail, or go on a refactoring expedition and end up removing a bunch of what appears to be excess complication but is actually a carefully constructed workaround for some wart in the system (the comment explaining this having long since been deleted - or maybe migrated to the team wiki, where all good information goes to die - by someone who had been watching a lot of Uncle Bob videos on YouTube at the time), and then production bugs sneak in, and eventually people quite rationally start to blame the technology.
Both of these are red flags. Sure, I can learn how to steer around all the potholes. But so will everyone else who works on the project. Eventually someone will miss some important detail, or go on a refactoring expedition and end up removing a bunch of what appears to be excess complication but is actually a carefully constructed workaround for some wart in the system (the comment explaining this having long since been deleted - or maybe migrated to the team wiki, where all good information goes to die - by someone who had been watching a lot of Uncle Bob videos on YouTube at the time), and then production bugs sneak in, and eventually people quite rationally start to blame the technology.
I agree it's a great idea to leave comments in code, for things that are done in a non obvious way for good reasons.
The highest purpose a comment can serve is to explain why you're doing something (which looks) stupid.
[deleted]
I've the tenacity to work through understanding it, but when there is an obvious configuration issue which has been overlooked or not spelled out clearly - that's what irks me.
Stuff like this is what puts me off React:
https://reactjs.org/blog/2018/03/29/react-v-16-3.html https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d...
It's at v16, and they're still making major changes to the basic component lifecycle, deprecating things, and then almost immediately having to write articles to teach against anti-patterns that already arisen in the new APIs!
A programming model that is so unintuitive people still cannot use it right, even after so many years, does not seem like a great bet to me.
https://reactjs.org/blog/2018/03/29/react-v-16-3.html https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d...
It's at v16, and they're still making major changes to the basic component lifecycle, deprecating things, and then almost immediately having to write articles to teach against anti-patterns that already arisen in the new APIs!
A programming model that is so unintuitive people still cannot use it right, even after so many years, does not seem like a great bet to me.
I'm not sure if you actually have ever used React but every single major version update is non breaking. The topics discussed in the link provided are discussing how an internal library is being updated (Context API) and how these functions are being depreciated in version 17 (https://reactjs.org/blog/2018/03/27/update-on-async-renderin...). The above depreciations are functions that typically should not be used in a v16 React application anyway! Using them typically means there lies a bug in your props updating logic.
> I'm not sure if you actually have ever used React but every single major version update is non breaking.
That would be fine if they were making major releases every 2+ years, when you release a major version on average of 3 times a year it's incredibly unstable. A typical upgrade will be jumping several versions.
That would be fine if they were making major releases every 2+ years, when you release a major version on average of 3 times a year it's incredibly unstable. A typical upgrade will be jumping several versions.
A major version change of React is different from a major version change in Angular. I upgraded several React apps of variying sizes from 14 to 17 over time and none of these upgrades took more than an hour.
Don't get confused by the version labeling scheme.
Don't get confused by the version labeling scheme.
React has always opted for better performance even if that causes the API to be harder to use. This can be seen in how setState() behaves differently depending on when you call it, keys, and now getDerivedStateFromProps. I've been using React since its inception and just the other day I got stuck with a gotcha on keys I was not expecting. Not saying this is good or bad, it's just the approach React took.
The major problem is that with the introdu of progressive web apps, people found easy to implement mobile apps, at the cost of sweating many hours on following React API changes, instead of learning native platforms API. This applies also to who is using Electron instead of native API on desktop.
It continually amazes me the contortions people will put themselves through just to be able to keep writing Javascript.
One can nit pick some of his points, but the general essay is right on point. Developers need to understand what they are building on top of to be able to navigate non-trivial problems.
I found this article from Saturday worth the read, as it explains what Docker actually is, and why no one needs it: http://catern.com/posts/docker.html.
The same goes for everyone working in the cloud; I've build my own clusters to compare the effort and expense (rather than just accept the marketing line) and running one's own servers, from one to hundreds, is exponentially more cost effective than any cloud service.
People are not doing their homework, and the herd mentality owns the entire tech industry.
I found this article from Saturday worth the read, as it explains what Docker actually is, and why no one needs it: http://catern.com/posts/docker.html.
The same goes for everyone working in the cloud; I've build my own clusters to compare the effort and expense (rather than just accept the marketing line) and running one's own servers, from one to hundreds, is exponentially more cost effective than any cloud service.
People are not doing their homework, and the herd mentality owns the entire tech industry.
Please could you elaborate on the cloud vs on-premise comparison? Are you including the initial on-prem costs of buying the hardware?
Yep. The expense of the cloud is crazy; in most corporate situations the expense of purchasing the same servers used by the cloud service is 1/4 your monthly cloud bill. The markup is unethically high, so they've brainwashed an entire generation of young developers and their equality naive CTOs that this is anything other than a swindle.
Running a server is child's play, people. Don't believe the hype!
Running a server is child's play, people. Don't believe the hype!
People may have a strong reaction to the word "crazy", but I'm not sure what else to call it, other than "mass delusion" or "mass hallucination".
I've done this analysis for (mostly small-scale) companies for about 10 years, and, every time, the cost of using public cloud computing has been 2x-10x of running ones own servers for 3 years.
I've only had one exception, where the incremental cost of compute was 1:1, if the servers were placed in more expensive space near the other servers in the existing datacenter. Data transfer costs made cloud more expensive, of course.
> Running a server is child's play, people.
I'd say that's a bit of a hyperbole, but I agree that the incremental expertise (and time/effort) required to deal with hardware over cloud, is far from the prohibitve headache it's made out to be.
I've done this analysis for (mostly small-scale) companies for about 10 years, and, every time, the cost of using public cloud computing has been 2x-10x of running ones own servers for 3 years.
I've only had one exception, where the incremental cost of compute was 1:1, if the servers were placed in more expensive space near the other servers in the existing datacenter. Data transfer costs made cloud more expensive, of course.
> Running a server is child's play, people.
I'd say that's a bit of a hyperbole, but I agree that the incremental expertise (and time/effort) required to deal with hardware over cloud, is far from the prohibitve headache it's made out to be.
Much like in The Princess Bride, when companies say they are moving to the cloud for "cost," that word does not mean what they think it means. What they are really saying is that it is "cheaper" to swipe their corporate card for some AWS each month than it is for them to deal with the political and cognitive effort of doing it themselves. You know you can cook a better and cheaper meal at home but then you have a lot more effort than if you just go out to a restaurant and swipe your card. Same deal here, and most companies just want to get on with being a health care provider, energy company, financial services company, etc and they are willing to admit that they just don't have the stomach for IT. Going to the cloud is one of those places where they say cost but what they really mean is <networking | servers | power | etc> are _hard_.
> Going to the cloud is one of those places where they say cost but what they really mean is <networking | servers | power | etc> are _hard_.
But I (and the GP) addressed that. It just isn't hard.
Your earlier comment is closer to the truth:
> political and cognitive effort of doing it themselves
With "traditional" industries, it seems the problem is entirely political, and it actually is about cost, because cloud isn't competing against the commodity gear we've been talking about here. Cloud is competing against "enterprise" hardware, which easily costs even more than cloud, not least of which due to maintenance contracts.
There was some discussion of this (somewhat tangential to the main topic) I participated in here https://news.ycombinator.com/item?id=17329028
But I (and the GP) addressed that. It just isn't hard.
Your earlier comment is closer to the truth:
> political and cognitive effort of doing it themselves
With "traditional" industries, it seems the problem is entirely political, and it actually is about cost, because cloud isn't competing against the commodity gear we've been talking about here. Cloud is competing against "enterprise" hardware, which easily costs even more than cloud, not least of which due to maintenance contracts.
There was some discussion of this (somewhat tangential to the main topic) I participated in here https://news.ycombinator.com/item?id=17329028
Well, unless your db master fails. Do yours automatically fail over?
Of course. That's essential to any enterprise.
> The same goes for everyone working in the cloud; I've build my own clusters to compare the effort and expense (rather than just accept the marketing line) and running one's own servers, from one to hundreds, is exponentially more cost effective than any cloud service.
I have servers in the data center and in the cloud, and I can say that the line "is exponentially more cost effective than any cloud service" has so many caveats attached, it's not even worth debating.
Simply put, if all you are doing is comparing running X servers in the DC and running the same servers in the cloud and that's it, yes, the cloud will be more expensive. This is why no cloud provider recommends simply doing that.
> People are not doing their homework
You should continue to do homework.
I have servers in the data center and in the cloud, and I can say that the line "is exponentially more cost effective than any cloud service" has so many caveats attached, it's not even worth debating.
Simply put, if all you are doing is comparing running X servers in the DC and running the same servers in the cloud and that's it, yes, the cloud will be more expensive. This is why no cloud provider recommends simply doing that.
> People are not doing their homework
You should continue to do homework.
> "I have servers in the data center and in the cloud, and I can say that the line" is exponentially more cost effective than any cloud service" has so many caveats attached, it's not even worth debating.
Only thing I'll add is that at best it's asymptotic to a constant factor more cost effective.
Only thing I'll add is that at best it's asymptotic to a constant factor more cost effective.
I found this article from Saturday worth the read, as it explains what Docker actually is, and why no one needs it: http://catern.com/posts/docker.html.*
Not sure I agree with the conclusions. A bunch of OS-specific alternatives don't compare as I see it, but regardless, for me the value of Docker isn't the filesystem trees alone but the tools that then leverage them; compose, swarm, etc.
Not sure I agree with the conclusions. A bunch of OS-specific alternatives don't compare as I see it, but regardless, for me the value of Docker isn't the filesystem trees alone but the tools that then leverage them; compose, swarm, etc.
Do you buy your own hardware? How do you run your own servers?
Yes, I buy new servers for high compute purposes, and used ones for file shares and web heads. A full cabinet at a colo is around $800 a month, and that will hold 48 servers. 24 physical high compute servers in the cloud will run over $300K per month running 24/7. Owning your own? $800! And the savings that first month bought the fucking servers!
The post you referenced reminded me of this HN comment regarding Dropbox right when it launched: https://news.ycombinator.com/item?id=9224
It might be simple for an adept developer but not all companies can find/hire that kind of talent. You need abstractions that simplify dev ops in a way. Yes, docker does not solve everything and should only be used when you can leverage some of its pros.
It might be simple for an adept developer but not all companies can find/hire that kind of talent. You need abstractions that simplify dev ops in a way. Yes, docker does not solve everything and should only be used when you can leverage some of its pros.
> People are not doing their homework, and the herd mentality owns the entire tech industry.
I've seen that, but I've also seen individual engineers and entire departments refuse to move on from what they are using. When they eventually realize they need to change, they are a lot further behind than they were initially, and it takes a lot more work to catch up.
A lot of organizations are getting real value out of Docker (and Kubernetes and NoSQL and React and all of the other trendy new things), and saying that "no one needs it" is just as myopic and wrong as being part of the herd mentality.
I've seen that, but I've also seen individual engineers and entire departments refuse to move on from what they are using. When they eventually realize they need to change, they are a lot further behind than they were initially, and it takes a lot more work to catch up.
A lot of organizations are getting real value out of Docker (and Kubernetes and NoSQL and React and all of the other trendy new things), and saying that "no one needs it" is just as myopic and wrong as being part of the herd mentality.
> A lot of organizations are getting real value out of Docker (and Kubernetes and NoSQL and React and all of the other trendy new things)
At the risk of nitpicking a word that may have been just used for emphasis, how can you be sure the value is real, though? Perceived value can be tough to tell apart, especially in a monoculture (called "herd mentality" earlier, perhaps too uncharitably).
Also, even if the value is real, is it technical, or political/behavioral? If it's the latter, that doesn't minimize theri value, but let's not pretend their advantages are technical. We could, instead, discuss if using the new tool is the best (or only) way to effect that change. It may be. It may even be that which tool it is doesn't matter, so long as it's different, as has turned out to be the case in ergonomics and RSI.
We've certainly seen some negative "NoSQL" headlines. How many startups used it to their eventual detriment, just following a trend and/or doing premature optimization? I'm not saying it can't provide value, rather than mere popularity and even perceived value, especially initially [1]
> saying that "no one needs it" is just as myopic and wrong as being part of the herd mentality.
I think that's what's called a "shallow dismissal" and is discouraged by the guidelines. The bare statement would be mere hyperbole and could possibly be "just as" wrong, but it was in reference to an entire article, which lays out the technical reasoning, which it's up to you to refute and point out they myopia of.
[1] I am reminded of how "easy" MySQL replication was always touted to be.. except that people choosing it did so with an empty database. If it broke, with a far-from-empty database, I found myself wishing for one of PostgreSQL's much more "difficult" options.
At the risk of nitpicking a word that may have been just used for emphasis, how can you be sure the value is real, though? Perceived value can be tough to tell apart, especially in a monoculture (called "herd mentality" earlier, perhaps too uncharitably).
Also, even if the value is real, is it technical, or political/behavioral? If it's the latter, that doesn't minimize theri value, but let's not pretend their advantages are technical. We could, instead, discuss if using the new tool is the best (or only) way to effect that change. It may be. It may even be that which tool it is doesn't matter, so long as it's different, as has turned out to be the case in ergonomics and RSI.
We've certainly seen some negative "NoSQL" headlines. How many startups used it to their eventual detriment, just following a trend and/or doing premature optimization? I'm not saying it can't provide value, rather than mere popularity and even perceived value, especially initially [1]
> saying that "no one needs it" is just as myopic and wrong as being part of the herd mentality.
I think that's what's called a "shallow dismissal" and is discouraged by the guidelines. The bare statement would be mere hyperbole and could possibly be "just as" wrong, but it was in reference to an entire article, which lays out the technical reasoning, which it's up to you to refute and point out they myopia of.
[1] I am reminded of how "easy" MySQL replication was always touted to be.. except that people choosing it did so with an empty database. If it broke, with a far-from-empty database, I found myself wishing for one of PostgreSQL's much more "difficult" options.
Docker adds unnecessary complexity, added insecurity, and the illusion that this is easier than just making a container by hand. It's insanity.
I can't see how I am going to get budget for "yeah guys I need half a year to provision 100 servers, 5 sys admins" VS "yeah I need 2 developers and a month, we can start selling to customer, just make markup adjusted with price for cloud storage". We have to minimize time to market, make money not build servers, but maybe others have other priorities.
> "yeah guys I need half a year to provision 100 servers, 5 sys admins"
It's this kind of gross exaggeration that's keeping AWS so profitable, I suspect. Half a year and 5 sysadmins for only 100 server would do the NYC MTA subway construction team proud.
> We have to minimize time to market, make money not build servers
This is a false dichotomy, though. Of course you'd start with something where you can have infrastructure on day 1 of product launch. At small enough scale, cloud (or a VPS) is actually cheaper, too. Once you're at "time to market", if you're not re-evaluating, I'd say that's foolish.
> make markup adjusted with price
I'd expect any business to prefer to keep that markup for themselves as profit, assuming they even have that pricing power in the first place.
It's this kind of gross exaggeration that's keeping AWS so profitable, I suspect. Half a year and 5 sysadmins for only 100 server would do the NYC MTA subway construction team proud.
> We have to minimize time to market, make money not build servers
This is a false dichotomy, though. Of course you'd start with something where you can have infrastructure on day 1 of product launch. At small enough scale, cloud (or a VPS) is actually cheaper, too. Once you're at "time to market", if you're not re-evaluating, I'd say that's foolish.
> make markup adjusted with price
I'd expect any business to prefer to keep that markup for themselves as profit, assuming they even have that pricing power in the first place.
You're already operating from the cloud services perspective. Try 100 cloud servers is the same as 5 physical servers. Say 100 cloud servers runs your organization X dollar per month, plus the team of engineers to build out and operate there. For 1/4 of one month's cloud expense one can buy 5 servers that are the same hardware the cloud services are trickle renting you. With your month over month savings, you CAN afford those hard to find developers. Many of them are actually unemployed because everyone thinks they need to use the cloud - I've been able to pick them up for spot situations over my head for $15 an hour.
This is why I choose Ember as my framework of choice. It's been there since Backbone, since Angular, and now React.
React, in my opinion, is filled with "best practices" where they choose complex solutions to simple problems. The dependency hell is also ridiculous in React. I would like to see how many of these apps are having issues upgrading to the latest versions of their dependencies in 5 years.
React, in my opinion, is filled with "best practices" where they choose complex solutions to simple problems. The dependency hell is also ridiculous in React. I would like to see how many of these apps are having issues upgrading to the latest versions of their dependencies in 5 years.
It's also why I chose Vue over React.
In terms of capabilities they are fairly similar but the the existence of an official router and official state management store means that the "things that can break in horrible ways" surface is reduced.
I stuck with KnockoutJS for a long time because they had (for a JavaScript project) incredible backwards compatibility and stability.
I've been programming long enough that "the new hotness" is of much lower interest than "what capability does it give me I don't have and will I still be able to build/deploy this in 3 years if I need to".
Also if something seems amazing I'll wait a year, if it was amazing it'll still be amazing in a year and I'll have 365 days of other people smacking their heads on the not amazing parts.
In terms of capabilities they are fairly similar but the the existence of an official router and official state management store means that the "things that can break in horrible ways" surface is reduced.
I stuck with KnockoutJS for a long time because they had (for a JavaScript project) incredible backwards compatibility and stability.
I've been programming long enough that "the new hotness" is of much lower interest than "what capability does it give me I don't have and will I still be able to build/deploy this in 3 years if I need to".
Also if something seems amazing I'll wait a year, if it was amazing it'll still be amazing in a year and I'll have 365 days of other people smacking their heads on the not amazing parts.
The knockout documentation is a thing of beauty. One should start with the framework for that reason alone.
It will take few years for people to realize, but Ember.js is the silver bullet for building web applications.
Why do you say that?
Someone else I know also has a soft spot for Ember though from my vantage point (dabbled in them all), they all seem quite similar. (Them being Ember, Backbone, Angular).
Someone else I know also has a soft spot for Ember though from my vantage point (dabbled in them all), they all seem quite similar. (Them being Ember, Backbone, Angular).
> For example, Object Oriented Programming became Functional Programming
What? No it didn't. An imperative language is the opposite of a declarative language. OP might want to edit this one.
What? No it didn't. An imperative language is the opposite of a declarative language. OP might want to edit this one.
Indeed. Right there alongside acknolwedging OCaml (albeit capitalized incorrectly) as a functional language, no less.
It is pretty clear that the author meant OOP -> FP with respect to popularity and NOT literally transformed from one to the other.
That's called experience. This is the reason why senior developers are normally paid more and make the important decisions.
And what the article tells is that you should actually get interested in what you are doing, if you want to become experienced and not just old. That should be common sense, but I guess it is worth repeating from time to time.
However, if you don't have 30 years of experience, ranging from coding on a C64 to modern JS frameworks, the Lindy effect (older technology tends to stay longer) is a good shortcut.
And what the article tells is that you should actually get interested in what you are doing, if you want to become experienced and not just old. That should be common sense, but I guess it is worth repeating from time to time.
However, if you don't have 30 years of experience, ranging from coding on a C64 to modern JS frameworks, the Lindy effect (older technology tends to stay longer) is a good shortcut.
> That's called experience. This is the reason why senior developers are normally paid more and make the important decisions.
The problem is we obtain that "senior" title long before we have this experience. Then when it's finally deserved (the 10+ year mark) the pressure starts mounting to move into architecture/management roles. And let's not forget the "old man can't keep up" that's always been rampant.
The industry as a whole seems to consider experience as a liability.
The problem is we obtain that "senior" title long before we have this experience. Then when it's finally deserved (the 10+ year mark) the pressure starts mounting to move into architecture/management roles. And let's not forget the "old man can't keep up" that's always been rampant.
The industry as a whole seems to consider experience as a liability.
To build upon your comment:
It's not because older technology is inherently better, but it's because if older technology is still relevant, it's survived the "will it be relevant in the future" test once before.
It's not because older technology is inherently better, but it's because if older technology is still relevant, it's survived the "will it be relevant in the future" test once before.
As a person with 40+ years experence (Yes I started with a 4004) I aggee.
Change is constend and the advancement of more and more complex systems is inevitable. Most of these is good but some with issues. The quote "A sufictly advanced technology is indistinguishable from magic" describes an ADVANCED tech.
I believe it is the speed we are developing the tech that is the problem. We are more often then not ignoring the wisdom of senior developers.
This obviously is a problem of new languages/high dynamical frameworks..
Why this isn't happening for languages such as C, C++, Java? Sure, new standards are kicking in, but you can still program using old standard, it will continue (more or less) to work.
Why do JS developers follow overhyped frameworks? I do not understand.. the few times I've programmed in JavaScript, I've always used jQuery: it might be old school, but it does its job well and bootstrap is still using it too.
Why this isn't happening for languages such as C, C++, Java? Sure, new standards are kicking in, but you can still program using old standard, it will continue (more or less) to work.
Why do JS developers follow overhyped frameworks? I do not understand.. the few times I've programmed in JavaScript, I've always used jQuery: it might be old school, but it does its job well and bootstrap is still using it too.
Which technology stack would you recommend going forward? And why?
Node.js? Vue.js? React? Angular? Elm?
I can't keep up with the Javascript tower of babel anymore.
And what happened to Django? Nobody seems to talk about it anymore.
Node.js? Vue.js? React? Angular? Elm?
I can't keep up with the Javascript tower of babel anymore.
And what happened to Django? Nobody seems to talk about it anymore.
Django is by far the best full-stack MVC solution IMO. It is well known in python communities, and python is growing in popularity year over year.
As for your javascript questions: React is the answer. Not just because it has the considerable resources of Facebook backing it, but because at it's core, the idea is extremely sound and well tested, going back 30 or more years.
Vue.js has similar principles and might also be a good choice, but what you need to look out for is the community surrounding it, and whether it will eventually be unsupported.
Node.js is great in the backend, but doesn't have quite as many mature frameworks like Django. If you're down to build things from bare metal using some libraries like Express.js or Koa.js, then you'll enjoy Node.js. Typescript and Flow have also made Node more attractive.
As for your javascript questions: React is the answer. Not just because it has the considerable resources of Facebook backing it, but because at it's core, the idea is extremely sound and well tested, going back 30 or more years.
Vue.js has similar principles and might also be a good choice, but what you need to look out for is the community surrounding it, and whether it will eventually be unsupported.
Node.js is great in the backend, but doesn't have quite as many mature frameworks like Django. If you're down to build things from bare metal using some libraries like Express.js or Koa.js, then you'll enjoy Node.js. Typescript and Flow have also made Node more attractive.
> Which technology stack would you recommend going forward? And why?
With React you have the most options and biggest community, including ways to shoot yourself in the foot. It's preferred by full stack JS guys who also use node, so it could be great if you're a startup and can hire somebody who can do everything.
Angular is popular with enterprises who know what they need (a stable environment at scale with strict rules), who have a high budget for hiring specialists, the whole framework is more complex.
Vue sits in between Angular and React, but more geared towards smaller businesses and their needs. It's very popular with PHP devs, and full stack devs who don't use JS exclusively. The main advantage is peace of mind, knowing that everything works well togehter.
Elm is very opinionated, but also very different from those other frameworks. In React or Vue you start thinking of components, in Elm you think about functionality, and create components as they emerge from patterns, potentially leading to a more cohesive and elegant result.
But that's not how designers used to work. Bridging the gap between designers and devs, and how they currently work, is the main advantage of React and Vue imo. Web designers (like graphic designers) are used to think in whole pages, or layouts, and break things down from there (top-down). React and Vue and the component first paradigm is a compromise, where devs aren't degraded into only doing the implemetation, and designers aren't degraded into doing the styling only. It still respects both roles.
Elm is basically the next level for designers, or designers who like to code. It's how design that left the analog world behind could be.
With React you have the most options and biggest community, including ways to shoot yourself in the foot. It's preferred by full stack JS guys who also use node, so it could be great if you're a startup and can hire somebody who can do everything.
Angular is popular with enterprises who know what they need (a stable environment at scale with strict rules), who have a high budget for hiring specialists, the whole framework is more complex.
Vue sits in between Angular and React, but more geared towards smaller businesses and their needs. It's very popular with PHP devs, and full stack devs who don't use JS exclusively. The main advantage is peace of mind, knowing that everything works well togehter.
Elm is very opinionated, but also very different from those other frameworks. In React or Vue you start thinking of components, in Elm you think about functionality, and create components as they emerge from patterns, potentially leading to a more cohesive and elegant result.
But that's not how designers used to work. Bridging the gap between designers and devs, and how they currently work, is the main advantage of React and Vue imo. Web designers (like graphic designers) are used to think in whole pages, or layouts, and break things down from there (top-down). React and Vue and the component first paradigm is a compromise, where devs aren't degraded into only doing the implemetation, and designers aren't degraded into doing the styling only. It still respects both roles.
Elm is basically the next level for designers, or designers who like to code. It's how design that left the analog world behind could be.
"A trailblazzer doesn't follow a trail" as Terry Davis says.
What slows me down is the little implementation detail that is causing this weird bug that I just don't understand.
And if it is a new technology, then stack overflow doesn't have the answer.
So, to take the example the author gives, when Rails was new, its not that I didn't understand the MVC framework and how the roles were different. I didn't understand that RVM had to be set to a default ruby version every time I restarted the console.