20 ms·

There was a previous discussion on how do you know when someone is addicted to over-engineering, and looking at this giant UML diagram, I think this might be th

There was a previous discussion on how do you know when someone is addicted to over-engineering, and looking at this giant UML diagram, I think this might be the case. The amount of complexity I'm willing to accept is proportional to the the difficulty of the problem. In this case it's manipulating web pages, which shouldn't be too hard. This isn't a knock on React in particular, but it seems all the major vendors are competing on complexity. React has "fibers", Ember has a "virtual machine", Angular has their own overblown architecture (I don't know anything about it, and don't want to). Now that the DOM API is implemented in a standards-compliant way across most browsers, it should be the perfect time to use it. I don't like the current mess that is front-end web development, and more of the status quo isn't going to get any simpler, quite the opposite. Shameless plug for my own DOM utility: http://simulacra.js.org http://simulacra.js.org

jacobr 9y ago
The place where complexity should be is exactly in third party library with a simple public API, avoiding as much complexity and optimizations as possible in your own application code.
- daliwali 9y ago
  Why does the third party library need to be so complex? And why should there be complexity in the first place?
  - litzer 9y ago
    Not the OP but my answer to that is because something has to be complex in a large web app. Complexity can be avoided until the number of features reaches some threshold (I don't think there's any debate that it's impossible to avoid complexity entirely if the app is large enough). In those cases, which I think are the majority of use cases, a simple DOM utility like yours would be enough to hide complexity because there wasn't much to begin with. But some of the websites React powers exceed that feature threshold. For example, if multiple sections of a web app want to update at once, the author could leverage React's lifecycle hooks where needed and rely on its reconciler, but if using a simpler library, might have to explicitly schedule each update in a more hacky/less efficient way.
    - daliwali 9y ago
      I think the conventional dogma that one must resort to a framework for a large web app is wrong. Your assumption that simpler is more "hacky" or less efficient, just isn't true. One can use built-in constructs like for loops in vanilla JS to update multiple DOM nodes at once, this yields the most optimal performance. Or one could use React/Redux and setup an action and a reducer and action creator and action type constant and... you see where this is going.
      - litzer 9y ago
        > One can use built-in constructs like for loops in vanilla JS to update multiple DOM nodes at once That's not the kind of use case that'd require React. I think we're on the same page that for the majority of apps, that setup is overkill. I'm just pointing out that there are apps with complex use cases where the "see where this is going" will end up being more elegant/simpler than fleshing out your own constructs (certainly more than a for loop)
rimliu 9y ago
Well, that's like judging a car to be difficult to drive by looking at the listings of all the embedded software in its cpu's. These are details of internal implementation. The public API which you actually use is very very simple. Calling React "DOM utility" does not sound fair. While one of the major problems it solves—slow DOM operations, I'd say that unidirectional data flow is even more important.
- daliwali 9y ago
  Your analogy isn't apt, a better analogy would be judging a car to be difficult to maintain by looking at the listings of all the embedded software. I know a guy who restored a 1960's VW Beetle to working condition with minimal expertise, the same couldn't be done for modern cars without a full machine shop that specialized in that make. Fancy selling points like "unidirectional data flow" don't actually mean anything. Each fanboy has their own variant of this, like "transclusions", "immutables", "dependency injection", etc. These are all phrases I've heard that don't translate to tangible results.
  - matthewmacleod 9y ago
    These are all phrases I've heard that don't translate to tangible results. Yeah… but they do translate to tangible results. Using something like React helps to make front-end code simple, scalable, fast, and testable. The car analogy is even worse. A modern vehicle is better than a 60s Beetle by almost every conceivable metric – performance, emissions, safety. In both of these cases, it is preposterous to assume that complexity was introduced for no reason.
    - daliwali 9y ago
      These are marketing buzzwords that can be said about every single web framework, effectively thought-terminating cliches. Every fanboy says their preferred framework is the simplest, fastest, most scalable and most testable. In the car analogy the improved performance of modern cars have more to do with mechanical engineering than software. And the analogy falls apart when you consider that modern web frameworks are invariably slower or roughly equal in performance to its vanilla JS counterpart, but never faster.
kaoD 9y ago
> looking at this giant UML diagram It's not an UML diagram. Looks more like an ad-hoc flow chart (unless I forgot a specific type of UML diagram that looks like this).
- daliwali 9y ago
  I think it's a UML activity diagram, which is in fact a flow chart.
  - kaoD 9y ago
    I was taught UML activity diagrams were high-level representations, while this is a (summarized) flow chart of code paths (which makes it quite big in comparison to what would be its high-level UML counterpart). UML is supposed to be an architectural diagramming standard. What's the point of diagramming in UML the actual code paths? E.g.: you'd never have object shapes or function calls in an UML activity diagram. This is just an ad-hoc flow chart AFAICT.
TekMol 9y ago
I agree that React introduces way too much complexity. From a quick look at your approach, I have one concern: <template id="product"> <h1 class="name"></h1> ... You seem to use classnames as variable names. What if some other template has a "name" variable too? What if a stylesheet uses it? I prefer simple placeholders. Instead of: <h1 class="name"></h1> I would use: <h1>{{NAME}}</h1>
- daliwali 9y ago
  Using class names was just an example, people may get the wrong impression that has anything to do with the variable name. It could have been made more explicit, but I wanted to be as terse as possible: <h1 class="name" data-bind="name"></h1> It was also a design goal not to introduce a templating syntax, so `{{}}` brackets are out of the question.
  - TekMol 9y ago
    I see now, that the bindObject() function takes a mapper from data to DOM. There are two downsides to this: 1) You have to define twice where the data is displayed. Once in the template and then again in the mapper. 2) <div>{{NAME}}</div> explicitly tells the reader "The name goes here". In your solution one would have to look it up in the mapper to be sure what goes where.
    - daliwali 9y ago
      I'm well aware that there must be an element and a selector for that element. But this is exactly how CSS works as well, it's separation of concerns. Only recently have inline styles become trendy, much to my dismay. The total absence of templating syntax is a deliberate decision. It enables one to start from an HTML mock-up or static page, and build interactivity on top of that without changing any HTML.
      - TekMol 9y ago
        this is exactly how CSS works as well I beg to differ. There is no mapping needed for CSS. CSS works by once defining where the style shall go: <div class=city></div> And once what the style is: .city {color: blue; font-family: arial;} Similar, template syntax once defines where the data shall go: <div class=city>{{NAME}} has {{POPULATION}} residents</div> And once, what the data is: city={name: "New York", population: 8491000} Neither need additional mapping.
