It looks like you're new here. If you want to get involved, click one of these buttons!
Subscribe to our Patreon, and get image uploads with no ads on the site!
Base theme by DesignModo & ported to Powered by Vanilla by Chris Ireland, modified by the "theFB" team.
Comments
Any recommendations? I'll be buying tonight or tomorrow
Whaaaaat
Does that mean I can buy them on the app but use on the pc?
When does the sale end?
What even.
We started using Angular 1 and got badly burned. Once you are using it you are basically locked into the framework and when two came along the upgrade path was "ground up rewrite your app". Unlike React which is the core of Facebook and Instagram Google don't actually use Angular all that much and tend to pull these kind of product abandoning tricks at will. We ended up having to bin a project and start again as a result.
Single Page apps with APIs are awesome though I wouldn't want to do a complex web app any other way now.
We've been using React quite a bit and it's very impressive, but I'm not totally sold on the whole JSX, Redux, Webpack tangle you have to build to get up and going. It's just a bit too complicated.
VueJS looks very cool.
I chose it because there seem to be a lot of roles that ask for a basic knowledge of js or html. Seems a smart thing to learn regardless. Hope it's good
However...Angular 2 is very, very different to Angular 1, and they seem to have sorted the upgrade path from v2 onwards so that it's not such a painful jump as from v1 to v2.
Personally, I remain completely unconvinced that any of these frameworks will show us any benefits whatsoever. This is absolutely the worst way to make a decision like that. We did a bunch of test screens, and in every single case I built it in Rails and jQuery faster than the guys could do it in Angular 2 (and, from what I can tell, it'd be a similar comparison to React or Vue), so the main ostensible argument of "It makes development really smooth" is out of the window. Hell, they spent a whole day building one screen of medium complexity, with all the crap involved that Rails takes away with its convention-over-configuration approach.
We're also never moving our customer-facing site to it (for forward-compatibility reasons), so this is only for our back-end systems...which run locally and so fast that there's no real performance benefit to using SPAs at all; the latency introduced to the workflow by the system is no more than a rounding error compared with the latency caused by a user sitting in front of it. We also don't get any additional functionality out of it; there's nothing we can do in Angular, React or Vue that we can't already achieve more reliably (and with less dependencies and code fragmentation) with Rails and jQuery.
However...a huge part of the reason for doing it is that most developers these days want to do it, so if we want to get good developers on the case (through the company that we outsource a bunch of our work to) then we have to use something that's trending. I remain utterly convinced that this is the worst way to make a decision, but the choice wasn't mine in the end and ultimately I'm existing in the decision-making process purely to temper the worst of the excesses caused by developers who just want to play with new toys.
The binding stuff in Angular can be a minefield for the unwary. Once you get things cascading events to other things and triggering updates all over the place you can get some really nasty chain reactions of weird stuff happening.
There is something to be said for shiny shiny. One of the reasons we moved away from using PHP at work was that you simply could not get anyone we would be prepared to employ to apply for a job. If you use PHP you end up with a bunch of absolute monkeys. I would have thought Rails would have been a bit better, but I guess it's not really cool anymore.
I feel like no one has quite cracked the perfect SPA stack yet.
Then, by the time everyone's realised what it'll actually be used for (usually a very small subset of actual apps that need to exist), it's out of fashion. By that point, they're so invested in it that they can't afford to move to something more appropriate, and they can't employ people who're interested in developing with something that's not going to be valuable in the next job they apply for after yours.
I'll be honest...after using Rails, the SPA frameworks I've seen so far all make me feel like I'm making a massive backwards-step to the painful days of Struts. None of them feel particularly modern at all.
I found Angular superficially easy to get into, but the more you do with it the more it seems half baked and needlessly complicated and inconsistent.
React is fine once you've got the framework in place, but that in itself is fairly torturous and it is just a view library not an application framework.
Vue and Ember I have no experience with.
To be honest, I see a situation where SPA frameworks are more or less obsolete in 5-7 years' time, because that functionality will end up baked into the browser and HTML standards.
The standout point that makes React so good is that it brings your HTML into the Javascript world, so you can work with both in one place. As well as making initial development a bit more pleasant, it helps with maintenance by other developers because they don't have to hunt around for the related code. These articles explain that really well:
https://medium.freecodecamp.com/angular-2-versus-react-there-will-be-blood-66595faafd51#.1qdkulg6q
https://medium.com/@housecor/react-s-jsx-the-other-side-of-the-coin-2ace7ab62b98#.5007n49wq
On the subject of learning, if you want to do any web development then learning Javascript is a really good idea. Not Angular, React, Vue, Ember, etc. But pure, unadulterated, Javascript.
* I'm not counting PHP here, because I have serious doubts as to whether the word "design" is remotely familiar to anybody who's ever been involved with its development
There are lots of opportunities to fall foul of the horrible old features that do weird things, but we use ESLint at work set to the AirBnB style guide and it protects you from most of it.
I've done a project in Typescript and also tried out Flow (the Facebook equivalent) and to be honest the additional headache of transpiling doesn't really justify the advantages. Most of the non trivial TS codebases I've seen are full of dozens of "any" declarations to shut the checker up meaning the type system is rendered useless.
Since there seems to be a good few developers on here, can I ask what you'd recommend for a webbased app that mostly deals with data?
I wrote an app for handling event timing many years ago, and it has been gradually modified as needed, however it is far from slick, just using a series of php pages. At events I use WAMP to give me a local webserver with php and MySQL to run things from.
As I'll be using it more often, and I'd like other people to use it, I think it's time for a major overhaul. I have signed up for a Udemy Angular 2 course, but I'd be interested to hear what others would suggest.
I would personally still build anything I had to in Rails (probably v4.2), because it's quick, easy and non-verbose. It's trivial to add API calls to Rails applications, so if the user requirements had a lot of interactivity I'd look at the SPA frameworks to see which one is the least painful for what I needed to do.