In the tech world, there's always a plethora of popular tools that have been around for some time, but some people including me just don't have the time/capacity/resource/insert-reason-here to try it out.
For me, it's Docker. Most repos now have a way to setup with Docker and infra services such as AWS or Digital Ocean also provide integrations with Docker. The hype is still going strong as of now and people are starting to use Docker in development as well. However, the effort of running it in development just doesn't justify the gain. Maybe it's great on production, but I have been putting up static sites as of late. I've got no time to invest on this I guess, maybe someday when I need them.
How about you all? I'm curious if people here at dev.to is more like the type of people who would always be trying out (or master) the popular ones, or maybe more like me, stick to the usual until it's necessary to try out popular ones.
Oldest comments (93)
Well, I don't want to mention AWS but I find it super boring watching any tut or course on their services. I'm too inclined to writing code that it gets boring very quickly for me.
I would also add Angular and PHP to the list. No offense, it's just me. Maybe things will change in the future :)
You and me both on Angular. I mainly use Vue and a little React, I don't think I can afford learning a third framework. I used to code in PHP in the past but not sure if it's still popular nowadays.
AWS, yes, it can be boring. With static sites I could get by with free services like Netlify. Maybe someday when I actually need them I'll dive in to AWS a little deeper...
WordPress still relies heavily on PHP. So PHP is still used here and there.
True that, PHP is still going strong with Wordpress. What's the closest non-PHP competitor to Wordpress nowadays? I'm not much into CMS.
Well wordpress relies heavily on PHP but if you really need to edit your PHP in a meaningful way and add a lot of new things(because editing is easy) then maybe you should stop developing the certain site in wordpress and consider creating a separate api server and transfer the login there while keeping the wordpress for view purposes and frontend editing.
Thats just my opinion though.
@briwa I'm not sure of what non-PHP solutions that there are. However, I would imagine that they are based on either Ruby on Rails or Node.js or similar javascript framework.
@greedman456 That's not how WordPress works. PHP is the only meaningful way to change the functionality of the WordPress blog like creating your own theme. All of WordPress's functions are written in PHP. Sure other parts of your site can use something other than WordPress, but then that would be maintaining two or more different systems.
WordPress handles the MySQL DB used in the backend. And I've never heard of anyone creating their own api framework to interface with the WordPress DB.
The whole point of using a CMS is to use it's feature of controlling blog posts, comments, changing themes, etc.
I know that and I'm not talking about the theme or the blog part. But as a site grows there are many times when the customer starts wishing other functionality. That's where adding an extra API can become beneficial in place of changing PHP.
You're talking about plugins. Again those are written mostly in PHP with a bit of javascript/HTML/CSS.
developer.wordpress.org/plugins/pl...
Well sorry to the op that the discussion has derailed. No i am not talking about plugins. These are indeed written in both HTML5 and PHP. Im talking about additional functionality in the form of new models in your system and customizations that need to happen in the backend. If you want to do it the wordpress way yes you would have to write it in php. You could however use javascript in the frontend of your wordpress to call a seperate api. I have done it in the case of a client who had a lot of different eshops and wanted to integrate them afterwards in a combined system. Instead of redoing everything I added calls to the frontend to my newly created global server and used the wordpress api to get the remaining data I needed. The new server was created with node and I completed the whole infrastructure pretty fast.
If I tried to do this with php I dont even know when or how I would do it.
Your first thought should be, "Is this relevant to the topic at hand?" The OP was only wondering if PHP was still being used. Not an explanation on how to avoid using PHP.
Just because you have an aversion to PHP doesn't mean you tell people to do it your way. There are multiple ways of doing things. There are WordPress sites that just use WordPress with a shopping plugin. No other code or servers and they maintain inventory via the plugin using the WordPress admin console.
You couldn't figure out in whatever time frame that you had to migrate everything to one server using only WordPress and plugin(s). You instead created a Node.js based server. Fine.
But nothing since your first reply is at all relevant to OP's "PHP... still popular nowadays" response. Think before you reply next time. Fin.
Well no reason to become so emotional. Of course it is my one way of doing things and of course this is my opinion. I thought very carefully before replying and getting angry because someone expressed a different opinion isnt very mature. Expressing our opinions is what we do here. You not understanding my point of view is another point alltogether and I could explain in detail if you asked like we had a discussion.
Just my personal opinion again(and advice), dont get emotional on supporting the technologies you work with. Learn everything possible and use it for what it is and what it can give you.
Best regards
Your reply is proof that you didn't think. Again, your story has nothing to do with the OP. I sure as hell didn't ask for your opinion on using PHP or not. The OP never asked for it either.
OP was ONLY concerned with PHP still being used. Just like my previous reply said.
And don't ever tell people to not get emotional and calling them "isnt very mature". You don't belong here. You went completely the wrong way to bring up your story/opinion.
I hope that you understand that you are being unreasonably aggressive. Nvm have a nice day
And you’re a Sea Lioning troll.
en.m.wikipedia.org/wiki/Sealioning
Hey folks!
Let's do our best to keep focus on the topic at hand. It's okay to disagree, but just avoid getting too personal with our comments. This conversation is straying away from development now, so let's please move on.
I've always had an aversion to Angular. There's three reasons for this.
I also share your feelings about docker too. I get that it helps teams to ensure consistent dev environments, but I've found that the trouble it causes (irrespective of if the devs that are forced to use it know it or not) do not justify this benefit.
True that, about Angular. I think it has gone a few major version changes that I started to lose track what was new. And yes, bidirectional data flow can be hard to debug or to keep track. I admire frameworks like CycleJS that has a clear unidirectional data flow that makes it so tidy and easy to follow, used to use that a while ago.
Huh? There’s a styleguide. Naming things is easy! Just run ng generate and it’s named for you!
That’s just your opinion, man.
Angular prefers unidirectional data flow.
Angular community is so welcoming. I suggest you give it another look.
React. I generally just don't like JavaScript, but if I'm going to use it I'd prefer either Vue or just vanilla. I can't get past the overwhelming hurdles of everything needed (webpack, redux, es6, etc.) to become even slightly productive with it. And the community trying to turn literally everything into React just seems like an abuse of React from outside looking in.
If you just want to try it out, create-react-app can save you from all the setup trouble. It's really great for a quick prototype or a small app, but obviously a much in-depth customizable setup may be good instead for production (or you can just
ejectthem). Or maybe if there's someone here actually running a large-scale production app withcreate-react-appbefore, I would love to learn from your experience.React
2) can you substantiate claim?
7) Ad hominem
2)
There’s probably more. In short problems arise because React implements different event and attribute bindings leading to unpredictability with browser API.
7) At times it seems like prominent members of the React community act like the web begins and ends with React. I don’t agree. I also don’t see this kind of attitude in other JavaScript framework communities. It matters how the people in a community act. Coding is as much about the people as it is the code.
If you use React and love it then keep using React. This isn’t about you. This is about why I avoid a popular framework. I’ve used React. When it first appeared on the scene I was really interested in why they would implement a front end framework this way. I even built a similar framework from scratch that implemented a virtual DOM. Then I realized well the DOM is already a tree. Why do I need to duplicate it? I rationalized that the whole premise for duplicating DOM was flawed. If DOM was not performant then shouldn’t it be the browsers that implement better performance? We don’t need JS frameworks to take up that mantle. A few years later that panned out and browsers have optimized several things. On top of that there are now several ways to declare a component and custom elements are the path forward in my opinion. That isn't to say a library like React still won't be useful. Custom elements still may require some pattern for managing state in your project. But that paradigm is much more for Redux to handle than React IMHO, or some other state pattern.
I think it comes down from the fact that there isn't yet an easy way to create reusable components natively in the browsers, which is why React and the likes were there in the first place. If we're going to wait until browsers catch up, I remember seeing Web Components specs a few years ago and it doesn't seem to be completing any time soon. I think people love implementing their own solutions when there isn't any available, at least I do.
But I hear you. I wish more efforts were there to improve the browsers or the specs instead, maybe by the community, but I think it's a different problem.
I'm curious tho, if you're not using React, what's your frontend framework of choice?Nevermind, saw your comment below mentioning Angular.Have you looked at Stencil? It’s a library that compiles down to Custom Elements v1 and promises interop between all the major frameworks. With a 133 byte “Hello World” it relies heavily on browser spec. The browsers already caught up years ago. You can build reusable components solely with browser spec today.
Whoa, TIL! Thanks for the info. All I remember that it was stuck until the spec level, never got around being the official fully usable feature on the browsers. I guess I should look into it.
React and Vue
Kubernetes. Too much undifferentiated heavy lifting.
You may regret that in a few years
Disagree. It will solve a problem, but not for everyone. If you are „small“ and not like Google, Uber or Whatever, Kubernetes brings more work to you as you might ever gain advantage.
It is a great tool, but it is not a one-size-fits-all.
If you are working with containers on production sooner or later you will find yourself wanting features that Kubernetes offers out of the box.And what’s even better than being available for everyone and not just Uber or Google, so why not
It’s not obvious to me and my clients how we can benefit from these features.
Our cloud providers already deal with orchestration, scaling and management. Docker and docker compose already deal with the basic containerisation needs of our internal build servers.
Instead of learning the guts of kubernetes, it’s cheaper and faster to outsource that to cloud providers.
UI frameworks/libraries are a different question, because the user interfaces we build are, by nature, highly specific and customised to our users. So it’s not so easy to outsource that work, and it’s worthwhile for developers to pick up that work.
But you may be in a different business setting and tech setup, which requires you to use Kubernetes and do all that management and scaling yourself.
Actually Cloud providers promote the use of managed Kubernetes for example,
Amazon's EKS, or Microsoft AKS or Digital Ocean. Nowadays you can have a turnkey Kubernetes cluster in a few minutes that it's also tailored for Enterprises.
There is clearly a great need for managing containers in the cloud as there are important considerations such as scalability and security that need to be handled efficiently. I think it's currently the best tool for that job and unfortunate not to invest on it.
EKS costs about $144 / mo currently, just for the part AWS manages. To startups that are trying to become the next big thing, that's a single droplet falling in the ocean of burning cash. But not every place operates that way. And bringing in Kubernetes requires a learning effort for all the extra bells and whistles (and all the new ways they can fail). For smaller shops like ours, it can make more sense to start on the zero-cost ECS or even Elastic BeanStalk until and unless we need more than it provides.
Unless you're trying to be some kind of AWS/Azure/Google cloud competitor, why would you devote precious time and energy to things like container orchestration, which they can already do for you? Why wouldn't you simply outsource anything at that layer (and maybe one or two layers above it)? For all you care, as long as your code runs cheaply, reliably and at scale, why does it matter which pieces of infrastructure run which parts of your code?
You should be focussing on the core of whatever it is that you actually do as a company. I would have thought comparative advantage is such an obvious and basic principle of business that anyone doing a startup would recognise it almost instinctually.
Am I missing context here? (Apologies if so.)
Yeah, you are spot on with using the services so that you can focus on the business aspects. That just makes sense.
Correct me if I'm wrong, but I think there is an underlying assumption that microservices are in use. Kubernetes solves a lot of orchestration problems for you in that case. But when you're not a large org with multiple dev teams per product, you don't have to do microservices. Obligatory reference to Conway's Law. And when you're not doing that, you don't have a lot of the problems Kubernetes tackles.
Vim. I don’t care how much more productive I’ll be, because I’m already comfortable using a GUI-based editor like VS Code.
I once saw someone who is so into Vim hotkeys struggled just to edit the comments on Github... Lol
I think that many people uses vim and emacs because of their capability of load in the terminals. I actually still use emacs but only for writing the commit descriptions.
It is interesting, now that we talk about that... might it be possible to make an user interface for vscode in plain text mode?
Would that make vim and emacs useless? ;-)
It would not make them useless, as there will still be people who prefer Vim and Emacs
And even then, by the time you have your terminal version of VS Code, you might as well allow use the real version with all the keyboard shortcuts.
No. I am not able to do it. I have nor the time nor the skills, but I would use it.
I strongly advice you to use it, or some similar tool that solve the same dependency hell problem.
It is not a matter of opinion, the problem is there and we can not ignore it.
It is not a hype. It is a tool that broke a paradigm, in the right moment that it was needed.
Which is good, because:
You can exactly reproduce the context of a prod error in your local machine without just a few commands. Those old programmers know that the most frequent phrase in the past was "But it works for me locally..." when they were argued to fix a prod issue.
It allows you to quickly setup the development frameworks and tools as needed for a project. Think what you would do if you have to work as freelancer for many projects as one, and they use distinct versions of the same frameworks and tools. Install and uninstall every time you need to work some hours in a project?
It allows you to have your machine clean, which speeds up the machine. Some systems like windows starts to be slow when there are many programs installed because of the amount of files in the system or app folders / partitions.
It allows you to restore your dev environment quickly after loosing the system. It might be that your hard disk died, or the system is slow or you want to change it. After reinstall you install docker, your code editor, check out some repos from git and everything is running. No need to spend hours configuring your frameworks or tools.
But if you don't want to worry is ok, at the end somebody else in your company is in charge of the IT, and it should provide a solution to you. By the way, many dev environments are moving to the cloud also, like: VSO, coder, etc..
Read this.
I think that is a matter of time that "all" the customers start to ask for equivalent technologies that fit the same paradigm shift.
At the end, if we don't learn how to build your dev environments aligned to the deployments ... we will need to pay for it... It is a decision to take for everyone.
Whoa, TIL! Thanks for the info about Docker. Will definitely try it out someday...
Poor choice of word, I guess. What I meant was the popularity. Hype kind of takes the meaning not in a good way.
Sure, knowing only how to build the development is bad on its own. But never actually tried building one for production has the same degree of sin, IMO. My idea is that one should know the benefit of using Docker in production first, then running it in development. As mentioned in OP, I haven't had any necessity to do it yet. Once I actually tried running one on prod, I would definitely see the benefit of running it in development.
I guess those are the best paradigm shifts for tools. That tool that we think we don't need, and at the end we can not live without them.
I had such a similar feeling during the rise of version control software, unit tests, etc.. I did programs at least six years without all of that and 24 years later I don't imagine living without them.
In hindsight, there are tools that we think we needed, but as it turns out it has become irrelevant or replaced by better ones. On the top off my head: Coffeescript (ES6 and Typescript made it irrelevant), jQuery (browser maturity/frontend framework made it irrelevant), Browserify (Webpack/other better bundler tools made it irrelevant). Obviously, I'm not saying Docker is going to be one of them LOL, I'm just saying that the statement could go both ways.
But I truly agree with you with version control, unit tests. There are certain things that we could invest early and it turned out to be really essential. I think it takes experience to know if which tool is which, and with Docker I'm going to agree with you because my devops skills as a frontend dev is totally 👎🏼 😂 Thanks for the detailed info tho!
Truth been told 👌
Docker is one of the tech killers of this century.
Not just that... Often, they continue to make more amazing stuff!
That would be a good survey.
I did really like a book that a friend did borrow me:
Software Paradigms from Stephen H. Kaisler
It makes a good presentation of all those paradigms and the context where they are useful. Not a compendium, just an introduction.
I am confident that many people might have creativity peaks that can bring the current paradigms down just by being informed on the current problems and where everything fits into.
And that's what be the main concern of this post. I guess nobody needs to be an expert in docker, git or anything other tool it with success to build new creative and useful stuffs.
The Full-Stack way of thinking should not be ... "I need to be an expert on everything", just I need to know what is everything for and which problem it solves for my team or the industry. Of course more deep knowledge on every stuff gives you more control and increase the possibilities of success. But the knowledge adquision process should be Breadth-first and just Depth-first when required by a project milestone or a debugging process.
That's why I have always preferred books who present introductions to those that present exhaustive compilations of something.
I am waiting for some math guru to write a similar book for the math branches and their current applications to the industry. Many paradigms have been broken with this kind of reasoning:
So the question should not about the tools or frameworks, the should be a about the paradigm shift that originated them and the problem they solve.
A good exercise for that is reviewing the tech comparison charts of wikipedia, the software reviews, etc.
Absolutely true!
Paradigms, architectural styles/patterns, and design patterns are really essential to properly solve a problem.
I really feel thankful being a software architect, so that I can realize when someone jumping for microservices solution (with docker, kubernetes, and whatever super duper tech) just cuz it's fancy 🤦
Or automating tests with Selenium just cuz big company X are using it 🤮
As you said, understanding the tech might be important to finish a specific project, but realizing the problems which the tech solves is x10 billion more important.
I guess it's time to write an article on "Why Software Architecture REALLY Matters for All Developers".
Looking forward to the article! I love it when an article breaks down the tiny problems from the top level to see the big picture (in this case, software architecture). I would love to learn.
Despite of the popularity, I don't like to invest time in PHP related stuffs.
i hate working with 90% of php tools but i do the majority of my client sites w/ php because deployment and long-term management is cake (no pun intended)
Came here to say React, realized that everybody else already came here to say React.
For example, 1,500+ dependencies for "Hello World" is not right.
same lol. the thing i like the most about web dev is simplicity...and while react has its merits, it is the opposite of that.
I really think we’ve passed peak React sometimes.
I think what was missing from that fact is that the 1500+ dependencies are there to allow people to build on top of just 'Hello World'... like something way more scalable and complex than that. But I see your point. I think this is because the language and the environment itself don't allow us to do complex scalable app without loads of dependencies (Web Components, maybe, someday...)
Lol I also came in just to say React. I expected a different outcome of the comments/poll.
Well I wrote and then deleted at least 100 words why I dont prefer it over Angular that I m using but I dont think there is any point in making another React vs Angular vs Vue post.
I ll just say that I prefer Angular because after the first 2-3 months of getting aquainted with most of the framework's features I found out that big projects are way more consistent and mentainable this way. I understand it has a steep learning curve but I like the everything in one package that it provides.
You can use React just by importing it into your HTML file in a script tag, you don't have to install 1500+ dependencies. Most of the dependencies in create-react-app are there to make the development process easier and are not bundled into the production app anyways.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.