6 ms·

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.

by udp 11y ago

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 https://github.com/Raynos/mercury

merb 11y ago
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 11y ago
  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.
Touche 11y ago
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 11y ago
  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 11y ago
    Or you could just have written a .ts.d file?
ufo 11y ago
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/ http://google.github.io/incremental-dom/
- leeoniya 11y ago
  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 11y ago
    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.
sergiotapia 11y ago
Great in theory, horrible in practice. How much time did you spend setting up the plumbing for the project? That's key.
- Cartwright2 11y ago
  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 11y ago
    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 11y ago
    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).
  - deleted 11y ago
    [deleted]
- sergiotapia 11y ago
  @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 https://github.com/kriasoft/react-starter-kit
cageface 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
        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 11y ago
    Until they rewrite everything, like angular 1 to angular 2.
leeoniya 11y ago
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 https://github.com/leeoniya/domvm [2] http://leeoniya.github.io/domvm/test/bench/dbmonster/ http://leeoniya.github.io/domvm/test/bench/dbmonster/
developit 11y ago
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 11y ago
  look into a animation demo , like react-gsap-enhancer

by udp 11y ago

merb 11y ago

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 11y ago
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.

Touche 11y ago

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 11y ago
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 11y ago
  Or you could just have written a .ts.d file?

ufo 11y ago

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/ http://google.github.io/incremental-dom/

leeoniya 11y ago
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 11y ago
  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.

sergiotapia 11y ago

Great in theory, horrible in practice. How much time did you spend setting up the plumbing for the project? That's key.

Cartwright2 11y ago
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 11y ago
  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 11y ago
  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).
- deleted 11y ago
  [deleted]
sergiotapia 11y ago
@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 https://github.com/kriasoft/react-starter-kit

cageface 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
  Until they rewrite everything, like angular 1 to angular 2.

leeoniya 11y ago

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 https://github.com/leeoniya/domvm [2] http://leeoniya.github.io/domvm/test/bench/dbmonster/ http://leeoniya.github.io/domvm/test/bench/dbmonster/

developit 11y ago

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 11y ago
look into a animation demo , like react-gsap-enhancer