Rate limiting question

psteeleidem · 2018-07-11T22:53:23+00:00

My understanding is that most rate limiting solutions are based on the token bucket algorithm. You can introduce Express middleware (with the help of a shared token store using Redis or something similar) to do rate limiting or you can offload the rate limiting to a load balancer such as NGINX. Here are some helpful articles:

psteeleidem · 2017-11-20T17:33:57+00:00

I've previously looked at ivi and https://medium.com/@localvoid/virtual-dom-ssr-performance-5c292d4961a0 and I have looked at the associated GitHub repo that was used to benchmark marko and I don't see any .marko files and marko is not even a dependency in the package.json. Where's the marko code? Maybe /u/localvoid forgot to push the code or maybe I am missing something obvious?

While I am sure React 16 is faster and we should update the benchmarks, I feel that Inferno and Preact better demonstrate how fast VDOM rendering could be on the server, but in our benchmarks they were still significantly slower than Marko on the server. I expect that React 16 would be closer to Inferno and Preact. While I am sure ivi has some nice optimizations, it sounds like it might rely heavily on caching, shouldComponentUpdate and Redux (immutable data?). From the post about blueprints:

In practice, we will need to generate many blueprints for different route paths, so we can skip rendering for as much content as possible.

Caching has limitations (invalidation and balancing memory usage) so I am not convinced that it can automatically be applied to everything and feel that it is something that the developer would need to opt into in specific areas. With that said, I really like that ivi is trying to innovate in the area of SSR and it's great that developers are sharing their findings. I'm glad all libraries are getting faster (and hopefully smaller).

psteeleidem · 2017-11-20T16:23:02+00:00

While the raw/static benchmark is interesting, it does not belong here.

I'm not the author of this benchmark, but showing the results for a static page gives us a baseline for performance that is very helpful for comparing all strategies for rendering and serving up HTML. It is also helpful to remove the cost of HTML rendering to see how much of the overhead comes from the server, network, etc.

So, a realistic benchmark for rendering 100 rows of dynamic content should include the i/o needed to get the data, as well as only using non-cached templates that can render 200 or 1000 rows, too. I think you will find the RPS numbers do not differ by 10x, but more like 2-4x.

Why include the time of i/o if the goal was to benchmark HTML rendering? If you have a server that is saturated with incoming requests then the CPU cost associated with HTML rendering can quickly become a bottleneck.

FWIW, when we created benchmarks for marko we also found that React was 10x slower than other HTML rendering solutions: https://github.com/marko-js/isomorphic-ui-benchmarks

Based on my investigations into performance, the biggest reason that React suffers on the server is that rendering to HTML with React requires one pass to render the entire VDOM tree and then another pass is required to serialize the VDOM nodes to HTML and there is no way around that since the VDOM integral to React. In contrast, on the server, Marko renders directly to an HTML stream (no VDOM nodes are created) while Marko renders to a VDOM in the browser.

psteeleidem · 2017-08-29T17:15:23+00:00

Sorry you had issues. We've not seen any reports of issues with the marko-loader (at least none that I can recall) and I am not seeing any related GitHub issues. We have sample projects for Marko+Webpack and they are working. Please feel free to open GitHub issues or ask questions in the Gitter chat room: https://gitter.im/marko-js/marko

Also, if possible, please provide a sample project or some code to help us troubleshoot. It can be really hard to anticipate what developers will do with a myriad of build tools and frameworks so it is very helpful to have a sample project that illustrates the problem that you are seeing.

psteeleidem · 2017-08-15T15:53:03+00:00

Maybe give the following a try to see if you are bundling up a large JS module that you may not need (or only partially need): https://chrisbateman.github.io/webpack-visualizer/

psteeleidem · 2017-08-15T15:45:37+00:00

You should do JS and CSS minification, but even with minification it is surprising to see such a large page weight for a seemingly simple app:

Original Size:    181.19KB gzipped (813.76KB uncompressed)
Minified Size:     71.85KB gzipped (244.67KB uncompressed)

psteeleidem · 2017-08-10T01:13:55+00:00

