My comment that said "So far, the Infinite monkey theorem is just giving us an infinite number of javascript frameworks, and no Shakespeare" acquired 29 points but then has been deleted. Why is it so?
Show HN: Moon – fast 7k Vue alternative
141–150 of 200 posts
Re: Show HN: Moon – fast 7k Vue alternative
#142My comment that said "So far, the Infinite monkey theorem is just giving us an infinite number of javascript frameworks, and no Shakespeare" acquired 29 points but then has been deleted. Why is it so?
It isn't deleted. It's rolled up down thread.
Re: Show HN: Moon – fast 7k Vue alternative
#143Earlier quoted context omitted.
Interestingly (to me), the AngularJS (1.x.x) repo on GitHub is still receiving a decent level of commits: https://github.com/angular/angular.js/commits/master Kind of glad about that, as it's what I'm still using. :)
1.x has ultra solid support from business software industry. It will for long remain "the COBOL of the web"
COBOL for the Web has already been done: http://www.coboloncogs.org/
Re: Show HN: Moon – fast 7k Vue alternative
#144Earlier quoted context omitted.
No: it leaves no goat unblown. Particularly for people new to it. Back in the day anyone could hack together a bit of JS for their website and get something up and running, even if it was a bit Heath Robinson. You actually still can do this but you wouldn't necessarily come away with that impression from reading about front-end development. Cynically, it sometimes feels like front-end developers are overcompensating…
When you code something, choose the most strict browser/compiler you can. Then you get it right the first time and don't have to see it break so much later when tested elsewhere.
Which do you use? I've been bitten numerous times by a seemingly normal object or array method being Mozilla only or not yet standardised...
Re: Show HN: Moon – fast 7k Vue alternative
#145Earlier quoted context omitted.
1.x has ultra solid support from business software industry. It will for long remain "the COBOL of the web"
I have yet to do anything on my webapp that uses a JS framework (the minimal interactivity is raw JS and at most a touch of jQuery) precisely because I've yet to see a framework that I was somewhat confident would be relatively stable over the long term, say 10 years? Something like "COBOL for the web" would be ideal. But if I were starting now I wouldn't choose Angular 1.x, would I? Any recommendations.
Angular 1 has its flaws but I've found it to be pretty stable, has developed some pretty consistent paradigms, and gets certain jobs done well. Don't put the round peg in a square hole, but I think it serves many web apps well, particularly if you're going the SPA route and don't care too much about things like viewing without javascript or ultra fast load times.
I used it first in a personal project, then in a job, and have used it after in a personal project. I think that says it's at least not the worst. I've wanted to look into Vue and React for some time but I'm mostly a back end developer. Angular is getting the job done to the point that I haven't been forced to switch.
Re: Show HN: Moon – fast 7k Vue alternative
#146Oh look a new JavaScript framework
Re: Show HN: Moon – fast 7k Vue alternative
#147So we are here. It didn't took so long for vue to go from "will vue be new react ?" To "vuejs alternative".
Just because something exists doesn't mean one has to care. The problem with "frontend fatigue" is similar to what we see elsewhere; caring about problems one doesn't have or own in the first place. I'm not addressing you specifically (as your comment seems more observatory) - but I reckon it's still worth pointing out. Let the curious create and share their creation with the world.
I agree about the principles but not about how it happens on the real world. Many front-end jobs now require you to know at least one front-end framework (normally React), which is a totally different and focused problem-solving tool. Before you had jQuery that scaled from small, personal projects to mid-size projects. This worked great as a learning progression, however now you have React (and others) that don't make sense for small projects and are a bit overkill for mid-size projects.
So new developers get thrown in this crazy world where they have to learn a thing that has no real practical use just because they want a job in the field. IMHO, new tools must make things easier for everyone and specially for newcomers, while React seems to make large-scale problems easier but a LOT harder for beginners.
And finding a new job is a problem that we all have from time to time.
Re: Show HN: Moon – fast 7k Vue alternative
#148I just want someone to take another look at ontercooler js, the best CSS and JavaScript is the CSS and JavaScript I don't have to write. Every time we hire someone fresh out of college they ask if we can learn angular and my reply is why do you need it? Because you heard of it? And basically that's the only reason they mentioned it.
Re: Show HN: Moon – fast 7k Vue alternative
#149Earlier quoted context omitted.
Moon is a part of js-framework-benchmark[1] (in the non-keyed results), and it performs faster than Vue there. The article I wrote a while back also has some benchmarks[2]. Finally, the overview section of the documentation also has benchmarks[3]. [1] https://rawgit.com/krausest/js-framework-benchmark/master/we... [2] https://hackernoon.com/introducing-moon-1d44a99635f0 [3] http://moonjs.ga/docs/overview.html
There's no keyed benchmark for Moon, that's more difficult to optimize.
He tried to solve performance problems in complex applications, and obviously complex applications doesn't need to preserve internal state when children list is changing :)
Re: Show HN: Moon – fast 7k Vue alternative
#150Earlier quoted context omitted.
> This makes it faster to load on mobile devices. That's not very significant, since even your favicon will be of comparable or even bigger size, much less any static asset like an image.
it's significant because code has to be additionally parsed and JIT-compiled. which is not true of images which simply blit pixels to screen as they decompress; it's not simply about size on the wire. https://twitter.com/HenriHelvetica/status/877924754195324928
But many libraries that has a primary focus on library size are usually sacrificing runtime performance to reduce size. Yes, they've reduced parse time, but significantly increased bootstrap time.
I understand that they are doing it because of marketing reasons, because many people think that smaller means faster.