Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: An Isomorphic JavaScript Framework Faster Than React

jsblocks.com

Post reply on HN
Print view View original

221–230 of 257 posts

Re: Show HN: An Isomorphic JavaScript Framework Faster Than React

#221

Post by jarrettc »

andybak wrote: post #191
kyllo wrote: post #142

Earlier quoted context omitted.

ng-if, ng-switch, ng-repeat? There's already a language in the browser that does these things, it's called JavaScript. Why do you even need dependency injection and singleton services and factories in a dynamic language with closures and first-class functions? You don't. Client-side testing works fine without DI. Angular is just a way to do Java in JavaScript. It's a pile of unnecessary complexity designed to sell to…

> ng-if, ng-switch, ng-repeat? There's already a language in the browser that does these things, it's called JavaScript. It's nice to have a largely declarative way to specify markup but still allow simple loops and conditionals. Hasn't every template language in the world has come to a similar conclusion?

> Hasn't every template language in the world has come to a similar conclusion?

No, not even every mainstream template language. For example, I still use ERB and EJS extensively, and so do many other engineers. ERB and EJS use the control flow constructs of the underlying languages (Ruby and JS, respectively).

There is of course debate about whether templates should expose the full power of a programming language. I have tried templating languages that do and ones that don't. For now, I'm sticking with templates that let me mix in arbitrary code as I see fit. Could I abuse that power and make a mess? Absolutely. But I try not to, and my code stays pretty maintainable.

Re: Show HN: An Isomorphic JavaScript Framework Faster Than React

#222

Post by acdha »

lhorie wrote: post #212
acdha wrote: post #200

Earlier quoted context omitted.

That only helps if you had poor state management and churning updates to things which hadn't changed. If you actually have a large number of DOM elements which need to be updated, you'll find that React is an order of magnitude worse than just using the DOM directly because it has to do that extra book-keeping multiplied by the number of elements.

Touching the DOM is by far the biggest bottleneck in performance. Of course for some arbitrary discrete task, hand coded DOM manipulation code is always going to be faster than a layer of abstraction on top of it. But the strength of virtual dom is that a single piece of code can handle insertions, deletions, sorts, splices and pretty much any data contortion you can throw at it without increasing code debt. Managing…

> Touching the DOM is by far the biggest bottleneck in performance

My point was simply that this devolves back to Amdahl's law: the only way that React overhead + the DOM can be faster than the DOM alone is when the pure-DOM code is doing too much work. It's possible that React makes the code so much easier to maintain that you write better algorithms but that has very little to do with the virtualdom rather than the strong push towards better structure.

Re: Show HN: An Isomorphic JavaScript Framework Faster Than React

#223

Post by z3t4 »

yummybear wrote: post #12

I think it's great that there is such an amount of active development in the JS sphere, and I'm sure your framework is fantastic - so don't take this as directed at your framework specifically. That being said... I am however feeling so overexposed to new libraries and frameworks that I can hardly muster the energy to even look at it. I constantly feel that I'm behind on my homework having to evaluate new libraries a…

Instead of learning a new framework, try learning a new paradigm. You can then apply that knowledge in whatever new shiny tool your boss want you to use to build the next big thing.

Re: Show HN: An Isomorphic JavaScript Framework Faster Than React

#224

Post by Dewie3 »

lectrick wrote: post #81
yummybear wrote: post #12

I think it's great that there is such an amount of active development in the JS sphere, and I'm sure your framework is fantastic - so don't take this as directed at your framework specifically. That being said... I am however feeling so overexposed to new libraries and frameworks that I can hardly muster the energy to even look at it. I constantly feel that I'm behind on my homework having to evaluate new libraries a…

> I constantly feel that I'm behind on my homework having to evaluate new libraries and frameworks showing up. Every two weeks, another one shows up with another paradigm shifting approach. Every two weeks ? Try every day. I hate to be that guy, but this sounds like whining. You're a developer, it's an incredible privilege (we're part of one of the fastest-growing, most-successful businesses ever, and we basically ge…

> Or to ask yourself if this is the right career path for you

Yeah. No wonder people figure out that it is not the right career path for them when people will jump on them for admitting any kind of "programmer weakness"[1], or for not being perfectly passionate about programming all the time, or for not thanking their boss for having the privilege of getting their generous pay-check and almost salivating at getting more overtime to work on the companies' interesting problems.

Sometime the work itself might not be as bad as the people you have to do it with.

[1] In their minds.

