Hacker News new | past | comments | ask | show | jobs | submit login

I can see the value in micro frameworks for the back-end as there can be tight constraints e.g. latency/throughput or startup time (serverless).

On the front-end though, I don't see why I would need to know more than one. You can pick up Vue in a day to make a simple ToDo or other app with REST calls with or without central state. You can then add to that knowledge for other uses and share knowlege other devs and google for what you don't know.

With bare-bones type frameworks, you're pretty much on your own just rebuilding patterns in JS. This is the most common reason for why Lisp isn't more popular. It's because they use Lisp and build a custom DSL/framework for the app then build the app with it. This means that two app developers who might have built almost the same product at different companies can't share what they've learned.

The only time this might make sense is if it's almost all static HTML and you want some jQuery to update a small part of it. Even then it's hard to know that it won't grow into an SPA eventually.




Agreed for Vuejs. I'm trying more and more to push back on developping de-facto SPAs because they _seem_ just easier to build now with React or whatever cool framework, but actually bring so much complexities. Unless there is a real reason for a complex SPA, I try to stick to normal MVC patterns, where each page is independently rendered from the server. In which case, Vue is to me the best framework to be able to t generate those type of "micro apps" for each page.


Curious why, React can do that just fine. It doesn't force you to build a SPA. What's different with Vue?


They do the same things

Try to enjoy yourself




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: