psteeleidem

8 ms·

1.
Show HN: 10 Awesome Marko Features(medium.com)
2 points by psteeleidem 9y ago|0 comments
2.
by psteeleidem 9y ago
In another comment I mention that the biggest conceptual improvement that Marko offers is async and streaming rendering. Async changes how you think about passing data to your view (you start rendering immediately and you can retrieve backe
3.
by psteeleidem 9y ago
Web components do not have a great story about passing complex data. If you want to pass typed data (not just strings) then declarative HTML suffers since HTML parses all attribute values as strings. You can use JavaScript properties to pro
4.
by psteeleidem 9y ago
Async and streaming rendering is probably the biggest conceptual difference since it changes how you think about providing data to your view (in a good way). The paradigms of how you build UI components is very similar across all of the maj
5.
by psteeleidem 9y ago
Building web apps is definitely hard work, but it can be fun if you are instantly rewarded with working components/pages that didn't require a ton of code :)
6.
by psteeleidem 9y ago
There's really no magic with implicit imports. The imports are resolved at compile-time and fully resolved imports are used in the compiled code. I see developers making mistakes with explicit imports all the time (using the wrong path
7.
by psteeleidem 10y ago
I'm the author of the article and one of the maintainers of Marko. We also recently published an article on the release of Marko 4.0 for context: [Marko 4.0 is here]( https://medium.com/@mlrawlings/marko-4-0-is-here
8.
Warp10: Optimized Node lib for transporting complex/circular JavaScript objects(github.com)
2 points by psteeleidem 10y ago|0 comments
9.
A Closer Look at Marko Widgets(markojs.com)
2 points by psteeleidem 11y ago|0 comments
10.
by psteeleidem 11y ago
You don't need a virtual DOM or real DOM on the server to render HTML. The fastest way to render pages on the server is to compile templates into JavaScript programs that produce an HTML string (not virutal DOM nodes and definitely not
11.
by psteeleidem 11y ago
Here's the notable differences based on my understanding after looking over the docs and the source code: - morphdom does diffing between two real DOM trees while incremental-dom does diffing between virtual DOM nodes and real DOM node
12.
by psteeleidem 11y ago
On the following note: > it should become faster whenever browser DOMs become faster The killer feature of React is that it made it possible to efficiently rerender the entire UI and for developers to not have to write code to manually
13.
by psteeleidem 11y ago
For the record, I got an email from Hacker News asking me to repost it since they thought it was a good story and it did not get many views. It's not wise to post something to Hacker News late on a Friday :)
14.
by psteeleidem 11y ago
Author of morphdom here. I don't necessarily disagree with anything you said. However, morphdom was designed to be fast enough in situations where you can't or don't want to introduce a virtual DOM. What matters more than a m
15.
Morphdom – fast and lightweight DOM diffing/patching (without the virtual part)(github.com)
60 points by psteeleidem 11y ago|15 comments
16.
Morphdom – fast and lightweight DOM diffing/patching (without the virtual part)(github.com)
10 points by psteeleidem 11y ago|3 comments
17.
by psteeleidem 12y ago
Thanks for the feedback zghst. Here's my response to your comments: > I'm sure it would help if these tests used the minified version of React on the server. Minification sometimes makes runtime performance worse due to the tri
18.
by psteeleidem 12y ago
This comparison benchmark was not designed to answer all of those questions. Perhaps just the following: "Does it scale well?" The conclusion from these tests is that React currently does not scale well on the server (at least for
19.
by psteeleidem 12y ago
funkiee, good catch on that issue. I just tried using the current index during iteration, instead of the actual unique ID of the search results item and that sped things up a lot. In fact, now React and Marko perform almost exactly on par f
20.
by psteeleidem 12y ago
funkiee, would you be interested in opening a Github issue or submitting a Pull Request if you believe that is the right thing to do? I'll give it a try in the meantime, but it would be great to have a public discussion on that so othe
21.
Marko vs. React: Performance Benchmark(github.com)
15 points by psteeleidem 12y ago|10 comments
22.
by psteeleidem 14y ago
FYI, when designing the Raptor Templates language I borrowed that technique from the Genshi templating language: http://genshi.edgewall.org/wiki/Documentation/xml-templates.... When the template compiler understands the actual HTML struct
23.
by psteeleidem 14y ago
Thanks for the feedback! I'm the lead developer on RaptorJS and I completely agree that the messaging needs to be improved and that is what we are working on right now. We haven't actually started actively promoting RaptorJS, so yeah, I sup