4 ms·

Look, you're kinda confusing things. For instance, I work in a lot of projects with Django on the backend and Angular or React on the frontend. The gist of al

Look, you're kinda confusing things. For instance, I work in a lot of projects with Django on the backend and Angular or React on the frontend. The gist of all that stuff is: REDUCING COMPLEXITY. Tying your hands, so you can free your mind. As Django and Rails are a way to better organize stuff on the backend, so are those frameworks a way to organize stuff on the frontend. For instance, take React+Redux or Vue+Vuex: you bind all the transformations on your UI to a single object. All stuff that happens on the UI is a consequence of a transformation on that object. So: 1) You just gained undo/redo, if you track alterations on your object. 2) You know the state of your application at all times, just looking at the object. You can also keep it and save it for later use. Now, compare that to something you would do on jQuery. It is a great tool, but it wasn't built with that complexity in mind. So pretty soon you're dealing with actions happening in 5 different places. It gets way harder to wrap your head around it.

nemild 9y ago
But just to be clear, it's really a function of what you're building. The answer isn't simply Angular/React good, jQuery bad. (And I'm sorry if I'm being too reductionist) For example, I'm shocked how many simple static sites are built with React. It makes sense for complex sites, especially with realtime, but it also adds complexity and maintenance issues. Like all engineering decisions, you have to be thoughtful about the tradeoffs.
- folkhack 9y ago
  > But just to be clear, it's really a function of what you're building. 110% agree here. Sometimes I just need a simple selector/UI event lib and don't want to fart around with the verbosity of vanilla JS - so I still pull jQuery (slimmed) in for a some things these days. It's non-opinionated with how I use it and it's almost universally understood by JS frontend devs. It's also very cross-platform friendly. Now for Angular, React, Vue, etc. Some are less opinionated than others, but I spend too much time thinking about how to do something elegantly within the constraints of the framework to "follow suit" with their established best practices. ALSO - I've seen FAR too many of these frameworks fall out of favor over the years: Knockout, Backbone, blah blah. My product lifecycle requires 3-10 years worth of forward maintenance/support/features and for the last decade jQuery is/has been the most stable and widely adopted option. (think Debian stable sorta mentality - I still have 1.* in the wild... on purpose for legacy browser support) > For example, I'm shocked how many simple static sites are built with React. Man - me too. It's like using a pneumatic hammer for a roofing nail. I mean, it works ... but why...?
  - nemild 9y ago
    Ha ha, I think we shared the same journey — and realizations. I wrote some reflections during my last experience: Chasing the Shiny and New https://www.nemil.com/musings/shinyandnew.html https://www.nemil.com/musings/shinyandnew.html
    - folkhack 9y ago
      I laughed out loud at the Atom/Neovim joke at the end - perfect cap to the article =) I very much appreciated that and unanimously agree with you.
andrei_says_ 9y ago
I’m not sure how adding a front-end framework reduces the complexity of static html+css, even if there’s some rudimentary interactivity (menus, carousels for example) handled by jquery. What additional interactivity do you have in mind when you propose a front-end framework?
- imauld 9y ago
  I appreciate the separation of concerns. Being able to deploy the front end for template changes without bringing the whole back end application along for the ride is nice. Additionally if your back end also serves an API for a mobile app (or other third parties via a JSON API) it's nice to be able to serve all your clients via the same endpoints as opposed to having and endpoint for JSON and an endpoint for HTML. You can probably do both of those things without a JS front end but I feel it's more common for monoliths to end up in a spot where they _need_ to be broken up rather than having kept everything isolated and clean from the beginning. That's just my experience though, YMMV of course.
  - andrei_says_ 9y ago
    I see. In my experience so far, MVC provides a good enough separation of concerns and in the absence of an immediate need for an API, it is more economical to build a monolithic app. Avoiding building a second application for the front end offers huge savings. Adding an API is fairly easy (Rails) and Turbolinks offer a great middle ground for native apps.

nemild 9y ago

But just to be clear, it's really a function of what you're building. The answer isn't simply Angular/React good, jQuery bad. (And I'm sorry if I'm being too reductionist) For example, I'm shocked how many simple static sites are built with React. It makes sense for complex sites, especially with realtime, but it also adds complexity and maintenance issues. Like all engineering decisions, you have to be thoughtful about the tradeoffs.

folkhack 9y ago
> But just to be clear, it's really a function of what you're building. 110% agree here. Sometimes I just need a simple selector/UI event lib and don't want to fart around with the verbosity of vanilla JS - so I still pull jQuery (slimmed) in for a some things these days. It's non-opinionated with how I use it and it's almost universally understood by JS frontend devs. It's also very cross-platform friendly. Now for Angular, React, Vue, etc. Some are less opinionated than others, but I spend too much time thinking about how to do something elegantly within the constraints of the framework to "follow suit" with their established best practices. ALSO - I've seen FAR too many of these frameworks fall out of favor over the years: Knockout, Backbone, blah blah. My product lifecycle requires 3-10 years worth of forward maintenance/support/features and for the last decade jQuery is/has been the most stable and widely adopted option. (think Debian stable sorta mentality - I still have 1.* in the wild... on purpose for legacy browser support) > For example, I'm shocked how many simple static sites are built with React. Man - me too. It's like using a pneumatic hammer for a roofing nail. I mean, it works ... but why...?
- nemild 9y ago
  Ha ha, I think we shared the same journey — and realizations. I wrote some reflections during my last experience: Chasing the Shiny and New https://www.nemil.com/musings/shinyandnew.html https://www.nemil.com/musings/shinyandnew.html
  - folkhack 9y ago
    I laughed out loud at the Atom/Neovim joke at the end - perfect cap to the article =) I very much appreciated that and unanimously agree with you.

andrei_says_ 9y ago

I’m not sure how adding a front-end framework reduces the complexity of static html+css, even if there’s some rudimentary interactivity (menus, carousels for example) handled by jquery. What additional interactivity do you have in mind when you propose a front-end framework?

imauld 9y ago
I appreciate the separation of concerns. Being able to deploy the front end for template changes without bringing the whole back end application along for the ride is nice. Additionally if your back end also serves an API for a mobile app (or other third parties via a JSON API) it's nice to be able to serve all your clients via the same endpoints as opposed to having and endpoint for JSON and an endpoint for HTML. You can probably do both of those things without a JS front end but I feel it's more common for monoliths to end up in a spot where they _need_ to be broken up rather than having kept everything isolated and clean from the beginning. That's just my experience though, YMMV of course.
- andrei_says_ 9y ago
  I see. In my experience so far, MVC provides a good enough separation of concerns and in the absence of an immediate need for an API, it is more economical to build a monolithic app. Avoiding building a second application for the front end offers huge savings. Adding an API is fairly easy (Rails) and Turbolinks offer a great middle ground for native apps.