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.
Top comments (93)
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
Some comments may only be visible to logged-in visitors. Sign in to view all comments.