3 ms·
I’m not a JS frameworks expert, too much churn to keep up. I learned Angular 2+ a few years ago and found it to be a bit heavy weight. Thinking of learning Vue
by selimnairb 5y ago
I’m not a JS frameworks expert, too much churn to keep up. I learned Angular 2+ a few years ago and found it to be a bit heavy weight. Thinking of learning Vue 3 now. Svelte looks interesting though. What I am hoping for long term is that the JS/CSS/HTML5 stack will be mature enough and have enough batteries included that I can just write apps using the “standard library” with minimal external libraries. Is that the direction things are going?
- arenaninja 5y agoI used React for 3 years and I'm using Angular for 2 years now; Angular is super heavy handed and gets in your way
- datavirtue 5y agoI have professional experience in Angular and it is simply a framework for building applications. It hits that out of the park. I genuinely tried React and had to ditch it. Way too much drama just to manage state. It is clearly for building components, not applications. I don't think comparing the two is relevant. Angular gets in your way if you are just building components but it unleashes a deluge of productivity instantly if you need to build an application--especially for a team.
- arenaninja 5y agoTo me scaling this Angular codebase has been more challenging than it was to scale React codebases for collaboration across multiple projects and teams. Going through NgModule instead of using plain node packages is my main gripe here; coincidentally this is also what gets in your way if you're trying to build reusable dumb components in Angular I almost like ngrx because it reduces boilerplate, but I don't understand why their createAction helper doesn't follow Flux Standard Action; I can't be convinced this isn't a design flaw
- recursivedoubts 5y agoYou might want to take a look at the HAT stack: https://htmx.org https://htmx.org - server interactions in HTML https://alpinejs.dev https://alpinejs.dev - small front end tweaks in your HTML https://tailwindcss.com https://tailwindcss.com - styling in your HTML This is pretty a simple stack that keeps everything in one file (for something I am calling Locality of Behavior[1]) and all of them are dependency free. full disclosure: I am the author of htmx [1] - https://htmx.org/essays/locality-of-behaviour/ https://htmx.org/essays/locality-of-behaviour/
- fokinsean 5y agoHTMX has been on my radar for a little while. Do you have a starter template with all of these hooked together? Or an example repo?
- recursivedoubts 5y agoThere are example projects in a bunch of different back ends available here: https://htmx.org/server-examples/ https://htmx.org/server-examples/
- dstick 5y ago> This is pretty a simple stack that keeps everything in one file (for something I am calling Locality of Behavior[1]) and all of them are dependency free. Not to be "that" guy but what you're describing is a .vue file. And with a Vue single file component you have 1 dependency: Vue. With HAT you have 3. Or am I missing something?
- arduinomancer 5y agoMy impression of reading [1] is that its just moving the "spooky action at a distance" to a different place. If I see this: <button hx-get="/clicked">Click Me</button> My immediate question is * What actually executes when I click the button? * How can I debug the code that sends the GET request? * How can I customize the GET request and add stuff like custom headers? In the jQuery example all of that is obvious on first glance. I feel like complexity can't be destroyed, only moved around.
- bmuon 5y agoYes and no. Browser differences are mostly disappearing, they have gained some very good APIs are CSS has gained significant layout capabilities with grids and flex. So the need for libraries like jQuery for dealing with DOM differences is disappearing. New standard libraries like Intl and now Temporal make libraries like Moment obsolete. The web is also gaining a component model with Web Components that will help you get some level of sanity when building some mildly complex reusable stuff. This is probably very good for content heavy sites, which make the majority of the web. The other part of the web is applications running on top of the Web platform. Those still heavily benefit from frameworks. Having some amount of sanity when managing state is very much welcome. And functional programming models have proven that a declarative way of approaching UIs is much better than dealing with browser APIs imperatively. So for some years frameworks will still be useful for certain use cases. For the others, we should be embracing Web technologies. Maybe with some light libraries like Stencil and Catalyst.