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

81–90 of 257 posts

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

#81

Post by lectrick »

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 get paid to solve puzzles by writing machines directly from our minds and in most dev shops I've worked in nobody cares if you roll in at 10am, not to mention that we get compensated quite well while arguably becoming ultimately smarter than doctors yet without any required certification or schooling... I mean, in the history of human jobs, I can't imagine it getting much better!!), and staying on top of new developments is part of our job description. If you're getting fatigued, perhaps it's time to take that vacation you've been putting off, or to (wo)man-up and ask your superiors for more. Or to ask yourself if this is the right career path for you (although there's so much work now that you can get by just fine even relying on decades-old technology/libraries/languages). OR... to specialize. The full-stack developer's days are unfortunately numbered, there's no way a full-stack developer can keep up with every new development while keeping his job anymore. I myself gave up on keeping up with frontend around the time Angular came out...

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

#82

Post by onaclov2000 »

MY personal reason I like Angular (haven't had time to look into the others, sorry, but most I assume fit this bill) is that I don't need a server, I can put my application up on a static hosting site, and worry about what is happening in my controller/html/css/etc I like that approach. Putting a server that you now have to maintain is just one reason I wouldn't want to use it. I Love Firebase/Sendgrid/etc because I can write a client side only app exclusively, and let people who are good at databases,email,etc manage the back end. Is it a poor approach? Maybe, but when you only have an hour here and an hour there to build things, spending 6 months just setting up a few simple things seems crazy. Getting to a working application quickly for me is the goal. (I am not amazing with databases, so something like firebase gives me database with ease, and I don't have to figure out how to setup a server, figure out the database, figure out where to host... Same goes for email providers, etc)

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

#83

Post by oabm »

I'm just generally not a big fan of "X is some percent slower than Y" stats, because I find them counterintuitive. However, in this case I think something is wrong.

Rendering:

  jsblocks: 700ms
  React:    950ms (35% slower)
  Angular: 2200ms (310% slower)
Doing some maths:

  700ms + (700ms * 0.35) = 945ms
  700ms + (700ms * 3.10) = 2870ms
Looks like they got a little carried away when calculating Angular's rendering speed. Same thing with the "Syncing Changes" stats.

Edit: formatting

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

#84

Post by kyllo »

dkersten wrote: post #52
hippich wrote: post #30

Earlier quoted context omitted.

What is problem for you - for some might be job security :) And I think Angular is still very much in fashion. At least this is impression I am getting from occasional talks with random recruiters.

this is impression I am getting from occasional talks with random recruiters What's in fashion isn't what the recruiters are talking about, but what the developers are talking about. Recruiters will always lag a bit behind whats actually in fashion.

Exactly, recruiters are not cool, so when they are asking for a particular framework that is the strongest sign that the framework isn't cool anymore.

It's just like when your parents start listening to your (former) favorite musician.

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

#85

Post by insin »

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…

     ...
The React (or Mithril, or Mercury, or other virtual DOM libraries - just change the function being called) equivalent would be:

    products.map(product => React.createElement('div', null, ... ))
Which you can use JSX (again in any virtual DOM library, via Babel) to sugar as:

    products.map(product =>  ... )
The flow control is outside the DSL, not part of it.

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

#86

Post by mozumder »

Finbarr wrote: post #66

Have you ever encountered a situation in the browser where 32k ops per second from underscorejs wasn't enough? How many rows/columns were in the table being repopulated? 10 times in 2400ms doesn't seem that bad - it's 240ms per refresh. Is this too slow for your use case? The 250ms gain on rendering 1500 rows - is this something you think needs to be optimized? I can't imagine a scenario where all of those rows would…

For me 240ms is very slow. I target 60fps for all operations, so that's 17ms. There's a very noticeable difference when you get to this level in performance.

A project i'm working on went from 10000ms -> 500ms -> 60ms -> 15ms. Each phase opened up a new usability model.

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

#87

Post by keslag »

Looks good, I look forward to playing with this.

One note on site design of the API section, you have some dead zone sizes issues. The window can be larger than trigger to turn the api list into a hoverable sidebar, but too small to display the content. This causes the API definition to fall to the bottom of the page. I was clicking for a while, thinking it not working, before realizing that the content was at the bottom.

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

#88

Post by vidarh »

Finbarr wrote: post #66

Have you ever encountered a situation in the browser where 32k ops per second from underscorejs wasn't enough? How many rows/columns were in the table being repopulated? 10 times in 2400ms doesn't seem that bad - it's 240ms per refresh. Is this too slow for your use case? The 250ms gain on rendering 1500 rows - is this something you think needs to be optimized? I can't imagine a scenario where all of those rows would…

Consider that this is rarely going to be the only thing you want to do.

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

#89

Post by xyzzy123 »

k__ wrote: post #26

Performance comparisons with Angular and React aren't that interesting anymore. They are good because they got Facebook/Google behind them and not because they are blazing the rest of the Frameworks away. Mess yourself with Mithril, Mercury or Elm.

Right; a large part of the "is this framework worth using" question really relies on "can we get other developers to work on this", "can we make a business case for it", "how is hiring going to work", and critically: "will stack overflow work for us". 50ms on the client is very negotiable and trivial versus cultural concerns.

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

#90

Post by moron4hire »

avinassh wrote: post #56
icemelt8 wrote: post #33

I seriously think this is some sort of parody of JS. Really? A new framework every week?

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 your code, they're more likely to just write their own code.

That's why I think the old style ala jQuery or Google Maps API of packaging everything manually as just namespacing-objects still makes the most sense, with the fewest tradeoffs. You give the user a single, minified JS file to either copy or reference on your CDN. It's a least-common-denominator solution and it lets the implementing developer figure out how to fit it into their workflow.

Post reply on HN