> your first version of your idea almost always doesn't need that hipster web framework you're thinking about using.
No, but I bet your last version will have. Right before it fades into obsolescence, never to be seen again.
You probably don't need that hip web framework
11–20 of 60 posts
Re: You probably don't need that hip web framework
#12He mentioned that it took a long time to get going with some of the frameworks to get an MVP but the advantage of most of those is that while they take time more to learn you'll be more productive with them in the long run and there will be less spaghetti code.
Re: You probably don't need that hip web framework
#13[deleted]
Re: You probably don't need that hip web framework
#14Why 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 writi…
The audience for this post is at the opposite end of the market from you: two buddies building an MVP in a garage on a shoestring budget.
Re: You probably don't need that hip web framework
#15Why 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 writi…
I'm with you. Whenever I see posts like this, I can't help but think, "More job security for me."
Re: You probably don't need that hip web framework
#16Why 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 writi…
Because your team is the exception. Isn’t that implied by the title?
Re: You probably don't need that hip web framework
#17At the end of the post he mentions what I think is a really under-rated approach: a “normal” server rendered application with Vue components used per-page when the UI is highly dynamic.
I’ve built a relatively large app this way and found it to be quite nice. Vue works very nicely inside the container elements in the page where I need it, and it’s pretty easy to bootstrap the initial state into the page using the same serializers I do for JSON endpoints, so once it’s rendered users can spent a lot of time on a particular screen without any further page loads.
The last bit that’s nice is bundle size. It’s not too hard to split bundles based on unique entry pages, so you can end up with something like 30kb of “global” JS and then a second bundle for the big meaty pages that may range from 20 - 200kb. With caching that means 90% of screens have a very small payload and load really fast, and the rest have a slightly slower first load and then the same perf profile.
This has been a highly productive way to work, I’m surprised that it’s not written about more often.
Re: You probably don't need that hip web framework
#18Why 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 writi…
> My team absolutely needs React/Redux/Sagas/Webpack/whatever-you-want-to-hate-on-today
Then you're in the 1% of people that use these tools and actually need them. The point of articles like this isn't that they never make sense and nobody needs them, it's that they're way over used where they aren't needed.
Re: You probably don't need that hip web framework
#19Why 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 writi…
My theory is its like this mostly because on HN because there's no downvote for posts. Everything useful that can be said about how bloated web frameworks supposedly are has pretty much been said imo, but there's a niche of people convinced every web app is actually simple and should be done using Netscape 4 era HTML.
I'm all for simplicity... but if you are developing a large web application, you probably would benefit from "heavy" web frameworks (they're not really that bad though.) What "large" is can be debated, but I'd argue most pages we use today are "large" enough. HN is a good exception. GitHub, large publications, webmail, online shops, anything dealing with realtime data... It's probably worth it.
Re: You probably don't need that hip web framework
#20At the end of the post he mentions what I think is a really under-rated approach: a “normal” server rendered application with Vue components used per-page when the UI is highly dynamic. I’ve built a relatively large app this way and found it to be quite nice. Vue works very nicely inside the container elements in the page where I need it, and it’s pretty easy to bootstrap the initial state into the page using the sam…
Seconded. This is a great way to go.
Quite often there isn't a reason to have SPA routing. But that doesn't mean you can't enjoy lots of benefits of the fronted framework without the unneeded complexity solving something you don't really need in the first place.