harel 9y ago
Because when you build large web applications, things get complex. Now a large part of that complexity is not my problem. Its Facebook's/React's problem. And I'm fine with it. With that complexity removed I can get things done much much quicker and in a more uniform and modular way than before. Not to mention it performs better. So I'm fine with this complex black box that just sits there and does its thing. And to the OP - thanks. This is quite a feat.
- daliwali 9y ago
  You literally said, "complexity is not my problem". You are the problem. This is how projects end up with millions of lines of black box dependencies. This is why `node_modules` folders that are hundreds of megabytes exist. Take a look at benchmarks [0] and tell me, if any framework performs faster than vanilla JS. They probably are faster than vanilla code that you'd be able to write on your own, but that says more about your abilities than the performance of frameworks. [0] http://www.stefankrause.net/js-frameworks-benchmark6/webdriver-ts-results/table.html http://www.stefankrause.net/js-frameworks-benchmark6/webdriv...
  - madeofpalk 9y ago
    That post doesn't benchmark how a team of developer worth together, or how you manage all your code. The speed of a for-loop is only a part of what makes a codebase 'fast'.
  - localvoid 9y ago
    >They probably are faster than vanilla code that you'd be able to write on your own, but that says more about your abilities than the performance of frameworks. I won't be able to write efficient vanilla code for something even slightly more complicated than this benchmark, and I wrote one of the fastest virtual dom implementations out there, so what you expect from an average web developer?
    - daliwali 9y ago
      I'm not saying, "don't use an abstraction on top of vanilla DOM code". Better performance just isn't a valid reason to use a DOM abstraction, it's a non-argument.
