I want to point out that it works perfectly fine making a JavaScript web app in just vanilla JavaScript using NodeJS as server and the browser as client. You do not need any frameworks!! Vanilla JavaScript works for both small projects and big projects. And it performs well! (at least compared to the popular frameworks) and it's very nice to debug! There is no complication step! And your code will be supported for ever unlike the framework's that will make your code obsolete within a year or so.
"And your code will be supported for ever unlike the framework's that will make your code obsolete within a year or so."
This is a confusing assertion. How does using a framework make your software unsupported in ways that not using a framework would not? i.e. if I build an application, whether I use a framework or not, and then I stop touching it, forever, why is the non-framework code more resilient to not breaking in the future?
The framework will keep evolving, but you're under no obligation to upgrade, if you don't need to keep developing. It seems silly to complain about the code you didn't have to write.
There are trade offs when using existing software to do things you want to do, sure. But, you get the core web app functionality you needed to implement, anyway, and it's been tested by a lot more developers than your code likely ever will be. In fact, I'd argue compatibility with a framework will be better than implementing it yourself, assuming you cover the same amount of functionality in each app; again, because of the heavier testing a widely used framework gets.
The devil is in the details. From experience, upgrading framework code is time-consuming. It's mainly because frameworks have a layer of architecture that you app needs to adhere to. When the architecture changes, so must the app.
When you roll your own, that is a non-issue. You can switch out libraries as you wish. I have made several major refactorings on my client's app with significantly less pain than it took to upgrade my previous clients' framework-based (i.e. Rails, angular) codebases.
When you roll your own, you can wait until libraries mature, or you can choose to use snippets of the essential code (thereby avoiding bloat).
I utilize patterns that minimize structural architecture, by utilizing dependency injection, es6 modules, promises, async/await, factory methods, agents with events. I avoid classes by utilizing factory methods.
I don't see how it can be. You've got to build and maintain it yourself now, instead of relying on a huge community of volunteers. If you're OK maintaining the entirety of the view layer framework (or whatever) yourself, where's the harm in starting from a known-good state? If you don't want to upgrade but want to add new features to the framework you picked, you can fork it and do that.
Now, if you don't like a given framework, having a framework is a loss because it'll suck to work on. I've seen this a ton. But, that's not the same problem and one that can be avoided by doing an extra day or two of due diligence and building a simple app before settling on your favorite. I dunno about you, but I've built libraries that I decided I hated after I was done with them. Sometimes, I rewrote them after I figured out why I was originally wrong about what I like, and sometimes I spent more time finding an appropriate replacement that somebody else made (this is usually the better choice).
Being able to upgrade the frameworks and platforms you choose to use is a legitimate concern.
When did you ever build a relevant application and stop touching it, forever? Any worthwhile software I've ever built has been maintained with continuous effort. On the web especially, "don't keep developing" is just a death sentence.
I'm not suggesting stopping development, I'm saying that the code you got for free (without any dev time) is not a loss, even if you have to do a little extra work to handle upgrades down the road. It's completely nonsensical to say obsolescence is a reason to not use a framework.
There's like this weird disconnect in this conversation where we're talking about code that has very low cost to adopt (the framework, where the cost is a day or three or whatever learning how to use it) vs. code that probably has a much higher cost to initially develop from scratch (definitely more than a day or three or whatever, assuming similar functionality; probably weeks, once bug-fixing and cross-browser compatibility is solved).
I mean it seems like basic math, to me. It takes X time (+ ~1 day) to deploy with a framework, while it takes X + Y time to implement the app and the framework your app uses (where Y is however long it takes to implement the functionality the framework would have given you). I mean, you're using a framework no matter what; either you use an off-the-shelf one that cost a couple days to learn, or you're building it and maintaining it yourself. How can the framework lose in this math unless it just isn't very good at the tasks it sets out to solve?
You may have to do something about the framework in the future, to keep moving forward, but you must do something about your own framework to keep moving forward. If the third party framework you choose is abandoned or forces a migration (ala Angular), you're still not further behind than the framework you built yourself...because you can still develop the third-party framework yourself. It's not a black box.
You're signing on to do all of the development work going forward if you choose to build your own framework. You only might need to deal with major changes or long-term maintenance costs, in the off-the-shelf framework.
Unless you're only building a tiny app, there's no way this works out in your favor in terms of time-to-launch or in terms of ongoing maintenance. The small frameworks under discussion are single-digit thousands of lines of code; optimistically, that's weeks of work to replicate. And, it's hard to say you're not going to need to implement most of the functionality of a view layer library like Vue or React, if you're building an SPA.
I mean, we're not talking about kitchen sink application frameworks here, where the cost of adoption might be high because the learning curve is high (and even then sometimes the math still works out in their favor if your app very closely matches the strengths of the framework...e.g. RoR did this for the backend; it is huge and learning it takes weeks, but a skilled RoR developer can be incredibly productive). This is a pick-and-choose kinda thing. You've got a few legos you can throw into a project to solve the obvious "everyone has to solve it" problems. And, then you build the real app, which does the unique stuff. You get more time for the unique stuff.
I dunno, it just seems backward to ignore everything good out there in the ecosystem because you're afraid you might have to change your code in the future to keep using the latest version of the library or framework, or whatever.
I want to point out that it works perfectly fine making a JavaScript web app in just vanilla JavaScript using NodeJS as server and the browser as client. You do not need any frameworks!!
You just end up inventing your own framework this way. You'll come across problems, come up with some solution you think is clever, come up with conventions to follow etc. Surprise! You've just manually rediscovered all the problems frameworks were created to solved and reinvented the wheel.
I'll use vanilla JavaScript or jQuery if the UI required is really basic but anything beyond that, you're going to save time using a well thought out framework rather than thinking you're smarter than whole communities who have spent years working on these solutions. Coders don't invent frameworks for the sake of it, they exist for a reason.
Comments
I want to point out that it works perfectly fine making a JavaScript web app in just vanilla JavaScript using NodeJS as server and the browser as client. You do not need any frameworks!! Vanilla JavaScript works for both small projects and big projects. And it performs well! (at least compared to the popular frameworks) and it's very nice to debug! There is no complication step! And your code will be supported for ever unlike the framework's that will make your code obsolete within a year or so.
"And your code will be supported for ever unlike the framework's that will make your code obsolete within a year or so."
This is a confusing assertion. How does using a framework make your software unsupported in ways that not using a framework would not? i.e. if I build an application, whether I use a framework or not, and then I stop touching it, forever, why is the non-framework code more resilient to not breaking in the future?
The framework will keep evolving, but you're under no obligation to upgrade, if you don't need to keep developing. It seems silly to complain about the code you didn't have to write.
There are trade offs when using existing software to do things you want to do, sure. But, you get the core web app functionality you needed to implement, anyway, and it's been tested by a lot more developers than your code likely ever will be. In fact, I'd argue compatibility with a framework will be better than implementing it yourself, assuming you cover the same amount of functionality in each app; again, because of the heavier testing a widely used framework gets.
The devil is in the details. From experience, upgrading framework code is time-consuming. It's mainly because frameworks have a layer of architecture that you app needs to adhere to. When the architecture changes, so must the app.
When you roll your own, that is a non-issue. You can switch out libraries as you wish. I have made several major refactorings on my client's app with significantly less pain than it took to upgrade my previous clients' framework-based (i.e. Rails, angular) codebases.
When you roll your own, you can wait until libraries mature, or you can choose to use snippets of the essential code (thereby avoiding bloat).
I utilize patterns that minimize structural architecture, by utilizing dependency injection, es6 modules, promises, async/await, factory methods, agents with events. I avoid classes by utilizing factory methods.
http://www.briantakita.com/posts/sveltejs-from-riotjs/
"When you roll your own, that is a non-issue."
I don't see how it can be. You've got to build and maintain it yourself now, instead of relying on a huge community of volunteers. If you're OK maintaining the entirety of the view layer framework (or whatever) yourself, where's the harm in starting from a known-good state? If you don't want to upgrade but want to add new features to the framework you picked, you can fork it and do that.
Now, if you don't like a given framework, having a framework is a loss because it'll suck to work on. I've seen this a ton. But, that's not the same problem and one that can be avoided by doing an extra day or two of due diligence and building a simple app before settling on your favorite. I dunno about you, but I've built libraries that I decided I hated after I was done with them. Sometimes, I rewrote them after I figured out why I was originally wrong about what I like, and sometimes I spent more time finding an appropriate replacement that somebody else made (this is usually the better choice).
Being able to upgrade the frameworks and platforms you choose to use is a legitimate concern.
When did you ever build a relevant application and stop touching it, forever? Any worthwhile software I've ever built has been maintained with continuous effort. On the web especially, "don't keep developing" is just a death sentence.
I'm not suggesting stopping development, I'm saying that the code you got for free (without any dev time) is not a loss, even if you have to do a little extra work to handle upgrades down the road. It's completely nonsensical to say obsolescence is a reason to not use a framework.
There's like this weird disconnect in this conversation where we're talking about code that has very low cost to adopt (the framework, where the cost is a day or three or whatever learning how to use it) vs. code that probably has a much higher cost to initially develop from scratch (definitely more than a day or three or whatever, assuming similar functionality; probably weeks, once bug-fixing and cross-browser compatibility is solved).
I mean it seems like basic math, to me. It takes X time (+ ~1 day) to deploy with a framework, while it takes X + Y time to implement the app and the framework your app uses (where Y is however long it takes to implement the functionality the framework would have given you). I mean, you're using a framework no matter what; either you use an off-the-shelf one that cost a couple days to learn, or you're building it and maintaining it yourself. How can the framework lose in this math unless it just isn't very good at the tasks it sets out to solve?
You may have to do something about the framework in the future, to keep moving forward, but you must do something about your own framework to keep moving forward. If the third party framework you choose is abandoned or forces a migration (ala Angular), you're still not further behind than the framework you built yourself...because you can still develop the third-party framework yourself. It's not a black box.
You're signing on to do all of the development work going forward if you choose to build your own framework. You only might need to deal with major changes or long-term maintenance costs, in the off-the-shelf framework.
Unless you're only building a tiny app, there's no way this works out in your favor in terms of time-to-launch or in terms of ongoing maintenance. The small frameworks under discussion are single-digit thousands of lines of code; optimistically, that's weeks of work to replicate. And, it's hard to say you're not going to need to implement most of the functionality of a view layer library like Vue or React, if you're building an SPA.
I mean, we're not talking about kitchen sink application frameworks here, where the cost of adoption might be high because the learning curve is high (and even then sometimes the math still works out in their favor if your app very closely matches the strengths of the framework...e.g. RoR did this for the backend; it is huge and learning it takes weeks, but a skilled RoR developer can be incredibly productive). This is a pick-and-choose kinda thing. You've got a few legos you can throw into a project to solve the obvious "everyone has to solve it" problems. And, then you build the real app, which does the unique stuff. You get more time for the unique stuff.
I dunno, it just seems backward to ignore everything good out there in the ecosystem because you're afraid you might have to change your code in the future to keep using the latest version of the library or framework, or whatever.
http://vanilla-js.com/
You just end up inventing your own framework this way. You'll come across problems, come up with some solution you think is clever, come up with conventions to follow etc. Surprise! You've just manually rediscovered all the problems frameworks were created to solved and reinvented the wheel.
I'll use vanilla JavaScript or jQuery if the UI required is really basic but anything beyond that, you're going to save time using a well thought out framework rather than thinking you're smarter than whole communities who have spent years working on these solutions. Coders don't invent frameworks for the sake of it, they exist for a reason.