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...
For further actions, you may consider blocking this person and/or reporting abuse
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.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.
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.
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...)
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.
I really think we’ve passed peak React sometimes.
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.
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.
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 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 once saw someone who is so into Vim hotkeys struggled just to edit the comments on Github... Lol
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.
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.
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.
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.
To answer the original question: I'm going to find it hard to go back to any of the frameworks (See the wall 'o text below).
Java and PHP are both on my list. I've used them both, but doing a deep-dive into them at this point seems like a waste. If I'd focused on mastery 10 years ago, I would feel differently, but it seems like Python and Node are the things we'll be talking about being old 10 years from now and Java and PHP will be in the Perl/COBOL camp of "important historical languages that served as a jumping-off point for more modern languages, but not a good choice for new projects".
Now, the actual reason for my post is that I saw a LOT of React/Angular/Vue point/counterpoint, and someone mentioned Stencil deep in a reply-thread.
Just my two cents on Stencil:
I've been building greenfield in vanilla Stencil (framework-less) since December (design starting in September, with a Java service build in-between haha). I came from Angularjs/Angular-land, and when I did the framework analysis for my current project, it came down to "We need an asynchronous web application, and a SPA is a better choice than static pages hyperlinked together. Should I get some production experience on the resume with React, or try this Stencil thing out?"
I have Stencil v0.0.12 components working on the same page with v1.0.0 (just released). Since they all compile down and don't share framework code (It's a compiler, not a framework) they all just work.
No chasing an upgrade cycle, and the compiled components are spec-compliant, so if it ain't broke I don't have to fix them every time a new version comes out. I went a bit ham and componentized EVERYTHING so my build process is a bit off, but that's my fault, not the compiler (And it's REALLY easy to fix). I can store a .tgz in our local npm and if I need one of the components I just
npm installit. Overall it's been an amazing relief to get away from frameworks and just write code... It uses tsx (jsx with typescript. I still just call it jsx myself haha) and has aspects of a React/Angular/Vanilla mashup...Most importantly: I COULD write the components without Stencil at all. It simply gives me a few convenience features, Developer QOL and polyfill support. But I could write a pure vanilla component and include it on a page and Stencil wouldn't blink an eye. I could include Angular IN a component, or include a component in an Angular app.... same goes for React and Vue. Hell, I could have three components, each running a different framework and they could live in harmony on the same page (Seriously, don't do this guys LOL). Oh yeah, I can also include a component on a static page. It doesn't force me to build a SPA, I just needed the style (And the views/"pages" are components themselves).
Successful micro-frontends are possible and being built today. That's really the reason we've been using the crutches of all these frameworks. The fact that it WASN'T possible because of browser limitations was the whole motivation to use things like React, Angular and Vue in the first place. The spec has now caught-up and incorporated the things we needed to have to do without them, a lot like JQuery had a ton of its functionality absorbed into the spec.
Just being the old guy mentioning that we all need to remember WHY we started using certain tools. Feels like JavaScript-land has started dividing into camps over the last few years, and we need to think about the original motivation to camp here in the first place haha.
Hey, thanks for the insights! With frontend framework giants like React, Vue and Angular, it's great to see a whole different point of view. And yes I truly have missed it in how browsers have caught up and maybe soon those frameworks could be irrelevant as how browsers did it to jQuery. One day I'll try to get out of my comfort zone and try out Stencils or micro-frontends mentioned in this comment, it's buried way deep down here. Wish I could save comments tho, not just posts... cc @devteam ? 😂
As a Front-End Developer, this will sound weird but... Bootstrap.
I just can't see those awful clases, that are 100% non-descriptive.
Speaking of that, have you heard about Tailwinds CSS ? It has more non-descriptive classes, in fact it is the purpose of the framework, to let you only use the utility classes. That way it is less bloated than Bootstrap. If I ever had to choose between that and Bootstrap, well, I choose Bulma 😂
Herd of it. Didn't try it. I'll look up Bulma, thanks.
For me it's Angular. Haven't tried it since version 1.x, and won't even bother again.
I personally like React, but love React Native. It's so easy to make prototypings with RN, and it's multiplatform by default.
Also wanted to break a lance in favor of Docker here. If you are in need to develop anything that involves database and a backend, docker is just the best. Need postgres? 2 files with less than 10 lines you've got it. Same for mongo/mysql/redis... Need node backend? You can download an alpine image and install node to it with a single line of code.
Of course there are some gotchas that you have to come up with. But nothing like handson experience.
fully agree) for me Angular break my lovely rule KISS
React, but specifically JSX. I’ve seen a lot of JSX in the wild and it just looks unreadable to me. I’ve tried to get into it with an open mind, but not for me. I prefer a specific templating syntax (like vue’s Or angular’s) for 99% of use cases I run into.
What specifically is unreadable to you? Just curious because I've moved from React to Vue and I found them quite similar.
The mangling of JS and HTML is very confusing to me. I imagine it becomes easier to read with time, but it isn’t natural for me.
Vue.
Coming from React world, it feels strange to be able to mutate nearly everything just like in the old jquery days. Also, I love jsx and having mark-up tapped into js seems to be far more readable and maintainable to me than coding things the vue's way.
Ha, yup, I started using Vue around 1+ year ago from using JSX and CycleJS where it is strictly prohibited to mutate the data and let it flow declaratively through the view. It was quite a paradigm shift for me too.
But Vue has its reasons of doing it differently from React, which has probably been covered by dozens of articles already, so at this point to each his own I guess.
Right. I was astonished when I first ran a Vue app with like 10 lines worth of configs. It's really easy to set up and use, no more worrying about wasted renders and so much more. But it just doesn't feel right...
PHP and jQuery. They feel old and outdated to me (especially PHP).
I learned jQuery, but never bothered with it in a project. Most of jQuery is redundant. Traversing the DOM is simple now in vanilla JavaScript. Animations can be handled by CSS3. AJAX is simplified now in the promise-based
fetch.So what's the point?
I tried learning PHP, but I found the language inconsistent and wonky. I didn't enjoy working in it, so I decided to not continue.
Same here, I sometimes need to use PHP in my projects, just a tiny bit, but I just refuse to know a language that is no going anywhere.
I'm going to say React like a lot of people here :D
I honestly thought I was going to be the only one choosing that.
Let's make a secret society folks! :P
True that, not interested in React has slowly become the popular unpopular opinion.
Yeah, I'm sure that we also love to bash on it, there's bias I have no doubt about it but still... it's a normal reaction to the hype machine that has been created around it :) Same for other technologies
I've heard similar opinions on how Vue is more noob-friendly than React and I agree. I think lots of people got thrown off by the JSX syntax and prefer Vue's HTML-like syntax.
But this isn't a jab at React. Obviously, React has its own great things compared to Vue. I'm pretty sure there's already a lot of articles covering their pros/cons.
Honestly, I don't have a personal need for Docker either, so I'm not inherently interested in it—especially not to the degree that it's abused.
I saw someone else say Java on social media and honestly I couldn't care less about that language.
If languages is permitted it's definitely Python for me. Coming from a statically typed world, mainly Java, I'm not a big fan of dynamically typed languages, but Python surpass all limits by removing curly braces and forcing me to structure the code only by identention. I lose myself pretty quickly in a small script.
The first time I tried Python I was surprised that the code won't let me compile because of an incorrect indentation... Coming from coding in Javascript I was truly befuddled.
I think it's important to differentiate freelancers/contractors from employees in this regard.
A freelancer/one-man-shop/consultant may face other consequences if they ignore certain technology. They are hired mostly based on their experience and are expected to be productive quickly.
I, as employed developer, can't choose not to learn tech which I need to use in my projects.
BUT: I don't need to learn it in my free time.
In my case: I couldn't care less about Angular. If I had the choice I wouldn't use it. (Personally I'd try to go with vanilla JS/WebComponents or maybe Vue/React if it fits the project and team.)
The e-commerce-platform we work with decided to base their interface-parts, starter-kits, CMS and whatnot on Angular in future.
(I disagree with that decision and don't think a web-shop should be an SPA. Nothing about this architectural decision makes sense to me. This is cargo-culting in its purest form.)
Still me and the other devs will probably have to work with it at some point.
As employees we don't have to learn "the Ng-Word" in our free time. I organised a three day course at our office with an external trainer. Everybody can take a deep dive this way; No personal time wasted. Plus everybody has a new tag for their CV.
Regarding Docker I feel the same as you. I never needed it for the personal stuff, and projects at work never used it. If we ever should, three-day-course here I come ✌️
This 100x. I should've empasized in the original post that it should be one thing that you have no interest with despite the popularity, but it should be from a hobbyist/weekend programmer standpoint, should have nothing to do with your daily job. That way, I think the opinions can be formed better. But apparently the thread blew up before I realized my mistake.
Just like anything else, Docker is a tool for specific purposes. If you're writing static sites you're going to deploy to a CDN then Docker is useless, but if you're writing apps then it's a great tool to get guaranteed similar behavior across architectures.
I'm personally not sold on React. If I have to pick all my pieces, why am I using a framework? Again, it's not for everyone and not for every project. I know, create-react-app.. how is that different than just using Angular which is preconfigured with all the things to make a production app? The "benefit" of React is the ability to change all the things, so why start with a subpar auto configuration? If you're doing that, use a full framework.
But to each his own. If you like spending all your time on Stack Overflow, go for it!
That's not to say Angular is the best. Vue is nice and relatively simple. Vanilla JS is great, too. You might not need a tool at all.
As a lover of docker, if you are just throwing up static sites, you aren’t really missing anything. Especially since there are a million ways to build/deploy with pretty limited configuration. If you are using circle it’s helpful, but even then, for most personal projects I am happy using Firebase/Zeit/Netlify. Docker is (in my experience) lower level than you need for front end deployment.
This! But for all the good things I've heard about Docker, I should definitely start looking into it.
Machine learning, AI, and Blockchain. I'm happy to be aware of what they are and their implications but have no desire to learn them deeply (deep learning?). I'm very confident I can be successful as a technologist without ever training a custom machine learning model.
Ha, true, I think the stigma of those mentioned have become slightly worse over time, now that it has somewhat turned into buzzwords. I see ads of a phone with "AI" camera and it made me cringe a little. But the tech behind it is always interesting to me.
Git.
Nah just kidding. For me it's probably golang, it's used at my job but I don't like it at all. It may be fast but it's really ugly and hard to reason about.
The language may be ugly but the mascot isn't tho! Yes, lots of people have been praising Golang for its speed, not much on the language I think.
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)
A little bit OOT; speaking of NodeJS, I just watched a video about the history of Node and NPM from the JSEUConf. It's really good to learn how things have evolved around NodeJS for the past 10+ years youtube.com/watch?v=MO8hZlgK5zc. There is hope!
React and Vue
Oracle. Every Oracle thing I've encountered in the wild has been inflexible as to be borderline useless. Might just be the implementations I've seen, but wow is it frustrating
I find it interesting how Angular does the scaffolding built-in, I think it really helps keeping everything under the same standard and structure 👍🏻
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.