jchw 9y ago
React's complexity literally only exists for two reasons: 1. To sidestep problems with the DOM. The virtual DOM helps with performance, and fibers help with responsiveness. 2. To implement reactive components. Virtual DOM makes rebuilding sub trees of the DOM cheap, making it possible to have clean components that don't need to constantly attempt to tweak the DOM. Doing this style of programming without DOM diffing is possible, but much slower. There are other approaches, but this one is significantly nicer to code for than DOM binding and is significantly faster than any naive approach. Yes, you can extract the essence of React into a several kb bundle. It's been done to death. But why? React is fast, mature, has a great ecosystem, and it's nice to code for. It does nice things like seamlessly support SVG and intelligently batching changes. If you're truly making a complex app, it's worth the bump in bundle size. The largest part of any web app is the browser. If the DOM wasn't so bloated and ridiculous, maybe we wouldn't need to spend all of our time minimizing our interactions with it. But if you try to count all of the work the browser has to do to layout and render one DOM element, suddenly React feels very tiny.
- daliwali 9y ago
  You don't need to rehash the marketing pitch of React here. It's the same old "virtual DOM fast, real DOM slow" that I've heard countless times from fanboys and repeated ad infinitum in any discussion about React. What's missing is that you can make complex web apps without any of these things, or the abstractions used can be something completely different. The reasons you stated just sound like ex-post facto rationalizations of what they did after they built it.
  - Vinnl 9y ago
    No, the main point was that it's > significantly nicer to code for than DOM binding There are other ways to code this nicely, but _those_ are slower than virtual DOM. Real DOM _can_ indeed easily be faster, but that's not nearly as nice to program for.
    - jchw 9y ago
      Simply saying "No" after a point and not rebutting it is not a good argument. A lot of people like to point out that the "real DOM" can be just as fast, but far fewer people have any good examples of this being done. Yeah, for making a button that signs you up to a mailing list or a simple SPA or something like that, you can just use the DOM. But if you have a complex app with a huge amount of data flow and many components, React (and Preact and etc.) absolutely will beat the naive answer because it will get rid of needless DOM updates. And it will do that without you having to do caching everywhere, because it's all done in one place at the lowest level before hitting the page. I'd love to see the horrible abomination of hand DOM updates that can magically beat a large React app. edit: Just noticed this wasn't a reply to me, but I think the points I raise here are still fairly valid, if I'm understanding your reply correctly. Sorry if that was confusing.
onion2k 9y ago
Now that the DOM API is implemented in a standards-compliant way across most browsers... At Facebook 'most browsers' has a very different meaning compared to other websites. When Facebook deploys code that works for 99.5% of their users that means they're failing ~10,000,000 people. Consequently they have a lot of code to handle the cases where they can't just rely on 'most browsers'. It's entirely valid that they maintain a relatively large library, and pretty awesome that they share it publicly.
Ralfp 9y ago
I am sorry but this sounds like Dunning-Kruger effect on your part. You have created library that you think the problem, but which seems to have limited adoption in the wild. What experience in the field you have? Have you wondered how much you don't know about problems and scenarios that view layer has to handle? I've been in same situation once with my OS project. I've did something small that I've been certain does what all those other heavier solutions do. But when users came I've learned that there's unimaginable number of edge cases and scenarios that are common enough to require annoying amount of work. React.js is not "DOM utility". Its battletested view library running one of busiest social sites in the world. It's highly performant, capable of handling thousands of components at single time, and handles countless edge cases, like maintaining input state while user is typing in it and its moved around DOM, normalizing events between browsers, maintaining scroll between large redraws or jumping user to components #fragment. Ember.js and Angular are complete app frameworks that implement view, layers, services, data, communications testing, tooling and more. Those are solid options for people writing dashboard applications (think intercom or Podio), even if they are losing ground in public-facing sites to more elastic stacks like React or Vue.
- daliwali 9y ago
  I've done very little marketing, and I am effectively a nobody without a huge following or elite credentials unlike some of the people behind the most popular frameworks. It would be completely unfair to judge me based on popularity and making negative assumptions about my experience, rather than merit. In fact I refuse to market my pet project as if it is something to be bought and sold. or to assign it a valuation based on how many big companies are using it.
