231–240 of 259 posts
Earlier quoted context omitted.
I would call the Hey UI and UX straight out of 2007. Opening an email requires a page reload.
Why is either of these a bad thing?
It’s opinionated nitpicking, not scientific analysis.
Earlier quoted context omitted.
I think that's holding SPAs to a higher standard than server side rendering. To compare apples to apples, you'd have to compare to the real world SSR app - think the average corporate intranet django monolith. Sure it's easier on client side network and CPU resources but the same engineers that create SPA monstrosities are the ones that create SSR monstrosities.
I don't think it's holding SPAs to a higher standard. It's holding SPAs to a reasonable expectation for SPAs. An SPA is significantly more complicated on the client side in exchange for some purported benefits, especially to the user (such as only downloading what you need). If everything is discarded on each "page" transition and re-downloaded again upon a return, and has the page-popping-into-place effect, that eli…
I think SPAs provide great benefits, but most users only visit a single page. So I would add that SPAs also tend to download more than you need (in JS) if it's something like a blog
I am a huge fan of server side rendering with progressively enhancing Javascript. It simply feels right to me: * Search engine indexing works as expected. * Informational web pages don't need a lot of interactivity anyway. * You don't need crazy amount of build tools. * You don't need extra browser extensions just to debug the JS. * If for some reason there's one JS error, most of the pages are still functional. * I…
Are you building an app? if so build an app. All UI is static hosted on CDN with content based urls that can be cached forever and all dynamic data coming in purely via REST apis.
If you are building a website, then serve html pages with sprinkled widgets here and there for interactivity.
Don't conflate the two. Users don't mind a slightly slow first load but super fast subsequent loads for an app. They'll love offline/PWA support, something that behaves like a native app. Search engines shouldn't care about indexing apps.
Web pages should behave like web pages. Search engines expect html as the format. Users expect the first load to be blazing fast. Proper href links, yada yada.
The worst is when its a half assed slow loading web page that wants to be an app, but is not an app.
Earlier quoted context omitted.
I don't know if I could go back to not having transactional DDL, partial and function-defined indexes, non-blocking ("concurrent") indexing, and so on...
I'm not sure where I suggested "Hey, long time Postgres users, you should switch to MySQL!". The point is it's a solid modern database and a completely fine option in 2020. MySQL8 supports functional indexes and concurrent indexing fyi. It still does not have transactional DDL nor partial indexes.
This is really the bit Rails was lacking for a long time. JS always felt like a second class citizen in Rails before, but webpacker finally brings the two worlds together in a way that makes sense. And with Stimulus, I actually find it a joy to write well organized js that is easy to reuse across my app. It's minimal, but just opinionated enough to keep me from mucking things up badly, the way I did in the asset pipeline days.
I wish Stimulus got more attention. It really is all most web sites need, and it works so well with the well proven Rails way of server side html added to judicious js. It's also a good tool to use as glue while you migrate legacy js over from the asset pipeline, you can just load your old js in a Stimulus controller and go.
I kind of wish Basecamp would promote it more, maybe even optionally bundle it with Rails, because it really is the missing piece that almost any Rails app could take advantage of. Having a little more guidance here would really help new Rails developers :)
Earlier quoted context omitted.
Why is either of these a bad thing?
I’m not complaining about it. I paid the $99. I’m pushing back that it’s a modern UI and modern UX. It works, but from my perspective it’s pretty ugly and dated. It’s opinionated nitpicking, not scientific analysis.
I will be very interested to see it after a year of polish however.
Noteworthy how they tout the success of their "magic" frontend stack made with vanilla JS, lack of a trendy framework, etc. But if you use the app, the UX is fairly laggy, requires frequent refreshes, all the animations and interactions are off - the list goes on and on. It's noticeably subpar (and I like Hey). Seems to me that the proof is in the pudding wrt their stack, but it's probably not what they wanted to pro…
They are using Turbolinks. They generate everything server-side and then Turbolinks calculates the delta between the existing loaded template in the client and the incoming template generated in the server and injects only the changes. This has a lot of advantages, mainly that you don't need to care about state on the client side and you're always synced with the real estate on the backend. It has one major drawback…
I've switched to Stimulus since seeing a presentation on it at last year's Railsconf and it has been a real joy to use. This is really the bit Rails was lacking for a long time. JS always felt like a second class citizen in Rails before, but webpacker finally brings the two worlds together in a way that makes sense. And with Stimulus, I actually find it a joy to write well organized js that is easy to reuse across my…
What I think is even more significant than Hey’s backend stack is its _frontend_ stack. There’s no complex JavaScript framework; it’s all server side rendered HTML with a few touches of lightweight JS (mostly Turbolinks and StimulusJS, afaik) on the client to add basic interactivity. And it feels just as fast—if not faster—than any other modern, well-built web app. It goes to show that libraries like React and Vue ar…
I would call the Hey UI and UX straight out of 2007. Opening an email requires a page reload.