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

241–250 of 257 posts

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

#241

Post by scorpion032 »

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…

Which is the reason, it is an appropriate time to back and stay with React for the long term.

React has so many technical benefits that is all covered through so many posts - That declarative is better, Fast DOM manipulation with Virtual DOM is nice and a great development API and syntax sugar with JSX is wonderful.

Having said all of that, I think what seals the deal in favour of React is that it is being used by Facebook on their homepage for half a decade and in all likely hood going to be continued to, which means you're assured of incremental upgrades and regularly maintained and yet no radical shifts, which would warrant a large change for your product.

I think Facebook has hit the abstraction level perfectly with "Product Engineering" and "Library Development" or "Infrastructure Development". This abstraction may not work well for all use cases. But for a large audience this is what is needed and where it is needed, it fits in perfectly.

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

#242

Post by tracker1 »

While I think this is relatively cool, I'd be somewhat more interested to see how it compares to knockout. Beyond that, none of the demos give any indication as to how one would create discrete components or modules, it seems like you'd wind up with some fairly difficult to manage code on a larger project.

React and related tools just feel more right to me... that or going more towards Polymer... There are several alternatives, and in practice, how many times are you going to change all 10k rows in a table 10 times? I'll lean towards more manageable code in this case. We aren't talking the performance drop to say Angular 1.x, or other frameworks that work directly against the DOM.

Of course most people don't need absolute performance in a web based application. To me React with something similar to Flux just makes the most sense... I think Flummox brings it to a nice circle, that's easy enough to reason about.

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

#243

Post by tracker1 »

kyllo wrote: post #211
ccalvert wrote: post #187

Earlier quoted context omitted.

Angular is helpful because it promotes things like loose-coupling, dependency injection, modularity, re-use and the factory pattern. I agree that two way data binding was oversold. It isn't a bad thing, just not the most important thing about angular. No doubt angular itself, and other libraries, will evolve. But I don't think angular is a mistake. It encourages developers to design applications the right way.

Angular is helpful because it promotes things like loose-coupling, dependency injection, modularity, re-use and the factory pattern. Modularity and code re-use are like apple pie and motherhood. The real question is, do you need dependency injection and the factory pattern to get those things? In JavaScript, the answer is no you don't, because you have closures and first-class functions. Patterns like DI and Factory…

I have to agree.. factories and IoC/DI in JS just seems like such alien overkill in the space. Yes, it's great when you need to create a testable system in a strongly typed world like .Net or Java, but in JS you can simple spike your module loader for unit testing your modules in certain conditions (proxyquire and the like).

Even in those platforms (.Net and Java) unit testing is such a miserable experience, and adds so much complexity it's easier to just skip unit testing in favor of simpler classes/methods and better integration tests.

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

#244

Post by tracker1 »

arcatek wrote: post #202
sillygoose wrote: post #151

Earlier quoted context omitted.

The overarching problem here is herd mentality. Using Angular is a bad idea, but lots of companies are using it anyway because The Herd stampeded towards the new shiny thing, mostly because of how cool two-way binding looked in Angular's demo toy app. Now all those companies are bogged down by Angular, but feel like ejecting it would be too costly. Elsewhere, lots of new developers are introduced to Angular and inves…

> Using Angular is a bad idea, but lots of companies are using it anyway because The Herd stampeded towards the new shiny thing The most ironic thing in all this is that your comment is still full of Herd mentality, except that it goes the other way. Angular is a framework, period. Using it is neither a good or a bad idea, it all depends on the people who actually use it.

The couple of times I've worked with angular, some things went incredibly smoothly, and when you hit those edges, it really reminded me of ASP.Net 1.0, it was nice for about 80% of your workload, but the other 20% took 10x the effort, and was a much bigger headache to work around.

Honestly, if/when browsers have better support, I think something closer to Polymer may be the best of all worlds with web development... for now, I find that React code tends to be the most sensible (with a decent framework around it)... not to mention shared client-server code with node/io.js

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

#245

Post by tracker1 »

rhapsodyv wrote: post #236
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…

Man, a few hours ago I was debating with some team mates about js frameworks. In the middle of this ocean of frameworks I keep going with ExtJS. And I'm very criticized about this. And today the discussion is as always - that it's a monster and I need try ember ou angular etc etc... But I keep using ExtJs happily focusing in my business and almost never worrying about why something not work and wondering how to use n…

