You probably don't need that hip web framework
1–10 of 60 posts
Re: You probably don't need that hip web framework
#2SPAs become necessary when the user experience requires bells and whistles, like cross-widget consistency of like/friend request counts (the original use case of React IIRC).
It's not "you ain't gonna need it," it's "you are gonna need it, users will judge you by your fluidity, sure it's overkill right now, but the overhead may be less than the pain of a frontend rewrite since you may need it soon."
I've often thought that if there was a way to gradually codegen a fluent React codebase from Django/Rails/Laravel server-focused frameworks, and move template-by-template into a rich frontend + API, a lot more people would start with those server-focused frameworks, because there wouldn't be a need for a full rewrite. It would be a holy grail for our industry and let us develop business apps way faster. Not an easy problem to solve. Email me if anyone reading this wants to chat though!
Re: You probably don't need that hip web framework
#3You probably need the right tool for the job. I'd argue that react, Vue, and company are only best for true web _applications_, that is highly stateful projects that are more akin to standard desktop apps than web pages, ex: google docs.
If you need server side rendering that could be a sign that what you have is a lot of public indexable information and that most often describes a traditional web site instead. In that case your "old school" rails or laravel solutions are almost definitely a better choice.
Re: You probably don't need that hip web framework
#4Let's be real: the author is talking about React (or similar), and calling it a "hipster web framework". I mean, come on.
Sure you don't need it, you don't need any library/framework.
Re: You probably don't need that hip web framework
#5People keep saying it, and it never really ceases to be true, but the cargo cult prevails, and the rituals continue. Maybe someday the mysterious sky whales will appear again, if we keep waving our magic wands as we know the foreigners did, to summon and command them.
Seriously though, it's pretty tiresome to see another moronic framework rear its head. The real reason the treadmill exists is to break the will of the seasoned developers that would puff their ego, and demand to be paid handsomely.
You're nothing, old man. We have interns that work all summer for nothing and they get more done in a month, than you will in a year.
Re: You probably don't need that hip web framework
#6The promise of front end frameworks is realized by startups when using a BaaS (backend as a service) - like Firebase.
The idea is that you only have to worry about one environment (the browser - yeah, I get the irony) and one deployment instead of multiple (the former plus backend deployment, monitoring, etc.).
The second you start worrying about SSR (server side rendering) you’re suddenly taking on the complexity of writing a backend again.
Re: You probably don't need that hip web framework
#7SPAs become necessary when the user experience requires bells and whistles, like cross-widget consistency of like/friend request counts (the original use case of React IIRC). It's not "you ain't gonna need it," it's "you are gonna need it, users will judge you by your fluidity, sure it's overkill right now, but the overhead may be less than the pain of a frontend rewrite since you may need it soon." I've often though…
The underlying concept of React is so intuitive that I would hope that browsers provide a native implementation. Use a `` tag or something so you still have the old fashioned API.
Re: You probably don't need that hip web framework
#8The promise of front end frameworks is realized by startups when using a BaaS (backend as a service) - like Firebase. The idea is that you only have to worry about one environment (the browser - yeah, I get the irony) and one deployment instead of multiple (the former plus backend deployment, monitoring, etc.). The second you start worrying about SSR (server side rendering) you’re suddenly taking on the complexity of…
My understanding of node's birth and rapid rise was that it was "backend tooling for frontend-devs" - suddenly it gave the front-end teams the power they needed to launch quickly using what they knew.
I've been looking for quite some time for "front-end tooling for back-end devs" without success - there are some great frameworks like Postgrest or Hasura which take you from Database through to API interface, but then you're faced with raw Javascript and all that pain synchronising browser state with the API via a web-worker. My attempts to use Vue & React have just resulted in the exchange of one kind of complexity (raw Javascript state change) with another (learning the framework).
I'm all ears, if anyone has used anything (framework, IDE, WYSIWYG editor, some SAAS app, anything) that simplifies the journey from OpenAPI spec to a webpage with a UI that changes as the API returns things.
Re: You probably don't need that hip web framework
#9Why do we keep seeing posts like this? My team absolutely needs React/Redux/Sagas/Webpack/whatever-you-want-to-hate-on-today, to ship and yeah we ship our backend with Docker. Why do I know we need it? Because we have years of experience in our workflow and we understand the problems we need to solve in the development workflow and timeline our company uses. Do you know who doesn't understand our needs? Someone writing a low-quality post about how _their_ specific needs can be met with existing technology. Please just leave me be and go focus on solving your own problems, I wouldn't be using this technology if I didn't think it worked better than anything else.
/rant.
Re: You probably don't need that hip web framework
#10To be honest, I’m still fine with jQuery and Laravel. I’ve looked at React and Vue and while they are marvels, I ain’t got that kind of time.
But, I also don’t write mobile apps. I’m dealing with desktop and the rules are different there.