Show HN: Routerless(163.172.181.149)
163.172.181.149
Show HN: Routerless
http://163.172.181.149:3000
51 comments
Can someone please ELI5 what I'm supposed to be seeing? I just opened this page and saw a bunch of buzzwords. What is this? What is this for? Why is it hosted on an IP address?
Why is it running on port 3000?
op couldnt be bothered to reverse proxy it behind nginx/{other load balancer}.
or just redirect port 80 traffic to 3000 with iptables, it's one command.
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3000
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3000
Thank you for all advices. I'll host it properly. But what do you think about the library?
It took me a while from reading all the comments to realize that it's a client side library that stores state in the URL.
It's nice but I'm still not sure when to use it and why you made it.
Maybe you could add your personal use and motivation to it? Otherwise it's a clever library.
It's nice but I'm still not sure when to use it and why you made it.
Maybe you could add your personal use and motivation to it? Otherwise it's a clever library.
I just disagree with declaring paths with kind of regex pattern matching set of rules. This approach is flexible and natural. It will not stop you when your application became complex and even with simple cases it's faster - you touch less places in your code to make a change.
I think I see what this is for, despite the unilluminating site. Storing state in the URL is a good idea - it lets your users bookmark and share links to your application's state.
I have a couple of questions though:
When I have done this in the past, I have used the url fragment to store the state, i.e.: https://sheep.horse/tagcloud.html#computing . This works even with static sites because the browser doesn't send the fragment (everything past the # symbol) to the server.
By encoding state in the path of the URL, you require server support. I guess the flip side of that is that your site can continue to work without js support.
I notice that your demo and docs don't mention anything about manipulating the browser's history to allow the user to move to previous states using the back button. That can be a pretty useful thing to provide.
I have a couple of questions though:
When I have done this in the past, I have used the url fragment to store the state, i.e.: https://sheep.horse/tagcloud.html#computing . This works even with static sites because the browser doesn't send the fragment (everything past the # symbol) to the server.
By encoding state in the path of the URL, you require server support. I guess the flip side of that is that your site can continue to work without js support.
I notice that your demo and docs don't mention anything about manipulating the browser's history to allow the user to move to previous states using the back button. That can be a pretty useful thing to provide.
Fragments are worse than described here. Fragments are incompatible with redirects. Not only does the browser not send them, but any server-side redirects will either require active-JS redirects to capture and redirect the fragment, or strip the fragment as inappropriate/pointless, or if you're very lucky, maintain it somehow through the redirect. Do not use fragments for any critical function without vetting your entire workflow and all servers and useragents in your request/response path.
What you say is absolutely true, and I agree. But I also subscribe to the URLs-are-user-interface school of thought and think that implementing redirects to change your UI requires careful thought. I'll admit that sometimes it is unavoidable as applications change over time.
Maintaining state in the path, query parameters, or fragment are all techniques that can work, but each comes with disadvantages.
I wonder if anyone has been mad enough to maintain state in subdomains:
https://accnumber18573.color-yellow.example.com/
Maintaining state in the path, query parameters, or fragment are all techniques that can work, but each comes with disadvantages.
I wonder if anyone has been mad enough to maintain state in subdomains:
https://accnumber18573.color-yellow.example.com/
You have a valid point about # and that it works on static site. I'm aware of that and I'll add this as a feature so you'll be able to choose on init().
Please explain me the part about back button on example.
Please explain me the part about back button on example.
Regarding the back button: take your demo page (youurlh/switcher/) as a perfect example, you can click on the "lights off" link and be taken to yoururl/switcher/night/1. I would expect the back button to take you back to the original switcher url and turn the lights back on, but it doesn't.
This is because your write() function uses relaceState() to modify the current url. If you used pushState (like your go() function does) then the browser would correctly maintain history.
Now, maintaining a history of the current state is not always the best thing to do. For instance, on your other demo page, the one where you type your name, you probably don't want to push a history item for each key press.
I think you should consider offering the option to push local history so that an app developer can decide if it makes sense.
This is because your write() function uses relaceState() to modify the current url. If you used pushState (like your go() function does) then the browser would correctly maintain history.
Now, maintaining a history of the current state is not always the best thing to do. For instance, on your other demo page, the one where you type your name, you probably don't want to push a history item for each key press.
I think you should consider offering the option to push local history so that an app developer can decide if it makes sense.
Oh yes. I was considering that. I've stayed for a while with a convention solution - write and toggle replaces, but go adds to the history. You can build on top of that, but I think it's reasonable now.
It manages for you what you want to be in a history. Imagine example with an input which writes on each keyup to the history and going back letter by letter.
So when you click on a "link" it goes to the history. If you play with params on a single view it replaces.
What do you think?
It manages for you what you want to be in a history. Imagine example with an input which writes on each keyup to the history and going back letter by letter.
So when you click on a "link" it goes to the history. If you play with params on a single view it replaces.
What do you think?
Sounds like a good rule of thumb but it really depends on the application.
I think I like the idea, but the docs are a major puzzle. This is a library for mapping URLs to data (or function calls? not sure) without a single URL in the docs. There is also a demo, which shows that it works, but not how it works (no source code displayed except if i want to dig down in the entire site's source code).
@madmaniak, add some examples, please :-)
@madmaniak, add some examples, please :-)
Thank you for kind words and sorry for being so enigmatic.
Step 1: Attach pro-router
Step 2: R.init(root: 'helloworld')
Step 3:
R.write('foo', 'bar')
# url changes from '/' to '/helloworld/foo/bar'
R.param('foo') # => 'bar'
Please ask me any use case you'd like to solve. I'll try to explain more.
Step 1: Attach pro-router
Step 2: R.init(root: 'helloworld')
Step 3:
R.write('foo', 'bar')
# url changes from '/' to '/helloworld/foo/bar'
R.param('foo') # => 'bar'
Please ask me any use case you'd like to solve. I'll try to explain more.
All I see initially is a white screen. Then realized I had to scroll down (and oddly to the right!) in order to see any content. Clicking on "DEMO" leads to the same thing (scroll right for actual content) but with super large text and oddly-placed elements. Still not quite sure what this is about, but it looks like a neat art project?
Obviously I failed with preparing a proper flexbox css. I had one day to make this website. I'll polish things too look well.
If you can ignore the layout you'll find neat art project for frontend routing :)
If you can ignore the layout you'll find neat art project for frontend routing :)
Don't you have a domain? And you can setup cloudflare for free..
Thanks for recommendation. I've linked it to my domain http://router.maniak.pro:3000 right now. I'll change the port to standard http soon.
You should try and make the page a bit smaller. This is what I see on my Macbook Air: http://imgur.com/a/Mi3lb
I tried scrolling to the left thinking there was more content, but that was it. It looked better on Chrome when I set the size to be 80%.
I tried scrolling to the left thinking there was more content, but that was it. It looked better on Chrome when I set the size to be 80%.
Thank you, I'll improve it
Treat url as a store. Serialize to url and deserialize to objects.
I can't think of too many instances in which I would use this personally, but seems very useful for things like saving web game state.
Game is a complex thing and it would handle it perfectly. Believe me it handles really well also simple cases. For me it's not a first iteration on the idea of routing automation. It gives you freedom and is really handy. Even if you never thought defining routes is a problem. I hope you'll give it a try.
Why is pattern matching "stubborn"? Seems like the perfect application of a pattern matcher.
How is this different than building a single page app with say, react router + redux?
You can use anything with this router (redux too). I agree react router is a nice tool - but in a classic paradigm. The difference is - you don't define routes. If you create a component and it needs a data you just ask the url store for it. Or if you need to persist some data you just write to the store. It creates nice urls - always a name and a value. Additionally you have setters which will handle a serialization of your object to nice string. And of course getters which will wrap your data into a custom object - so it's not a string.
Probably want to remove "goddamn"
lol, what?
as you see it's a small tool you can use with any framework
Tiny lib with a website that pulls 1.1 MB of JS.
Will fix. I was in a rush.
Why are you showing something that's rushed? If this is a personal project what's the deadline? Why not wait until you have a finished product (eg hosted on a proper port 80 web URL with a domain name)
My gut tells me it's a great idea, but indeed as others say, take the time!
Thank you for your advices. What can I say - I am and I will be in a rush for a while. I have also bigger personal projects. I'm glad I was able to ship it now. I have good feedback and I'll make it better thanks to your comments. I'm glad you took a while to see it despite all defects of the project site. If you like it please subscribe or connect me on twitter - I doubt I'll reach your attention again. Promoting personal projects is incredibly hard.
>Just 67 lines of code and less than 900 bytes while minified and gzipped.
If this is 67 lines of code with zero dependencies, why do I need it as a dependency?
Regarding CDN implementation, why would anyone add an HTTP request to the page for 900 bytes?
If this is 67 lines of code with zero dependencies, why do I need it as a dependency?
Regarding CDN implementation, why would anyone add an HTTP request to the page for 900 bytes?
1. Please explain me what you'd like to know. Router is one layer of SPA / PWA so you need it if you want to make one. It's framework independent and I'd not like too add more dependencies to your project for such a small thing - even if it's powerful.
2. If you want to check it out quickly with minimal effort, play in your browser js console - it's there.
2. If you want to check it out quickly with minimal effort, play in your browser js console - it's there.