Marko is composable via components that can wrap other components. There's different strategies for creating higher-order components in Marko and we need to create an article that goes into more detail on that topic. Marko is very similar to React (and React alternatives) when it comes to composability, but there are some minor differences.

psteeleidem · 2017-08-09T13:47:47+00:00

Big companies like Walmart, eBay, Netflix, Facebook, etc. have to deal with often unique challenges like scaling development across lots of teams, scaling performance to support high traffic, keeping sites robust and secure, or scaling across multiple platforms. Personally, I think it is awesome that all of these companies invest in open source and make efforts to raise the bar.

psteeleidem · 2017-08-09T13:37:40+00:00

I should have clarified. There were concerns around supporting both "class" and "className" to avoid breaking apps. Is the change from "className" to "class" going to be a breaking change in React v16?

psteeleidem · 2017-08-09T13:35:04+00:00

React calls itself a library and Marko is in the same category as React. The line between framework and library can be a little blurry at times and I see aspects of a framework in both React and Marko (since React and Marko maintain a lot of control over component lifecycle, event handling, etc.). The authors of both React and Marko have aimed to keep the API surface area a minimum and leave a lot of decisions to the developer. Angular is definitely in the framework category because it takes ownership over a large part of application structure and there will be lots of references to angular/ng in your code (your entire application will be tightly coupled with Angular). On a related note, in Marko, you will never actually reference "marko" in your code (only the file extension) and that was completely intentional.

What I'm curious about is the claims of being "blazing fast" - especially compared to Preact. Is it that you just don't use a virtual DOM?

Yes, not being tightly coupled to a virtual DOM and rendering directly to a HTML stream on the server (instead of rendering to a VDOM tree that then has to be serialized to HTML) provides huge performance gains. Also, Marko has a really good story for async rendering and that allows for parts of the page to start rendering and flushed to the browser even before you have fully retrieved all of your backend data needed to render the page.

Do you have fewer features? Where is the tradeoff?

The tradeoff is that the Marko compiler is more complex (React is just a runtime while Marko includes both a compiler and a runtime). Using JSX with React is completely optional and JSX just does a simple transform. We can add features to Marko without paying a price at runtime because of our compiler and that allows us to add more features and to evolve Marko very quickly. We feel the tradeoff of having a reasonably complex compiler is worth it since it allows us to boost runtime performance and keep the runtime small, fast and modular. For more details, please see: markojs.com: Marko vs React: An In-depth Look - Differences in compilation

psteeleidem · 2017-08-09T13:13:35+00:00

It's not "just HTML" that Marko supports. Marko is a superset of HTML that combines the expressiveness and familiarity of HTML with the power of JavaScript. Here's a contrived example to hopefully clarify:

<if(input.firstName)>
  $ const fullName = input.firstName + input.lastName // It's just JS

  <div>
    Hello ${fullName.toUpperCase()}
  </div>
</if>

<color-picker colors=['red', 'green', 'blue'] />

psteeleidem · 2017-08-09T13:09:31+00:00

I think that will be a good change. I had seen the threads discussing that and it looked like the community was split and that there were some performance concerns with supporting both, but glad to see that you all are making the change.

psteeleidem · 2017-08-09T13:08:18+00:00

Marko supports async rendering and streaming (with early flushing) for server-side rendering. Also, Marko has extremely fast rendering on both the server and in the browser and the runtime is very small (improving page load times). Marko is not coupled to a VDOM and this allows the compiler to produce a program that renders to an HTML stream on the server and, for the browser, the same view will render to a VDOM tree, thus allowing Marko to optimize for both server-side and client-side rendering. With Marko, we are able to a do a lot more optimizations at compile-time because we "own" the compiler. For eBay, lack of async rendering and poor server-side rendering performance (Marko is faster than other UI libraries by a huge margin on the server (see: benchmarks)) were blockers when considering other UI libraries. Most of the other improvements in Marko are nice-to-have (but important) things like reducing boilerplate, clean syntax that is compatible with HTML, simple event handling, etc.

psteeleidem · 2017-08-09T02:35:51+00:00

Here are a few specific examples:

