Starting a new web app project. Wary of bloated frameworks with a gabillion dependencies. I'm a relatively inexperienced developper and I often fee...
For further actions, you may consider blocking this person and/or reporting abuse
Whether or not to use a framework more often than not comes with insight from experience.
For frontend frameworks (Vue, react, etc) I think using them helps when you have complicated business logic and dom manipulation rules. For instance if you have a rule saying if the X = 1 and Y = 3 or Y = 5 and the user does this then show this one widget then frameworks can help make building that out and maintainable much easier. Additional if you have a lot of reusable widgets the components you can make with a framework can save you time. However, there is a price to pay as always. There is more code to ship, and more knowledge someone needs to know to even start coding. Generally speaking the less business logic you have the useful a frontend framework is imo. I have never run into issues with performance with Vue, but using a framework does have overhead and should be considered. Most of the time good UX will prevent the overhead of the framework from being an issue.
For backend frameworks are a bit of a different beast. The backend overall is a lot more complicated and performance is an even larger issue. Here frameworks do two main things: save you time, and structure your code. Some frameworks achieve both, but at the cost of performance usually. I think a backend framework should be used when maintainability and time are the largest concerns. Having a consistent code structure can go a long way in sizable projects.
Hopefully that helps :)
If the amount of investment (time and money) makes sense to use it (either from the get-go or later on after you get the hang of it), using a web framework can be useful.
What I think about when thinking about using/trying out a framework:
Some questions one can ask when considering any framework:
ie: when a framework does a lot of plumbing and forces everyone (from junior to senior) on the team to utilize proven architecture, the framework might save us weeks to build basic functionality so we can focus on creating actual functionality and a product. If the questions above are answered positively and we have a good vision we might do a test project with it and see if it works out.
Thanks for your input. Those are some really good questions to ask yourself, although many of them are hard to answer beforehand. Do you have examples of projects/contexts where the answers to those questions would lead you to determine that using a framework is worthwhile, or not worthwhile?
For sure. I remember a discussion at a previous company that I worked for.
What frontend library should we use for development: Angular, (then still in beta) Aurelia, React was just in its early stage.
By using the questions I mentioned, an intern got to work with it.
He built a small project for all three libraries and tested what worked the fastest.
✅does it connect to the in-house knowledge that I / the company have?
✅how difficult is it to master it? (can we build something quickly with it?)
✅will it speed up development of products?
Using a knowledge matrix that I had been setting up for the team in addition to an inquiry he did about expertise, goals etc. the intern managed to answer a couple of answers more.
✅will it increase the quality and/or maintainability of the product/project?
✅does it have a vision/roadmap that makes it future proof? > for us, as the team that was going to use it...
He also performed an online (desk)research between the options, anwering these questions:
✅does it have enough support from the community and/or the company behind it?
✅is it updated regularly and recently?
✅does it have a vision/roadmap that makes it future proof?
✅what are its biggest competitors/alternatives?
And asking the community and/or the companies behind the frameworks for the last:
✅no hidden costs / efforts?
I believe this was done in a week or two. I agree on your part that this is not easy peasy. It's more than just a matter of Googling during lunchbreak and doing it all within the hour.
I love it. This is a great process to determine which framework/library to choose from. I wonder, how would you modify the process and the questions, if you also wanted to evaluate the possibility of not using a framework at all?
For many of the questions, I would think that vanilla HTML/CSS/JS would be the clear winner, by a long shot, for instance:
If we agree on this, the determination of when to use a framework then depends on the weight we give to the other questions and the way we answer them.
I'm curious, do you see situations where the quality / maintanability of a project would actually be increased by NOT using a framework? Or where the hidden costs / efforts of using a framework would be too great compared to using a vanilla solution.
What I'm especially interested in getting at is the sets of conditions / contexts, that make people decide to use a framework or not.
For example, if the project I'm working on has X views / pages, necessitates X functionality, has X requirements, is expected to last for X amount of time, will have X amount of people working on it, with X amount of experience etc... then I would consider using / not using a framework. You get the idea.
Well, most of the time I use 3-point-estimation to make visible the amount of work that's needed to implement a solution. And an estimation of how many hours it would take to maintain it (rough expert guess).
When looking at frameworks I need to be able to check off enough items of the requirements estimation to make it worthwhile for those hours. If there's more work into it than it saves and there aren't any other obvious benefits (it be on the short- or long term) I'm done with the framework.
Another criterium to bounce off frameworks is:
If I'm in a 5 person company and only 1 knows the language/architecture in which the framework takes a seat, it needs discussion if the team will invest into learning the framework. Often it isn't worth the deal.
But TBH: the critera are more experience based than actual hard figures. No excel sheet that I can sling up for you else I would.
A couple of angles I like to approach these decisions from:
If you're probably going to re-invent most features of React/Vue in your project, consider using them from the start. You probably won't do it better.
If all you need is switching pages without a full reload, use PJAX.
If you have lots of static content but some highly dynamic features in some places, use React/Vue only for those features, and leave the rest to the server. Example: E-Commerce (Mostly page-based, but needs Search-Filters, Checkout etc.)
There is more than Server-Rendered vs. React/Vue. Think WebComponents, Gatsby, Rails, Phoenix.
React/Vue are useful for enforcing certain good development-practises, which may be an advantage depending on the team.
When in doubt, implement a small and well-defined feature from the project in a couple of methods/frameworks and use the experience to decide how to continue.
deciding whether we should use or not a framework on a project depends on the project it's self , in web globally if the project is more statically then dynamically there is no need to use a framework , besides if your content will change permanently and need to be updated , in that case you should .
so we can not cite all case studies where we should use / not use a framework , it's up to the developer to make a decision based on the study he made
So if I understand correctly, for you, the biggest determinant is whether the project will have static or dynamic data. You say "if the project is more statically then dynamically there is no need to use a framework". Can you try to explain what more static than dynamic means to you? Maybe give us an example of a kind of project where you would not use a framework and one where you would.
I've fallen into using SvelteJS for smaller scale projects since I just can't tear myself away from using a component-based system for development. The nice thing about it is all components get compiled down at the build step, so your page just gets loaded in a single bundle.js with server side rendering options that are dead simple to learn.
Because of this, it prevents pages from feeling heavyweight compared to the simple vanilla JS way, but abstracts away a lot of DOM manipulation I would like to avoid if I can.
Here's the thing, you said you're new to web development.
Are you going to setup Babel to transpile everything for cross browser compatibility? Probably not, unless you use a framework. So use a framework.
Also, maybe it isn't always needed, however many who speak out against frameworks are merely uncomfortable using them, and they have trouble understanding some project, rage quit, and post terrible things about frameworks.
Lastly, if it's a standard use case that doesn't need an extra organization beyond VanillaJS, then why aren't you using WordPress (or even Wix)? There are very few situations between these extremes, and most of them are projects that will grow or single code snippets that should be componetized.
Not quite, I said I was relatively inexperienced. I'm familiar with the JS ecosystem and have used Webpack, Babel, Parcel, Rollup, Typescript, NodeJS, Angular, Vue, ExpressJS, NestJS etc... but I'm no expert in any of them and have only been coding, by myself, for three years. I lack professional experience, especially in a team setting. I know the tooling enough to not have to use a framework for the sole purpose of bundling my code for cross browser compatibility.
So, if I understand correctly, if you have a static website to build, don't even bother firing up your code editor and mess with HTML and CSS, just use something like Wix.
On the other hand the minute you start to deal with complexity and would benefit from component reuse, you reach for a framework.
What about Web Components, or light weight libraries that allow for componentization without all the added complexity and bloat of a full-fledged framework? Do you never see any situations where a project's scope and complexity is likely to hover in a way that could make that an interesting middle ground?
I don't really see any use for HTML/CSS by themselves unless it's just to play around (i.e. not in a professional environment). You need something to transform your code to a production ready state, or you're wasting your time. What I mean is, there are tools out there like WordPress that will give you sites that you might be tempted to code with no framework, and they will do it in a way that will handle all of your cross-browser compatibility issues.
I mean if you want to go add --moz prefixes to whichever CSS values need it (looking it up or memorizing it is a task unto itself), then by all means you can spend valuable time doing that, however it won't be as perfect of a product, and it won't work as well as something done with a tool.
I'm no fan of WordPress, and I might not even be making an argument for frameworks per se (even though I'd argue that the "bloat" is often doing something very much worth it). I am definitely making an argument for build tools that will make your code production ready.
I think I can get behind that. Even if I were to consider going framework-less on my next project, I would for sure, at a minimum, use Typescript and Parcel. Probably SCSS too.
There's a difference between front-end and back-end frameworks.
If your app is very task-based then you may not need a front-end framework.
But, a back-end framework I would say is pretty much necessary for any non-trivial applications.
They handle things like:
Trying to build that stuff on your own in a secure way is asking for trouble.
The alternative of "picking and choosing" lots of little libraries to do these things can have serious drawbacks: lack of documentation, lack of support in general, hard to find other developers who are experienced with the tools you chose, lack of holistic integration, etc.
One of the worst things that I keep seeing over-and-over in the industry is this desire to build custom ways to solve problems that have already been solved.
It's always better to spend time researching how other people have solved problems XYZ instead of putting your head down and writing code.
I've seen systems that were built using custom conventions and tools piled on top of each other. These teams will get new hires and have people leave... and now you have a team that has no idea how to even debug the system, build it, or just plain find stuff.
Back-end: use a web framework
Front-end: it depends
I tend to agree with you regarding the use of frameworks on the back-end. I may be wrong but I really feel like they are usually more focused and it's easier to understand how they work under the hood.
I'm more interested in the front-end frameworks for this discussion. You said "it depends". On what? Can you give us examples of projects / situations / contexts where you would choose to use a front-end framework and some where you would choose not to?
If you need a really snappy UI experience then front-end framework is probably the way to go. On the other side of the spectrum is an enterprise task-based app that needs to have top-notch security.
Security agreements in certain industries might actually prevent the use of front-end frameworks in general (I've heard of this but don't have any examples).
Something like this government standard might force you to go with the simple route (no front-end framework).
One might opt not to go with front-end frameworks for the overhead of having to manage multiple projects (front and back), extra build steps, etc.
One reason I love vuejs, for example, is that I don't need to build my entire UI with it. It's super easy to just drop it wherever I need - whether on a specific page, section of a page or even as a mini app within the larger app.
I'm going to talk about the backend, since lots of people are talking about frontend. "Framework" covers a lot of ground. It ranges from Flask, which is basically a request router, and in languages like Go is part of the standard library, to Ruby on Rails or Django which provide logins and sessions, an ORM, and piles of other stuff.
Most backends are wrappers around a relational database. You save time by
2 and 3 aren't really framework material, though libraries to do them may be included in frameworks. So when should you use a backend framework? If you can find a framework that provides a big hunk of your business logic that you then don't have to write yourself without messing up your ability to write the endpoints you need otherwise.
Ultimately any framework is to extract out some of the repetitive work that a set of application (in this case web applications) all have to do in common.
So why not? It is like why not just program in assembly instead of higher level languages. All technologies are build on previous technologies, so take advantage of it instead of reinvent the wheel.
The key is to chose the right framework for your project. The factors to consider are:
You should use a web framework whenever it saves you time.
Yes. Definitely. So can you give us examples of projects / situations / contexts where you would usually determine that a framework would save you time, and others where it would not?
I always use a framework, as I'm experienced with Symfony and that Symfony is actually coming in a small package... I use it whenever I have to make web thing.
For front related work, I'm using jQuery because I know it, I'm not good with vanilla js so I just use jQuery that I know pretty well.
Because as I said, it makes me gain time.
Another example, I actually have to make a small java project with J2EE. I could use Spring but I use J2EE from scratch to learn the tech.
Philippe, our founder chose your awesome question to answer on our YouTube channel. We hope it helps you!
youtu.be/BXt6LXrk_tg
Yeah! Thanks for that. I can't believe I'm a Youtube star now! But seriously, good advice. Shipping the product should be my priority and a framework will help me do that.
I guess it just bugs me that I know how to get things done with Angular but I don't (often) know how Angular gets those things done. If that makes any sense.