I disagree. When designed correctly, large projects are simple to work on individual features and only complex when observed in aggregate as as complete system.
> Chasing a magic bullet can temporarily make it look like you're avoiding the problems of large projects, because when you're constantly switching frameworks you never actually reach the point of having built something large enough.
I never alluded to scrapping or restarting projects to get on the latest framework so not sure where this comment came from. I've build large systems with "jQuery", large systems with React and Flux. The latter was simpler to work on, more fun, and suited the needs of the client.
React won. And that's a good thing. Anyone reading this has one less decision to make. If you're building a JS frontend you want to be using React. You'll also want Redux to structure your application around React.
Doesn't really scale to larger projects. Managing application and UI state becomes too cumbersome.
With that said the new things are still very rough, I agree, but they will make our lives easier after it all settles down. It's already beginning to settle down with React becoming semi-standard.
No, not like condoms. If STDs became blockable with common sense and condoms started shipping with perforations and prickles on the inside then yes, but that's not the case is it.
Just another reminder that antivirus is dead. Any antivirus can be trivially circumvented. Based on the level of incompetence of multiple antivirus developers over the past few years, and my own experience with antivirus slowing down and heating up my machine, antiviruses themselves are more trojans than anything.
"Javascript should be used for form validation, interactive elements like OpenStreetMaps, but nothing else"
Not if you want to get hired. We've moved on from that simple model. I don't like it either but ignoring the fact that things are changing is a good way to end up unemployed.
"What I'm getting at is, I don't know why you need to update anything"
Shocking advice. There is a huge amount to learn. Any developer coming from the 1990s needs to re-learn all their technologies or they are going to have a very stressful time delivering anything appealing to users expectations in 2016.
"Since the stuff you already know still works, there's not much need to use anything else"
This kind of mentality leads to becoming deadwood and unemployment. Developers must keep learning especially with the rate of change of technology over the past 5 or so years.
Wow, there is a lot of awful advice in this thread.
HTML, Javascript and CSS are still extremely important and they have come a long way since 1990. Forget everything you knew about them and research their state in 2016. You have a lot to learn, but you'll find all three more powerful and expressive today than they were in 1990.
There is currently a big shift in the way clients want their websites to work. In the past (and present) clients were happy with simple HTML pages that were generated on the server and sent down to the client for every action the user performs. Now and in the future, we're shifting towards "Single page apps" which are Javascript centric applications that store page templates client-side and talk to the back end through APIs. Page transitions are emulated with Javascript routing libraries. This means the frontends are more complex but can provide a richer, more interactive experience. To see the cutting edge of this technique search for React + Redux.
Backend development is still important. People generally converge under a simple set of rules for backend development called Model-View-Controller. This is a design pattern that dictates how requests are delegated into your business layer. Investigate MVC as well as Domain Driven Design to get yourself up to speed.
Understand that there is an enormous amount of garbage out there right now. Some things to be extremely wary of are NoSQL databases (they have very limited use cases but are marketed as a silver bullet) and NodeJs (a backend server which executes Javascript but has more than a few shortcomings). Be extremely skeptical of any advice you receive over the internet. There are too many people dispensing advice with no actual credibility because of the ease of access to the Internet.
The best thing to do is to work with some talented developers and build your own network from them. A lot of developers on the leading edge use Twitter and often drop useful bits of advice to keep you on the right track.
In my experience any developer worth hiring can do complex frontend work (even by 2015/2016 standards) and backend work. I've never seen a "frontend only" or "backend only" developer.
> SignMeTheHELLUp is complaining about Waterline ORM, but I'd argue that Hibernate is worse
Are you serious. Hibernate and all it's language-specific variants are actual feature-complete ORMs. Waterline falls flat as soon as you get past eager-fetching a child property. It's a toy.
I wasn't just complaining about Waterline either. Every time I had issues with Sails I had to dip into the Sails source and patch bugs out, eventually I replaced parts of Sails with libraries that actually worked. By the end of the project the only "Sails" left was the routing component...
Edit: Of the two sites you linked to, one is a splash page and the other is an aggregator that loads slowly. Neither are real-world LOB applications with complex logic underneath them.
I can write solid code on Node the same way I can on any PHP framework, but I'm experienced enough to know to look elsewhere when my requirements are complex.
I found SailsJs unfit for any projects that had even a moderately sized set of business rules. Partly due to Node's lack of threading and partly because SailsJs feature set was a weak or incomplete copy of 'real' frameworks which failed to meet needs once they had to offer anything more than an extremely light CRUD wrapper.
I agree with fideloper that it's better not to use NodeJs or any of that mess of an ecosystem for projects more complex than 'plumbing code'.
Saw this comment and it reminded me how Waterline ORM became a running joke at my office. Save yourself a headache and avoid these JS backend frameworks:
> I can chime in on Waterline since everyone keeps mentioning deep populate! The PR for the polyfill is pretty much ready to go, it's a recursive query runner that will run queries until the results are completed. This will increase the query count in sql adapters until the adapters understand how to interpret and build these join queries (nosql adapters don't have joins so those will work).
Who needs N+1 select issues when we can have recursive queries baked right into the ORM! smh
Thanks. Based on that information any privacy-conscious users should simply not use Steam or the Steam website until the bug is fixed. By not using Steam, their pages won't end up in cache and will not be leaked to others.
That kind of authentication and authorization can be found in any respectable CMS. Choosing Joomla because Wordpress isn't any better is like choosing to drink your own urine for breakfast because stools taste worse.