marko
marko copied to clipboard
marko-js
Client side URL Routing
Open Questions
I understand marko can be used with a number of server side frameworks like express that handle URL dispatching but does it include any client side router or are any plans to support this?
Thanks
We'll be putting some proposals on the table soon, but if anyone wants to share ideas or their favorite router, please feel free.
I like the JSX-syntax support in React Router. Also need solid support of server-side rendering. The Inferno port of React Router is probably worth looking at: https://github.com/infernojs/inferno/tree/master/packages/inferno-router
Any update on this?
Besides the router I think a router-link core component would be needed, similar to this: https://router.vuejs.org/en/api/router-link.html
Will https://www.npmjs.com/package/marko-path-router become the default router, or is one being built internally? My biggest requirement is lazy loading/code spitting modules within the routes. So the initial app size is minimal.
I was rather surprised marko didn't have anything out of the box for client-side routing.
I've been using Vue for a little over a year and love that it has officially supported plugins for critical SPA/PWA functionality like routing (vue-router), state management (vuex), and browser devtools (vue-devtools). Once you start bolting on a few of these it can increse the JS bundle size quite a bit but it's sooo convinient.
Marko is super apealing to me mostly because of the performance, small file size, and super sweet server rendering features. Because of this I feel the marko team is really doing a lot of things right and I've started to use it on performance critical projects.
However, the lack of client side routing means the page needs to be refreshed on each route change. This prevents a nice SPA experience and sucks since JS needs to be loaded and parsed constantly. It's the main thing holding my company back from using marko in more projects (we do a lot of microsites and new PWA featured projects). 3rd party solutions are out there but I need the confidence of an official solution.
I'd love to see an official router for marko. You guys has done such an amazing job with marko so it would be so great to see an equally performant and small filesize router solution.
I've been using Vue for a little over a year and love that it has officially supported plugins for critical SPA/PWA functionality
Couldn't agree more. IMO Vue router and Vuex blow react-router and Redux out of the water when considering the tight integration with Vue.
The lack of these official packages is also what's holding us from considering Marko more seriously.
The lack of these official packages is also what's holding us from considering Marko more seriously.
Same here. We're considering frameworks for UI development, and Marko looks like a very good candidate. However, client-side routing is a must for our needs and without an officially supported router, we're reluctant to invest the time and effort into learning and developing for Marko.
The lack of these official packages is also what's holding us from considering Marko more seriously.
I'll pile on as well (sorry). Without an official pattern for routing I don't understand how others are adopting this library in production (Ya'll just have 1 route?!?). I am on day 3 for a POC to determine if our company should adopt Marko and I'm slowly coming to the conclusion we can't use it yet which is quite unfortunate... React will likely be our library of choice.
If I can go a little further, and perhaps I'm misunderstanding the use case for Marko so forgive me, but how are others handling server-side redirects, 404's, etc? All the examples load a single template for the / route which is a great example and all but what about loading more routes? What about authenticated routes? I know these are all solvable with custom code/implementation but as Marko is an opinionated library it feels like there should be examples/patterns offered for these common scenarios.
Reviewed resources:
- https://markojs.com/docs/color-picker/#routing
- https://github.com/matteozambon89/marko-router
- https://github.com/charlieduong94/marko-path-router
- https://github.com/charlieduong94/marko-path-router-demo
- Issue #700
- ~https://github.com/kjbekkelund/redux-simple-router~ (abandoned? Last commit: 2yrs)
I can't speak to anything official, but to answer the question of "how are we using it without a router or data library", the short answer is we built our own. Not ideal, but on the flip side we could write exactly what we needed, and nothing more. Which we found to be a benefit as we are super sensitive to bundle file size. Not using a package that is trying to be all things to all people was actually better for us. I know that doesn't address the topic but just providing an answer on how others (we) use Marko without these things being available.
I do agree that having an official one would be helpful, even if it only served as a guide to how we could hook the router deeper into Marko, rather than as a layer on top.
A 1kb router for markojs:
https://github.com/scriptmaster/simple-marko-router/
#Features
Provides two new tags, <router ... /> and
Supports named routes. Supports pushstates. Route Components changed event.
Guys, try this new package: https://jesse1983.github.io/marko-router5.
Supports:
- Named routes
- Wildcard paths
- Nested routes
- History browser states
- Link component
- Change event emitter
- Async routes
Feel free to download and open a issue if necessary.
I like the idea by @jesse1983 , its worth a look at. We would love some thing like react-router.
Marko 6 with FLUURT and client side routing can be a game changer. Client side routing is necessary for building SPA, desktop and hybrid mobile apps. I hope Marko team will consider adding support for client side routing.
In the same way, React router wasn't built by React. Nothing stops anyone from picking up a common JS router and making Marko components out of it. Things like https://router5.js.org/ or https://visionmedia.github.io/page.js/ come to mind. In fact there is a Router5 port above in the comments.
To address the question throughout this thread though "How do you use Marko without client-side routing?" Not every app is a SPA. Many eCommerce, blog, news, and content sites don't benefit from it. Not being SPA lets Marko ship considerably less JS to browser when content is more static. This can drastically improve performance on low power devices and slower networks. Especially in situations where initial page load performance is important (eCommerce). While I'm not 100% in alignment on the ideal setups, this article basically lays out the type of thinking https://jasonformat.com/application-holotypes/.
Marko can do SPAs, it just happens to uniquely be a really good solution for other types of sites that SPA Frameworks aren't good at. By no means should that discourage other usage but we definitely play to our strengths.
Marko is great for MPA there is no doubt about it, but why restrict it to just MPA? I understand MPA is a priority for eBay but out of box official support for other use cases will bring more users/contributors. Marko is so good but it hasn't become a main stream framework. Bigger community/echo system will ultimately benefit eBay and everyone.
We can use any JS router but it would be nicer If it is integrated with Marko cleaner and no one else knows Marko's internals better than the core team.
Marko has a great team and I specially havee a great respect for @ryansolid for the work he is doing. Both Solidjs and Marko/FLUURT are next generation tech and no other framework is even close in innovation. I thank you sir.
I understand the core team is very busy working on FLUURT and it's not the right time for asking for an official client side router but I request you on behalf of Marko community to consider adding support for client side routing on your longer term roadmap.
A MarkoKit like sveltekit built on vitejs can kill both Sveltejs and Vuejs. Sveltekit is using adapters for building applications for different use cases like SSR, SPA, cloudflare workers. I request Marko team to please consider this adapter based approach.