- aaron-lebo 9y ago
  But React is bloated. Check it out in comparison to something like Mithril which does everything it does and more in a much smaller and faster package.
  - Ralfp 9y ago
    Last time I've checked Mithril it had no event normalization, JSX, scroll control and input state preservation. Does it have those now? I've did Mithril for 6 months year an half ago, before that Ember.js for two years and Angular.js for year even before that. I've eventually settled with React.js because it was just view library, with everything else up to you.
bliashenko 9y ago
Well, actually it looks like (IMHO) there are too many abstractions levels, in fact - I omit many of them on the scheme, and it's still complex. But if we think why that happened, it's because of multiple platforms supports mostly (native, server rendering, etc), each "sensitive for platform" part of logic requires at least module with interfaces, modules with implementation per each platform, module-injector for exact implementation and so on..
lopatin 9y ago
It's not complexity that you take on. The React API is minimal. It's complexity that the React authors take on in order to provide a stable, cross platform, predictable component lifecycle. And if some of that complexity leaks through, or you don't like the file size of the resulting library, feel free to not use it, but I wouldn't go so far as to say that solving hard problems via sufficiently abstracted away complexity is a bad thing. With React Native I re-use over 75% of code from the web version of my apps. An actual measurable leap in productivity. Or even just for the web version, React and other frameworks (inb4 "not a framework"), provide their own proven patterns and best practices for scaling a code base, a task that is out of scope of any DOM utility library. And if providing those patterns requires more complexity under the hood, well, you don't refuse a free Lamborghini because it's "more complex under the hood" than your current Toyota.
always_good 9y ago
You're being a bit dishonest in these posts. Maybe it's your marketing style and maybe it works, but it puts me off. I even see it in your landing page marketing. > MINIMAL > One function > Its entire API surface area is a single function Then I scroll down. var bindObject = require('simulacra') var bindEvents = bindObject.bindEvents var animate = bindObject.animate var retainElement = bindObject.retainElement
- daliwali 9y ago
  There is actually only one function, that is the one returned from `require('simulacra')`, the others are merely conveniences that are common enough, and `retainElement` is a symbol, not a function. To demarcate this separation better I have considered moving the optional convenience functions into a separate module, which might help clear things up. Edit: actually it seems that you were being dishonest when quoting me, this is what it says, you cut it off short: >Its entire API surface area is a single function (with some optional helpers and symbols) That makes it pretty clear that the core functionality is a single function.
  - deleted 9y ago
    [deleted]
  - RUTHLESS_RUFUS 9y ago
    I appreciate your attempt, but we don't need any more astronaut-architects. We have the tools. It's 2017 and high time for JavaScript tooling to finally slow down a bit and settle into its bigger britches.
    - daliwali 9y ago
      >Astronaut-architects Facebook can come out with a project that's over 40k lines of code, and it is "extremely simple". But no, it is me with my little 5kb function who is the "astronaut-architect". >It's 2017 I don't care what year it is, you act like the current frameworks are the only viable options in the future. Hint: they aren't.