Re: Show HN: An Isomorphic JavaScript Framework Faster Than React

#225

Post by MikeOfAu »

zaynetro wrote: post #149
idibidiart wrote: post #105

Earlier quoted context omitted.

Correct. But React is also a step behind ClojureScript based React wrappers :) like Om and Reagent.

Could you explain why are they step ahead? I am not familiar with ClojureScript, but my interest in it is really high.

This is a slightly long read, but it will give you a feel for it: https://github.com/Day8/re-frame

(disclosure: I am the author)

Re: Show HN: An Isomorphic JavaScript Framework Faster Than React

#226

Post by norman784 »

astoilkov wrote: post #114
norman784 wrote: post #109

Will be hard to compete with those big libraries like angular and react, b/c they have yet a large community, IMO I like angular on top of react (didn't like the way you create DOM with javascript, tried it 2 years ago, maybe it evolve but I doubt it). Also I'll wait till the project get more mature and get a significant community, b/c I'm not with the energy to learn every library that come out there, maybe will tes…

You are absolutely correct. It is hard to compete with Google and Facebook. Possibly impossible. I love what I do and it is great experience developing jsblocks. And one last thing you could check OneScript - https://github.com/astoilkov/OneScript . Do you think it is simple?

Its simple but got an issue, you need to hack your html. IMO the best approach will be the angular one, just add params to elements, so your designer that is brain less and only knows html can see your template after you put all the logic.

An advice maybe will be try to get as much html friendly as you can, so ppl don't need to relearn / hack html.

I only can give the point of view of someone that uses libraries, not developing libraries, so maybe there is some unknown reason to me for those approaches.

Re: Show HN: An Isomorphic JavaScript Framework Faster Than React

#227

Post by up_and_up »

> I am however feeling so overexposed to new libraries and frameworks that I can hardly muster the energy to even look at it.

My rule is to ignore pretty much anything and everything until either:

1. A year goes by and it seems like it is gaining traction.

2. certain key people that I know personally and respect also start talking about it etc.

Re: Show HN: An Isomorphic JavaScript Framework Faster Than React

#228

Post by kansface »

svl wrote: post #213
rattray wrote: post #134

Earlier quoted context omitted.

@dang, if you're listening, an idea: make the "upvote" buttons invisible on stories that the user hasn't visited before. This could be done like so: // css a.upvote-botton:visited { visibility: hidden }; upvote triangle The href & onclick handlers would need to be added in javascript so as not to affect hn for non-js users.

That doesn't actually work in pretty much any browser, since it allows for history-mining by a malicious site. :visited styling changed a couple of years ago to only honor color changes, thus preventing most ways of exploiting that issue. http://dbaron.org/mozilla/visited-privacy is one of the better resources explaining the issue more fully. I guess you could create the triangle solely with CSS borders, and then sty…

Could you not just render the anchor out of the view port and look at its color?

Re: Show HN: An Isomorphic JavaScript Framework Faster Than React

#229

Post by sitkack »

vdaniuk wrote: post #96
kyllo wrote: post #73

Earlier quoted context omitted.

Only if you feel that Angular itself was a mistake. I do, primarily because it's yet another attempt in a long history of misguided attempts to bestow Turing completeness on XML.

I don't. If Angular has produced a local optima of efficiency in the range of "misguided attempts" then it's effect on the development ecosystem was a net positive. That said, I am extremely concerned that most popular frameworks/libraries are products of megacorps.

I think that has more to do with developer evangelists/pr people and budgets. Most good ideas languish in obscurity, even when given the light of day.

Re: Show HN: An Isomorphic JavaScript Framework Faster Than React

#230

Post by reverius42 »

aikah wrote: post #77
snarfy wrote: post #3

> Well, one problem is declarative programming has never been as expressive as imperative programming. In React you'd use JavaScript for this iteration. This is why I like React over say Angular, with ng-each, ng-if, etc. Flow control does not belong in markup. I cringed the first time I saw an XML schema with an IF element.

A lot of stupid arguments in your message, the biggest being : > Well, one problem is declarative programming has never been as expressive as imperative programming Haskell is declarative, are you saying Haskell isn't expressive ? > Flow control does not belong in markup > In React you'd use JavaScript for this iteration There is no flow control in HTML , but some frameworks use DSLs in the HTML. If you are saying fr…

A DSL for logic inside of a declarative markup language is very different from a DSL for declarative markup inside a programming language.
Post reply on HN