> The client-side JavaScript application is developed, built, and tested with many open source libraries including React, Redux, Normalizr, Globalize, Babel, Webpack, Jest, WebdriverIO, and Yarn.
In React Native, you don't have the standard DOM elements since you're not working in a DOM, so it provides some standard elements that get turned into native components (Button, Text, etc). It looks like this is porting those components back to the web. Sounds silly at first, but looks like it can be useful for RN shops.
This comment is getting downvoted but if it's true, it's absolutely a good point. They are optimizing for what is inherently slower: loading JS in the client before anything can be seen or interacted with, rather than rendering HTML and forms so one doesn't have to wait for JS to compile and execute (and all the tracking bloat that comes with it).
It is not true, the slow part of web applications is loading over the network, server side rendering puts a dependency on the network and is therefore vastly slower.
With service workers and client side storage you can get to display at least a shell, sometimes the entire UI without touching the network. It is a lot faster
Where do you think that JS in a web page comes from? Not from the network?
Service workers are a cache (and background process), and you still have to consider cache misses. Even if you have a giant JS app and cache it, users still have to download all the JS to actually work offline no matter what.
IMO installing this alongside third party twitter apps will make a great combo for push notifications alone. My preferred app just refreshes all notifications hourly, which is obviously worse than the official app.
This is much better then the bloated main UI. But I'd wish an option for an even lighter HN like interface. It still doesn't look to good in a text browser like elinks. One or 2 lines per tweet max would be ideal. That and a rss/atom feed that can be fed into the matrix network and clients.
Originally it was a listing of 140c messages, ideal to quickly view the status of your friends to enhance social proprioception. Since then it unfortunately morphed into a bloated, marketing oriented and visual distraction party where it mostly serves the look at me and commercial agendas. Authenticity, tele-awareness, social proprioception and efficienty flew away with the original twitter bird. Did he have a name? Is he coming back one day?
I was just thinking why not go the extra mile, I'd pay for using this though 1$/month - but I could also make it myself through tampermonkey or the api
I'd pay a bit to use twitter. What I'm concerned about is that I'd like something comparable to "reddit gold" - a means to pay for other people to use twitter so they can continue to post there for my and others' benefit.
It might only be alpha phase, but why not give it a shot? I'm not the developer for that, but am a happy user of the matrix protocol. Also, there are plenty of users leveraging matrix with several other bridges as well such as irc, slack, gitter, etc.
It's impressive how much faster it is on even a recent laptop on broadband (admittedly I'm "only" on DSL broadband, not fiber). You now click on a username, for example, and you get their page almost instantly. While on normal Twitter, there's a noticeable half-second or so lag for the transition to load and render.
You might LOVE the paginated, minimal javascript version you get if your user-agent is an older mobile browser like "Opera/9.80". You can use https://addons.mozilla.org/de/firefox/addon/uacontrol/ to set that just for mobile.twitter.com.
This is going to sound negative, even though I'm glad this is here:
How did we arrive at a time where it is news-worthy to launch a non-bloated service client?
Or to phrase it differently: What is the claimed consumer gain of a bloated client?
More like this please. It feels like going back in time when I first tried a 100Mbps connection in the late 90s and all the web content was made to accomodate DSL and modems.
I support your idea that software is often bloated.
However, as usual you're doing the mistake of somehow thinking that you are a customer of Twitter's. Of course you're not, since you're not paying to use the service.
That turns things around so that you're the usual ad target product, meaning the app might swell to contain more candy to tease you into clicking, and so on.
Uh, and just to be clear I'm not meaning "you" in a very personal sense, this applies to me too when I use Twitter, of course. :)
* I disabled UO, and I can see no ads on twitter, other than the occasional promoted tweet.
* Ads can be served very discretely (as pointed out above), and doesn't have to "bloat" a client from a sub-1MB to a 20MB app. Ads also doesn't have to adversely affect (much) how fast something loads.
A third point would be how much gain ads actually drive, but that's another discussion.
I love this. I was always frustrated by the ever-growing-in-size Twitter app. Which is around 105 Megabytes now (aka ~73 1.44 floppies). So I welcome this.
> Today, we are rolling out Twitter Lite, a new mobile web experience which minimizes data usage, loads quickly on slower connections, is resilient on unreliable mobile networks, and takes up less than 1MB on your device.
1 MB is “acceptable” by today’s standards, but when you think about it — 1 MB to display a few 140-character tweets?
Cmon, that's disingenuous. It does a lot more than just display a few text strings.
You've got routing, templates, event handlers, search, a lightbox, settings pages, the whole DM chat-style interface, the whole posting interface, and probably more that I'm not even thinking about.
Now I'm not saying that it couldn't be smaller - quite probably even substantially smaller. It'd be great to get it down to 100KB. I bet you could have a much smaller first load for just the feed, and then dynamically load in the JS for the other routes as they're requested. That could then be cached locally with service workers.
Edit: Looks like they do actually already do that. I just unregistered their Service Worker and refreshed - my load was ~300KB. Still kinda weighty but a lot less than 1MB.
> the app streams the initial HTML response to the browser, sending instructions to preload critical resources while the server constructs the initial app state. Using webpack, the app’s scripts are broken up into granular pieces and loaded on demand. This means that the initial load only requires resources needed for the visible screen. (When available, a Service Worker will precache additional resources and allow instant future navigations to other screens.) These changes allow us to progressive load the app so people can sooner consume and create Tweets.
It's because Twitter (the company) has no idea what to do with Twitter (the product), and are trying to branch out in increasingly dubious ways.
For comparison, Tweetbot is 7.6MB and Twitterific is 10.3MB (both on iOS), and they provide a much nicer experience for using Twitter than the official app.
Answering my own question, I just unpacked the iOS Twitter client thinking that it must contain massive graphic resources or something. Nope: mostly frameworks, the biggest being the T1Twitter.framework - 80.1Mb of who-knows-what.
That doesn't include the 17 other frameworks all over 1Mb in size (there are innumerable other smaller frameworks) for periscope and other features.
Seems to me they could ship a 5Mb app that just wraps the Twitter web site and provides iOS native experience (notifications, apple watch, etc) and call it a day.
I believe that, currently, if you iOS app uses any Swift code, you have to include the Switch libraries in your app. This has something to do with how quickly Swift has been changing, and Apple wanting you to reference your own library instead of the system one for now.
This has caused a number of apps to balloon in size lately, but the hope is that it is temporary.
As a user, that's totally opaque to me. I know my phone is running out of space and photos in general and Twitter in particular take up most of that space.
Tell me about it - Reddit's app does the same thing. I'll be browsing for an extended period of time and will get the "storage full" message. I then check usage settings and it's up over 600 (whereas normally it's ~200)
Seconding recommendation, but there are drawbacks: it's nearly impossible to read an entire thread by a person, and sometimes even seeing the chain of parent tweets is difficult.
That is an unfortunate limitation of the Twitter API for 3rd party clients. I've heard that the new way threads are presented on the Twitter website is also terrible.
Not only it's big, but it's a bandwidth hog as well... It's the most hungry app on my phone and I do a lot of web browsing on it. Twitter should not out-consume the web.
Well they can release something good after all. Look at the main Web UI. I don't know what they are thinking at Twitter. Its the most unintuitive UX I've ever seen.
E.g. :
Click on the Image -> Only the Image gets larger
Click on the frame around the image -> See the comments and Image is larger.
Yeah and only one of the options allows you to do a right-click and "save image as".
Quite frustrating because I take photos mainly with the Twitter app and later at home download them and repost them on Facebook... oh and you have to take care WHERE exactly you right-click because sometimes it will give you a compressed version and not the ".jpg-large" version you want... and then you have to rename the image so that other sites accept it for upload.
It's great to have a less bloated site, but it still uses the same UI which is only viable for the most basic usage. The thing I want improved the most is list viewing and management. Right now the only good way to view lists is tweetdeck which only really works on desktop.
If you click on your profile avatar image you can access your lists.
From that point, you can use the url for a specific list as your entry into "Twitter". So in some ways, the use of lists is better than the mobile app, because they are URL accessible.
On mobile, if you "save to home" screen, then that icon becomes a one click way to get to a list.
164 comments
[ 4.3 ms ] story [ 192 ms ] threadfrom https://blog.twitter.com/2017/how-we-built-twitter-lite
OP probably assumed React Native was in the list.
With service workers and client side storage you can get to display at least a shell, sometimes the entire UI without touching the network. It is a lot faster
Service workers are a cache (and background process), and you still have to consider cache misses. Even if you have a giant JS app and cache it, users still have to download all the JS to actually work offline no matter what.
The font is also unreadably small, and there are no options to change font size.
Originally it was a listing of 140c messages, ideal to quickly view the status of your friends to enhance social proprioception. Since then it unfortunately morphed into a bloated, marketing oriented and visual distraction party where it mostly serves the look at me and commercial agendas. Authenticity, tele-awareness, social proprioception and efficienty flew away with the original twitter bird. Did he have a name? Is he coming back one day?
There exists a matrix-to-twitter bridge that I believe allows for this use-case: https://github.com/Half-Shot/matrix-appservice-twitter
It might only be alpha phase, but why not give it a shot? I'm not the developer for that, but am a happy user of the matrix protocol. Also, there are plenty of users leveraging matrix with several other bridges as well such as irc, slack, gitter, etc.
I would also like to use it on my desktop!
https://i.imgur.com/NfdM2sk.png
I wish we did not have to use such hacks though. And the normal mobile site has a huge header on my desktop, annoying.
How did we arrive at a time where it is news-worthy to launch a non-bloated service client?
Or to phrase it differently: What is the claimed consumer gain of a bloated client?
More like this please. It feels like going back in time when I first tried a 100Mbps connection in the late 90s and all the web content was made to accomodate DSL and modems.
However, as usual you're doing the mistake of somehow thinking that you are a customer of Twitter's. Of course you're not, since you're not paying to use the service.
That turns things around so that you're the usual ad target product, meaning the app might swell to contain more candy to tease you into clicking, and so on.
Uh, and just to be clear I'm not meaning "you" in a very personal sense, this applies to me too when I use Twitter, of course. :)
* I disabled UO, and I can see no ads on twitter, other than the occasional promoted tweet.
* Ads can be served very discretely (as pointed out above), and doesn't have to "bloat" a client from a sub-1MB to a 20MB app. Ads also doesn't have to adversely affect (much) how fast something loads.
A third point would be how much gain ads actually drive, but that's another discussion.
Wish I hadn't given away my 2007 twitter account for free.
1 MB is “acceptable” by today’s standards, but when you think about it — 1 MB to display a few 140-character tweets?
You've got routing, templates, event handlers, search, a lightbox, settings pages, the whole DM chat-style interface, the whole posting interface, and probably more that I'm not even thinking about.
Now I'm not saying that it couldn't be smaller - quite probably even substantially smaller. It'd be great to get it down to 100KB. I bet you could have a much smaller first load for just the feed, and then dynamically load in the JS for the other routes as they're requested. That could then be cached locally with service workers.
Edit: Looks like they do actually already do that. I just unregistered their Service Worker and refreshed - my load was ~300KB. Still kinda weighty but a lot less than 1MB.
From https://blog.twitter.com/2017/how-we-built-twitter-lite:
> the app streams the initial HTML response to the browser, sending instructions to preload critical resources while the server constructs the initial app state. Using webpack, the app’s scripts are broken up into granular pieces and loaded on demand. This means that the initial load only requires resources needed for the visible screen. (When available, a Service Worker will precache additional resources and allow instant future navigations to other screens.) These changes allow us to progressive load the app so people can sooner consume and create Tweets.
For comparison, Tweetbot is 7.6MB and Twitterific is 10.3MB (both on iOS), and they provide a much nicer experience for using Twitter than the official app.
If Twitter can write a webpage that provides the functionality in only 1Mb then what is in the mobile app?
That doesn't include the 17 other frameworks all over 1Mb in size (there are innumerable other smaller frameworks) for periscope and other features.
Seems to me they could ship a 5Mb app that just wraps the Twitter web site and provides iOS native experience (notifications, apple watch, etc) and call it a day.
I believe that, currently, if you iOS app uses any Swift code, you have to include the Switch libraries in your app. This has something to do with how quickly Swift has been changing, and Apple wanting you to reference your own library instead of the system one for now.
This has caused a number of apps to balloon in size lately, but the hope is that it is temporary.
It is unfortunate that apps can't dynamically link to standard swift libraries in the OS, but that still doesn't explain the other 150Mb of binaries.
[0] https://f-droid.org/repository/browse/?fdfilter=twidere&fdid...
https://www.apkmirror.com/apk/twitter-inc/
In the data saving settings sub category. The setting panel itself seems rather hidden.
E.g. :
Click on the Image -> Only the Image gets larger
Click on the frame around the image -> See the comments and Image is larger.
Quite frustrating because I take photos mainly with the Twitter app and later at home download them and repost them on Facebook... oh and you have to take care WHERE exactly you right-click because sometimes it will give you a compressed version and not the ".jpg-large" version you want... and then you have to rename the image so that other sites accept it for upload.
Sadly the Google stack (ionic, angular) is not so mature at this stage and twitter opted for the facebook stack.
From that point, you can use the url for a specific list as your entry into "Twitter". So in some ways, the use of lists is better than the mobile app, because they are URL accessible.
On mobile, if you "save to home" screen, then that icon becomes a one click way to get to a list.
Safari 10.1 tab loaded with https://mobile.twitter.com/home ~ 140MB RAM
Safari 10.1 tab loaded with https://sublevel.net ~ 40MB RAM (same as HN)