mmcnl 9y ago
The current state of front-end web development isn't a mess, it's actually the opposite. I would argue it is bleeding edge. If you look at it from an engineering perspective (inside-out), it's probably not the best. But if you're looking at the quickest way to deliver value you to your customers, it is unmatched. Every other application development stack other than front-end development requires compile, build and deployment steps. With front-end development, you can literally reach billions of customers whenever you decide to do so. The only requirement is a somewhat modern browser. The current state of front-end development is amazing.

jacobr 9y ago

The place where complexity should be is exactly in third party library with a simple public API, avoiding as much complexity and optimizations as possible in your own application code.

daliwali 9y ago
Why does the third party library need to be so complex? And why should there be complexity in the first place?
- litzer 9y ago
  Not the OP but my answer to that is because something has to be complex in a large web app. Complexity can be avoided until the number of features reaches some threshold (I don't think there's any debate that it's impossible to avoid complexity entirely if the app is large enough). In those cases, which I think are the majority of use cases, a simple DOM utility like yours would be enough to hide complexity because there wasn't much to begin with. But some of the websites React powers exceed that feature threshold. For example, if multiple sections of a web app want to update at once, the author could leverage React's lifecycle hooks where needed and rely on its reconciler, but if using a simpler library, might have to explicitly schedule each update in a more hacky/less efficient way.
  - daliwali 9y ago
    I think the conventional dogma that one must resort to a framework for a large web app is wrong. Your assumption that simpler is more "hacky" or less efficient, just isn't true. One can use built-in constructs like for loops in vanilla JS to update multiple DOM nodes at once, this yields the most optimal performance. Or one could use React/Redux and setup an action and a reducer and action creator and action type constant and... you see where this is going.
    - litzer 9y ago
      > One can use built-in constructs like for loops in vanilla JS to update multiple DOM nodes at once That's not the kind of use case that'd require React. I think we're on the same page that for the majority of apps, that setup is overkill. I'm just pointing out that there are apps with complex use cases where the "see where this is going" will end up being more elegant/simpler than fleshing out your own constructs (certainly more than a for loop)

rimliu 9y ago

Well, that's like judging a car to be difficult to drive by looking at the listings of all the embedded software in its cpu's. These are details of internal implementation. The public API which you actually use is very very simple. Calling React "DOM utility" does not sound fair. While one of the major problems it solves—slow DOM operations, I'd say that unidirectional data flow is even more important.

daliwali 9y ago
Your analogy isn't apt, a better analogy would be judging a car to be difficult to maintain by looking at the listings of all the embedded software. I know a guy who restored a 1960's VW Beetle to working condition with minimal expertise, the same couldn't be done for modern cars without a full machine shop that specialized in that make. Fancy selling points like "unidirectional data flow" don't actually mean anything. Each fanboy has their own variant of this, like "transclusions", "immutables", "dependency injection", etc. These are all phrases I've heard that don't translate to tangible results.
- matthewmacleod 9y ago
  These are all phrases I've heard that don't translate to tangible results. Yeah… but they do translate to tangible results. Using something like React helps to make front-end code simple, scalable, fast, and testable. The car analogy is even worse. A modern vehicle is better than a 60s Beetle by almost every conceivable metric – performance, emissions, safety. In both of these cases, it is preposterous to assume that complexity was introduced for no reason.
  - daliwali 9y ago
    These are marketing buzzwords that can be said about every single web framework, effectively thought-terminating cliches. Every fanboy says their preferred framework is the simplest, fastest, most scalable and most testable. In the car analogy the improved performance of modern cars have more to do with mechanical engineering than software. And the analogy falls apart when you consider that modern web frameworks are invariably slower or roughly equal in performance to its vanilla JS counterpart, but never faster.

kaoD 9y ago

> looking at this giant UML diagram It's not an UML diagram. Looks more like an ad-hoc flow chart (unless I forgot a specific type of UML diagram that looks like this).

daliwali 9y ago
I think it's a UML activity diagram, which is in fact a flow chart.
- kaoD 9y ago
  I was taught UML activity diagrams were high-level representations, while this is a (summarized) flow chart of code paths (which makes it quite big in comparison to what would be its high-level UML counterpart). UML is supposed to be an architectural diagramming standard. What's the point of diagramming in UML the actual code paths? E.g.: you'd never have object shapes or function calls in an UML activity diagram. This is just an ad-hoc flow chart AFAICT.

TekMol 9y ago

I agree that React introduces way too much complexity. From a quick look at your approach, I have one concern: <template id="product"> <h1 class="name"></h1> ... You seem to use classnames as variable names. What if some other template has a "name" variable too? What if a stylesheet uses it? I prefer simple placeholders. Instead of: <h1 class="name"></h1> I would use: <h1>{{NAME}}</h1>

daliwali 9y ago
Using class names was just an example, people may get the wrong impression that has anything to do with the variable name. It could have been made more explicit, but I wanted to be as terse as possible: <h1 class="name" data-bind="name"></h1> It was also a design goal not to introduce a templating syntax, so `{{}}` brackets are out of the question.
- TekMol 9y ago
  I see now, that the bindObject() function takes a mapper from data to DOM. There are two downsides to this: 1) You have to define twice where the data is displayed. Once in the template and then again in the mapper. 2) <div>{{NAME}}</div> explicitly tells the reader "The name goes here". In your solution one would have to look it up in the mapper to be sure what goes where.
  - daliwali 9y ago
    I'm well aware that there must be an element and a selector for that element. But this is exactly how CSS works as well, it's separation of concerns. Only recently have inline styles become trendy, much to my dismay. The total absence of templating syntax is a deliberate decision. It enables one to start from an HTML mock-up or static page, and build interactivity on top of that without changing any HTML.
    - TekMol 9y ago
      this is exactly how CSS works as well I beg to differ. There is no mapping needed for CSS. CSS works by once defining where the style shall go: <div class=city></div> And once what the style is: .city {color: blue; font-family: arial;} Similar, template syntax once defines where the data shall go: <div class=city>{{NAME}} has {{POPULATION}} residents</div> And once, what the data is: city={name: "New York", population: 8491000} Neither need additional mapping.

