4 ms·
Ask yourself if you're building a website or a web application. The main difference in my mind is websites are static documents at the end of the day, allowing
by dcwca 10y ago
Ask yourself if you're building a website or a web application. The main difference in my mind is websites are static documents at the end of the day, allowing users to read text, while web applications are dynamic and often allow the user to modify the data in the system.
If it's really a web application you're after, then get ready for some complexity. The state of the art has progressed significantly in the last couple of years, to the point where modern web applications are as complex as iOS and Android applications in terms of the number of moving parts. To add to the confusion, there seems to be a large number of framework and library choices on the web, where with iOS and Android the vendor largely controls the environment, and the tooling choices are more obvious.
Try to see the big picture as you're looking at all these tools, and recognize that they're largely interchangeable. We can see a common architecture emerging, where the latest versions of all the largest libraries have coalesced around the same basic patterns and ideas:
- Web Components (Angular 1 directives, Angular 2, Vue.js, React, Polymer, Preact, etc)
- State management (ui-router, Redux, MobX)
- Network interface ($.get, $http, restangular, W3C fetch())
- Local storage & persistence (W3C localStorage, ngStorage, react-localstorage)
- Build system (webpack, gulp, grunt, jake, make, npm scripts)
- BDD Testing (Jasmine, mocha, Karma, Chai, Enzyme, Jest)
You really can't go wrong learning any one of these libraries. Even if you aren't using the same library a year from now, you'll understand the application design patterns and JavaScript, two skills which aren't going away any time soon.
Hopefully that helps clarify things, and good luck!
- dom0 10y ago> If it's really a web application you're after, then get ready for some complexity. I beg to differ. In many cases it is perfectly acceptable to build a web application with most of the logic in the server, and comparatively little scripting in the client. Not everything has to be a one-page app / SPA with lots of scripting and the complexities of client-side state. There are also many cases where a SPA is really what is needed and then you indeed need the complexity of a SPA. (And even without being a SPA a frontend has plenty of room for complexity) tl;dr what I'm trying to say here: Know your requirements.
- dcwca 10y ago> Know your requirements. I agree with you and had my own way of saying it off the top of my post. If your application has a simple data workflow such as "ask server for document, show document" and "store document on server, show new document" then by all means do not build a client-side web application. However, fully reloading a document for interactivity is a very crude model, and doesn't allow for complex interactions, state transitions, offline support, the ability to package your app and deliver it to app stores, and so much more. Additionally, I often see teams who build their UI application directly into the server fail to develop a robust API for 3rd party applications such as mobile apps and data integrations.
- spankalee 10y agoOf the list of UI libraries and frameworks you listed, only Polymer creates Web Components. All the others have their own component model. There are Web Components libraries besides Polymer: Skate JS, Reactive Web Components, Bosonic, X-Tags, and probably others. They're all interoperable.