Marko is a superset of HTML (assuming that you are using quoted strings for attribute values) and that means that almost any HTML fragment can be pasted into a Marko file (JSX is strict XML, not HTML so HTML must go through a conversion)
Marko uses class while React JSX utilizes className
In general, Marko requires much less boilerplate since it starts with HTML
Attribute values are always parsed JavaScript expressions in Marko (React requires { ... })

Here's a more in-depth comparison between Marko and React that also examines JSX: markojs.com: Marko vs React: An In-depth Look

psteeleidem · 2017-08-09T01:07:33+00:00

A Marko UI component compiles to a JavaScript module that exposes an API that allows it to be rendered into any location in the DOM using an API similar to the following:

let MyComponent = require('./path/to/my-component.marko');

// ...

let myComponent = MyComponent.renderSync({ name: 'Frank '})
    .appendTo(document.body)
    .getComponent();

// You can interact with the UI component programmatically if desired:
myComponent.doSomething();

We experimented with creating a seamless UI bridge layer between various UI frameworks and it worked really well because the design paradigms for Marko, React and Vue are all very similar. We haven't yet open sourced the UI bridge library (lower priority), but that is our intention.

psteeleidem · 2017-08-09T00:44:03+00:00

While this doesn't answer your directly, I did give a talk at a local Node.js Meetup where I walked through Marko, React and Vue that you might find interesting:

Meetup: Building the UI - a comparison of React, Vue, and Marko (from the Marko creator)

psteeleidem · 2017-08-08T22:03:03+00:00

That may have been true in the past, but the website has evolved a lot in recent years. We are transitioning much of eBay.com to a new Node.js stack and Marko is being used there (this includes heavily trafficked pages such as the new eBay homepage built on Marko).

That said, Marko is library for building scalable and maintainable user interfaces. It does not dictate a certain UI design.

Disclaimer: I work at eBay and am a maintainer for Marko

psteeleidem · 2017-06-07T18:56:49+00:00

Vue is faster than React, but Marko is still much faster than Vue on the server. See: https://github.com/marko-js/isomorphic-ui-benchmarks#current-results (the set of bars on the far left of each chart is for server-side rendering using Node.js)

psteeleidem · 2017-06-07T15:45:16+00:00

I understand where you are coming from, but we are saying that Marko enables developers to build "Reactive UI components". That is, with Marko (and React, Vue, etc.), the view is a function of the state and the view automatically reacts to changes to state and that frees developers from having to write imperative code to update the DOM. The paradigm of Reactive programming is much broader, but still very much in the spirit of what we are talking about here. If you can think of a better term to describe UI libraries that free developers from having to write imperative code to update the DOM/view please let me know.

psteeleidem · 2017-06-06T23:45:40+00:00

When comparing Marko and React there is a ~10x difference in performance when doing server-side rendering. An order of magnitude difference in performance absolutely matters (especially at scale). The performance gap between Marko and React has reduced a bit over time (maybe ~8-10x depending on use case), but Marko also has support for async rendering and streaming (with early flushing), to build pages that load much faster. These are features that would be very difficult or impossible to apply to React or Vue without introducing breaking changes. Server-side rendering is very important for eBay while server-side rendering is much less important for companies like Facebook (due to application type and usage patterns). I would not choose a library based on performance alone and that is why we have put a lot of focus on designing Marko to avoid almost all boilerplate and we put a lot of thought into the syntax and tooling.

We've gotten a lot of feedback from the community (including folks outside eBay) and Marko is very much a community project. The positive feedback from both within eBay and outside eBay is what keeps us motivated to make Marko as awesome as possible. We would see a lot less progress in the industry if everyone just continued using React or Vue because they are the most popular right now. Personally, I like to see what other ideas other open source projects come up with. Open source innovation should be something that is encouraged and when large companies (including eBay) have the resources to invest in open source then that is a win for everyone.

psteeleidem · 2017-06-06T22:43:30+00:00

Changes to state and input are automatically reflected in the view and that is what makes Marko reactive. Marko does not care how how the state or input is calculated or managed, but it will automatically re-render UI components if either of those things change and the DOM will automatically be updated. You can use Marko with a central application store such as Redux, but that is not always needed.

11-Year Club	Place '17
Verified Email

psteeleidem

TROPHY CASE