5 ms·

I'm quite happily and non-fatiguely doing a lot of JS front-end development for my own projects... without any frameworks except a bit of jQuery for DOM manipul

I'm quite happily and non-fatiguely doing a lot of JS front-end development for my own projects... without any frameworks except a bit of jQuery for DOM manipulation. Now, my needs don't quite fit the common interface models anyway, and as I'm doing stuff for technical users, I don't bother with any browser backwards-compatibility. But as far as managing data, behavior, socket communications, and CSS-styled DOM manipulation goes, I have zero desire to enter the morass of heavyweight framework churn. JavaScript is a pretty reasonable language that you can be quite productive with even in the browser for front-end tasks.

mythrwy 9y ago
It's all fun and games until that little bit of jQuery turns into a lot of jQuery. Sometimes you don't have much of a say into how big things eventually get and sometimes things get a whole lot bigger than you initially imagined. Good organization helps but still, as a jQuery fan myself who has gone through this a few times recently I've started to realize there may just be a better way. Particularly throwing more than one dev in the mix. Going through someone else's tangled box of electrical cords is no fun at all.
- vlunkr 9y ago
  I hear this sentiment a lot: that jquery projects inevitably become spaghetti, and I can relate, because I've seen it happen, but I also worked on projects with a great MVC pattern with jquery handling the view and it worked nicely. At a certain size you should look into frameworks, but it's not always necessary.
  - unclebucknasty 9y ago
    >I also worked on projects with a great MVC pattern with jquery handling the view and it worked nicely >At a certain size you should look into frameworks I hear this a lot--the idea that jQuery or vanilla JS can work for smaller projects if well-organized, but larger projects require frameworks--however, I honestly have no idea how it makes sense. Seems to me that if you have a good pattern and foundation, then it should scale up to larger projects; else, what we're really saying is that it's still a mess, but a small mess that's manageable because the project is small and there isn't that much code. But, the framework dogma these days is such that we dare not even suggest undertaking a large project without committing to an "acceptable" framework du juor. I say this as someone who sees some value in frameworks, but also doesn't believe that the ROI is always there, or that it is absolutely necessary to use a framework on even larger projects. After all, frameworks aren't magical. They are just code. More specifically, they are reusable libraries attached to pattern enforcement. Why can't I choose a couple of libs, come up with reusable code, and implement my own patterns without all of the added cruft, opinion, politics, and risk of jumping on someone else's framework? Plus, many frameworks have just gotten way too big and complex, and we too infrequently emphasize the cost of using a framework vs. simply championinig the benefits. I want one-way data binding, but I have to change languages, introduce copious build steps, and generally follow all of your opinionated patterns, introducing layers of cruft and structure? Then, after all of this, you may change course with no upgrade path or the framework may simply become unpopular? No thanks.
    - watwut 9y ago
      Scalling up means more people,new people, and people with different opinions about what is good. It is easier when framework itself encourages common patterns. Own solution tend to be tailored to first use case and work nor as well in general.
      - unclebucknasty 9y ago
        >It is easier when framework itself encourages common patterns It's like developers don't want to design anything these days. Frameworks are generally overkill and, increasingly, insert too much opinionated cruft into a project. How can it possibly always be more efficient to wedge in this singularly opinionated way to implement every app just because the team exceeds n members? There are ways to enforce discipline on larger teams without relying on someone else's ideas.
    - Chris_Newton 9y ago
      I agree with the general argument here. Frameworks have pros and cons, but they aren’t magic, and they certainly aren’t the only way to get good results. Often the challenge in scaling up UI code isn’t the amount of data, it’s the increasing complexity of the relationships between different parts of the data. The more dependencies, the more you have to take into account when you’re updating one part of the UI in response to a change somewhere else. In another comment, le-mark mentioned Brooks’ distinction between essential and accidental complexity, and that applies here as well. A UI needs enough logic to represent the essential complexity in the underlying data, which might be complicated in itself. However, sometimes the UI also introduces accidental complexity to handle transitioning from one state to another. This is why I find the modern rendering libraries like React to be a genuine improvement in the state of the art. They allow rendering based on the absolute state of your system, instead of changing the DOM selectively relative to whatever was already there, which in general may be an exponentially more complicated situation. Adopting this approach can directly and sometimes dramatically reduce the complexity of the UI code, compared to manually changing the DOM in response to changes in the underlying state. The heavyweight frameworks I’ve seen don’t offer that same sort of qualitative improvement. They do provide a systematic architecture, which can certainly be helpful as software grows. On the other hand, we’ve been building much larger software than any web app using good software design principles for decades, without necessarily needing the help of these pervasive frameworks. The trade-off with frameworks usually seems to be a quicker start time as the big advantage against potentially being less flexible if the project’s needs change later as the big disadvantage, but since neither of these issues is unique to frameworks this feels like a quantitative question more than a qualitative one.
