Live data from Hacker News

Guide to JavaScript Frameworks

javascriptreport.com

61–70 of 244 posts

Re: Guide to JavaScript Frameworks

#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 slightly disagree with what a more established framework does.

Looking through a number of the entries in this list you read that it was "inspired by React". Why not just make React more flexible so that your alternative way of handling code fits within it? Does each of these new approaches really require a whole new framework?

Contrast this with something like the .NET Framework (which is something I'm more familiar with). Whilst the CLR has the potential to run frameworks other than the .NET Framework, you don't see the same churn in frameworks that you see with JS. I'd suggest this is due to a mixture of two things:

1. A greater focus on getting things done over code elegance.

2. The more mature a framework becomes, the more work is required to match its feature set.

On this second point, if JS continues its constant framework churn, it'll be stuck with immature frameworks. I'd suggest that JS devs should be doing what they can to get past this stage, and if that means (for a few years) treating new frameworks as interesting experiments rather than the next big thing, then that may be a cost worth paying.

Re: Guide to JavaScript Frameworks

#62
post #60

Starting from fresh, I would honestly recommend PureScript or Elm (and eventually Haskell/GHCJS when that moves to WASM). The benefit you get from the amazing type systems and compilers these have, is worth so much when it comes to refactoring, and later on boarding new people, giving them the confidence to make changes thanks to the help of the compilers.

If you want type-checking, going with React + Flow/Typescript is a wiser decision than choosing Elm. Better support, better ecosystem, much bigger community by a huge difference.

Re: Guide to JavaScript Frameworks

#63

Whats the right choice for building a repacement for an existing app that has survived for 15 years and you want the replacement to last at least another 10? Whats the long term hedge?

If you think Facebook will still be there in 10 years, then you can safely pick React.

Re: Guide to JavaScript Frameworks

#64
post #7

Reasons why Vue will rock your socks off - Don't need to know jsx! - Sane way of scripting puts the script in an object and each component is html javascript css - Event buses allow sharing of variables between child components without either redux or pushing variables down one child at a time (finally!) - v-for looping is saner than reacts mapping - v-if allows v-if statements without renderIf component or multiple…

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 suggest anyone thinking of using two-way binding for anything to rethink their choice. There is always a better way.

Re: Guide to JavaScript Frameworks

#65
post #7

Reasons why Vue will rock your socks off - Don't need to know jsx! - Sane way of scripting puts the script in an object and each component is html javascript css - Event buses allow sharing of variables between child components without either redux or pushing variables down one child at a time (finally!) - v-for looping is saner than reacts mapping - v-if allows v-if statements without renderIf component or multiple…

The points you've listed are the very reasons why i would prefer React actually ... - JSX fixed all the templating issues from 10 years ago, i see no reason to go back to dependency injection, scope loss, arbitrary code-in-html expression and a semi-javascript accent - Presentational view logic belongs to the controller while business logic is elegantly abstracted in React: view=fn(state). There's no point in ripping…

[deleted]

Re: Guide to JavaScript Frameworks

#66
post #57

The rumours of Ember's demise are greatly exaggerated. I have yet to hear of people making the same amount in any other framework. Seniors are making $200k to $500k in remote positions (the people I know live in Toronto, but they could be anywhere). It is hard to learn, and I'm far from an expert, but the highest I've heard another JS developer who knew both Angular and React completely and he was responsible for mig…

I'd point out that often rare and often unused skills get higher pay due to simple supply and demand. I've heard similar salary ranges for Assembly programmers for example. Angular and React are widely used, and there are many people out there that know them. No need to pay a ton. > The problem with Ember is the learning curve because it doesn't usually let you take shortcuts. I'm guessing that's precisely one of the…

It’s not a language, it’s a framework. You can take any experienced JS developer and make them proficient in either Ember or any framework mentioned in the article within days.

People overexaggerate how difficult each framework is. They’re all front end frameworks made to do one job. Yes, each of them have their own nuances, but nothing that cannot be understood spending few days coding, reading docs and speaking with someone experienced in this particular framework.

Re: Guide to JavaScript Frameworks

#67
post #44

I come from a pure HTML + CSS + JS (mostly via jQuery) background. My career has headed in a direction that focusses a lot less in the frontend web, but every 2 months or so I read one of these guides and I get giddy - "Finally, I will teach myself angular/vue/react/backbone/knockout". After about 10 minutes I am filled with dread. I expect to learn about a specific piece of software, instead, I am greeted with requi…

I'm coming from a similar background and mindset but over the past few months I've been doing a lot of prototyping and some production using Vue without the build tools. I just include vue.js and use x/template scripts for the templates. It's definitley saved me hundreds of hours already.

Re: Guide to JavaScript Frameworks

#68

Whats the right choice for building a repacement for an existing app that has survived for 15 years and you want the replacement to last at least another 10? Whats the long term hedge?

That’s what Ember was made exactly for. Stability without stagnation. LTS versions. Strict semver.

Re: Guide to JavaScript Frameworks

#69
post #7

Reasons why Vue will rock your socks off - Don't need to know jsx! - Sane way of scripting puts the script in an object and each component is html javascript css - Event buses allow sharing of variables between child components without either redux or pushing variables down one child at a time (finally!) - v-for looping is saner than reacts mapping - v-if allows v-if statements without renderIf component or multiple…

The points you've listed are the very reasons why i would prefer React actually ... - JSX fixed all the templating issues from 10 years ago, i see no reason to go back to dependency injection, scope loss, arbitrary code-in-html expression and a semi-javascript accent - Presentational view logic belongs to the controller while business logic is elegantly abstracted in React: view=fn(state). There's no point in ripping…

These are exactly the same reasons that I think React is the best. Vue looks like it's going backwards compared to React. Furthermore, you get native mobile apps for free with React Native. Also, React has a much, much bigger community and bigger companies supporting it.

Re: Guide to JavaScript Frameworks

#70
post #60

Starting from fresh, I would honestly recommend PureScript or Elm (and eventually Haskell/GHCJS when that moves to WASM). The benefit you get from the amazing type systems and compilers these have, is worth so much when it comes to refactoring, and later on boarding new people, giving them the confidence to make changes thanks to the help of the compilers.

If you want type-checking, going with React + Flow/Typescript is a wiser decision than choosing Elm. Better support, better ecosystem, much bigger community by a huge difference.

If you want strong static typing on par with haskell, check out reasonml.
Post reply on HN