Live data from Hacker News

Show HN: An Isomorphic JavaScript Framework Faster Than React

jsblocks.com

251–257 of 257 posts

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

#251
post #222

Earlier quoted context omitted.

> 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…

That productivity gain is, in my mind, the better reason to use React. Browser performance characteristics change and most of the time you're not pushing the limits but ugly code is forever.

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

#252

Earlier quoted context omitted.

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?

Why not joining Elm instead?

do you think that Elm is in the good track? if you are involved with Elm, why I must using it? give me good reasons ;)

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

#253
post #110

Earlier quoted context omitted.

> I am however feeling so overexposed to new libraries and frameworks that I can hardly muster the energy to even look at it. That's the nature of the job. In the front-end new frameworks are born all the time, new apis are created, new paradigms are "invented". Coming up with the "perfect" framework is clearly a work in progress. Here is a list of the techs I had to learn and work with during my career : - flex - jq…

I'm not even going to try to equate the pace of backend tech libraries with frontend, but you can't just learn one stack and be set on the backend. SQL->NoSQL, various queuing methodologies, diff. Automation platforms, different scripting languages rising and falling.., You can be a Java developer on hibernate the same way you can be a frontend dev doing jquery for almost a decade but being on the cutting edge is the…

I totally agree with the point about always needing to learn on front-end because things are always changing...but having recently been exposed to the Java world there is a huge amount of stuff there too and if you're a server side dev then it's constantly changing e.g. you're org has a django app now but what about Go, Clojure, Scala, Haskell, etc, etc, etc. Different tech for different use cases but there are constantly evolving options out there.

Things are always changing but that's the beauty of it, isn't it?

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

#254
post #215
post #110

Earlier quoted context omitted.

> I am however feeling so overexposed to new libraries and frameworks that I can hardly muster the energy to even look at it. That's the nature of the job. In the front-end new frameworks are born all the time, new apis are created, new paradigms are "invented". Coming up with the "perfect" framework is clearly a work in progress. Here is a list of the techs I had to learn and work with during my career : - flex - jq…

The obvious followup question (not necessarily directed at you) is why do front-end technologies appear to be so much more transitory than back-end ones?

Probably because javascript engines (since 2008ish) are constantly improving and each new ES version adds new specs/features so there are opportunities for the smart, brave and foolish to build libraries and frameworks for these.

I think it's good that there is so much fervour around it. Time and use will flush out the things that don't work and we'll be left with the bits that do (well mostly)

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

#255

Earlier quoted context omitted.

> Sure if you don't have a family and kids Family and kids are, by any measure, a huge time and energy sink. But that too is also important work that must be done, even if it has professional costs. The guys writing these new things, more often than not, don't have a family and kids and do have all that extra time. If you have committed to a family and kids, then join a shop where family people work and be content to…

> You don't have to keep up with everything, perhaps just general trends. Just watch out for that gentle slide into irrelevancy. ;) I would argue that wasting time learning the JS "framework of the day" is not the best approach to stay relevant. Learn the logic and math behind programming and you can watch the industry slowly catch up...

Yep and if you know the fundamentals then you can pick up a new framework in a couple of weeks because these frameworks being discussed are built around core CS concepts and patterns borrowed (rightly) from elsewhere.

I was recently at a jobs fair and spoke to a lot of companies and everyone (apart from one) were saying they wanted developers who had the core fundamentals and could learn any framework or language (the latter obviously takes longer but not much longer). So they weren't putting an emphasis on having to know the latest frameworks even if they were using them, but instead looking for people with knowledge of core concepts.

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

#256
post #70

Earlier quoted context omitted.

Take a look at Mithril. People are frequently surprised by its small learning curve (and for many, the majority of the learning is for knowledge that you can go and apply outside of Mithril)

I went from Backbone to Angular to Mithril, and published a blog post about it: https://medium.com/@l1ambda/mithril-vs-angular-vs-react-d0d6...

I haven't heard of mithril until I read this thread but I think I might give it a try. I've only just picked up angular to build a form app served from a node server that communicates with good old soap services. I've kept the soap stuff on the node server so that the angular stuff is relatively light but still find it pretty heavy handed.

I'd be quite keen to look at either refactoring to use mithril or react, so will check you blog post - thanks!

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

#257
post #115

Earlier quoted context omitted.

I filled out my explanation further.

Thanks. That looks like the SV experience. I realise that this is an SV site, but it sure is tiring hearing the 1%s point of view as if it's the norm across the industry globally.

...silicon valley. sigh
Post reply on HN