- jondubois 9y ago
  True, a good framework serves to standardize the parts of the code that are generic and makes the project easier for new developers to pick up. I think that without frameworks, software developers would not have been able to move between companies so easily and salaries would not have gone up so much.
- white-flame 9y ago
  Can you explain that a bit more? I've been building various web UIs for quite a few years, and the jQuery parts are generally just simple calls whenever the DOM needs to be updated, or when an action needs to recollect some UI state to carry out actions. Most state is held in the JS data structures, and the UI simply reflects it through pretty basic transformations. I don't quite understand the model of writing that would lead to massively tangled jQuery code. Obviously, I'm building internal use and personal projects, but I also design my UI elements based on what HTML/CSS already offers, instead of trying to force foreign designs & models on it. Of course, JS & front-end development isn't my primary domain. Backend distributed non-web servers, data analysis, and software automation is more my thing. Front ends are just a side requirement of completing the loop sometimes, but software manageability issues at scale aren't unfamiliar to me. I just don't see how people can tangle themselves up as much as they have across the board in the web front end domains.
  - mythrwy 9y ago
    LOL. I remember saying almost exactly the same things and not long ago! It's not necessarily a matter of "tangled up" (although that happens also with size if one isn't careful). It's more a matter of very unwieldy to work with and a lot of cognitive overhead. The few "updating DOM" things turn into hundreds, the callbacks multiply, "what function was it that did this? What file was that in?", the bindings start tripping over each other, it quickly turns into another level of problem at size and when it gets to the point it does it's big enough to be real work to refactor. At the scale you are talking about sure, raw HTML, a handful of global functions doing this and that and a few arrays and objects holding data, no problem. If you have (or work with) something of a different scale using jQuery I'm pretty sure you'll see for yourself and come to the realization I have. There's a reason for the rise of these frameworks and it isn't all fancy hipster nonsense. Well not all of it anyway :)

mythrwy 9y ago

It's all fun and games until that little bit of jQuery turns into a lot of jQuery. Sometimes you don't have much of a say into how big things eventually get and sometimes things get a whole lot bigger than you initially imagined. Good organization helps but still, as a jQuery fan myself who has gone through this a few times recently I've started to realize there may just be a better way. Particularly throwing more than one dev in the mix. Going through someone else's tangled box of electrical cords is no fun at all.