You might actually want to spend some time looking into useing node/babel to transpile ES6/7 syntax JS into ES5.. this will give you a leg up in writing inherited classes with JS... alternatively there is TypeScript, which you may also like and be more productive with.

That said, I think that ExtJS's UI is starting to look a little long in the tooth, but it's still usable. I really never liked it... class based hierarchies in JS always seemed like a waste to me.

That said, if that's your path, there are still some newer tools (namely node+babeljs) that can greatly improve your development experience... I think the module and class syntax from es6 would be a boon for you, along with being able to use es7 async/await combined with a fetch shim...

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

#246

Post by tracker1 »

avinassh wrote: post #143
joshuacc wrote: post #120

Earlier quoted context omitted.

My personal theory is that it is because * JS is possibly the largest programming language community in the world * There are a lot of shortcomings in "the web platform" for app-style development * Most JS developers are primarily developers in another language with a stronger culture and set of ideas/idioms Combine these things and you get .NET developers creating C# flavored JS frameworks, Ruby developers creating…

Is there any Pythonish JS framework?

There are clones for most popular template rendering systems, and would be surprised if there wasn't similar as a whole application framework.

Do a search of https://npmjs.com/ for a framework you want a synonym to, and you will probably find it.

For me, some tools simple ring better in the JS way than others... if it's too cobbled, and relies on strange markup behaviors I like it less. If it's really class centric I tend to like it less, though ES7 classes and React isn't too bad. It just depends on your likes.

I really don't like seeing certain patterns in JS (factories and di/ioc) as they simply aren't needed and only add complexity.

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

#247

Post by tracker1 »

moron4hire wrote: post #90
avinassh wrote: post #56

Earlier quoted context omitted.

As someone who mostly codes in Python, I don't understand, why JS gets new framework so often. What is the reason behind? Is Javascript makes thing easy to develop a new framework? Why doesn't Python get new framework so often?

It because package management in JS is complete garbage. I can't believe people actually like using Bower or Browserify or JSPM or any of it. While NPM for Node has some scaling problems, at least it just works for the simple cases. I've never not had problems with the client-side JS package systems and managers. So package adoption is hard because of this. If you make it a pain for implementing developers to use you…

In general I just use npm... I don't use bower or jspm... for that matter, I don't think browserify where needed is so bad.. there's also options with babeljs, which I'm liking more and more.

A base set of packages, for your external functionality, your core (shared functionality) and the rest makes a lot of sense, and isn't that hard to do. In the end it's pretty easy to reason about, and with sourcemaps and better build tools it's easy to use. Though having to have a watcher or build process when JS changes takes some getting used to... if you're used to compiling server code, it really isn't bad...

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

#248

Post by tracker1 »

acdha wrote: post #222
lhorie wrote: post #212

Earlier quoted context omitted.

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…

There's the fact that dom changes related to a given set of events can be made as part of the same changes to the DOM as a whole... which can reduce parts of the render time overall.

However, depending on your needs, a stream of changes may behave differently in different use cases... to me React simply represents in my mind a better way to manage components and rendering logic, combined with something like flux for data and event flows.

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

#249

Post by lewisl9029 »

xtrumanx wrote: post #188
alejandrodob wrote: post #167

Earlier quoted context omitted.

Because Clojurescript uses immutable data structures, and keeps the state in a centralized atom, so comparing different states is as easy (and fast) as comparing the different versions of the data structure, which in turn (and thanks to being immutable data structures) reduces to compare their memory references, which is fast.

Immutable.js is a project also from FaceBook that brings immutable data structures to your JS applications including those using React. Since Clojurescript compiles down to JS, wouldn't it be possible to use Immutable.js and a slightly different app design (a single Flux Store for the entire app) to get the same benefit of using React with Clojurescript?

The centralized immutable state oriented architecture advocated by Om can definitely be implemented using plain JavaScript (my favorite in this space is https://github.com/moreartyjs/moreartyjs), but language features like core.async, transducers and macros are not so easily replicated.

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

#250

Post by rattray »

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…

Ah, good catch. You would just do `color: white` then, no?
Post reply on HN