5 ms·

I've been struggling with the thought that both react and vue feel wrong when writing. Vue seems quickier but things like emit feel gross. React is kinda fun

• MuffinFlavored 8y ago
  I agree with you. What are your thoughts on https://github.com/hyperapp/hyperapp https://github.com/hyperapp/hyperapp ?
  • joobus 8y ago
    V2 is coming relatively soon, and will have breaking changes.
• tejohnso 8y ago
  >...turn ugly when you start breaking down components into smaller and smaller components. Care to elaborate? This seems opposite to how components ought to work.
  • wolco 8y ago
    Take a table that is broken into rows then cells, within the cell you have a media object within that you have a list with items. Each of those become separate components. Can you reuse them, yes but it would be more helpful to keep them in one component.
    • crooked-v 8y ago
      So keep them in one component.
    • fastball 8y ago
      You can keep them in one component. Nobody is making you split every single object into discrete components.
    • kccqzy 8y ago
      Then don't split them. If you use powerful methodologies to keep track of complex state in one component, not splitting is generally easier too, although you will lose slightly on performance. No one forces you split a component into multiple ones. I've implemented entire games in just one component with logic cleanly described by a finite state machine.
      • pnloyd 8y ago
        Reading this makes me feel better I make large monolothic components. Most examples would have you believe doing so is a big no no.
• trevyn 8y ago
  Thoughts on Mithril?
  • RodericDay 8y ago
    Mithril is incredible.
  • seabass 8y ago
    I rewrote a ~30k line React app in Mithril and since then it's been my go-to view library. It's not mentioned here often, which is surprising given how nice it is to work with. The biggest improvements for my workflow have been closure components and the css selector syntax. Closure components let you use closures to hold state, which ends up being a very elegant pattern. In react: class Square extends React.Component { constructor(props) { super(props); this.state = { value: null, }; } render() { return ( <button className="square" onClick={() => this.setState({value: 'X'})} > {this.state.value} </button> ); } } Is roughly equivalent to the following mithril code: function Square() { const state = { value: null }; return { view() { return ( m('button.square', { onclick() { state.value = 'X'; } }, state.value); ); } } } Notice that the closure gives us access to the state without needing to know what `this` refers to. You can also see the selector syntax in the mithril hyperscript above (`'button.square'`). That becomes especially nice if you're using an approach like tachyons for css, where simple classes are layered to create a style. I use this all the time for layout, which in react I would have created a bunch of stateless components for. Also worth noting: we happen to be directly mutating state in this example, but since mithril isn't opinionated about that you could really store and update your state however you please. Also, for quick projects that don't justify all the cruft that you get with `create-react-app`, it's nice to be able to just use a framework with no build steps whatsoever.
  • bostonvaulter2 8y ago
    Mithril felt really slow to load for me, using it on a little hobby site and was not impressed with it's page-load performance.
• paulddraper 8y ago
  There's Angular 2+, which largely follows the Shadow DOM + Web Components specs.
• fny 8y ago
  Just because a framework/language gives you a tool, doesn't mean you need to use it. Instead of emit, you can easily track state in a Vuex store and then have that change propagate to the required components.
  • wolco 8y ago
    A store could be used and things get cleaner but the overhead increases too much.
  • anonytrary 8y ago
    You can also inject sideways data dependencies in React by using an event emitter. Shitty POC: // global-store.js const remove = (arr, el) => { const i = arr.indexOf(el); if (i < 0) return false; return !!arr.splice(i, 1); } class GlobalStore { constructor(data){ this.data = data; this.subs = []; } sub(cb){this.subs.push(cb)} unsub(cb){remove(this.subs, cb)} notify(newArr){ for (let s of this.subs) s(newArr); } addData(item){ notify(this.data = [...data, item]) } removeData(item){ if (remove(this.data, item)) notify(this.data = [...this.data]) } } // my-component.js import myStore from "./stores" class MyComp extends Component { ... componentDidMount(){ myStore.sub(this._cb = data => { this.setState({data}) }) } componentWillUnmount(){ myStore.unsub(this._cb) } } Obviously, not super optimized, but it's just a POC.
• billmalarky 8y ago
  If you are using Vue for anything other than the most basic use case and are not using Vuex you are not doing things the "best practice" way. Same goes for React without Redux. The frameworks have a strong architecture the moment you introduce the flux architecture (vuex for vue, redux for react). Writing vue/react code w/o flux is like putting your entire application code into the view layer of an MVC app.
  • orangecat 8y ago
    The creator of Redux disagrees: https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4... Writing vue/react code w/o flux is like putting your entire application code into the view layer of an MVC app. You can easily create a model that knows nothing about the view without Vuex/Redux.
    • billmalarky 8y ago
      >You can easily create a model that knows nothing about the view without Vuex/Redux. Sure, but why not use the standard solution for the ecosystem. As far as that linked Abramov post, it felt like a hedge to me. Basically he's saying you don't need redux to write a react app, which is a truism, then lists all the reasons why you should use redux. Redux "code" is a simple library. But if you follow Abramov's architecture opinions that he only implies in the redux guide, you end up with a full highly scalable front-end framework architecture. Plus vanilla react is non-deterministic with state. Redux solves this problem and that alone is worth the price of entry.
• gadfadget 8y ago
  > Vue seems quickier but things like emit feel gross FYI: You can pass a function as a prop in Vue.js too, just like React.
• hkjayakumar 8y ago
  Relevant xkcd [0] [0] https://xkcd.com/927/ https://xkcd.com/927/
• nostalgeek 8y ago
  > I think there is still space for one more framework to rule them all. People should learn to write apps with the DOM, that's the framework to rule them all and it's already in the browser. There no need for a framework to write apps that follow the unidirectional dataflow principle. That principle just need to be taught, like MVC or SOLID.
  • goostavos 8y ago
    Oh my goodness, please no. I already lived through the home-rolled, pure-js, custom frontend "frameworks" made by each team's resident "smart guy" once. I shudder just thinking about those days. React/Angular/framework-whatever are glorious angels protecting us from the tyranny of half-baked, poorly thought out approaches to frontend development.
    • nostalgeek 8y ago
      > Oh my goodness, please no. You don't educate developers to good practices just by abstracting the hard things. You don't need to use React/Angular/Whatever to manage state the right way in a front-end application. You don't need a framework to make code maintainable or testable, or you're just saying front-end developers are so incompetent and undisciplined they need a framework. No they don't, just like one doesn't need a framework like Rails or Spring or Django to write a server app. > React/Angular/framework-whatever are glorious angels protecting us from the tyranny of half-baked, poorly thought out approaches to frontend development. No they are not, they are making the developer ignorant of the underlying DOM architecture.
      • goostavos 8y ago
        Uh oh, I think we found our 'resident smart guy.'
        • nostalgeek 8y ago
          No, i'm not smart, I'm just not ignorant. Learning Django isn't going to make you learn HTTP spec for instance, you know what i'm saying? the same way, learning Angular OR Vue.js will not make you understand how event bubbling or event delegation works. plenty of "full stack" front-end developers out there who know nothing about the DOM.
• bmarkovic 8y ago
  If ($)emit is not something you use for very ephemeral events, that otherwise cannot be expressed as state changes in natural way, or in a custom, reusable component (i.e something you could publish separately from your application), you're using it wrong. I rarely ever use emit and when I do it's either a very active reusable component or a solution for an otherwise very difficult problem. And I don't see what a meaningfully prettier/better API would be.