[udp]

We don't need smaller frameworks, we need more modular frameworks. If the framework is modular you can take what you need, and replace the parts you don't like.

I'm using mercury [0] in my current frontend project for this purpose. Most of the features of React, none of the commitment. Every single component is interchangeable; the core repository is simply an index.js requiring other modules, which can be depended on individually if you're not looking for a kitchen sink solution.

[0] https://github.com/Raynos/mercury

[cageface]

I prefer opinionated, integrated frameworks. I can count on the whole stack being well tested and don't have to worry about subtle bugs and versioning issues between components.

The JS community has gone way overboard on factoring everything into a dozen little submodules, IMO.

[sotojuan]

While I feel like I'm close enough to tame the React ecosystem (and like it!), I honestly agree. Personally I do prefer opinionated. Luckily Ember exists in the JS world.

[orf]

Ember is awesome, it doesn't seem to get much love on HNews though. Which is a shame because its really really good - I tried react and spent 2 days messing with various starter packs, trying to get webpack configured and not getting anywhere. Ember took me half an hour to get started.

[sotojuan]

Not just HN. I rarely see it mentioned elsewhere. Even in those "JS fatigue" articles which is funny because Ember is the antidote to that.

[szines]

Because Ember devs already found the best tool years ago and they are super productive. The community is huge and super active but they definitely totally ignore this "fatigue" bullshit... you know, if you found your love of your life, you don't go any more in the dance club to chase other boys/girls... ;)

[jbergens]

Until they rewrite everything, like angular 1 to angular 2.

[szines]

Ember 2 was released middle of last year and the transition was super smooth. Ember's update pipeline is strict and the backward compatibility is serious. Big startups and corporates are switching to Ember, because they want results... Luckily, we can say, at the moment Ember.js is at least 1 year, but more likely 2 years ahead of other js libraries and frameworks. The framework really matured, the best bet nowadays if someone plan to build larger frontend application.

[boubiyeah]

So agree.

Mercury has the classical issues of wrapper models too, whereas with something like flux or similar, you can easily work with good ol JSON.

virtual-dom is a pretty nice lib though, and a strong foundation for people willing to create their alternative, opinionated lib.

[Touche]

Mercury fans always say this but I'm never seen anyone swap out random libraries it uses, like dom-delegator. Stuff is still made to be used together, you could swap out dom-delegator if your version had the exact same API, but then what would be the point.

[udp]

When I ported my frontend to TypeScript I swapped out the whole observ* suite for my own typed observables. Sure, some of the components are too specific to replace trivially, but then those most likely aren't the ones you're interested in replacing.

Decomposing your code into modules is step one. Making the interface between your modules generic enough to easily replace is the next problem, but if your code is a monolithic blob in the first place that's not going to be possible.

My main issue with modularity in JavaScript is the lack of strict typing, because you won't know if your interface fits correctly until runtime - which is why I've been looking into TypeScript and Elm recently.

[igl]

Or you could just have written a .ts.d file?

[developit]

Hiya! author here. I have used Mercury and Mithril, both are great. I personally think there is a use-case for both modular and batteries-included libraries. There's an open issue for modularizing preact in the tracker that'll be addressed shortly if that helps.

[taivare]

look into a animation demo , like react-gsap-enhancer

[sergiotapia]

Great in theory, horrible in practice.

How much time did you spend setting up the plumbing for the project? That's key.

[sergiotapia]

@Cartwright2: Meteor is heading in that direction with version 1.3. Cohesive toolchain that integrates the best from the Javascript world, that is modular if you want, but ultimately a fantastic developer UX designed for happiness and productivity.

Everything will just work with defaults. Not like this travesty: https://github.com/kriasoft/react-starter-kit

[Cartwright2]

I think, and hope, that the "modularity" of the Javascript ecosystem will lead to extreme decision fatigue, followed by a doubling-down on the best individual modules, aggregation into larger, monolithic frameworks that work well, and finally an increase in developer productivity and standardization of the choices of frameworks. At this point, the Javascript field will no longer be in shambles as it is today.

All it will really take is one person to merge, say, React with a boilerplate-reduxed Flux framework, a REST library, and a handful of other must-haves, under a single, new product name. Let's call it "Rimble". When people realize they can "import { Component, Actions } from Rimble" we'll see a shift towards monolithic frameworks and the ball will start rolling back in the right direction.

[jamesism]

There is absolutely nothing stopping people aggregating modular pieces into boilerplates that work well. Developer productivity isn't some entity manifest from a singular repetitive workflow. That sounds to me like an appeal to create dumb cogs of critical thinkers.

Can you justify why 'monolithic frameworks' is the right direction?

[developit]

You could take 10 seconds and write 1-line modules to abstract your specific imports - "import Component from 'mycomponent'". This is not a valid argument in favor of modularity or small modules (and I love small modules).

[merb]

then you should look at this library. Currently I'm skeptical about every js library, however this library makes a lot of things good.

Especially by using ES6. Also these guys made some cool addon libraries that are as small as the core library.

The only thing I dislike is that the core library is a single source file. Why do people create source files with < 1000 lines..

[developit]

It started as a CodePen. Thankfully, someone switched the build to use Rollup, which makes it very easy to move things around. Modular structure (in terms of files) will be part of the 3.0 major bump.

[ufo]

I recently found out about incremental-dom[1], a very small library that just does the "dom updating" algorithm. Its very low level and does not rely on keeping around a "virtual dom tree" so its supposedly very interoperable. Does anyone here have any experience with it?

[1] http://google.github.io/incremental-dom/

[leeoniya]

incremental dom is extremely low level, so low that it's basically DOM assembly. it is not practical and is actually not that fast. many other vdom libs are both more useable and faster.

check out vidom, kivi, citojs, domvm (mine), etc...

domvm is actually one level above pure vdom libs and a level below frameworks. it offers a very fast, stateful and reusable view layer over a vdom diffing engine. it was written to solve some architectural disagreements and speed issues i had with using Mithril MVC for several projects.

[boubiyeah]

Yep; It's also in a completely different category, on its own. incremental-dom's API is very imperative, so completely different from React & others design goal.

[leeoniya]

try domvm [1] it's maturing fast, 8k min, isomorphic, has pure js templates, is extremely quick [2] and allows you to write truly reusable imperative/declarative components. disclaimer: mine.

[1] https://github.com/leeoniya/domvm

[2] http://leeoniya.github.io/domvm/test/bench/dbmonster/