5 ms·
I love Elixir. Phoenix makes web development a pleasure and LiveView is even more exciting. I would love to find a job doing it.
by mostlysimilar 6y ago
I love Elixir. Phoenix makes web development a pleasure and LiveView is even more exciting.
I would love to find a job doing it.
- ketzo 6y agoDude, LiveView is wild. It feels kind of magical, and I think people are gonna start adopting slowly, then all at once. There's an awesome blog post on their website. where Chris McCord, creator of Phoenix, builds a real-time Twitter clone in 15 minutes. https://www.phoenixframework.org/blog/build-a-real-time-twitter-clone-in-15-minutes-with-live-view-and-phoenix-1-5 https://www.phoenixframework.org/blog/build-a-real-time-twit...
- bcrosby95 6y agoGod I hope so. I loved Erlang and OTP when I tried it back in the late 00s and it never really caught on, despite many of its strong points being what most websites would look for. Hopefully with the focus on the web and the fresh coat of paint Elixir has given the ecosystem it will eventually gain more adoption. But I still have my doubts because despite looking more mainstream than Erlang, it's still kind of a "funny language".
- ketzo 6y agoYeah, it does have that stigma. It certainly did for me; "Why the hell are there colons before these variables..?" It's funny how much the first languages you learn (for lots of people, Java/C/JS) have such an impact on what "feels weird," when every programming language is basically magic anyway.
- dnautics 6y agoWell, Ruby and Julia and scheme, I think?) all have those same colons too, so it's not totally crazy. It's the post- colon that's strange (but Ruby has those too)
- pmontra 6y agoIn a JSON world post colons are normal :-) and we've been living there for ages. Ruby added x: y as a short form for :x => y
- heipei 6y agoI've been watching Elixir/Phoenix/LiveView from the sidelines, reading just enough to salivate a little but still left with the feeling that my use-cases wouldn't be adequately covered by it. Which kind of SPAs wouldn't work well in LiveView? I'm working on an app in Ember right now where a lot of data is fetched by the client asynchronously and then either showed once its fetched or only when the user pushes a button. How would the latter be possible with LiveView? Can you push data to the client that's only show on client-side interaction? Do I still need a client->server->client roundtrip to toggle a "visible" flag to show said data? I just don't understand how "smart" the client side of LiveView is.
- dnautics 6y agoThe spas that won't work are the ones that need to keep state while offline. Everything else works pretty fantastic, and arguably better than most spas which need to do heavyweight xhr Json or grpc calls, though if you can have a persistent grpc connection over websocket you might be competitive performance-wise.
- ketzo 6y agoI'm honestly not sure. I would ask on the Phoenix [1] forums -- they're pretty active, including a lot of responses from Phoenix's creator, Chris Mccord. [1] https://elixirforum.com/c/phoenix-forum https://elixirforum.com/c/phoenix-forum
- pythonaut_16 6y agoThe biggest "homerun" case for LiveView is all of the forms where you'd typically do server side rendering then add a bit of JavaScript for the few dynamic pieces you need. Think about what you might typically see in a Ruby on Rails app. Lots of Ruby generating the views, a bit of JavaScript for client-side whatever. LiveView can be used for way more than that, but I think replacing "glue" JavaScript is the most slam-dunk case.
- moreaccountspls 6y agoI'd love to hear your opinion on this https://news.ycombinator.com/item?id=23252862 https://news.ycombinator.com/item?id=23252862 if you have any experience.
- enraged_camel 6y agoControversial opinion: the "magic" is why I'm staying away. It's the same reason I stopped coding in Ruby/Rails: too much magic. But I'm also a full-stack developer and I'm not afraid to write JavaScript. I realize not everyone is on the same boat, and LiveView might cater to them.
- elixirdev 6y agoLiveView is a nightmare from a deployment point of view. LiveView stores state on the server associated with the web socket connection. If the web socket connection disappears which is what will happen during a deployment then the user's state will disappear. The value of LiveView is not having to write javascript but the only way to preserve any non-complicated state in LiveView when the web socket disappears is to write javascript. It is only recently that LiveView added support to automatically preserve form input values across a state crash. [https://github.com/phoenixframework/phoenix_live_view/blob/master/CHANGELOG.md https://github.com/phoenixframework/phoenix_live_view/blob/m... | Recovery form input data automatically on disconnects or crash recovery] Prior, to 0.7.0 if the web socket died while you were typing input values in a form then the page would reload and all your input into the form would be wiped out.
- josevalim 6y agoYou are right that state is transient but JavaScript is not the only option. For transitions and screens, you can use live navigation. For forms there is automatic recovery (as you mentioned). Another option is to persist the state on the server. For example, go back to the Twitter timeline example. Imagine that you want to do a banner that says "N tweets unread - click here to expand them". You could keep this counter in the LiveView but if you reconnect the counter will be lost. But you can also solve this by storing a pointer to the last shown tweet on the DB. Then if you reconnect, you can compute how many tweets are pending. If you are doing a multi-step wizard you can persist each step on the DB too, etc. Depending on the use case, this could even yield further benefits, such as automatic synchronization between devices. I.e. if you read some tweets on your phone, you can automatically bump the "last shown index" on all devices. Or start the wizard in one place and finish it elsewhere. That's the point of LiveView, you can build interactive applications that are more server-centric. Some of those features are new but that should be no surprise, it is still pre-1.0 software. Even as we add new features, you may still have to (or want to) rely on JS on many scenarios, and that's totally fine.
- kuzee 6y agoKamanahealth.com is hiring, remote-first, and doing a lot to help combat covid. I don't work there, just got got an email from a friend noting that they are looking for Elixir devs. https://www.notion.so/Kamana-is-Hiring-644e0dd0eb2d433daf7a7ff8f0dc4e93 https://www.notion.so/Kamana-is-Hiring-644e0dd0eb2d433daf7a7...
- lawik 6y agoLiveView will take some time to really get general acceptance and will probably always be somewhat controversial. Both for server roundtrips and because it is so oddly specific and doesn't have a comparable solution in most other languages. But it is fantastic where it fits, truly.
- moreaccountspls 6y agohttps://news.ycombinator.com/item?id=20383814 https://news.ycombinator.com/item?id=20383814 exists, so I'd expect it to catch on in other languages if it really is a killer app. I don't know how well such a thing would work without OTP though.
- dnautics 6y agoYeah if you have a minor miscode/footgun in blazor you're really not gonna have a good time. If you have a minor miscode in liveview, OTP's got your back.
- QuinnWilton 6y agoMy team at Synopsys is hiring. We were recently acquired by them, and we build dynamic security analysis tools in Elixir, and make heavy use of Phoenix and GraphQL through Absinthe. We're also open to remote work, and have offices in most large cities. The job posting is a little bit generic, but it's specifically for my team: https://sjobs.brassring.com/TGnewUI/Search/Home/Home?partnerid=25235&siteid=5359#jobDetails=1511023_5359 https://sjobs.brassring.com/TGnewUI/Search/Home/Home?partner... Feel free to reach out to me (my website is in my profile) if you want more info!