Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Guide to JavaScript Frameworks

javascriptreport.com

Post reply on HN
Print view View original

201–210 of 244 posts

Re: Guide to JavaScript Frameworks

#201

Post by rk06 »

Klathmon wrote: post #15
paul7986 wrote: post #3

Did you learn Jan2018.js yet? If not your behind and your skills are outdated.....

I know people love to shit on JS for being blisteringly fast, but does it really apply here? All 3 of "the big 3" are over 4 years old, making all of them older than windows 10... And of the notable category: Aurelia: around 2014 Elm: around 2013 Inferno: around 2015 Polymer: 2014 Preact: 2016 ReasonML: 2016 Svelte: late 2016 So most a few years old. Yes, it's faster than older technology stacks, because the web is s…

Technically speaking, Angular 2.0 was released in sept 2016. So it is only 1.5 years old.

Re: Guide to JavaScript Frameworks

#202

Post by swyx »

keithnz wrote: post #181

I like that the only con for Vue is there's no jobs for it. Having done two major projects in React and Vue, Vue is my preference. While vue is supposedly faster, speed has never been an issue for either. I think the biggest thing for me is it's just easy. While I like React, I think vue is nicer and often more concise, and if you really want jsx, it also supports that. I also use Bulma for the visual side which work…

i mean its also because the author is obviously biased toward vue. see the other comments here for why people actively pick react over vue. dont confuse the printed word for fact.

Re: Guide to JavaScript Frameworks

#204

Post by dsego »

hobofan wrote: post #125
dsego wrote: post #94

Earlier quoted context omitted.

JSX is NOT just HTML and JavaScript! If it was just html I could write and not , I could write instead of . It's not even just javascript, or I would be able to write a simple if-else statement. JSX is a DSL, a minimal one, but still. I mean, you could say it's even worse, because those subtle differences can cost you hours of looking for mistakes.

> If it was just html I could write and not , I could write instead of In case you don't know (and I also didn't until recently), those namings come from the HTML DOM Javascript API, and not from React. So having that naming in React+JSX is more a consequence of operating on that abstraction level, than a quirky decision of the React developers.

Well, if you're being pedantic, DOM is not HTML.

Re: Guide to JavaScript Frameworks

#205

Post by mlsarecmg »

dsego wrote: post #94
Kiro wrote: post #64

Earlier quoted context omitted.

I've used Vue for larger project and like it but the things you list are the drawbacks IMO: - Don't need to know jsx! But you need to learn Vue's template DSL. JSX is just HTML and JavaScript. - v-for looping is saner than reacts mapping - v-if allows v-if statements without renderIf component or multiple render statements in react (antipatterns boo!). Strongly disagree! - two way data binding with vue-model I sugges…

JSX is NOT just HTML and JavaScript! If it was just html I could write and not , I could write instead of . It's not even just javascript, or I would be able to write a simple if-else statement. JSX is a DSL, a minimal one, but still. I mean, you could say it's even worse, because those subtle differences can cost you hours of looking for mistakes.

> If it was just html I could write and not , I could write instead of

for and class are reserved statements, hence htmlFor and className are the official api names, in other words they belong to the actual web-api spec, there's nothing arbitrary about it:

https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...

https://developer.mozilla.org/en-US/docs/Web/API/HTMLLabelEl...

If you really dislike it, you can still use class and for: https://github.com/insin/babel-plugin-react-html-attrs

> or I would be able to write a simple if-else statement

{} evaluates to a ternary. You can use if, according to the spec that's what do expressions are there for.

    do {
        if (condition) yes
        else nope
    }
Though most would probably prefer the following for stylistic reasons:

    condition 
        ? yes 
        : nope
> because those subtle differences can cost you hours of looking for mistakes

These two things are explained in a single sentence, every tutorial eases you into it, the first thing that comes up once JSX is mentioned.

Re: Guide to JavaScript Frameworks

#206

Post by expertentipp »

vanilla_nut wrote: post #187
expertentipp wrote: post #104

Earlier quoted context omitted.

> Set it up and just look at node_modules. Just a shit ton of dependencies and you have no idea what any of them do. All this sort of scaffolding set up that you're supposed to ignore. Yeah, good luck going through legal/license compliance audit in any serious company doing software.

Security is more of my concern: these things change constantly and versions can even be completely replaced, so even if you convinced someone to do a full security audit (and they checked all the dependencies of the dependency, etc. etc.) I still don't think I'd feel entirely secure.

> checked all the dependencies of the dependency

Is it even possible? I once checked perhaps at the depth 5-6 and it reached maybe thousands of items. At some point though there were many repeated dependencies, sometimes on different versions of the same module.

Re: Guide to JavaScript Frameworks

#207

Post by expertentipp »

deecewan wrote: post #144
expertentipp wrote: post #133

Earlier quoted context omitted.

Fair enough. Now imagine that your product or service is gaining popularity on the market where Google or Facebook consider you a competition.

They will buy you first.

Acquisition by Big4 is not everyone's dream, imagine.

Re: Guide to JavaScript Frameworks

#208

Post by RobertRoberts »

csallen wrote: post #98
tbranyen wrote: post #76

Earlier quoted context omitted.

Completely untrue. I was at Bocoup and we wanted to standardize on Ember. It took weeks to get devs doing the basics in a large app. Ember isn't gone because its misunderstood. Its gone because we can build the same apps using more suitable libs/frameworks, in a fraction of the time, with less code, less magic, and less upgrade burden. Ember sucked at upgrades, even though they tried to make it better.

Ember isn't gone or anything close to it.

Not to be a jerk, but can you provide any links to large sites or apps that use Ember? Again,this is a serious question, as I like to keep tabs on trends for JS stuff like this.

Re: Guide to JavaScript Frameworks

#209

Post by RobertRoberts »

ZenoArrow wrote: post #61

Purely from an outsider perspective, it's interesting to see all the different frameworks out there, but for front end devs I can't help but feel that this type of comprehensive list hinders more than it helps. One key thing JS needs less of is fragmentation. If I were in the front end dev community I'd want to see people making the front runners more mature and flexible, not endlessly fragmenting just because they s…

I actually think fragmentation is ideal, it demonstrates the failures in a system more cleanly. For example, I started with Protoype.js many years ago, after a bunch of research at the time. But then later switched to jQuery, because it was simply better in every way.

There simply was no fixing the problems with Prototype.js, they were inherent in the system.

I think when a fragmentation occurs in every framework, its for the same reason. Consider Angular 1 to Angular 2, they broke backwards compatibility because they had too. Angular 2 could have been called something else, and it would be viewed as "fragmentation" not an "upgrade", but in effect, it was fragmentation.

This is the exact reason why I think all of these frameworks will ultimatly end up in the dustbin of history. Does any major programming language in the last 30 years use a framework that requires multiple build systems, multiple "dialects" of differing syntax just to do what is inherently available already? (but just faster and easier?)

This sounds like the end result is Webassembly, not the "perfect framework".

Re: Guide to JavaScript Frameworks

#210

Post by RobertRoberts »

Klathmon wrote: post #114
expertentipp wrote: post #107

Earlier quoted context omitted.

They appear and disappear as fast as startups and projects which use them:)

Do you have any information or statistics or studies to add, or did you just want to post your quippy oneliner?

I would actually like to know if there's a list of systems, apps, sites, whatever, that are using any particular framework. Using data from Stackoverflow or NPM downloads just isn't the same as real-world examples of actual use.
Post reply on HN