[HN Gopher] Hotwire: HTML over the Wire
___________________________________________________________________
Hotwire: HTML over the Wire
Author : samename
Score : 651 points
Date : 2020-12-22 16:29 UTC (6 hours ago)
(HTM) web link (hotwire.dev)
(TXT) w3m dump (hotwire.dev)
| cs510 wrote:
| I'm a big fan of pure HTML pages because of performance and
| simplicity, but the techniques presented here are neither of
| those.
|
| For performance, server-side rendering is just bad. It won't
| scale to high volume traffic, cost too much money and is
| complicated to maintain. Hosting a static HTML files is more
| performant than that.
|
| For simplicity, the current protocol relies on so much "magics"
| to give the impression of simplicity. I think that's just an
| illusion of simplicity.
| arvindamirtaa wrote:
| If you can get away with hosting static html files, there's not
| much else that's more performant.
|
| The comparison is only between server rendered HTML vs backend
| API + some frontend rendering locally (which is not as
| performant) and more importantly is a lot more complex to
| implement technically.
| heidar wrote:
| For those unaware, this is the "new magic" that dhh has been on
| about since HEY was in beta.
| grumple wrote:
| This is a continuation of existing Rails ideas: "This is a
| conceptual continuation of what in the Rails world was first
| called RJS and then called SJR, but realized without any need for
| JavaScript. The benefits remain the same" [1]. So if this doesn't
| wow you, that's why; Rails already largely can do this, but you
| have to write some javascript yourself. This does seem simpler
| for the toy example. I'm curious as to how it works with nested
| templates, there are no examples for it that I noticed.
|
| 1. https://turbo.hotwire.dev/handbook/introduction
| ashton314 wrote:
| Can someone familiar with this please diff it with Phoenix
| LiveView?
|
| https://github.com/phoenixframework/phoenix_live_view
| fuball63 wrote:
| I read a little about Turbo, not sure I get it, is this like
| htmx? https://htmx.org/
| zomgwat wrote:
| They're similar in concept but Turbo uses WebSockets and htmx
| is more about AJAX.
| simonw wrote:
| Turbo uses Ajax for most of its functionality too. The
| WebSockets bit is an optional add-on if you want to push
| updates from the server e.g. for notifications.
| w_t_payne wrote:
| I've been using HTMX to send "server push" updates over SSE
| ... I think it wouldn't be too hard to use websockets as
| well..
| deltron3030 wrote:
| My first thought was that some dude is ripping off LiveWire and
| Turbolinks because of the strange centered text (no professional
| web designer would do that), until I saw that those were renamed
| evolutions of those technologies from Basecamp, cool!.
| corytheboyd wrote:
| I get the feeling it will draw a bit of criticism from this
| crowd. IMO it's fine to experiment with tech like this, but I
| have to wonder where sending HTML fragments over Websockets
| instead of HTTP falls apart.
|
| Curious to hear about the success/horror stories in a few
| months/years from any adopters :)
| tester756 wrote:
| It's proved technology
|
| .NET's Blazor (server based) uses this.
| city41 wrote:
| I found this little thread on Twitter interesting, complaining
| Hey (powered by hotwire) is too slow
|
| https://twitter.com/youyuxi/status/1337851036015480843
| konha wrote:
| The inventor of one of the most successful js frameworks
| might be a tad biased when it comes to the whole ,,as little
| JavaScript as possible" thing.
| rk06 wrote:
| he is complaining on Hey's lack of speed and interactivity,
| not complaining about the lack of js.
|
| which is a fair complaint, I would say.
| konha wrote:
| It is. But he also wrote this in a subsequent tweet:
|
| > For a typically long running app like an email client,
| the obsession with shipping as little JavaScript as
| possible is actually detrimental to the end UX.
| petey283 wrote:
| And here's some additional followup. Minor speculation that
| maybe his location is what caused slowdown.
|
| https://twitter.com/swyx/status/1292825527116369922
| methyl wrote:
| That's one of the reasons SPA aren't going anywhere: trying
| to handle all the user microinteractions on the server is
| great when you leave next to it, but it falls apart when
| your users are spread across the world, especially if it's
| not western-ish world with fast internet connections.
| vasachi wrote:
| Huh? How does SPA help here? JSON payloads don't go
| faster over the wire than html.
| mromanuk wrote:
| An app with longer usage leans towards SPA. Quick or
| sporadical stuff, shouldn't be a SPA. The problem is
| always doing, SPA all the things or Do everything in the
| backend like if it's 2005
| deergomoo wrote:
| Surely a JSON payload is almost always going to be
| considerably smaller than the contents of that payload
| laid out in an entire HTML document?
| jeroenhd wrote:
| JS interacting locally can make a web page be perceived
| to be faster, even if there's no meaningful content yet.
| Humans enjoy working with systems that so _something_ as
| soon as they interact with them and a
| placeholder/spinner/animation is that exact something. Of
| course, you don't want any placeholders or animations to
| go on for too long, but it's good to know that the button
| you just pressed actually did something and the screen
| hasn't hung.
|
| Minimal JS pages often have very little direct
| interaction built in, so they feel blazing fast when the
| connection is good and the payload is small (HN is a
| great example) but terribly slow if your internet
| connection is bad and it's not masking the network delays
| (again, HN is a great example).
|
| The 2-5s mentioned on Twitter are something else though,
| perhaps the Hey app is being transferred through a
| saturated connection in the US or something.
| vasachi wrote:
| Well, a spinner can be added even into non-SPA
| applications. So I don't see how that is an argument for
| SPA.
|
| I presume you can _lie_ to user by pretending that their
| change was instantly submitted, while syncing in
| background. In that case, yes, SPA all the way.
| dsego wrote:
| Skeleton screens and spinners don't feel faster.
| dashesyan wrote:
| Because the DOM can be updated client-side before the
| server responds
| bryanrasmussen wrote:
| In this non-westernish world the internet is slow but how
| much processing power do the computers have to render the
| SPAs?
| save_ferris wrote:
| I got into the Hey beta, wound up purchasing it and I haven't
| had any performance issues to speak of. I'm curious to know
| what their setup is.
| corytheboyd wrote:
| It never performed slowly for me. It ended up having none
| of the features I wanted, but that's a different concern
| altogether. Definitely rode the hype train and feel dumb
| about it now haha
| eecks wrote:
| I've used Hey daily since it launched on desktop and mobile
| and I can't see it being slow in any way. I guess you could
| count that it shows a loading symbol for a file to appear
| (on the first load only).. but that would be excessive
| nitpicking.
| jlokier wrote:
| It falls apart in environments where WebSockets doesn't work,
| unless there's a fallback mechanism using XHR.
| jtms wrote:
| yeah... fallback is not a problem, you can always long-poll
| as socket.io has done for years
| [deleted]
| [deleted]
| newsbinator wrote:
| I'd like to try a version of this outside of Ruby/Rails.
| OJFord wrote:
| 'HTML over the wire' is an unfortunate tagline, but it does
| actually seem interesting, I'd suggest looking at the 'Turbo'
| docs before reacting.
|
| I have thought in the past I wish I could have a frameworky
| component-style frontend, but where the component is HTML
| rendered by my rust (or whatever) backend. This would seem to get
| me a lot closer to that.
| jshen wrote:
| Yes, I'm curious how hard it is to get this working with a
| different backend stack. I'd love to have this in Go.
| arvindamirtaa wrote:
| Getting turbo is trivial on any backend. Just include the js.
|
| Stimulus is also not any different from any other javascript
| you'll write. There's no need for any kind of scaffolding
| from the backend stack except for some features - and those
| aren't particularly hard to implement either.
|
| Source: Using Turbolinks & Stimulus js with Django.
| ivanhoe wrote:
| Laravel's crew had a very similar idea with Livewire (even the
| name sound similar, probably not intentionally) and it also
| created a lot of buzz back when it was released - but I don't
| think it really got past "let's play with it a bit" step for most
| of teams. We'll see how well this one does...
| paxys wrote:
| It's hilarious that web servers rendering HTML and sending it to
| the browser over a TCP connection is now "cool new tech".
| mosselman wrote:
| This isn't new at all. This is version 7 of Turbolinks that has
| been renamed to Turbo and has some added versions. It has been
| what the Ruby on Rails and it's creator have promoted for years
| and years.
|
| The new thing about it are the name and associating it with
| Stimulus and some features, not the general concept.
| hadrien01 wrote:
| Oh wow that is not clear at all. The old website of
| StimulusJS doesn't redirect to its new home, and the old
| GitHub repo for turbolinks (not turbolinks-classic) still
| exists.
| [deleted]
| wejick wrote:
| It's actually not as simple as that. The simplification is too
| brutal and doesn't appreciate the details.
|
| It's the answer for people that sick of the weight of modern
| webapp, where everything need to be rendered client side.
| sfvisser wrote:
| Honestly, my experience is that most webapps aren't that
| heavy for what they actually do.
|
| Web __sites __are heavyweight, serving megabytes of useless
| nonsense just to display an article. With a bunch of ads
| obviously.
| ravenstine wrote:
| I'll just take a break for 3 years until SPAs become cool
| again. But they won't be called SPAs anymore... they'll be
| called "microapps". Elixir and Rust will be "just not fast
| enough" and there will be a new language VM that will "promise
| Hyperspeed(tm) on Google Crystalline(tm) chips". JSON will be
| considered harmful, and XML will be in favor again because it
| is flexible and there's plenty of bandwidth for all the extra
| bytes.
| antoineMoPa wrote:
| The downside of this is very high coupling between the frontend
| and the backend. However, many companies have been successful
| with strong coupling to Rails so maybe it's not a problem.
| dsego wrote:
| The backend here _is_ your frontend. Nothing stopping you from
| adding another service layer behind it.
| antoineMoPa wrote:
| The backend here _is_ your frontend.
|
| This supports my argument that there is tight coupling.
| dsego wrote:
| Between what? Your frontend is serving the html/css/js,
| that's your frontend. You can have another background
| service behind it, as many layers as you want. This
| separation doesn't have to be at the http level.
| antoineMoPa wrote:
| Let's say you take another approach. Build a backend that
| serves REST, GraphQL or whatever protocol. This can be a
| Rails backend, could be Python, JS, whatever. Now you or
| the frontend team are free to build the frontend with
| whatever technology.
|
| You can update it more freely to shining new JS
| frameworks because it is not entirely tied to your
| backend.
|
| Also, if your client/boss asks you to build a native IOS
| frontend, you already have built an API, useful no?
| clarkevans wrote:
| In many one-off applications there's no real need to create a
| separate API, tight coupling lets you focus on an MVP without
| having to focus on abstracting out an intermediate model -- you
| could go from the SQL database right to HTML rendering.
| dangoor wrote:
| If you have a frontend that is entirely dependent on data from
| the backend to display something to the user, then you've
| already got high coupling between the two.
|
| You probably wouldn't use this for a drawing app. But if you've
| got something where you're showing/updating database data, this
| model is likely fine.
| brtkdotse wrote:
| This sounds a lot like server-hosted Blazor, streaming HTML
| snippets though websockets. Am I understanding it correctly?
| freen wrote:
| You are not.
| poxrud wrote:
| I'm curious how this is different from Turbolinks, which was been
| available since rails 3.
| staticelf wrote:
| Turbolinks afaik, loads a larger part of a page upon hover and
| click, replacing all of the old html while this only updates
| the parts that has needs updating. This will prevent forms from
| being cleared or other state in the DOM to be wiped.
| werdnapk wrote:
| Exactly. Targeting specific sections of the page is pretty
| helpful when dealing with dialog content for example. If a
| dialog is open and you're managing something like the state
| of a form within that dialog, you don't want anything else
| outside of that dialog content being touched during a page
| update.
| latortuga wrote:
| "Turbo Drive", one of the parts of Hotwire, is a rebranding of
| Turbolinks. So it's new functionality on top of Turbolinks.
| kaleidawave wrote:
| There will be a very _hot wire_ when I have to ask the server to
| render a component on the server after I asked to increment a
| single counter
| jtms wrote:
| it might not be so bad
|
| <div id='counter'>42</div>
|
| is not so many more bytes than...
|
| { counter: 42 }
|
| also - no massive up front JS bundles to contend with
| kaleidawave wrote:
| Assuming that the counter state is on the client. A button
| with an event listener that runs x.innerHTML =
| state.counter++ makes a lot more sense than a round trip to
| the server.
|
| Just looked and Turbo is 135kb. I rewrote this website
| (http://40.115.126.159/) with my own JS framework and it
| comes at 15kb, that's 9x smaller Turbo...
| danjac wrote:
| So far, this looks very much tied to some Rails gems :
| documentation for installing outside of Rails is pretty much non-
| existent, I guess to be expected for a beta. My issue with
| Turbolinks/Stimulus is really that it's developed pretty much
| behind closed doors at Basecamp and we maybe get a shiny new
| release every few years, instead of being developed as a more
| open source project with incremental improvements and input from
| a wider group of contributors with diverse needs and insights
| than one small team at one company.
| rubyfan wrote:
| This is sort of ironic because many years ago what caused me to
| move functionality to client side was the fact that Ruby on Rails
| was slower on server side and required horizontal scale and
| things like memcached to meet my demands.
| [deleted]
| bcheung wrote:
| What are the pros and cons of this technique? Seems like this
| pushes a lot of the rendering compute power from the client to
| the server. I guess that is good for low power devices but now
| you need more powerful servers?
| alunchbox wrote:
| How do they intent to not have "Send massive files without using
| other apps" being abused? Isn't this one of the key reasons to
| use a separated system.
|
| I can see this becoming a big problem on their ecosystem if it
| starts to scale it'll start to be very costly.
| arvindamirtaa wrote:
| They charge $100 a year. It already is very costly (for us).
| kawera wrote:
| $100 per month: https://basecamp.com/pricing
| staticelf wrote:
| I love that these new techniques come out to make web dev simple
| again. I however think Phoenix Liveview is still the best from
| all the alternatives I have seen so far and that is mainly
| because Elixir as a language seems to be very stable and suited
| for having a lot of websocket connections open at the same time.
|
| It seems easier to accomplish this with Liveview and perhaps
| Alpine.js for displaying stuff like modals etc. It's a really
| good way to build applications I think for places that need a
| server roundtrip anyway which is most of the stuff in a modern
| app.
|
| I write a SPA app for work in javascript and about 90% of the
| issues that occurs are mainly state issues where the state
| differs or is in a bad state for some reason. State management is
| very hard to do right and I think solutions like these simplyfies
| it a lot!
|
| I urge people to check out Elixir and Phoenix Liveview which I
| think is the "original gangsta" when it comes to sending small
| updates over websockets and if you try it I will guarantee you
| will be blown away of the speed of which you can develop web apps
| as a solo dev.
| fortran77 wrote:
| I've been using Phoenix LiveView and I love it. I'm much more
| comfortable with Erlang syntax, though, and wish there was
| still a viable Erlang web framework.
| phaedryx wrote:
| I wish they'd document how to write tests for this stuff. Also, I
| wish they'd provide an example with multiple moving parts.
| Axsuul wrote:
| Yep-without good testing support, it's hard to consider this
| for production usage.
| esroyo wrote:
| Generally people argue that static HTML is more _energy
| efficient_ than server side rendering. I wonder If that is true
| in the case of static HTML "that loads an SPA", versus a server-
| side rendering with a proper cache in place. The SPA loading will
| still consume good energy on each client computer. Would love to
| see some numbers. Lots of hype, lots of projects and approaches,
| and lots of opinons about what is more convenient, but few
| numbers measurements of resources (space, time, what more?). May
| be It silly me, and the difference in energy terms is irrelevant.
| umaar wrote:
| Two points on client-side JS have been a constant for me for many
| years:
|
| - Noticed excessive JavaScript contributes to poor web
| performance - Things cause JS to break, which breaks other
| interactivity, often I end up using incognito
|
| During lockdown, I struggled ordering groceries because 20
| seconds of JavaScript execution on the main thread made my
| "delivery slot" expire!
|
| Similar to heydonworks.com stating "Please disable JavaScript to
| view this site", I'm glad Hotwire is encouraging folks to think
| about things a little differently.
| nlh wrote:
| Gotta give @dhh credit - he is one of the world's great
| marketers/promoters. He's been building hype for this as the
| "next Rails" for months and the man knows how to pique an
| audience's interest.
| stanislavb wrote:
| For those interested in the source code, here they are the repost
| of the mentioned tech:
|
| - Turbo (HotWire) https://github.com/hotwired/turbo - Stimulus
| https://github.com/hotwired/stimulus
| dorkandstormy wrote:
| Am I the only one who was very, very surprised when the
| screencast immediately jumped into Rails? There's no mention of
| Rails anywhere on the landing page.
| yopo wrote:
| Ya same here. I've been doing web dev for 13 years and was
| genuinely looking forward to this magical HTML only solution of
| theirs but left feeling deceived after finding out it's rails.
| arvindamirtaa wrote:
| It's not rails. It's very specifically backend agnostic.
|
| Source: I've been using turbolinks and stimulus with Django
| for a good year and a half.
| elchief wrote:
| wasn't this called Hijax back in the day?
|
| https://domscripting.com/blog/display/41
| poisonta wrote:
| It took a decade for the industry to realize that JS frameworks
| were overhyped and the degraded productivity because of them was
| not worthy. I think they will be replaced by Hotwire-like
| technologies in the next decade.
|
| The same thing will happen to micro services (especially,
| distributed monolith) and Kubernetes. They are just overhyped.
|
| Productivity matters most!
| Nextgrid wrote:
| The last decade in tech has shown that productivity does not
| matter most and I'm not sure the pendulum is swinging back
| (yet?). The only time productivity matters most is maybe small,
| bootstrapped businesses where cash isn't infinite and actual
| value delivered is what matters. In fact, the company behind
| this is Basecamp which is almost an outlier in tech at this
| point, as they're one of the few out there that actually makes
| its $$$ by selling products/services people pay money for, as
| opposed to endless VC money or acquisitions.
|
| When it comes to VC-funded crap or big legacy enterprise trying
| to "modernise" itself, over-engineering allows grifters to
| twist the situation for their own personal gain. The business
| problem the tech is supposed to solve often warrants a simple
| solution, but why would someone solve it with a simple solution
| and 3 people when they can bring Kubernetes, microservices,
| "service mesh", blockchain and multiple programming languages
| to the mix and suddenly become an "engineering manager"
| managing 30 people, put big words on their resumes and speak at
| conferences about how they solve big (self-inflicted, as a
| side-effect of the overengineering) problems where more of
| their peers (either new and genuinely believing this is the
| proper way to do things - like I once was - or experienced
| enough to know this is BS but support it as it paves the way
| for their own career) encourage them?
|
| This happens at multiple levels too, it's not just developers
| or would-be engineering managers. The funding side of things is
| also broken in the sense that you'll attract more investors and
| raise more money (some of which you'll keep in your pocket as
| salary, even if the company folds in the end) if you throw big
| words and pitch an over-engineered solutions such as blockchain
| as opposed to a simple and proven one (even though the latter
| is more likely to actually pay off).
| le_didil wrote:
| I don't think this is going to happen. Hotwire-like
| technologies have existed for a long time with turbo-links,
| adoption is low and it's very unpractical to work with compared
| to a split backend api + frontend (framework or not as you
| prefer).
| arvindamirtaa wrote:
| >it's very unpractical to work with compared to a split
| backend api + frontend
|
| This is just demonstrably false. Both paradigms have areas
| where they shine. One or the other is not better across the
| board.
|
| I guess the point of Hotwire is that there isn't pretty much
| anything you can't do with the "old tech" that you can with
| the modern javascript CF.
| joelbluminator wrote:
| Hotwire sells like hot cakes!
| tmakks wrote:
| tldr content marketing for Hey (email web app), carries DHH
| signature + cargo cult + magic, many social media bots/DHH
| fanboys upvoting comments + a second submission + silencing other
| opinions
|
| _Edit: As I predicted, I 've got my downvotes by DHH's social
| media team haha._
| _verandaguy wrote:
| Is this just PHP templating with extra steps?
| johnghanks wrote:
| i don't get it. isn't this just traditional SPAs but worse and
| more limited in basically every way?
| korijn wrote:
| I chuckled when I read "traditional singe page application".
| Anyone else share the sentiment?
| shrimpx wrote:
| Where does this fit with the recently hot SSG/SSR projects like
| Gatsby and Next.js?
| llimos wrote:
| It sounds a lot like Laravel Livewire[1]
|
| Also a lot like React Server Components that we saw on HN
| yesterday[2]
|
| It seems like this is the next wave of web apps. Hopefully once
| the hype settles, we'll be able to decide which approach is best
| for which project.
|
| [1] https://laravel-livewire.com/
|
| [2] https://news.ycombinator.com/item?id=25497065
| clementmas wrote:
| Caleb Porzio (creator of Livewire) made videos about "Server-
| Side Applications": https://laracasts.com/series/javascript-
| techniques-for-serve...
|
| His work inspired me to build my app (TravelMap) with SSR
| views: https://clem.travelmap.net
| twsted wrote:
| Very good work!
| jamesvandyne wrote:
| Off topic from the main thread, but Travel map looks really
| good. Reminds me of all the travel blogs I used to read when
| I was in high school / college dreaming about getting out and
| exploring the world. Great work!
| dsego wrote:
| I wonder how recruiting companies will continue selling
| frontend react rockstars and backend nodejs warriors who can
| write endpoints. And yes, that's how they differentiate between
| frontend and backend, because knowing how to format your json
| urls (which is not real REST) is backend work and react is
| frontend.
| etxm wrote:
| > not real REST
|
| Rarely admitted, but absolutely truth.
| sodapopcan wrote:
| Livewire, of course, having been heavily inspired by Phoenix
| LiveView
| https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html
| bnt wrote:
| Tho, LiveWire is AJAX, while LiveView and Stimulus Reflex are
| Sockets. LW is a pleasure to work with for small pieces of
| interactivity.
| dnautics wrote:
| I believe (but could be wrong) that liveview degrades to
| http long poll.
| [deleted]
| sodapopcan wrote:
| It does indeed!
| banjomet wrote:
| How does Hotwire compare to Phoenix LiveView?
| nickjj wrote:
| > How does Hotwire compare to Phoenix LiveView? It seems
| the same to me.
|
| It's much different based on a preliminary reading of
| Hotwire's docs.
|
| Live View uses websockets for everything. If you want to
| update a tiny text label in some HTML, it uses websockets
| to push the diff of the content that changed. However you
| could use LV in a way that replaces Hotwire Turbo Drive,
| which is aimed at page transitions, such as going from a
| blog index page to contact form. This way you get the
| benefits of not having to re-parse the <head> along with
| all of your CSS / JS. However LV will send those massive
| diffs over websockets.
|
| Hotwire Turbo Drive replaces Tubolinks 5, and it uses HTTP
| to transfer the content. It also has new functionality
| (Hotwire Turbo Frames) to do partial page updates too
| instead of swapping the whole body like Turbolinks 5 used
| to do. Websockets is only used when you want to broadcast
| the changes to everyone connected and that's where Hotwire
| Turbo Streams comes in.
|
| IMO that is a much better approach than Live View, because
| now only websockets get used for broadcast-like actions
| instead of using it to render your entire page of content
| if you're using LV to handle page transitions. IMO the
| trade off of throwing away everything we know and can
| leverage from HTTP to "websocket all the things" isn't one
| worth making. Websockets should be used when they need to,
| which is exactly what Hotwire does.
|
| I could be wrong of course but after reading the docs I'm
| about 95% sure that is an accurate assessment. If I'm wrong
| please correct me!
| flixic wrote:
| For one, LiveView doesn't send HTML over the WebSocket
| channel. It sends a highly optimized diff structure that is
| applied to HTML.
| somurzakov wrote:
| Sounds like Phoenix LiveView. I love phoenix <3
| codethief wrote:
| In case anyone from Basecamp sees this thread:
|
| The introductory video is far too long, far too technical (I know
| a lot about web dev but don't know a lick of Ruby or Rails) and
| far too fast to follow. I was really interested in Hotwire
| because of the comments here and now... not so much anymore.
|
| (Which of course doesn't say anything about the quality of the
| tech. I just thought I'd post my first impression of the
| website.)
| mrblues wrote:
| I agree. the video is terrible, nothing like the original Rails
| introduction screencast
|
| the tech is dope
| nickjj wrote:
| I'm not from Basecamp but it's interesting you mentioned it's
| too fast. I noticed that too and this is coming from someone
| who listens and watches everything at 2x speed.
|
| I've seen a lot of DHH's talks and demos and never had a
| problem listening to them at 2x. This is the only time where it
| feels like he scripted out the entire video word for word and
| then talked over a screen recording that was recorded
| separately from his voice. This video sounds nothing like what
| he normally sounds like (both tone and speed). I really wonder
| if he recorded this in a booth.
| tarsinge wrote:
| This is exciting! I am less convinced by the Stimulus part
| though. I currently prefer the Htmx (ex Intercooler) + AlpineJS
| combo, or VueJS components sprinkled into views for heavier stuff
| (setup is a bit tricky but then it's very easy to enhance views
| with augmented html). Am I missing something?
| dmix wrote:
| Yeah there's a million ways to do this already with JS
| frameworks or even combining them with Rails.
|
| It's trying to standardize a fullstack approach to it I
| presume.
| tarsinge wrote:
| I agree with the need of standardization. But it's just that
| I find the above mentioned libraries "hyper declarative"
| approach more in line with an HTML centric philosophy than
| the logic in a JS controller approach of Stimulus.
| yashap wrote:
| As others have noted, seems reasonably similar to LiveView,
| Livewire and Blazor. I'm somewhat bullish on these approaches -
| server side rendered monoliths (Rails, Django, etc.) are SO
| productive, at least for the first few years of development, but
| lack of interactivity is a big issue, and this solves it well.
|
| However, another big issue is the dominance of mobile. More and
| more, you've got 2-3 frontends (web and cross-platform mobile, or
| explicitly web, iOS and Android), and you want to power them all
| with the same backend. RESTful APIs serving up JSON works for all
| 3, as does GraphQL (not a fan, but many are). This however is
| totally web-specific - you'll end up building REST APIs and
| mobile apps anyways, so the productivity gains end up way
| smaller, possibly even net negative. Mobile is a big part of why
| SPAs have dominated - you use the same backend and overall
| approach/architecture for web and mobile.
|
| I'd strongly consider this for a web-only product, but that's
| becoming more and more rare.
| clarkevans wrote:
| > I'd strongly consider this for a web-only product, but that's
| becoming more and more rare.
|
| They have accompanying https://github.com/hotwired/turbo-ios
| and https://github.com/hotwired/turbo-android projects to
| bridge the gap.
| webmaven wrote:
| _> More and more, you've got 2-3 frontends (web and cross-
| platform mobile, or explicitly web, iOS and Android), and you
| want to power them all with the same backend.
|
| RESTful APIs serving up JSON works for all 3, as does GraphQL
| [...]. This however is totally web-specific - you'll end up
| building REST APIs and mobile apps anyways, so the productivity
| gains end up way smaller, possibly even net negative._
|
| I bet someone will produce a native client library that
| receives rendered SPA HTML fragments and pretends it's a JSON
| response. They might even name it something ironic like
| "Horror" or "Cringe".
|
| That said, an ideal API for desktop web apps looks rather
| different than one for mobile web or native clients. Basically,
| for mobile you want to minimize the number of requests because
| of latency (so larger infodumps rather than many small updates)
| and minimize the size of responses due to bandwidth limitations
| and cost (so concise formats like Protocol Buffers rather than
| JSON).
|
| It is definitely possible to accommodate both sets of
| requirements at the same API endpoint, but pretending that
| having a common endpoint implies anything else about the tech
| stack is rather disingenuous. If you want server-side rendering
| and an API that delivers HTML fragments instead of PB or JSON,
| that can be done too.
| ziftface wrote:
| Everyone who is talking about how the route the industry took
| with SPAs was just a silly mistake, and that we should go back
| to the good old days of PHP are forgetting that at the end of
| the day the most important thing is to choose the best tool for
| the job at hand.
|
| This, while very interesting and might have a preferable set of
| constraints for some projects, is simply not a good fit for
| many others, as you mentioned in your comment. This looks
| amazing, and I would definitely try it for a project in which
| it would fit, but I don't really see a reason to disparage the
| work others have been doing over the past decade. We need those
| other tools too!
|
| (sorry for the rant)
| arvindamirtaa wrote:
| We gotta wait and see what Strada has in store. Looks like
| Basecamp and Hey mobile apps are fairly good.
| OOPMan wrote:
| Is this real?
| underdeserver wrote:
| Laugh all you want but the hey.com website loads wicked fast.
| petee wrote:
| Why wouldn't it? It's got like 2 pictures and isn't long. I
| also wouldn't call it wicked fast - this is normal speed, which
| everyone seems to have forgotten
| underdeserver wrote:
| The landing page has a lot more than 2 pictures, but also the
| rest of the website is fast. Show me another modern-design
| website that loads that fast.
| petee wrote:
| Either way it's still under 400KB for the whole site, it
| had better not be slow. Not sure what modern has to do with
| it.
|
| By comparison of a similar design, golang.org is twice the
| size and only takes .3 seconds longer. So what exactly are
| we comparing?
| mrmonkeyman wrote:
| Sorry, this is right. You have all forgotten about how fast
| the normal web is or are too young to have experienced it.
| Sub 100ms is normal. 1000ms is not normal.
| arvindamirtaa wrote:
| Go ahead and load the hey login page.
|
| The js bundle your browser downloaded right there is the
| entire bundle for the whole email app.
|
| What size is it?
| SkyPuncher wrote:
| Wow! That is ludicrously fast.
| lxe wrote:
| These folks literally invented Ruby on Rails and were building
| web applications for over 20 years now. This tech seems "old" but
| it's solid.
| JeremyBanks wrote:
| This kind-of tangential reply is in bad taste, but DHH is
| currently being an asshole about _this very topic_ on Twitter,
| so:
|
| This seems cool, but the progress that HEY has made since launch
| isn't very impressive if that's the flagship example.
|
| HEY's search UX, which uses these capabilities, has been
| _abysmal_ since the day it launched. It 's a much better
| experience if you disable JavaScript/Hotwire and fall back to the
| server-side-rendering instead of the hybrid mess they push down.
| I'm very disappointed that this hasn't been improved. (I sent
| feedback about this while they were still in their invite-only
| phase.)
|
| We were also promised custom domain support by the end of the
| year, and we don't have a timeline or even pricing yet. (That's
| obviously backend and unrelated to this announcement.) I don't
| want to go back to Google, but the lack of improvement isn't
| giving me a lot of confidence as a HEY customer, so I'm
| considering alternatives.
| ksec wrote:
| >We were also promised custom domain support by the end of the
| year,
|
| Basecamp / DHH generally speaking hate deadlines / roadmap etc.
| They are ready when they are ready.
|
| Although I do agree a little update would be nice.
| bschne wrote:
| I'd be curious to hear about your general experience w/ hey -
| from the outside it looks like it has some cool new(er)
| approaches, but I've seen someone's actual full email account
| in a screencast once and it looked like it'd get messy with
| actual heavy usage really quickly and the UX might deteriorate.
| Any takes?
| save_ferris wrote:
| Not OP, but I have a Hey account and I really enjoy it. The
| screener feature is worth the price alone IMO. The biggest
| challenge for me was having to re-conceptualize email after
| switching over since Hey doesn't use traditional email
| terminology (i.e. "paper trail" vs "archive").
|
| The amount of inbound email I get has dropped immensely due
| to the screener and my inbox ("imbox") is so much easier to
| manage with Hey, IMO.
| JeremyBanks wrote:
| I find HEY's general workflow very good for my medium-volume
| personal email. It encouraged me to filter a lot more stuff
| out of my inbox than I did with Gmail, while spending less
| time configuring filters. The ability to leave internal
| comments on external email threads (business accounts only)
| is very useful as a first-class feature, instead of relying
| on fiddly BCC. The apps are quite nice to use. Overall,
| there's less clutter and it is a more pleasant experience
| than other email clients I've used... until I try to search
| in the Hotwire-powered web view.
| warpech wrote:
| Not to be confused with Turbo by Yandex:
| https://yandex.com/dev/turbo/index/, which is a competitive take
| on Google AMP.
| Nijikokun wrote:
| Sigh, this is already what modern frameworks do.
| modernerd wrote:
| Pure JS developers trying to jump off the JS train have a few
| decent choices now:
|
| - Elixir / Phoenix
|
| - .NET / Blazor
|
| - Laravel / Livewire
|
| - Rails / Hotwire
|
| Or hold on for the JS ecosystem to figure out good patterns that
| balance performance/maintainability (React Server Components look
| ok, and will probably trickle into Next.js for those who want a
| framework).
|
| Does one of the above stand out as a good thing to learn from a
| career perspective, say, for a JS developer growing tired of
| frontend?
|
| Is the thirst for React developers ever likely to dry up and
| leave devs who know these frameworks with an advantage?
| arvindamirtaa wrote:
| It's really not Rails + Hotwire. It's any backend + hotwire.
|
| It works just fine with Django.
| cutler wrote:
| Well Blazor ain't gonna reduce your load front-end load, that's
| for sure.
| danielsokil wrote:
| Also IHP (Haskell) has Auto Refresh
| https://ihp.digitallyinduced.com/Guide/auto-refresh.html
| [deleted]
| tecnocriollo wrote:
| Like old fashioned PHP
| SahAssar wrote:
| I've never seen one of these "logic in html-attributes" systems
| take error checking seriously. In stimulus they start to mention
| it in "Designing For Resilience" (though only for feature-
| checking), but in "Working With External Resources" where it uses
| calls network/IO bound calls they never mention how to handle
| errors or if the framework just leaves it up to you. Stimulus is
| also where you need to write your own js code, so I guess you
| could handle it yourself but in turbo when I skimmed the handbook
| I find no mentions of what/how to handle errors (or even what
| happens when turbo gets one), and when loading stuff over the
| network that is pretty much crucial.
|
| From the turbo handbook: "An application visit always issues a
| network request. When the response arrives, Turbo Drive renders
| its HTML and completes the visit." Using the phrase "When the
| response arrives" begs the question of what happens if it doesn't
| arrive, or if it takes a minute for it to arrive, or if it
| arrives but with a faulty status code.
| Nextgrid wrote:
| Counterpoint: is there any error handling in the majority of
| SPAs today? From my experience, SPAs can crap out in all kinds
| of interesting ways when the underlying network connection is
| flaky and I often end up stuck on some kind of spinner that
| will never complete (nor give me a way to abort & retry the
| operation when I already know it won't complete and don't want
| to wait for the ~30-second timeout, if there is a timeout
| even).
|
| Not saying this is better from an error handling perspective,
| but at least the whole idea of Hotwire and its peers
| (Turbolinks, etc) is that there is no state and it should thus
| be safer and quicker to reload the page should things go wrong.
| ketamine__ wrote:
| I refresh SPA apps more than other apps because of these
| problems.
| masa331 wrote:
| Me too. However, this also doesn't work properly on a lot
| of SPAs xD
| SahAssar wrote:
| I agree that most SPA apps do it badly too, but hiding the
| opportunity to do it well certainly does not help.
|
| > there is no state and it should thus be safer and quicker
| to reload the page should things go wrong.
|
| That's not exactly true since there are non-idempotent HTTP
| methods and while the browser will prompt you if you want to
| resend a non-idempotent HTTP request when refreshing a normal
| form POST I don't think that turbo/turbolinks/similar will
| allow you to prompt or resend.
|
| On refresh should turbo retry a POST? The "right way" is to
| keep the state of the last POST and prompt the user for
| confirmation, but it seems like it is undocumented as to what
| it does. I'm guessing it either does not retry or it retries
| and hopes effect will be idempotent.
|
| No one (SPAs, traditional webpages and "spiced" webpages like
| this included) is doing everything right, but my objection to
| this framework is that it seems to try to say things are
| simple or easy when they clearly aren't.
| phaedryx wrote:
| Yes!
|
| 1. What if something goes wrong?
|
| 2. How do I test for handling success/error?
|
| They never address this stuff.
| blablabla123 wrote:
| ...also what is when response/request "items" are not handled
| chronologically due to load. I once wrote a real-time
| application with that pattern (HTML over AJAX). It worked but
| it was not enjoyable at all. Also literally every larger
| feature change would break the code because you had all these
| weird corner-cases.
| inopinatus wrote:
| They do already address error handling. GP is shooting the
| breeze here, evidently has no specific knowledge of
| Turbolinks family API or behaviour.
| memco wrote:
| A very good point! Presumably the appeal of a system like this
| is the potential for graceful degradation where if sockets
| aren't working or some requests are failing then the default
| html behavior should still work: links will just take you to
| the original destination, but there's no indication that this
| is actually what happens.
| inopinatus wrote:
| This is an isomorphic fetch. The original href already is the
| visited URL, so I'm not sure that trying that _again_ is
| wise, or appropriate, unless the user chooses to reload.
|
| The entire design philosophy here is to mimic apparent
| browser behaviour, or to delegate to it. Hence, to GP's
| question; you should expect the appearance of browser-like
| behaviour in any circumstance, modulo anything Turbo is
| specifically trying to do different. Deviation from baseline
| browser semantics was certainly a basis for filing bugs in
| its predecessor (Turbolinks).
|
| As for what Turbo actually does, I checked the source. Good
| news, even for a first beta, they're not the cowboy nitwits
| alleged; it gracefully handles & distinguishes between broken
| visits and error-coded but otherwise normal content
| responses, and the state machine has a full set of hooks,
| incl. back to other JS/workers, busy-state element selectors,
| and the handy CSS progress bar carries over from Turbolinks.
| fiddlerwoaroof wrote:
| I've used intercooler with browser-side routing and, the
| strategy for error recovery that makes sense in that context is
| "if something goes wrong, reload the page": the server is
| designed to be able render the whole page or arbitrary subsets
| and, so, reloading should usually be safe.
| [deleted]
| mdoms wrote:
| Spoiler, it's just Ajax but it pushes the data through your
| templates before sending it to the client. We were doing this
| literally over a decade ago in the early days of XHR.
| Osiris wrote:
| I have a small website and I have one page with an order form
| and I show a modal with the result of the order. This is how I
| do it. The Ajax calls gets back HTML that it shoves into the
| modal. It was just easier than writing JS with templates and
| parsing JSON. It always felt icky to me because that's not the
| way you're "supposed" to do it, but it works quite well.
| joelbluminator wrote:
| Oh no, a decade ago!! please show me some hot new
| Next/Redwood/Svetle code so I can calm my nerves!
| aantix wrote:
| The goal is to have a productive set of patterns for the
| programmer to follow for dynamic updates.
|
| Less boilerplate. More reuse. Consolidation of app state to the
| server.
|
| Feel free to post your code from a decade ago so that we can do
| a bake-off and compare implementations side-by-side.
| [deleted]
| goshx wrote:
| Next year they'll come up with hosting your websites on your own
| bare-metal.
| [deleted]
| naikrovek wrote:
| amazing. This used to be called /cgi-bin/ with templates and
| XMLHttpRequest (a Microsoft invention initially supported only in
| IE then adopted by everyone) and now it's suddenly a new
| technology/approach but with a new name so you're not ridiculed
| for using it?
|
| I gotta give them credit for revisiting server-side page
| assembling though; moving application logic and templating mostly
| to the front end was a HUGE mistake. JS is very fast now, but
| it's still absolutely glacial in its speed compared to server-
| side code written in compiled languages.
| Trasmatta wrote:
| > and now it's suddenly a new technology/approach
|
| I don't think I've ever seen DHH or the Basecamp crew advertise
| any of this type of stuff as some groundbreaking new approach
| that nobody has ever tried before. On the contrary, I usually
| see them talking about how those old ways of doing web
| development were actually better in many ways, which is why
| they're pushing to move away from the current "everything is an
| SPA" approach.
|
| And all this new tooling makes the experience much better than
| it ever was in the past.
| arvindamirtaa wrote:
| >I don't think I've ever seen DHH or the Basecamp crew
| advertise any of this type of stuff as some groundbreaking
| new approach that nobody has ever tried before
|
| Not disagreeing with the rest of the stuff. But they
| literally call it "NEW MAGIC" per DHH's tweet.
| jshen wrote:
| cgi-bin didn't give you the ability to update a chat page
| across several different windows in near real-time.
| naikrovek wrote:
| It did if you used XMLHttpRequest.
| jshen wrote:
| If you type a chat message in your browser, how does it
| automatically show up in my browser with XMLHttpRequest?
| icedchai wrote:
| In old school chat rooms, this was usually done by
| polling for new messages every X seconds, or doing a
| refresh / reload of an IFrame containing the chat.
| webmaven wrote:
| _> cgi-bin didn't give you the ability to update a chat page
| across several different windows in near real-time._
|
| Servers could maintain an open connection and stream new data
| to the browser.
| sdevonoes wrote:
| Is this a joke? What's new about sending HTML over a TCP
| connection?
| dogsgobork wrote:
| For a minute I thought it was the html version of vanilla-js
| http://vanilla-js.com/
| capnorange wrote:
| the dev experience
| [deleted]
| dmitriid wrote:
| Without reading the details, LiveView in Phoenix (Elixir) sends
| HTML/DOM updates only. Hotwire sounds pretty similar (and it's a
| good thing IMO)
| pictur wrote:
| Hype hype hype hype...
| elamje wrote:
| This is the Ruby on Rails version of what Elixir Phoenix Live
| View and .NET Blazor do.
|
| For those not familiar, rather than using a standard web
| framework where a lot of processing is done client side, these
| frameworks allow html buttons etc to call native Ruby, C#, or
| Elixir functions on the server rather than using some sort of
| post/get request to do that. Every UI interaction goes over the
| wire, which is where performance can be hurt.
|
| Having used Blazor in production for nearly a year, it speeds up
| development, but your server is doing a lot more processing and
| will not be able to handle an equivalent amount of users that a
| normal web app would because it's keeping a copy of the clients
| DOM in memory. It's updates the dom on the server then streams
| that update through websockets to the clients dom, creating your
| magic Single Page App experience.
|
| I think it's cool tech, but not necessarily scalable due to the
| increased server load. I'd be interested to hear from people
| using it to serve large orders of magnitude of clients at once.
| kfk wrote:
| It depends right? If your app is a dashboard this could be less
| work when using smart cashing. You could cache entire html
| fragments on the server for specific user defined filter
| values. If you are serving hundreds of users you'd have
| dashboard faster than most BI tools out there including
| PowerBI.
| aantix wrote:
| It's not keeping a copy of the DOM server-side..
|
| That's not how it works, at all.
| dhh wrote:
| I get the rush to provide technical comparisons to something
| that was just revealed five minutes ago, but none of what you
| just said is actually how Hotwire or Turbo works. There's no
| client DOM in memory on the server, there's no html buttons
| that call native code.
|
| There are forms being submitted, there are normal requests
| happening, there are templates being rendered on a per-request
| basis (just like a full page load).
|
| This is like a normal web application that renders HTML, from
| the perspective of how the server works. Just as scalable as
| every other Rails application that renders HTML. Be that GitHub
| or Shopify or Zendesk or Basecamp or HEY or any of the many,
| many other apps that have long ago definitively proven that
| Rails Scales.
|
| Although I do find the commentary that the current #1 comment
| on the HN thread is literally a "bUt DoES iT SCaLE??" take,
| based on a misunderstanding of how this works. All is indeed as
| it's always been
| saltcod wrote:
| Literally LOL'd at the first part of this. A+++.
| aomega08 wrote:
| Hi @dhh!
|
| Loving the tech and the website (and Rails, and Basecamp,
| etc). However it looks very similar to StimulusReflex
| (https://stimulusreflex.com), which has already attracted a
| few users.
|
| Can you highlight the biggest differences between the two?
|
| Thanks!
| OJFord wrote:
| Looks like link should be https://docs.stimulusreflex.com/
| (the root domain you linked doesn't go anywhere).
| ksec wrote:
| And while we are at it, Motion
| (https://github.com/unabridged/motion)
| [deleted]
| [deleted]
| progressbwc wrote:
| I can't speak for Blazor but LiveView does not keep a DOM on
| the server nor it requires all UI interaction to go to the
| server.
| BryanBeshore wrote:
| Any idea how many people use Hey.com? That might be an early
| indication as to how scalable this is (at least for hotwire's
| concerns)
| ksec wrote:
| Well Rails was never not scalable in literal sense. It was
| just the cost of scaling being expensive; comparatively
| speaking when people say Rails not able to scale. And for
| most if not _all_ _SaaS_ that should never be much of a
| problem. Because you are getting revenue per user, and
| generally speaking the cost percentage of user / app /
| server resources is so small, that is a rounding error in
| grand scheme of things.
|
| What doesn't work quite as well is when the app is operating
| a freemium / ad based model. Where a large volume of traffic
| are required _before_ you start generating revenue.
| SkyPuncher wrote:
| I always find the Rails/scalable thing to be a funny
| argument - especially on the startup-minded HN.
|
| You don't need scale at a startup. You need velocity. If
| you're hitting scale at a startup, you've done one of two
| things:
|
| * Written absolutely terrible software
|
| * Succeeded
|
| Unless you've hit the second one, it will almost always be
| cheaper to simply spin up another server.
| EdwinLarkin wrote:
| Could be because a lot of startups are just trying to
| squeeze just as much traffic as they can with very little
| capital involved.
|
| It's basically here's my app that does billions of things
| and wants billions of users and runs on potato thing.
| simonw wrote:
| GitHub scales just fine on their own variant of Turbolinks.
| BryanBeshore wrote:
| Agreed. My comment about scaling is simply that a lot of
| other companies use rails at scale, and alike that of
| hey.com (which I presume is heavily used) it is probably
| built to... scale
| zemnmez wrote:
| from a security engineer's perspective, these things seem great,
| but ultimately become really tricky where DOM nodes need to be
| produced safely. string concatenation doesn't cut it for obvious
| reasons, then you have mXSS from mismatches between the backend
| server and the browser's interpretation of the HTML
| sourc3 wrote:
| This is so exciting to see, especially for older folk like me.
|
| Almost 20 years ago, one of my professors told us before
| graduation that hot tech is mostly about the idea pendulum
| swinging back and forth. I immediately chalked it up to 65+ above
| white wise men snobbery.
|
| However, this is exactly that. We started with static pages, then
| came Ajax and Asp.net and the open source variants, then we went
| full SPA, now we are moving back to server side because things
| are too complicated.
|
| Obviously tech is different, better, more efficient but the
| overall idea seems to be the same.
| shadowgovt wrote:
| I think I'd be more impressed by this idea if their server
| wasn't currently down.
| craftinator wrote:
| It's back up. If you check out the traffic to it, we hugged
| it to death.
| callamdelaney wrote:
| >65+ above white wise men snobbery
|
| Nice! Casual ageism and racism mixed into one post.
| preordained wrote:
| Seriously. That's a WTF from me, dawg...
| WhitneyLand wrote:
| Conventional wisdom is discrimination against privileged
| groups such as white men is less offensive because they've
| endured so much less of it.
|
| On one hand, it's true. It's part of white privilege which is
| tangible.
|
| On the other hand, however less often people in a privileged
| class are realistically impacted by discrimination, it's
| still > 0.0%. Since it usually costs nothing more to include
| everyone it seems useful.
|
| But I think the biggest reason it's important to care about
| discrimination wherever it shows up and not let people off
| the hook is that it's unifying.
|
| There's a story out of Buddhism that suggests it's important
| to think equally kindly about rich people, kind of similar in
| that they're a privileged class.
|
| I know it's a hard sell. I don't do it justice here. However
| a powerful argument can be made that not disparaging
| privileged classes, actually helps us all in the long run/big
| picture.
|
| If I get down voted I understand, that's ok. If it makes a
| difference I don't mean to minimize the 10,000 year history
| of pain suffered by any humans due to discrimination.
| rs23296008n1 wrote:
| Racist people like you make peaceful protests and working
| for change against racism so much harder. You're just out
| for revenge and your rhetoric shows it.
| callamdelaney wrote:
| Racism is singling out white people as the source of all
| evil, and then backing it up with statistics which don't
| tell the whole story.
| tclancy wrote:
| Rough guess OP is making fun of himself with this now.
| mfer wrote:
| It's not just that things are too complicated... the JS being
| sent to browsers is large and a lot of work. That requires more
| bandwidth, processing, and power usage on client devices. This
| eats phone, tablet, and laptop batteries.
| alunchbox wrote:
| But... that's one of the pro's of not having to do the
| rending cycle on the server. Also caching of framework
| libraries off CDN's and such.
|
| I don't see much merit in moving back to server side
| rendering aside from obfuscation & helping SEO ratings (web
| crawlers have a hard time with SPA)
| combatentropy wrote:
| In a few tests I ran, I found rendering to be fast and
| lightweight. If you already have prepared the associative
| array of values, then the final stage of combining it with
| a template and producing HTML doesn't strain the server,
| and so it doesn't help your server much to move that part
| to the client.
|
| The server's hardest work is usually in the database:
| scanning through thousands of rows to find the few that you
| need, joining them with rows from other tables, perhaps
| some calculations to aggregate some values (sum, average,
| count, etc.). The database is often the bottleneck. That
| isn't to say I advocate NoSQL or some exotic architecture.
| For many apps, the solution is spending more time on your
| database (indexes, trying different ways to join things,
| making sure you're filtering things thoroughly with where-
| clauses, mundane stuff like that). A lot of seasoned
| programmers are still noobs with SQL.
|
| Anyway, if rendering is lightweight, then why does it bog
| down web browsers when you move it there? I don't think it
| does. If all you did was ship the JSON and render it with
| something like Handlebars, I think the browser would be
| fine, and it would be hard to tell the difference between
| it and server-side rendering.
|
| I think what causes apps to get slow is when you not only
| render on the client but implement a single-page
| application. (It's possible to have client-side rendering
| in a multipage application, where each new page requires a
| server roundtrip. I just don't hear about it very much.)
| Even client-side routing need not bog down the browser.
| I've tested it with native JavaScript, using the History
| API, and it is still snappy.
|
| I guess what it is, is that the developers keep wanting to
| bring in more bells and whistles (which is understandable)
| especially when they find some spiffy library that makes it
| easier (which is also understandable). But after you have
| included a few libraries, things start to get heavy. Things
| also start to interact in complex ways, causing flakiness.
| If done well, client-side code can be snappy. But a highly
| interactive application gets complicated quickly, faster
| than I think most programmers anticipate. Through careful
| thought and lots of revision, the chaos can be tamed. But
| often programmers don't spend the time needed, either
| because they find it tedious or because their bosses don't
| allot the time --- instead always prodding them on to the
| next feature.
| mfer wrote:
| > But... that's one of the pro's of not having to do the
| rending cycle on the server. Also caching of framework
| libraries off CDN's and such.
|
| This doesn't save battery life on a device. If someone
| downloads a few meg of JS their browser has to parse and
| execute that JS locally. This use of processing uses power.
| If that same person had half as much JS to parse and
| execute it would use less power.
|
| A CDN does not save from this happening.
|
| When power use happens on a server it's more on the server
| but less on devices with batteries. Batteries aren't used
| up as quickly (both between recharges and in their overall
| life).
|
| A server side setup can cache and even use a CDN to only
| need to render parts that change.
|
| My points are that it's not all cut and dry along with
| considering batteries.
|
| Oh, and older systems (like 5 year old ones)... surfing the
| web on an older system can be a pain now because of JS
| proliferation.
| grishka wrote:
| I think there's some kind of weird mentality among web
| devs that client-size computations are free, but server-
| side ones cost resources because you do more of them the
| more users you have.
| deergomoo wrote:
| They are free, just not to the client.
| RandallBrown wrote:
| You're right it's not all cut and dry.
|
| The two things that use the most battery in a phone are
| the radio and the screen.
|
| If you can do most of the work client side, the phone can
| turn off the radio and save battery. The amount of
| battery savings of course depends greatly on what the
| application is actually doing.
| mfer wrote:
| > Oh, and older systems (like 5 year old ones)... surfing
| the web on an older system can be a pain now because of
| JS proliferation.
|
| This matters because of the poor, the elderly (on a fixed
| income), and those who aren't in first world countries
| don't have easy access to money to keep getting newer
| computers.
|
| Then there is the environmental impact of tossing all
| those old computers.
|
| So, there is both a people and environment impact.
| mekkkkkk wrote:
| An interesting development is that the argument "common
| libraries will be cached in the browser" is no longer true.
| Chrome and other browsers are starting to scope their
| caches by domain, to mitigate tracking techniques that used
| 304 request timing to identify if the client had visited
| arbitrary URLs.
|
| Yes, I'm aware that "it will be cached" lost most of its
| glory when bundling became mainstream, but I still hear it
| as an argument when pulling things from common CDNs.
| rorykoehler wrote:
| And state is not reflective of reality in the database which
| is a terrible idea for most apps
| [deleted]
| wwweston wrote:
| The interesting thing is that if you don't think of the browser
| as just another runtime, nothing more than The VM That Lived
| (where applets and flash died), but actually think of your
| applications as Web Applications, then you get the ideas behind
| this faster.
|
| JSON is just a media type that a resource can be rendered as.
| HTML is another media type for the same resource. Which is
| better? Neither, necessarily, it depends on the client
| application. But if you are primarily using JSON to drive
| updates to custom client code to push to HTML, well, that
| should give you something to think about.
| jhpriestley wrote:
| The Rails people never went for SPAs though. Releasing another
| server-rendering AJAX thing for rails (previous was TurboLinks)
| no more represents "the pendulum swinging back" than a new
| version of COBOL that runs on mainframes represents the
| pendulum swinging back to mainframes. If this approach gains
| market share against React etc., then that will be meaningful -
| but don't hold your breath, there are legitimate reasons for
| the move to SPAs and also an enormous amount of institutional
| inertia behind it.
| danmaz74 wrote:
| Lots of rails back end applications power SPAs on the front
| end. Sometimes for good reasons, often enough just because it
| was more "modern" - but much less efficient in terms of
| programming.
| jpxw wrote:
| > I immediately chalked it up to 65+ above white wise men
| snobbery.
|
| Perhaps this can be the opportunity for you to look through
| your past and consider and reevaluate other ideas you discarded
| because of your own bigotry.
| dgb23 wrote:
| I don't think this addresses all of what SPAs is used for. It
| seems to assume full-stack control.
| Trasmatta wrote:
| It's specifically built for Rails, so yeah, it definitely
| assumes full-stack control.
|
| And there are definitely applications I would prefer to write
| as an SPA over the Hotwire approach. But given that the vast
| majority of websites are just a series of simple forms, I
| prefer this approach over the costs you incur from building
| an entire complex SPA.
| mfer wrote:
| While it works with Rails... some of the parts are just
| JavaScript and will work with any underlying platform.
| bzb6 wrote:
| Nice casual racism you threw in there.
| craftinator wrote:
| .
| fmakunbound wrote:
| I'm glad this technique is making a comeback. The last 10 years
| of JavaScript on the client have been an utter shit show that
| left me wondering wtf people were thinking.
| some1else wrote:
| > The last 10 years of JavaScript on the client have been an
| utter shit show
|
| A fair number of people would disagree. I'd say it's advanced
| a lot, considering the limited role of JavaScript on the
| client in the past.
| tvaughan wrote:
| Couldn't have come soon enough. I'm exhausted
| blorenz wrote:
| You have the benefit of hindsight at this time. You can draw
| parallel to history of flight and all the crazy contraptions
| that people attempted. Great technology can emerge from the
| combination of numerous shit shows. The whole is greater than
| the sum of the parts.
| epistasis wrote:
| I'm not a front end engineer, but it always seemed crazy to
| me. I remember testing out the Google Web Toolkit when it
| came out more than a decade ago, and the craziest thing
| about it to me wasn't the Java --> JavaScript compilation,
| it was that the server just dumped an empty page and filled
| everything in with JavaScript on the client.
|
| Then, remember the awful awful #! URLs? Atrocious, and
| seemed like obviously a terrible idea from the start, yet
| they spread, and have mostly died, thankfully. But even
| with the lessons from these bad tech designs, new
| frameworks come out that repeat mistakes, yet get
| incredible hype.
| mruniverse wrote:
| Around the time that GWT came out, offshoring was a big
| thing. And most of the contractors only knew Java. Also
| Java was the trusted language and javascript was not.
| bryanrasmussen wrote:
| The only big GWT project I've ever been on was a
| governmental project that I won't go into (because it's
| Danish and I would have to describe a bunch of stuff that
| everyone in Denmark knows and nobody outside would
| probably care about), but the company providing it was
| porting their Java version to JavaScript and had a
| significantly large codebase to leverage.
| Twirrim wrote:
| AWS used to rely on JWT for their consoles (haven't for a
| few years now, most folks migrated away some 5 years ago)
|
| It's why they used to be horrendously bloated with large
| javascript bundles that took so long to process on the
| client side.
|
| Roughly speaking the idea was "We don't have any
| Javascript developers, but we do have Java developers.
| JWT allows us to bridge that divide". Neat in theory, and
| an understandable decision, but diabolical in practice!
| filmor wrote:
| Hashbang URLs are gone because of the PushState API, not
| because people have given up on the idea.
| Cederfjard wrote:
| Very true. I think that mostly, web dev mainstream has
| taken a rational path. It's with the benefit of hindsight
| as you say, or the yoke of unusual requirements, that
| people now say "we did it all wrong".
| Twirrim wrote:
| > You have the benefit of hindsight at this time.
|
| People have been pointing out it's a shit show with no end
| in sight for the entire duration of the phase. Pointing out
| the performance impact and cost to end users, how
| diabolical it is for those on lower latency or poorer
| network connectivity (i.e. most of the world), and so on.
|
| Same thing as always happens with these pendulum swings,
| newer engineers come in convinced everyone before them is
| an idiot, are capable of building their new thing and
| hyping it up such that other newer engineers are sold on it
| while the "old guard" effectively says "please listen to
| me, there's good reasons why we don't do it this way" and
| get ignored. Worse, they'll get told they're wrong, only to
| be proven right all along.
|
| I'm not denying there are obstructionist greybeard types
| that just refuse to acknowledge merits in new approaches,
| but any and all critique is written off as being cut from
| the same cloth.
|
| It's perfectly possible to iterate on new ideas and
| approaches while not throwing away what we've spent decades
| learning ('Those who do not learn history are doomed to
| repeat it'), but tech just seems especially determined not
| to grow up.
| freeopinion wrote:
| I guess I've become a grey beard. I've done the whole
| journey from CGI everything to a bit of js to SPA. As
| much as I'd really like to be nostalgic about the good
| old days, there are reasons everything got pushed into
| the client. One of those reasons is maintaining state.
|
| "HTML over the wire" isn't really a return to the good
| ol' days. It's still the client maintaining state and
| using tons of js to move data back and forth without page
| reloads. It just changes the nature of 1/2 the data and
| moves the burden of templating back to the server.
|
| It is amusing that they make a claim that reads a lot
| like "eliminate 80% of your Javascript and replace it
| with Stimulus". What is Stimulus? A Javascript framework.
| combatentropy wrote:
| They mean JavaScript that you write.
| rorykoehler wrote:
| I'm glad I'm not the only one who thought this.
| philote wrote:
| Same. And I'm still amazed that people loved JS so much they
| put it on the SERVER too! And now node/npm is everywhere.
| devwastaken wrote:
| Yeah people shouldn't make applications in programming
| languages. If your application can't be made with html/css
| then it's bloatware. All this java, .net and C are totally
| unnecessary.
| easton wrote:
| I don't think the problem is with programming languages,
| but with JavaScript specifically, since it was never
| designed to be stretched this far. TypeScript is an
| improvement, but if you could write C or whatever on the
| client side and run it as easily as JS I think more people
| would go that route.
| Trasmatta wrote:
| Literally nobody is saying this
| devwastaken wrote:
| They are, look at the context of what they're saying. JS
| is simply a programming language in a VM like plenty of
| others, there's nothing inherently bad about it. But
| every thread here's the uneducated hate for it,
| completely misunderstanding that html/css static pages
| don't solve the problems a programming language does.
|
| I'd like to see these people make applications in pure
| XML. No programming.
| Trasmatta wrote:
| No, the argument has never been "replace all JS with
| static HTML/CSS". The argument is "JavaScript frontends
| are becoming unnecessarily bloated, slow, and
| complicated, and we can do better". Solutions like the
| one Basecamp is proposing with Hotwire include pushing as
| much rendering logic as possible to the server, where
| you're using a language like Ruby for logic. Nobody
| thinks you can just remove all logic from a web
| application unless it's literally just static content.
|
| And even with Hotwire, you're not getting rid of
| JavaScript entirely. You can write it with Stimulus. The
| idea is just that frontend web development has become a
| mess, and it's possible to simplify things.
|
| > there's nothing inherently bad about it
|
| Disagree.
| deergomoo wrote:
| People often conflate use with abuse.
|
| The bad experiences stick out to people, whereas all the
| well behaved JS-heavy apps out there likely don't even
| register as such to most people.
|
| Even with SPAs, it's very possible (and really not that
| hard) to make them behave well. Logically, even a large
| SPA should use less overall data than a comparable
| server-rendered app over time. A JS bundle is a bigger
| initial hit but will be cached, leaving only the data and
| any chunks you don't have cached yet to come over the
| wire as you navigate around. A server-rendered app needs
| to transmit the entire HTML document on every single page
| load.
|
| Of course, when you see things like the newer React-based
| reddit, which chugs on any hardware I have to throw at
| it, I can sort of see where people's complaints come
| from.
| threwawaay wrote:
| I like how so nonchalantly you turn this into a racist comment
| and yet no one is calling you out on it.
| scubbo wrote:
| Probably because they are relating an anecdote from their
| past, and self-deprecatingly pointing out how naive and
| overly-judgemental they were _back then_.
| [deleted]
| CyberDildonics wrote:
| You went to a school with professors and dismissed their final
| advice to you as "65+ above white wise men snobbery"?
|
| Which part of that is supposed to be a reasonable thing to say?
| scubbo wrote:
| > Which part of that is supposed to be a reasonable thing to
| say?
|
| None of it - that's the point. They are self-deprecatingly
| pointing out how naive and judgemental their younger-self
| was.
| craftinator wrote:
| Lol so did I. Ageism is a thing, and it's everywhere. At
| least when you're young, you don't have the excuse of already
| having been in the other age class. That being said, several
| of my older professors were entirely full of snobby shit. The
| older I get, the more I see how they were not trying to
| impart knowledge, but to gain some kind of status as "hard-
| ass" old men with the younger generation.
| ficklepickle wrote:
| Nobody is doing what they claim. It's all ego and
| posturing. I'm getting tired of humanity.
| frereubu wrote:
| I read it as a self-deprecating dig at his / her younger
| self.
| jjkaczor wrote:
| Exactly, it is kind of like Clarke's first law:
|
| https://en.wikipedia.org/wiki/Clarke%27s_three_laws
|
| Youth are always writing off the oldies - I did it, and now
| that I am old, I see it happening to me - and that is ok -
| we need that passion to shake things up, even if they end-
| up eerily similar to the way things were done before...
| craftinator wrote:
| I would point out that those are older also tend to write
| off the younger. I think it's just perspective mismatch;
| If I can emulate another person's perspective in my head,
| I can anticipate their decisions (and reasoning), so I
| can decide if they are being reasonable.
|
| However if I can't understand their perspective, I have a
| very hard time in understanding and judging their
| reasonableness (because I'm basing my judgement solely
| off of my own experiences and memories that are similar
| to their circumstances).
|
| This lack of understanding translates to seeing a lack of
| credibility in them. "Maybe if they were more like me,
| they'd make more sense, be more reasonable". This type of
| thinking is common in most types of prejudice.
|
| It's why young people write off older people: "They're
| too older to remember what it's like being my age, or to
| understand how things are now".
|
| Why the opposite occurs: "They're still too young to
| understand how life works yet".
|
| Why people of very different cultures tend to be
| prejudiced: "Their kind are ignorant of how the world
| works", and the opposite: "They've never been through
| what I've been through, they don't understand me or
| mine".
|
| All of these statements evaluate down to: "If they were
| more like me, they would be reasonable". Which is of
| course true, if "they" were more like "you", their
| systems of reasoning and value be more similar to yours,
| and vice versa.
| nine_k wrote:
| Indeed, this is exactly how web chats worked in late 1990s,
| except for the use of WebSocket (they used infinite load
| instead). They even seem to revive frames, another staple of
| 1990s design!
| csixty4 wrote:
| I'd take it back even further:
|
| We started out on mainframes.
|
| Then things moved to the desktop, with some centralized
| functionality on servers (shared drives, batch jobs).
|
| The processing moved to centralized web servers via the web,
| SAAS, and the cloud.
|
| Then more moved into the client through React & similar.
|
| And now things are moving back to the server.
|
| Tick. Tock.
|
| These changes are not just arbitrary whims of fashion, though.
| They're driven by generational improvements in technology and
| tooling.
| ballenf wrote:
| I got a chuckle out of Apple M1 chip touting having shared
| video memory as a big step forward. (Which it is, but is
| still amusing to me how it might have sounded like a
| groundbreaking innovation to a layperson.)
| mywittyname wrote:
| Apple takes Cue From Original Xbox with Latest Chipset.
| hugi wrote:
| Or; Apple takes cue from own Macintosh IIsi from three
| decades ago?
| cleaver wrote:
| Yes. I have thought about this a lot. There are cycles...
|
| Like thin client (VT100), to thick (client/server desktop
| app), to thin (browser), etc.
|
| Similarly, console apps (respond to a single request in a
| loop), to event-driven GUI apps, to HTTP apps that just
| respond to a simple request, back to event-driven JS apps.
|
| It depends on how you define the boundaries, but history
| rhymes.
| exabrial wrote:
| Virtual machines, containers, very similar to partitions and
| spaces on mainframes as well.
| greenyoda wrote:
| Virtual machines are not a recent invention. They were
| already being used on IBM mainframes starting in the early
| 1970s:
|
| https://en.wikipedia.org/wiki/VM_(operating_system)
|
| Notably, the VM operating system could run an instance of
| itself in one of its own virtual machines.
| rvense wrote:
| Is it really a pendulum, or is it more that this was always
| an idea with merit that's now finally seeing wider adoption
| because it's become more widely available? (In part, I
| understand, due to some IBM patents that expire 10 or so
| years ago)
| madmulita wrote:
| And serverless is an anemic CICS executing non-
| transactions.
| dsego wrote:
| Serverless is kind of like Apache running PHP scripts in
| virtual hosts.
| vp8989 wrote:
| The greatest trick the devil ever pulled is convincing
| people that shared hosting is preferable to dedicated,
| and then charging them way more money for it.
| Hypergraphe wrote:
| I think the same.
| dasloop wrote:
| Every time the pendulum returns, it returns profoundly changed.
| And it returns because the changes makes the coming back
| possible.
| echelon wrote:
| So when and how does the p2p / distributed pendulum swing
| back? When do we stop using AWS mainframes for everything?
|
| I sense that you're right about swings requiring change to
| older techniques. But I think there's also a component of
| being fed up with the direction things are currently facing.
| cyrialize wrote:
| I completely agree with this. For reference, I'm a relatively
| new developer - 3.5+ years of experience in my first developer
| position.
|
| At the beginning of college everyone was SUPER into NoSQL. All
| my friends were using it, SQL was slow, etc.
|
| Nearing the end of college and the beginning of my job I began
| seeing articles saying why NoSQL wasn't the best, why SQL is
| good for some things over NoSQL, etc.
|
| Technology is cyclical. 10 years from now I expect to read
| about something "new" only to realize that it was something
| old.
| mywittyname wrote:
| The NoSQL trend was so terrible. Anyone starting out right in
| that time frame where mongo and other NoSQL DBs were getting
| popular was really done a disservice.
|
| I sit in design meetings all the time where people with <5
| years experience go out of their way to avoid using a
| relational database for relational data because "SQL is
| slow". They will fight tooth and nail, shoe-horning features
| in to the application which are trivial to do with a single
| SQL command.
|
| I helped out on one project lead by a few younger devs who
| chose FireStore over CloudSQL for "performance reasons" (for
| an in-house tool). They had to do a pretty major rewrite
| after only a few weeks once they got around to deleting,
| because one of their design requirements was to be able to
| delete thousands of records; a trivial operation in SQL, but
| with FireStore, deleting records requires:
|
| > To delete an entire collection or subcollection in Cloud
| Firestore, retrieve all the documents within the collection
| or subcollection and delete them. If you have larger
| collections, you may want to delete the documents in smaller
| batches to avoid out-of-memory errors. Repeat the process
| until you've deleted the entire collection or subcollection.
|
| > Deleting a collection requires coordinating an unbounded
| number of individual delete requests.
|
| Turns out, once they started needing to regularly delete
| thousands-millions of records, the process could run all
| night. Luckily, moving over to CloudSQL didn't take very
| long...
| combatentropy wrote:
| NoSQL is very much like the databases that were around in the
| 1960s ("navigational" databases, nested sets of key-value
| pairs). E. F. Codd proposed a database of tables (which he, a
| mathematician, called "relations") to solve a number of
| problems that these primitive databases were having, one of
| which was speed.
| notsureaboutpg wrote:
| I just have no idea why this trend got so popular because in
| my undergrad CS program, we all had to take a database
| fundamentals class. And once you actually understand _how_
| databases implement transactions, rollbacks, atomicity, etc.
| and when you use said SQL databases and see how fast the
| queries actually are, how in the world could anyone convince
| you that a non-ACID database with no defined schema is
| better?
| tamrix wrote:
| Sql has always been faster in querying. Faster in development
| though is another thing depending on the project and
| experience.
| ghego1 wrote:
| A while ago, way before SPA were cool and even AngularJS was
| around, I had done something sort of like this, based on Ajax
| calls though, so the underlying tech was definitely different.
|
| While this is truly clever and being based on sockets does seem
| to simplify communications between client and server, I'm not
| fully convinced.
|
| Currently I see client side rendering as a way to delegate some
| computing to the clients. Which is a nice way to lower operating
| costs.
|
| I can see the benefit of this and the reasoning behind it.
| Because SPA still need a server (serverless still implies server
| side coding) as long as you are executing code on the client you
| need two codebases. One for the client, one server side.
|
| With this solution it would seem that it's possible to serve a
| web app with only one codebase, so that's definitely a plus. But
| then performance and costs do preoccupy me a little.
|
| Perhaps the ideal scenario for this tech would be for
| (enterprise) apps to be deployed on proprietary servers, where
| scale is a minor concern.
| marcosdumay wrote:
| The one performance concern on distributed systems is on data
| coherence. You optimize it, and treat anything else as
| relatively free.
|
| Rendering (or anything else that you can choose to do on the
| server or the client) has no impact on data coherence. Thus, as
| optimization goes, it's something you care about less than
| nearly anything else.
|
| By the way, I have seen my share of really horrendous code
| though my life. Only twice I have seen something that isn't
| data coherence being a bottleneck to anything. Both times were
| really stupid bugs.
| fergie wrote:
| Gentlemen, we have come full circle.
| acabal wrote:
| I thought this had to be satire when I opened the page. Now I'm
| still not sure.
| rk06 wrote:
| I thought it was a joke. and completely ignored it when i
| first saw the headline. only later someone else referred to
| DHH's hotwire. it clicked me that it is the New Magic thing.
|
| I am still wondering if there is any benchmark presenting
| some objective facts
| therealmarv wrote:
| I'm also still not sure. Also thought this is satire.
| DrFell wrote:
| That's good, because I've been deliberately ignoring pop webdev
| technology in hopes this would happen.
| gassius wrote:
| Wait, we still need to add a cgi-bin to this
| bengalister wrote:
| cgi-bin has been rebranded serverless: running external
| processes to the web server.
| wnevets wrote:
| web development has jumped the shark, I thought this was a
| parody at first.
| jtms wrote:
| reminds me of the http://vanilla-js.com/ which is actually a
| parody, but also... not?
| ausjke wrote:
| SPA moves all the routing/templating to the browser side.
|
| server side rendering does it all on the server and spits out
| html(legacy cgi style)
|
| between these two: static html template downloaded from the
| server, then use ajax to update json in the html pages, which is
| the old boring way but it might still be the best middle ground?
|
| Unless I need make a desktop complex GUI program where SPA could
| be a reasonable choice, I will just do the html/ajax old way, not
| fully geared towards to server or client side rendering, life is
| much easier.
| 1f60c wrote:
| I wonder how long it will take before we reinvent SPAs?
|
| I like Hacker News in part because the tech is so boring. Server-
| side rendered, static HTML with a minimal amount of JS[0].
|
| [0]: https://news.ycombinator.com/hn.js
| freedomben wrote:
| I also prefer boring and love how HN works. That said though,
| modern consumers expect much more. We tech people like command
| lines, the ultimate in simple and boring. Modern consumers
| often want animation and things[1].
|
| Source: UI/UX researchers tell me this when I push back and say
| "let's keep the tech simple and forgo some of the animations,
| etc in the name of using simple OOTB stuff without hacking
| thousands of lines of JS together." Also family members will
| tell me the same things.
| matthoiland wrote:
| Consumers want electronic starters on their chainsaws - but
| they're less reliable, prone to error, more expensive, etc...
| in the end, us engineers gotta make products that people will
| buy.
| rorykoehler wrote:
| Do people really want that stuff out do they just think they
| want it?
| scythmic_waves wrote:
| If you have trouble selling a product without that stuff,
| does it make a difference?
| trog wrote:
| Do people think they want it, or do developers and
| designers think the people want it?!
| stopChanging wrote:
| Thanks for the link. I'm new to JS, but it seems funny to me
| how the first block of one-liner functions reads like it's just
| making up for how awful the JS standard library is.
| arvindamirtaa wrote:
| Hackernews, Crigslist, the old redddit (which is still VERY
| actively used). The list goes on.
| w_t_payne wrote:
| Reminds me of HTMX
| kurko wrote:
| You had me on "Oops"
| jarym wrote:
| I won't say this is a step backwards in terms of progress but it
| is a step back to the way things used to be done in the early
| days of Ajax - albeit with a slightly more modern approach.
|
| It is appropriate for some applications and not for others.
| That's just my view.
| CrazyStat wrote:
| I'm not really a web dev, though I've built a couple small
| (mostly static) sites.
|
| Could you expand a bit on what makes it appropriate or not for
| different applications?
| clementmas wrote:
| What's the browser support for Turbo? It uses the History API,
| fetch, AbortController, etc.
|
| So Edge 16+, Safari 12.1+, FF 57+?
| mmastrac wrote:
| What's old is new again. I recall ASP.NET had some interesting
| tech around this in the 2000s where it could dynamically update
| parts of the page.
|
| If I recall correctly, this made use of that new technology of
| the time called "XMLHttpRequest" (/s) which pretty much jump-
| started web 2.0.
| vittore wrote:
| good ol' ASP.NET 2.0
| axegon_ wrote:
| My thought exactly, though I fully support that. I often rant
| about how the modern web is billions of layers of duck tape
| over duck tape and it has become an unmanageable mess of
| libraries, frameworks, resources, all while javascript remains
| the most outrageous and absurd language ever created. I'm by no
| means a fan of rails or ruby for that matter but I think things
| like these are a considerably better alternative than all the
| ridiculous libraries and frameworks everyone uses, which result
| megabytes of javascript and require corporate-grade bandwidth
| and at least an 8-th gen i7 and at least 8gb of memory to open.
| And all that to open a website which has 3 images and a contact
| form. I mean someone should create a package that analyzes
| websites and creates a minimum requirements manifest. It's good
| to see that there are people who are trying to bring some
| sanity.
| ithrow wrote:
| Javascript as a language is actually pretty decent these
| days, your criticism probably applies more to certain parts
| of the ecosystem.
| axegon_ wrote:
| No, I'm talking about js as a whole. Standard library is
| crap, inconsistent, even the most basic of naming
| conventions are not followed anywhere. The fact that the
| standard library jumps between camel case, pascal case,
| snake case and unicase at random is a perfect example. The
| list of absurdities is beyond ridiculous[1].
|
| [1] https://github.com/denysdovhan/wtfjs
| edoceo wrote:
| Who on this thread was saying what's old is new? 100% of
| what you said has also been lobbed at PHP recently and
| I've heard similar complaint about PERL and MS-SQL (that
| I remember well) and I'm sure others (one of those Delphi
| product too)
| mgkimsal wrote:
| What's been strange to me though is I've heard JS
| advocates lobbing those criticisms at PHP, making the
| case for, say, why 'Node is awesome, PHP sucks'.
| Conflating a framework vs a language, then pointing out
| PHP 'issues' that also exist in JS... there's generally
| little point in trying to engage/correct at that point
| (context: primarily conference hallway conversations and
| meetup groups back when those actually happened).
| rorykoehler wrote:
| JS is the new PHP. Part of the problem with massive
| popularity is it attracts also the lower ability devs and
| the ecosystem slowly degrades due to this. This cascades.
| cutler wrote:
| What standard library?
| fwip wrote:
| Surely your point could be made better without the hyperbole?
|
| "Most outrageous and absurd language ever," "Megabytes of
| javascript", "corporate-grade bandwidth", "8th-gen i7 and 8GB
| of memory" to open "3 images and a contact form."
|
| I'm sure you can find one or two poorly-optimized sites that
| have 2MB of javascript to download, but it's by no means the
| necessary outcome of using "ridiculous libraries and
| frameworks," and not even a particularly common one.
| [deleted]
| Nextgrid wrote:
| > it's by no means the necessary outcome of using
| "ridiculous libraries and frameworks," and not even a
| particularly common one
|
| The real world disagrees with you; go check out any major
| website and observe as your laptop's fans spin up.
|
| However I think the main problem here isn't the symptom
| (websites are bloated) but the root cause of the problem.
| I'm not sure if it's resume-driven-development by front-end
| developers or that they genuinely lost the skill of pure
| CSS & HTML but everyone seems to be pushing for React or
| some kind of SPA framework even when the entire website
| only needs a handful of pages with no dynamic content.
| kevin_thibedeau wrote:
| > one or two poorly-optimized sites
|
| Try every old media site and most e-commerce.
| rektide wrote:
| There is plenty of duck tape yes,
|
| But there is suprisingly little layers on layers. Part of
| what has been amazing about the web is that the target
| remains the same. There is the DOM. Everyone is trying
| different ways to build & update the DOM.
|
| Agreed that there are better alternatives than a lot of what
| is out there. We seem to be in a mass consolidation, focusing
| around a couple very popular systems. I am glad to see folks
| like Github presenting some of the better alternatives, such
| as their Catalyst tools[1] which speed up (developer-wise &
| page-wise (via "Actions") both) & give some patterns for
| building WebComponents.
|
| The web has been unimaginably stable a platform for building
| things, has retained it's spirit while allowing hundreds of
| different architectures for how things get built. Yes, we can
| make a mess of our architectures. Yes, humanity can over-
| consume resources. But we can also, often, do it right, and
| we can learn & evolve, as we have done so, over the past 30
| years we've had with the web.
|
| [1] https://github.github.io/catalyst/
| axegon_ wrote:
| If by surprisingly little, you mean 4 pages and 500mb of
| requirements for a "hello world" project with the "modern"
| web, then yes. The DOM has always been a mess, much like
| javascript. And the fact that no one has tried to do
| something about it contributes to the mountains of duckt
| tape. It was bad enough when angular showed up, but when
| all the other mumbo jumbo showed up like react, vue,
| webpack and whatnot is when it all went south. I refuse to
| offend compilers and call this "compiling", but the fact
| that npm takes the same amount of time to "compile" it's
| gibberish as rustc to compile a large project(with the
| painfully slow compilation that comes with rust by design),
| is a clear indication that something is utterly wrong.
| rektide wrote:
| Again, you are attributing to the web what a pop-culture
| is doing with it.
|
| While willfully ignoring all the people doing better.
|
| Maybe we are- as you fear- stuck, forever, in thick JS-
| to-JS transpilers & massive bundles & heavy frameworks.
| Maybe. I don't think so.
| AirMax98 wrote:
| npm does not compile, it is just a package manager. That
| said, I understand your frustration.
| ChrisLTD wrote:
| Preach! Websites don't seem all that much better to me than
| they did 10 years ago [^fn], so what are we gaining with all
| these much more complex and fragile tools?
|
| [fn]: Arguably, the web is worse with chat bots, sticky
| headers, and modals constantly vying for your attention.
| craftinator wrote:
| > Arguably, the web is worse with chat bots, sticky
| headers, and modals constantly vying for your attention.
|
| We can blame this on the MBA types. I've literally never
| heard a software engineer say "hey, let's make this pop-up
| after they've already been looking at the page for a
| minute!" or anything like it.
| rorykoehler wrote:
| Engineers typically aren't tasked with increasing
| revenue/engagement.
| Nextgrid wrote:
| Unfortunately I have to disagree - if there weren't any
| engineers around to implement the dark patterns they
| wouldn't be as prevalent. Maybe this calls for an
| equivalent of the Hippocratic Oath but in the tech world?
| rorykoehler wrote:
| Brick layers. Developers develop, designers design was
| more my point, though of course this line is blurred in
| many organisations.
| domano wrote:
| Just wanted to point out that it is called duct tape, just to
| avoid misunderstandings since i had a similiar spelling error
| as a non-native speaker :)
| edoceo wrote:
| Check out Gaff Tape as a replacement for the duct-tape at
| home use-case.
|
| And for actual ducts you'll want to use foil-tape because
| temperature changes wreck the adhesion of duct-tape, then
| the moisture leaks into the walls/ceiling which is $$$$
| bad.
| webmaven wrote:
| _> And for actual ducts you 'll want to use foil-tape
| because temperature changes wreck the adhesion of duct-
| tape, then the moisture leaks into the walls/ceiling
| which is $$$$ bad._
|
| This strongly depends on the type of duct. Flex ducts
| that are a plastic skin over a wire coil don't work so
| well with aluminum tape.
| DavidAdams wrote:
| Interestingly, waterproof fabric-based tape was originally
| called "duck tape" (for its waterproof quality). The same
| kind of tape was later also called duct tape, but it's
| actually pretty terrible for ducts. You want to use the
| all-aluminum tape for ducts.
| https://www.mentalfloss.com/article/52151/it-duck-tape-or-
| du...
| offtop5 wrote:
| I'm a native speaker.
|
| I use alot of Duck Tape .
|
| From the little language study I've done, English is one of
| the most flexible. You can discard entire parts of speak
| and it still works.
|
| Saying , ,'ey you woke up yet', is ok in many contexts.
| Igelau wrote:
| "Duck tape" originally referred to tape made from duck
| cloth. They started using it for duct work, and began to
| call it "duct tape", to the point where "duck" fell out of
| common use and was able to be trademarked. They've also
| stopped using it for ducts.
|
| So call it either one and people will know what you're
| talking about.
| dharmab wrote:
| This error is understandable as there is a popular brand of
| duct tape called Duck Tape.
| [deleted]
| recursive wrote:
| AjaxContentPanels or something to that effect. Those things
| were a nightmare. At the time, asp.net pretended to be stateful
| by bundling up the entire state of the page into "ViewState"
| and passing it back and forth client to server. Getting that to
| work with those panels was more work than just ajax-ing the
| content and injecting it with jquery.
|
| In the Microsoft-verse, this might also draw some comparisons
| to the more modern server-side blazor.
| mmastrac wrote:
| Oh yeah. I remember that ViewState could reach 100s of KBs on
| a page if you weren't careful. It was a huge juggling act
| between keeping state in your input fields vs ViewState.
| toddwprice wrote:
| <UpdatePanel /> see here: https://docs.microsoft.com/en-
| us/dotnet/api/system.web.ui.up...
|
| I used it 13 years ago. It was fancy.
| shireboy wrote:
| Glad I'm not the only one seeing that parallel. I'd be hesitant
| to use this for that reason, but maybe that's bias on my part?
| Just seems like you'd get stuck in a similar mess of "special"
| updatepanels aka hotwire frames that are trying to "save you
| from having to write javascript". Except it still uses
| javascript under the covers, so you still have whatever issues
| that may entail, only now it's more removed from the developer
| to be able to solve.
| hn_throwaway_99 wrote:
| Interesting bit of history (and yes, I see the /s),
| XMLHttpRequest was actually invented by Microsoft in Explorer
| because the Outlook team needed better responsiveness for the
| web email client.
| grishka wrote:
| Is this that web framework from Microsoft that hid the
| transaction-orientedness of HTTP from you by letting you set
| server-side click listeners on buttons and generated all the
| code needed to glue it all together? At the time, I didn't feel
| good about it because it abstracted away too much, and required
| Windows on the server. Little did I know about all the ways
| people would start abusing JS in 10 years.
| jack_riminton wrote:
| Most of the comments here are along the lines of: this is old
| tech!
|
| But this isn't really about the tech, it as much a productivity
| hack that allows people to be much closer to that old fashioned
| concept of a full stack developer
|
| This is what has allowed Basecamp to create Hey with a team just
| a fraction of the size of their competitors
| ljm wrote:
| Somewhere along the way Mythical Man Month was turned from a
| cautionary tale into a competition, and it only ever seems to
| happen once VC gets their mitts on a company.
|
| Does it really take a team of 800 engineers to maintain your
| fancy todo list app, rather than your focussed team of 10 or
| 20? What are all of those people doing except piling on
| organisational cruft so the business has no choice but to over-
| encumber itself with talent? Most of them aren't working on the
| product, that's for sure.
| notsureaboutpg wrote:
| At scale, yeah it does take a lot of people to do this. It
| has nothing to do with the type of app and everything to do
| with how business works.
|
| At scale you have huge enterprise customers with complex
| setups and they want to integrate your fancy todo list app
| into their setup and will pay you tons to do it. Your fancy
| todo list app suddenly needs to have all sorts of security
| certifications, needs to guarantee some type of uptime, needs
| to be able to integrate with all sorts of systems and other
| products (some of which none of your current engineers will
| have experience with). A new device will be released (think
| Apple Watch) and you're leaving money on the table if you
| don't hire some engineers to put your fancy todo list app on
| that platform along with the 5 or 6 others it's already
| maintained on.
|
| At scale, 1 in a million type bugs/problems come up every day
| and you need more engineers to deal with them.
|
| At scale, you are generating and producing (and thus need to
| be collecting and analyzing) an amazing amount of data, which
| should be used to better your product, learn about your
| customers and try to grow your business into providing other
| products and services your customers want / need. All that
| data collection, storage, and analysis requires more and more
| engineers.
| jack_riminton wrote:
| Yeah somewhere along the line people confused success with
| the amount of money you've raised and the number of people
| you employ. This just incentivises complexity
| ivanhoe wrote:
| It's a productivity hack for companies that have more backend
| devs that strongly prefer ruby to javascript, like a presume
| basecamp team is... AFAIK this doesn't apply to the average web
| dev teams nowadays, most of whom never even used ruby before...
| jack_riminton wrote:
| Yes funnily enough a Rails feature will only help those who
| code with Rails
| mrtweetyhack wrote:
| json payload is much smaller than html
| dperfect wrote:
| Is this the "new magic" that DHH teased on Twitter, or are we
| still waiting to see what that is? Also, should we expect this to
| be included in a future version of Rails?
|
| My first impression is that the API seems a little convoluted,
| but that might just be me. In an ideal world, I'd love to just
| build components (similar to React components) on the server
| side, and let the framework intelligently handle synchronizing
| state over the network (Phoenix LiveView seems closer to that),
| but this feels like it involves a lot more framework-specific
| logic (and markup) with special cases - stuff that's likely to
| change as the framework evolves, so I'm not sure how I feel about
| it.
|
| I guess it makes sense in terms of making this easier to add to
| an existing rails app incrementally (since it's more-or-less
| "opt-in" for each model, view, and controller), but if I'm
| building a new project with this and want it on everything, it
| feels like it will necessitate a lot of code duplication. Either
| that, or I use it judiciously only when absolutely needed (and
| use traditional rails behavior for everything else), but that
| feels like a mess of two very different approaches bundled
| together in one codebase.
| pdxandi wrote:
| You should check out React Server Components.
| arvindamirtaa wrote:
| Yes this is the new magic stuff.
|
| But I doubt they'll integrate this into Rails. They'll just
| create better and better tooling to make using this with rails
| a cinch.
|
| I think this will just remain backend agnostic, like turbolinks
| and stimulus were before "hotwire".
| simonw wrote:
| Yes, this is the "new magic".
| rajangdavis wrote:
| A few years ago, I had this bright idea of updating a site I
| maintained to be a single page application (SPA). I was very
| inspired by this site
| (https://pocketjavascript.com/blog/2015/11/23/introducing-pok...)
| and thought it would make the user experience a lot better by
| making the site easier to navigate.
|
| I preloaded data such that a user could navigate via search or
| clicking through some drill-down menus without having to wait for
| a full page refresh. The data would hydrate the views so that the
| transition time between views was almost always fast, even on
| slow mobile traffic.
|
| One aspect that was very difficult to figure out was
| incorporating views that would require more data from the server.
| Once a user drilled down to such a view, the challenge became how
| to load the view via AJAX without having to make another AJAX
| call to load more data.
|
| The solution was to return server side rendered HTML instead of
| JSON...
|
| Looking at the demo, this seems very similar to some of the
| things I had to do minus 95% of the hacky Angular/PHP code I had
| to set up.
|
| This is a killer feature to have in Rails and I am looking
| forward to learn more of the conventions that will surround the
| implementation.
| arvindamirtaa wrote:
| >This is a killer feature to have in Rails
|
| Hotwire is backend agnostic.
| saltcod wrote:
| This all seems super cool, but mega complicated. I'm not in the
| Rails ecosystem at all, so would love someone's assessment.
|
| Is this a new, giant complexity or a nice add-on? A huge
| mental/development shift or a nicely paved new path to something
| better?
| Trasmatta wrote:
| > mega complicated
|
| I would argue it looks a lot simpler than the average SPA
| framework or library.
| davish wrote:
| If you're used to SPA-style frontend development with React,
| Vue, or any similar framework, then yes, this will probably be
| a big mental/development shift.
|
| Turbolinks (the project at Basecamp that Hotwire grew out of,
| now it seems it's called Turbo Drive) was a way to bring
| single-page style load times to traditional, server-rendered
| apps. Hotwire is the evolution of that: Turbo Frames let you
| dynamically replace certain parts of the page on the frontend,
| rather than having to throw the baby out with the bathwater on
| every page action. If you're used to developing server-rendered
| applications without much JavaScript using Ruby on Rails,
| Django, or a similar "batteries included" backend framework,
| then you'll be able to add a more dynamic feel to your web app
| without much of a mental shift: certain template partials
| (basically the components of your frontend) will be wrapped in
| this `turbo-frame` HTML tag, which will be slotted in to your
| page dynamically by Turbo.
| jack_riminton wrote:
| I'm in the Rails system so this seems like blissful simplicity
| compared to the React/redux/typescript/whatever else is new
| this week world
| dsego wrote:
| More complicated than having to deal with auth, routing,
| validation, xhr, application state, business logic in an SPA?
| And write your endpoints again with another round of routing,
| auth, validation, business logic. And then integrating
| everything.
| eecks wrote:
| I agree. This seems complex but I am NOT a rails developer. The
| least complex stack I can find is Svelte (with Sapper) on the
| front end that calls out to API made in Spring Java.
|
| That lets me have quick development on the frontend, server
| side rendering for fast first page load and use of a typed
| language for the backend. The client is also overburdened with
| a large JS framework.
___________________________________________________________________
(page generated 2020-12-22 23:00 UTC)