harel 9y ago

Because when you build large web applications, things get complex. Now a large part of that complexity is not my problem. Its Facebook's/React's problem. And I'm fine with it. With that complexity removed I can get things done much much quicker and in a more uniform and modular way than before. Not to mention it performs better. So I'm fine with this complex black box that just sits there and does its thing. And to the OP - thanks. This is quite a feat.

daliwali 9y ago
You literally said, "complexity is not my problem". You are the problem. This is how projects end up with millions of lines of black box dependencies. This is why `node_modules` folders that are hundreds of megabytes exist. Take a look at benchmarks [0] and tell me, if any framework performs faster than vanilla JS. They probably are faster than vanilla code that you'd be able to write on your own, but that says more about your abilities than the performance of frameworks. [0] http://www.stefankrause.net/js-frameworks-benchmark6/webdriver-ts-results/table.html http://www.stefankrause.net/js-frameworks-benchmark6/webdriv...
- madeofpalk 9y ago
  That post doesn't benchmark how a team of developer worth together, or how you manage all your code. The speed of a for-loop is only a part of what makes a codebase 'fast'.
- localvoid 9y ago
  >They probably are faster than vanilla code that you'd be able to write on your own, but that says more about your abilities than the performance of frameworks. I won't be able to write efficient vanilla code for something even slightly more complicated than this benchmark, and I wrote one of the fastest virtual dom implementations out there, so what you expect from an average web developer?
  - daliwali 9y ago
    I'm not saying, "don't use an abstraction on top of vanilla DOM code". Better performance just isn't a valid reason to use a DOM abstraction, it's a non-argument.

