Even though I do some Angular now and then, I still reach for RiotJS (and D3) whenever I want to build a PoC. A lot of front-end stuff is just too complex to iterate upon quickly and with minimal tooling (I keep changing machines, and the overhead of setting up new projects/workspaces every time has always been a pain, even with the umpteen Node-based bootstrapping tools of the post-Yeoman era).
You probably don't need that hip web framework
51–60 of 60 posts
Re: You probably don't need that hip web framework
#52At 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…
Did anybody solve reusing single file components in a page? I tried to reuse two components in a single page and I had to inline the contents to the page I wanted them. Is there a way I could import them?
``` Singe file component 1:
Single file component 2: ```
``` {% include singlefilecomponent1 %} {% include singlefilecomponent2 %} ```
Re: You probably don't need that hip web framework
#53Earlier quoted context omitted.
That's the thing though. Is my team really the exception? When you look at the highly immersive web that product managers and customers have come to expect, you simply can't build it without javascript. Once you've crossed that bridge, is it really easier to finagle some event handling using vanilla js/jquery or pull down create-react-app and get all the tooling necessary to 1-click-deploy to Heroku, S3 or Github pag…
I have no idea. But saying that you feel like you need a project is not a counterargument to the thesis: most teams don’t need it, even if some do. Maybe that’s right, or maybe it’s wrong, but your original comment was not a rebuttal. You questioned why we keep seeing these arguments. Perhaps it’s because nobody on the other side cares to listen?
Why are there even "sides"? it's very obvious that this new tooling can be very useful for the modern Web. it's also apparent that a certain intersection of skill set and project requirements can do better with more classic tooling. why is there a continuous need to pull someone to one side or another? whatever happened to using the most appropriate tool for the job?
Re: You probably don't need that hip web framework
#54In short: Pick the right tool for the job. Some projects need systems like React; some don't. A lot of projects do NOT need complex underlying systems - and some do. It's sad that "pick the right tool for the job" is somehow controversial.
funny, I just replied to another comment almost word-for-word in exactly the same terms, before seeing yours. I agree completely.
Re: You probably don't need that hip web framework
#55SPAs 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…
No.
Overly complex interfaces are part of the problem.
Re: You probably don't need that hip web framework
#56Earlier quoted context omitted.
I have no idea. But saying that you feel like you need a project is not a counterargument to the thesis: most teams don’t need it, even if some do. Maybe that’s right, or maybe it’s wrong, but your original comment was not a rebuttal. You questioned why we keep seeing these arguments. Perhaps it’s because nobody on the other side cares to listen?
Why are there even "sides"? it's very obvious that this new tooling can be very useful for the modern Web. it's also apparent that a certain intersection of skill set and project requirements can do better with more classic tooling. why is there a continuous need to pull someone to one side or another? whatever happened to using the most appropriate tool for the job?
Because there are two or more sides to every debate.
The “most appropriate tool for the job” is exactly what the article is arguing for.
Re: You probably don't need that hip web framework
#57Earlier quoted context omitted.
Makes sense why Apollo is such a clusterfuck then. Have you looked at Nest for Node on the server side? I'm using it for a client project right now and find it the best offering for server side javascript. The ecosystem _is_ still immature though relative to something like Rails or Laravel.
What's wrong with Apollo?
I don't feel that anything is wrong with it; it's just not the whole answer for many projects. You end up bundling tons of middleware for things like logging, metrics, tracing, authn, etc. If you use typescript, you inevitably end up wanting more type safety so you'll reach for resolver codegen, which Apollo does not do on the server (they do do it for the client). And it doesn't assert any opinions about how the rest of the app should be structured, such as business logic, dependency injection, etc.
Apollo Server would be a great component in a broader, opinionated server-side web framework.
Re: You probably don't need that hip web framework
#58SPAs 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…
That sounds exactly like the Rails + Vue setup we are using on our current project. Its basically 90% of a standard admin style interface which we had up and running in lightning speed using the great, but boring activeAdmin. For the couple of pages that are very interaction heavy we serve a per-page Vue app. It really does feel like the perfect combo.
Re: You probably don't need that hip web framework
#59SPAs 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.
Web components
Re: You probably don't need that hip web framework
#60Earlier quoted context omitted.
The hard part in my experience is that a lot of teams don't know if they absolutely need it. I have worked on some projects that are more hype driven development using React/Redux/Sagas for a barely interactive webapp. It adds a ton of complexity for little to no benefit.
Can we stop grouping React, Redux and Sagas when discussing complexity/bloat? They all have totally different complexity profiles. For example React adds tons of software complexity but very little development complexity, whereas Redux is the polar opposite. And Saga is just a clusterfuck. I don't even understand how people can use it with a straight face.
Ok, but only if we can also stop saying React and Vue in the same breath. React is the spearhead of a galaxy of the biggest, heaviest, enterprisiest solutions in it's class, and it has it's place, but Vue is at it's best in lighter applications. You can do quite robust SPA development with Vue, but I'd argue it's even better when it's sprinkled lightly into a project, as a drop-in replacement for the ajaxing and updating we used to use jQuery for.