Hacker News Reader

Comment by jacquesc | Hacker News Reader

"I’ve come to the realization that this much client-side processing and decoupling is detrimental to both the speed of development, and application performance"

While Fuchs is a credit to the early JS community, he's been railing against larger JS frameworks (including jQuery) for the better part of 4 years.

He hasn't been proven right in practice. His approach of 100% server side generation may work well for some apps, but the clear trend is client side apps, with shared REST apis between mobile and web.

Client devices are powerful, why do everything on the server? Let the server be the data store, and the UI rendering work on the client. Makes more sense, and is going to happen no matter how much Fuchs and his followers wish against it.

[edited to be less antagonistic]

View on HN

Powerful? I gave up using my ipad 1 to surf the web. From "the next web" to blogger.com, every website is miserably slow and simply opening tabs causes memory warnings and the eventual safari crash.

Also, those frameworks do way more than just 'UI rendering', they are full applications which are usually REST clients, UI is just a part of it.

My company is writing an application that requires the use of some framework. We are evaluating both ember and angular for some time and will definitely use it. There are heavy downsides and we had many meetings, built demos and hacked together until we were sure using a framework at all was a good decision.

That's the implementor's fault, and usually the result of loading two dozen scripts, blocking ads, external webfonts, share buttons and other crap. A framework like Backbone is very lightweight and fast if used correctly (typed from an ipad 1)

Conceded, backbone shouldn't add stress to any website. But if you put together angularJs: directives on external html rendered in a ng-repeat (50 items or so) you will have to put the MBP on a table because it gets really warm.

Rendering anything but the simplest DOM templates from JSON can be extremely slow. We so wrote a book on JavaScript performance -- runtime performance, not simply asset delivery. In that nearly 4yo book, we recommended against templating. A couple years later, we thought things got better & faster and it wasn't an issue any more. We thought wrong.

It is usually more than fast enough. The project I'm currently working on renders completely on the client with around ten different templates/partials, and the rendering adds up to just a couple ms - that's using handlebars which is not the fastest engine around. 99% of the application time is on data retrieval and processing.

I understand you had issues with your project, and email apps are complicated beasts, but let's not generalize. The truth is in between. I bet rendering a complex template server-side on Ruby can be slower than js.

I'm Thomas Fuchs. That's interesting. How many apps have you developed?

Your reply is about as good as his comment.

Not when you consider the original blog post, which addressed the question of "Why not let the server be the data store?" Among the other "points"[1] jacquesc raised.

[1] anyone who wants to pretend to have a serious, rational discussion -- don't start it by calling the person a zealot. Bam! Insta-noncredibility.

recuter, put down your weapons and surrender. you're surrounded!

To be fair, he said he was "railing like a zealot" -- a subtle but important difference. Calling someone a zealot is attacking them as a person, calling their behavior "zealot-like" is only attacking the behavior.

Ah, yes, one word changes characterizations like "railing" and "zealot" into… a slightly (slightly) subtler ad hominem. But still an ad hominem.

Whoever's down voting me, see Jacques' line about editing his own comment to be less inflammatory. He admitted it. You're not achieving anything here.

A few. Don't worry, I'm a fan of your work. But I think you're way off base on this one point.

We can still be friends :)

Nope, we aren't - and won't be. Friends don't use ad hominem attacks on friends.

Bummer. Well, I guess all I can say it's nothing personal. I thought I was arguing against Thomas's opinion (which I disagree with), and his constant attacks against any JS framework over 2K in size.

Best of luck with your ventures.

In case anyone reading this exchange isn't privy to the facts of the matter:

Thomas doesn't "constantly" "attack" libraries "over 2k in size."

He's a core team member of Prototype, wrote/"founded" Scriptaculous, scripty2, and Zepto. All significantly larger than 2k. All different types of frameworks, libraries. All of which we use.

What Thomas does is promote smaller, more modular libraries -- based on experience. He promotes them because large libraries dominated the market utterly, and monocultures are not productive for hackers. So he started http://microjs.com.

Some people like to characterize him as a zealot for promoting an alternative and talking about why huge frameworks/libraries often have more tradeoffs than benefits.

I guess after writing Prototype with it's 2GB source it's understandable that one would become a promoter of smaller, modular libraries ;)

I'm myself a supporter of small libs, actually wrote a zepto "competitor" to be compatible with IE9 [1], but get the impression everyone is being a little too defensive (offensive?) on the matter.

[1] http://ryejs.com

I'm not sure if you intended it, but this comment seems extremely egotistical.

Are you genuinely interested in his/her experience and having a conversation about it, or are you saying (as it seems to read), "How many apps have YOU developed?"

If it's the latter, you're being kind of a dick. Just saying.

NB: My husband isn't a native English speaker. His point was that he wrote about our experience with a specific app and that the bulk of jacquesc's argument was "Thomas rails like a zealot" and implies Thomas is an old dead horse (?), and otherwise was basically "nuh-uh." Without supporting detail.

It was an invitation to provide details instead of ad hominem attacks (speaking of being kind of a dick). Because his native language isn't English, this got a little bit mangled. I already pointed that out to him.

Also he wanted to say he was the original author, and it ended up sounding like a line from an action movie.

I'm sorry for calling Tom a zealot (which I've since removed).

If it makes you feel better, I'm a client side MVC zealot. For Aiur!

I can see how my comment could be taken this way. It's not want I wanted to express. I wanted to state, as a disclaimer, that I'm the author of the post.

As for answering the comment, it's really more of an ad hominem so that's why I wrote the snarky "That's interesting".

I am interested in what he developed though, especially as he's so sure of his one true way.

Let us not declare client side rendering as the winner prematurely.

Client Devices are powerful, but they are constrained by the Client Browser/Javascript Language where as Server side rendering are constrained only by the Operating System with the flexibility to use many language.

If the same view is going to be rendered to multiple clients, it makes sense to create it in the server once and send to each client rather than cache the data in the server only and render it every time in the Client? It will improve the performance of the client.

The ideal approach will be to have both client and server side rendering and take a decision based on the requirements rather than be constrained to only client side or server side.

Reply on news.ycombinator.com