jchw 9y ago

React's complexity literally only exists for two reasons: 1. To sidestep problems with the DOM. The virtual DOM helps with performance, and fibers help with responsiveness. 2. To implement reactive components. Virtual DOM makes rebuilding sub trees of the DOM cheap, making it possible to have clean components that don't need to constantly attempt to tweak the DOM. Doing this style of programming without DOM diffing is possible, but much slower. There are other approaches, but this one is significantly nicer to code for than DOM binding and is significantly faster than any naive approach. Yes, you can extract the essence of React into a several kb bundle. It's been done to death. But why? React is fast, mature, has a great ecosystem, and it's nice to code for. It does nice things like seamlessly support SVG and intelligently batching changes. If you're truly making a complex app, it's worth the bump in bundle size. The largest part of any web app is the browser. If the DOM wasn't so bloated and ridiculous, maybe we wouldn't need to spend all of our time minimizing our interactions with it. But if you try to count all of the work the browser has to do to layout and render one DOM element, suddenly React feels very tiny.

daliwali 9y ago
You don't need to rehash the marketing pitch of React here. It's the same old "virtual DOM fast, real DOM slow" that I've heard countless times from fanboys and repeated ad infinitum in any discussion about React. What's missing is that you can make complex web apps without any of these things, or the abstractions used can be something completely different. The reasons you stated just sound like ex-post facto rationalizations of what they did after they built it.
- Vinnl 9y ago
  No, the main point was that it's > significantly nicer to code for than DOM binding There are other ways to code this nicely, but _those_ are slower than virtual DOM. Real DOM _can_ indeed easily be faster, but that's not nearly as nice to program for.
  - jchw 9y ago
    Simply saying "No" after a point and not rebutting it is not a good argument. A lot of people like to point out that the "real DOM" can be just as fast, but far fewer people have any good examples of this being done. Yeah, for making a button that signs you up to a mailing list or a simple SPA or something like that, you can just use the DOM. But if you have a complex app with a huge amount of data flow and many components, React (and Preact and etc.) absolutely will beat the naive answer because it will get rid of needless DOM updates. And it will do that without you having to do caching everywhere, because it's all done in one place at the lowest level before hitting the page. I'd love to see the horrible abomination of hand DOM updates that can magically beat a large React app. edit: Just noticed this wasn't a reply to me, but I think the points I raise here are still fairly valid, if I'm understanding your reply correctly. Sorry if that was confusing.

onion2k 9y ago

Now that the DOM API is implemented in a standards-compliant way across most browsers... At Facebook 'most browsers' has a very different meaning compared to other websites. When Facebook deploys code that works for 99.5% of their users that means they're failing ~10,000,000 people. Consequently they have a lot of code to handle the cases where they can't just rely on 'most browsers'. It's entirely valid that they maintain a relatively large library, and pretty awesome that they share it publicly.

Ralfp 9y ago

I am sorry but this sounds like Dunning-Kruger effect on your part. You have created library that you think the problem, but which seems to have limited adoption in the wild. What experience in the field you have? Have you wondered how much you don't know about problems and scenarios that view layer has to handle? I've been in same situation once with my OS project. I've did something small that I've been certain does what all those other heavier solutions do. But when users came I've learned that there's unimaginable number of edge cases and scenarios that are common enough to require annoying amount of work. React.js is not "DOM utility". Its battletested view library running one of busiest social sites in the world. It's highly performant, capable of handling thousands of components at single time, and handles countless edge cases, like maintaining input state while user is typing in it and its moved around DOM, normalizing events between browsers, maintaining scroll between large redraws or jumping user to components #fragment. Ember.js and Angular are complete app frameworks that implement view, layers, services, data, communications testing, tooling and more. Those are solid options for people writing dashboard applications (think intercom or Podio), even if they are losing ground in public-facing sites to more elastic stacks like React or Vue.

