Live data from Hacker News

Show HN: An Isomorphic JavaScript Framework Faster Than React

jsblocks.com

231–240 of 257 posts

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

#231
post #9

This is interesting, but it doesn't excite me. My initial reaction is to be curious as to why it's able to thrash underscore and lodash (and React too, but separately) on speed. There could be many reasons for this. Maybe I'm personally not interested in adopting a new framework, maybe your target audience (which includes me) has some sort of fatigue or lack of interest, maybe speed isn't enough of a reason to sell m…

I was curious about the claimed collection performance too, since this is an area that a lot of people have looked at, and a 5x improvement there would be pretty impressive.

Apparently, what makes jsblocks different is that it appears to be doing dynamic code generation. That's an interesting idea, though I'd have concerns about how it respects lexical scoping. There are a couple bumps apparent as well:

- the benchmark is only faster because it ends in a .reduce(). I suspect that code generation allows them to remove all collection generation here and just update the reduced value in a loop. If you remove the reduction at the end, then lodash is fastest, as expected.

- the jsblocks code in their own benchmark reports the wrong result. It appears there's either an off-by-one error or the generated code runs the filter step before the map. I'm not counting this against the method, as presumably it's fixable, but it might speak to the difficulty of code generation as a strategy.

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

#232
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.

Flow control does not belong in markup. My favourite templating system is enlive[1] (or enliven[2]). You use CSS-style selectors to select snippets of HTML to manipulate and then use code to duplicate, remove, move or replace these snippets, insert content, set attributes etc. The "template" is pure HTML without any additional markup and without any logic. The code then says "repeat this snippet for every item in thi…

Genshi [1] is (was?) wonderful in a similar respect. Although the "code" was itself an html document, it allows master templates to fully select and manipulate nodes from child templates.

[1] http://genshi.edgewall.org/

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

#233
post #50

Top article on the front page of Hacker News as I write this, and not a single positive comment below. Great job, guys... To the author: I think the homepage looks great, the examples are clear and informative, and I would definitely give this a try if I weren't wed to a couple of other frameworks right now.

I think a lot of the negativity has to do with the marketing. This isn't being sold as "a cool thing I made", but "Better MV-ish Framework" and "Faster than React". If you try to position it as better than existing alternatives, HN commenters will tear it down if they don't think it makes the cut. If you put it out as "exploring interesting new approaches", I think you're likely to see a lot less negativity here. Com…

I think upvoting means promoting discussion, not necessarily liking the article linked.

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

#234
The title of this post "faster than React" is misguided.

React is fast. Most libraries and frameworks have to be fast to be widely adopted. But speed is not, in my opinion, one of the main reasons to use React.

I use React professionally. I choose React because of maintainable the resulting code is. There are other libraries/frameworks that I could use which are faster than React. I choose not to because, having used several of them, I found the code produced comparatively more difficult to understand and maintain in the long run.

I'm sure jsblocks is awesome and some people will love it. I haven't tried it yet but perhaps I will someday. Nonetheless I think calling it faster than react, while perhaps true, will be misleading to some.

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

#235
post #110

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 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 same deal on frontend as it is backend.

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

#236

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 new new coolest javascript/css/html thing - I almost never touch html and css since I begin to use ExtJS. I'm happy and it's working.

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

#237
post #112

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…

Geography. The replies I've read, as they so often do, ignore geography. SV might move rapidly from one to the next, but the city I'm in is more conservative and moves slower, so all I've ever seen much of from recruiters are jquery, knockout, angular. SV is the gladiatorial arena, and only the survivors make it through the filters to elsewhere, so elsewhere has fewer to deal with. If you engage with SV news while li…

> all I've ever seen much of from recruiters are jquery, knockout, angular

A year ago they weren't even asking for angular.

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

#238
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.

I'm at a loss- I don't know what the SV acronym stands for :O

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

#239
post #189
post #154

Earlier quoted context omitted.

Sorry, poor word usage on my part. As vvpan more eloquently puts it, DOM construction via js functions. This is the example from their website. This is very difficult to maintain, and personally, I become very adverse to making changes. Though it appears vvpan has a link to a project attempting to fork(?) React's transformer to be usable in mithril. todo.view = function() { return m("html", [ m("body", [ m("input"),…

Not "attempting to fork", MSX is a JSX fork that outputs Mithril-compatible virtual DOM JS objects. It works as advertised :-)

Since I've been called out twice on my use of language in this thread alone, I serious need an editor to proof my comments before I submit them from now on.

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

#240

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 most ironic thing in all this is that your comment is still full of Herd mentality, except that it goes the other way.

No it's not. There. Did I win?

> 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

Right, and a hammer is just a tool like any other, so using one to cut steel is neither a good or a bad idea, it all depends on the people who actually use it!

Post reply on HN