vlunkr 9y ago
I hear this sentiment a lot: that jquery projects inevitably become spaghetti, and I can relate, because I've seen it happen, but I also worked on projects with a great MVC pattern with jquery handling the view and it worked nicely. At a certain size you should look into frameworks, but it's not always necessary.
- unclebucknasty 9y ago
  >I also worked on projects with a great MVC pattern with jquery handling the view and it worked nicely >At a certain size you should look into frameworks I hear this a lot--the idea that jQuery or vanilla JS can work for smaller projects if well-organized, but larger projects require frameworks--however, I honestly have no idea how it makes sense. Seems to me that if you have a good pattern and foundation, then it should scale up to larger projects; else, what we're really saying is that it's still a mess, but a small mess that's manageable because the project is small and there isn't that much code. But, the framework dogma these days is such that we dare not even suggest undertaking a large project without committing to an "acceptable" framework du juor. I say this as someone who sees some value in frameworks, but also doesn't believe that the ROI is always there, or that it is absolutely necessary to use a framework on even larger projects. After all, frameworks aren't magical. They are just code. More specifically, they are reusable libraries attached to pattern enforcement. Why can't I choose a couple of libs, come up with reusable code, and implement my own patterns without all of the added cruft, opinion, politics, and risk of jumping on someone else's framework? Plus, many frameworks have just gotten way too big and complex, and we too infrequently emphasize the cost of using a framework vs. simply championinig the benefits. I want one-way data binding, but I have to change languages, introduce copious build steps, and generally follow all of your opinionated patterns, introducing layers of cruft and structure? Then, after all of this, you may change course with no upgrade path or the framework may simply become unpopular? No thanks.
  - watwut 9y ago
    Scalling up means more people,new people, and people with different opinions about what is good. It is easier when framework itself encourages common patterns. Own solution tend to be tailored to first use case and work nor as well in general.
    - unclebucknasty 9y ago
      >It is easier when framework itself encourages common patterns It's like developers don't want to design anything these days. Frameworks are generally overkill and, increasingly, insert too much opinionated cruft into a project. How can it possibly always be more efficient to wedge in this singularly opinionated way to implement every app just because the team exceeds n members? There are ways to enforce discipline on larger teams without relying on someone else's ideas.
  - Chris_Newton 9y ago
    I agree with the general argument here. Frameworks have pros and cons, but they aren’t magic, and they certainly aren’t the only way to get good results. Often the challenge in scaling up UI code isn’t the amount of data, it’s the increasing complexity of the relationships between different parts of the data. The more dependencies, the more you have to take into account when you’re updating one part of the UI in response to a change somewhere else. In another comment, le-mark mentioned Brooks’ distinction between essential and accidental complexity, and that applies here as well. A UI needs enough logic to represent the essential complexity in the underlying data, which might be complicated in itself. However, sometimes the UI also introduces accidental complexity to handle transitioning from one state to another. This is why I find the modern rendering libraries like React to be a genuine improvement in the state of the art. They allow rendering based on the absolute state of your system, instead of changing the DOM selectively relative to whatever was already there, which in general may be an exponentially more complicated situation. Adopting this approach can directly and sometimes dramatically reduce the complexity of the UI code, compared to manually changing the DOM in response to changes in the underlying state. The heavyweight frameworks I’ve seen don’t offer that same sort of qualitative improvement. They do provide a systematic architecture, which can certainly be helpful as software grows. On the other hand, we’ve been building much larger software than any web app using good software design principles for decades, without necessarily needing the help of these pervasive frameworks. The trade-off with frameworks usually seems to be a quicker start time as the big advantage against potentially being less flexible if the project’s needs change later as the big disadvantage, but since neither of these issues is unique to frameworks this feels like a quantitative question more than a qualitative one.
jondubois 9y ago
True, a good framework serves to standardize the parts of the code that are generic and makes the project easier for new developers to pick up. I think that without frameworks, software developers would not have been able to move between companies so easily and salaries would not have gone up so much.
white-flame 9y ago
Can you explain that a bit more? I've been building various web UIs for quite a few years, and the jQuery parts are generally just simple calls whenever the DOM needs to be updated, or when an action needs to recollect some UI state to carry out actions. Most state is held in the JS data structures, and the UI simply reflects it through pretty basic transformations. I don't quite understand the model of writing that would lead to massively tangled jQuery code. Obviously, I'm building internal use and personal projects, but I also design my UI elements based on what HTML/CSS already offers, instead of trying to force foreign designs & models on it. Of course, JS & front-end development isn't my primary domain. Backend distributed non-web servers, data analysis, and software automation is more my thing. Front ends are just a side requirement of completing the loop sometimes, but software manageability issues at scale aren't unfamiliar to me. I just don't see how people can tangle themselves up as much as they have across the board in the web front end domains.
- mythrwy 9y ago
  LOL. I remember saying almost exactly the same things and not long ago! It's not necessarily a matter of "tangled up" (although that happens also with size if one isn't careful). It's more a matter of very unwieldy to work with and a lot of cognitive overhead. The few "updating DOM" things turn into hundreds, the callbacks multiply, "what function was it that did this? What file was that in?", the bindings start tripping over each other, it quickly turns into another level of problem at size and when it gets to the point it does it's big enough to be real work to refactor. At the scale you are talking about sure, raw HTML, a handful of global functions doing this and that and a few arrays and objects holding data, no problem. If you have (or work with) something of a different scale using jQuery I'm pretty sure you'll see for yourself and come to the realization I have. There's a reason for the rise of these frameworks and it isn't all fancy hipster nonsense. Well not all of it anyway :)