daliwali 9y ago
I've done very little marketing, and I am effectively a nobody without a huge following or elite credentials unlike some of the people behind the most popular frameworks. It would be completely unfair to judge me based on popularity and making negative assumptions about my experience, rather than merit. In fact I refuse to market my pet project as if it is something to be bought and sold. or to assign it a valuation based on how many big companies are using it.
aaron-lebo 9y ago
But React is bloated. Check it out in comparison to something like Mithril which does everything it does and more in a much smaller and faster package.
- Ralfp 9y ago
  Last time I've checked Mithril it had no event normalization, JSX, scroll control and input state preservation. Does it have those now? I've did Mithril for 6 months year an half ago, before that Ember.js for two years and Angular.js for year even before that. I've eventually settled with React.js because it was just view library, with everything else up to you.

bliashenko 9y ago

Well, actually it looks like (IMHO) there are too many abstractions levels, in fact - I omit many of them on the scheme, and it's still complex. But if we think why that happened, it's because of multiple platforms supports mostly (native, server rendering, etc), each "sensitive for platform" part of logic requires at least module with interfaces, modules with implementation per each platform, module-injector for exact implementation and so on..

lopatin 9y ago

It's not complexity that you take on. The React API is minimal. It's complexity that the React authors take on in order to provide a stable, cross platform, predictable component lifecycle. And if some of that complexity leaks through, or you don't like the file size of the resulting library, feel free to not use it, but I wouldn't go so far as to say that solving hard problems via sufficiently abstracted away complexity is a bad thing. With React Native I re-use over 75% of code from the web version of my apps. An actual measurable leap in productivity. Or even just for the web version, React and other frameworks (inb4 "not a framework"), provide their own proven patterns and best practices for scaling a code base, a task that is out of scope of any DOM utility library. And if providing those patterns requires more complexity under the hood, well, you don't refuse a free Lamborghini because it's "more complex under the hood" than your current Toyota.

always_good 9y ago

You're being a bit dishonest in these posts. Maybe it's your marketing style and maybe it works, but it puts me off. I even see it in your landing page marketing. > MINIMAL > One function > Its entire API surface area is a single function Then I scroll down. var bindObject = require('simulacra') var bindEvents = bindObject.bindEvents var animate = bindObject.animate var retainElement = bindObject.retainElement

daliwali 9y ago
There is actually only one function, that is the one returned from `require('simulacra')`, the others are merely conveniences that are common enough, and `retainElement` is a symbol, not a function. To demarcate this separation better I have considered moving the optional convenience functions into a separate module, which might help clear things up. Edit: actually it seems that you were being dishonest when quoting me, this is what it says, you cut it off short: >Its entire API surface area is a single function (with some optional helpers and symbols) That makes it pretty clear that the core functionality is a single function.
- deleted 9y ago
  [deleted]
- RUTHLESS_RUFUS 9y ago
  I appreciate your attempt, but we don't need any more astronaut-architects. We have the tools. It's 2017 and high time for JavaScript tooling to finally slow down a bit and settle into its bigger britches.
  - daliwali 9y ago
    >Astronaut-architects Facebook can come out with a project that's over 40k lines of code, and it is "extremely simple". But no, it is me with my little 5kb function who is the "astronaut-architect". >It's 2017 I don't care what year it is, you act like the current frameworks are the only viable options in the future. Hint: they aren't.

mmcnl 9y ago

The current state of front-end web development isn't a mess, it's actually the opposite. I would argue it is bleeding edge. If you look at it from an engineering perspective (inside-out), it's probably not the best. But if you're looking at the quickest way to deliver value you to your customers, it is unmatched. Every other application development stack other than front-end development requires compile, build and deployment steps. With front-end development, you can literally reach billions of customers whenever you decide to do so. The only requirement is a somewhat modern browser. The current state of front-end development is amazing.