What is it isomorphic to? How do I compute the isomorphism between this framework and some other thing?
In javascript frameworks, isomorphic usually refers to running the same code in the server (node.js) as well as the client.
Show HN: An Isomorphic JavaScript Framework Faster Than React
121–130 of 257 posts
Re: Show HN: An Isomorphic JavaScript Framework Faster Than React
#122What is it isomorphic to? How do I compute the isomorphism between this framework and some other thing?
> What is it isomorphic to?
Don't bother, most people using this word in the context of javascript apps do not understand what it really means. It just has became a buzz word meaning :" you can render your views on client and on the server using JavaScript". IE you can render an HTML page representing the initial state of your app, then upgrade to an interactive application using JavaScript on the front-end seamlessly .
You can't do that with angularjs 1.x for instance without some kind of heavy machinery relying on a headless browser. That's why angular 2.x basically ditches 1.x and is a completely different framework.
Re: Show HN: An Isomorphic JavaScript Framework Faster Than React
#123I'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.
What do you mean by "helper assisted javascript"? Can you give an example where this has caused problems for you?
I'm trying to decide between mithril and this library.
Re: Show HN: An Isomorphic JavaScript Framework Faster Than React
#124Earlier quoted context omitted.
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.
I don't. If Angular has produced a local optima of efficiency in the range of "misguided attempts" then it's effect on the development ecosystem was a net positive. That said, I am extremely concerned that most popular frameworks/libraries are products of megacorps.
That is in part due to the complexity of problems in frontend and that most companies don't need to solve those problems (or don't have the resources to solve them).
Re: Show HN: An Isomorphic JavaScript Framework Faster Than React
#125I 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?
Ahh. You just haven't been around Python for long enough.
Python used to get new server framework every other week. There was a Cambrian Explosion of them at one stage. Then it settled down. Javascript is still evolving. React has just kicked off a whole new iteration by putting the reactive/functional/immutable paradigm firmly on the agenda. That's going to take a couple of years to play out.
BTW, If you want to see what that combination looks like in a more suited language then look towards ClojureScript or Elm.
Re: Show HN: An Isomorphic JavaScript Framework Faster Than React
#126Earlier quoted context omitted.
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…
What do you think about OneScript - https://github.com/astoilkov/OneScript ?
Can't say I'm a fan honestly. Reminds me too much of PHP, I guess.
The thing about reagent/hiccup is that the markup is just a clojurescript data structure and can be composed and manipulated like one. This also means that you can easily write pure functions to generate the UI (data in, markup out).
The thing about enlive/enliven is that the markup and the logic are completely separated.
OneScript has neither of the things that I like about enlive or reagent.
EDIT: I should probably add that I'm not particularly a fan of JSX either, so I'm probably the wrong person to ask for an opinion on this.
Re: Show HN: An Isomorphic JavaScript Framework Faster Than React
#127I'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.
You mean how the DOM is constructed via JS functions? There's this project to fix it: https://github.com/insin/msx
Re: Show HN: An Isomorphic JavaScript Framework Faster Than React
#128Earlier quoted context omitted.
So don't study it then? It's perfectly fine to continue using what you are using. Most recruiters talking to me still ask for Angular, even if I consider it a little hairy and prefer not using it. After being in the JS sphere for a while and living with these changes, I have learned a lot. Because there is nothing new under the sun, these all do pretty much the same thing - but in different ways. There are tradeoffs,…
The problem is, it's our fault that recruiters are now asking for Angular, because we sold our employers on Angular and built their apps in Angular. Now that Angular is mainstream and has fallen out of fashion, they need to hire more developers to maintain all those Angular apps we built for them.
I think it's not so much the fact that developers praised Angular, but rather this same above mentioned proliferation of frameworks - with so many choices, at some point it becomes paradoxically more likely that people will follow the herd instead of picking each his own framework (if I may oversimplify to make the point clearer) with the risks that entails (possibility of bad choice, of support ending while you still need it...). Nobody's gonna get fired for betting on a big name like Google.
Re: Show HN: An Isomorphic JavaScript Framework Faster Than React
#129Earlier quoted context omitted.
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.
I guess it is also depends on who is judge - either business (my case) or developers (yours :))
If you're talking about finding a job now, then I absolutely agree. But if you're talking about what technology developers will persuade their employers to adopt in the future, then developers are the ones who decide.
Employers seem to be influenced by what the developers push (maybe not short term, but longer term it seems to me to be that way). Recruiters go where the employers are. Therefore, IMHO, ultimately its the (vocal) developers who pick the fashion.
Re: Show HN: An Isomorphic JavaScript Framework Faster Than React
#130Earlier quoted context omitted.
Is this just criticism of the "isomorphic" term? I'm not a fan of it either ("isomorphic" already has a different well-defined meaning in CS), but it does seem to have some traction now. Perhaps you have an alternative term you'd prefer these frameworks used?
I've seen "progressive javascript"[1] and "heterogeneous javascript". Both of which are much better IMHO. [1]: https://medium.com/the-thinkmill/making-the-case-for-progres...
Agreed, both of those are better. Hopefully one will gain traction.
Thanks for the link, good to know people are thinking about the naming issues.