Live data from Hacker News

Show HN: An Isomorphic JavaScript Framework Faster Than React

jsblocks.com

71–80 of 257 posts

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

#71

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?

Server code is spread across different languages. But every webdev is forced to use JS on the client. It's the sheer amount of people using this language.

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

#72

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?

I've been coding JS for a while now, and it personally feels having imposter syndrome most of the time.

It's easy to get into making/sharing something, but has no (strict) guidelines on how things are structured or work. So you have countless ways to do one thing.

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

#73
post #58
post #51

Earlier quoted context omitted.

Oh ok, well then I guess it's just Google's fault.

It's Google fault as in a mistake, a defect, an offense that they've created a popular js framework? Is that a correct interpretation of your words?

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.

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

#74
post #70

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…

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)

Tired of looking at new javascript frameworks? Look at this javascript framework that will fix everything!

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

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

I agree. Performance is important because the lack of it creates problems. Additionally, with performance I want to showcase that you can rely on a framework that is built with care because it is hard to be compared with frameworks like React and Angular built from the two largest companies in the world. It needs skill for a single person to create such a framework.

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

#76

I'd be more interested to see a performance comparison with Mithril[1] rather than React, their core functionality is similar but Mitril strives to be lean and fast. [1] https://lhorie.github.io/mithril/

Mithril's use of helper assisted javascript for it's view templating is a giant drawback for me. I'd be using it exclusively, but as an old crusty dev, I've gone down that path more than once, and it's always been a train wreck.

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

#77
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 frameworks shouldn't be using DSLs yet you praise React which uses JSX which contains a declarative DSL in form of XML markup ... your point is a big contradiction.

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

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

How do the frontenders and CSS folk feel about you making assumptions about what CSS selectors there should be in order to render a template on the backend? Its hard enough to get dedicated frontend folk to stick to an adaptable/maintainable CSS architecture like SUITCSS, let alone backenders too. I've always thought Enlive seems to create a brittle co-dependency between frontend and backend codebases, ok for small projects with 1 or 2 devs with skills that span front and backend, but surely a nightmare for larger project with lots of people working on them?

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

#80
Resuming:

I know that we are still in the wild west but Javascript Land should start learning politics.

Javascript Land tribes need to merge and get a larger population support, a small tribe even with fast weapons will never be more than a guerrilla. External support is also crutial (Angular, React and Typescript without Google, Facebook and Microsoft, respectively, wouldn't be nearly as strong. Even Meteor has external support: Horowitz). It completely saddens me watching little tribes as Elm, Purescript or Clojurescript struggling even with such a great weaponry. These little tribes should at least merge. Sometimes is too difficult but other times is just pride: their leaders want to remain as such. Stepping down a bit in the hierarchy doesn't seem acceptable for them, they prefer to be the leaders of the guerrilla till the end - because normally there is an end.

Politics are boring and ugly but they work: just look at Meteor.

Post reply on HN