Document? Library? A new kind of component? Microsoft had a hard time explaining what its Fluid Framework is An intriguing technology preview at Microsoft's just-finished Build event is Fluid Framework – but the company has not done a great job of communicating what exactly it is. Microsoft opened up on the Fluid Framework a year ago at Build 2019. It is presented as a feature of Office 365, by which document components such as …
What the arse do we need this crap for? Sounds like poncing around with fonts and layouts to me. I never had a word processor on the Dragon 32, but I had an Amstrad PCW 9512??? something or other with a daisywheel printer and that was fine. I even did a bit if DTP on the Atari ST and of course once I moved to PC was able to write with much swisher applications. I get that you might want to update one type of document embedded in another, this has been around for years.
What is my point?
Well we have users that do not know the difference between a template and a document (e.g. docx vs dotx) and so the chances of them getting to grips with this "fluid" is a big fat zero.
Is this going to change the world? No. They would be better spending time fixing the multitude of problems with Windows 10.
interesting point - I started reading that and saw this: "What drives me crazy is that ever since my first job I’ve realized that as a developer, I usually average about two or three hours a day of productive coding".
It is generally my own practice to bill one of two ways: a) I'm on site and it's "on site time"; b) I'm at home and it's "when I'm productive" time. I can generally get a full week in with 'b' but sometimes must do 'a' to satisfy a client''s need. So I end up working "in spurts" when doing 'b' and it's quite effective to go for 2-3 hours, play some video games, get back to it, etc. until you've done your hours... but I digress.
So this is a typical "productive day" for a Micros~1.DEV ? And the article might say it all, it took him WAY too many paragraphs to get to the point. "A little every day" is interesting, but if his day starts with web surfing while "on the clock" his manager should restrict his browsing hours (or NONE at all).
There must be a ZILLION alternate projects at Micros~1 that people could volunteer for during those "think about it" periods that we all get. A prioritized list might help. Go down the bug list and submit a patch. That's a good start. Audit a function from the list of things that need an audit. Then get back to your normal assignment and you might have NEW inspiration. But then again, that's how I try to do things. Juggle mutliple projects so you can "stay manic" and pound out code all day long.
Even better, hybrid office/home work. Go in for 4-5 hours, to beat the traffic but make the meetings, then take it home with you for 2-3 hours a day. [that works VERY well for me when I need to be on site]. Surf the web while you drink coffee at the start of the day, check mail to see if anyone has a particular issue, drive in with MUCH lighter traffic, maybe think about stuff from morning mail, arrive, do meetings and get things done, leave before 4, drive home in relatively light traffic, then arrive home, read 'The Register' and comment on a few things, then finish up your day while eating your dinner and don't spill it on the keyboard....
A nice PRODUCTIVE day, where you're actually doing WORK for the hours you're being paid.
(pirate flag for being such a PRIVATEER, harrr)
Admittedly with the 'work at home' part, the ability to collaborate on documents now becomes a LITTLE more important. but chances are that you could do that BETTER by sitting in a room at lunch, with plates of sandwiches and with 2 or 3 people standing behind the fastest typist (or with the monitor contents on a projected screen), going over the collab document one part at a time and letting "that one guy" do the typing and combine things, fix it, etc. while you discuss the contents and "collaborate" the old fashioned way.
yet more client+bandwidth expensive "but light on the server" bloatware to ruin productivity for MOST things while claiming "uber-flexibility" to a targeted niche of customer 'wants' [not necessarily 'needs'], using (of course) JAVASCRIPT.
At least, that's what it sounds like to ME. I was LESS than 'unimpressed' with Google Docs and their alleged ability to do the same thing with their on-line editor (using JavaScript in a browser) that performs like a pregnant elephant in a tutu.
What is it about these "developers" and their OBSESSION with CLIENT-SIDE JAVASCRIPT? it's not "a solution"... more like THE PROBLEM with "online anything" these days.
And just how often are multiple people trying to edit the same document at the same time anyway? Normally a collaboration has people sandboxing their own stuff, and an "editor" or supervisor combines it all. I expect that online latency issues affecting the ability to even EDIT the thing are going to be worse for getting stuff done than doing things "the old fashioned way".
It's worth pointing out that we have methods that are well defined for working with source code in a programming environment. Perhaps using THAT approach makes better sense, when working on a collaborated document, provided that you bust it up into "work units" or similar so that .the results can be later combined by "the editor" responsible for it.
Most .NET developers also know Javascript. Because .NET is very popular for web applications and JavaScript is essential for client-side scripting on web applications (at least for now).
Additionally, and this may come as a shock to you. Good developers can pick up new languages and frameworks pretty easily. It's not like those crusty old IT guys who freak out every time a Windows patch comes out.
"JavaScript is essential for client-side scripting on web applications"
If it can't be done with just CSS and HTML5, or on the server end, you probably shouldn't be doing it on the client side. My opinion. But yeah no doubt C-pound devs are familiar with JavaScript, especially because C-pound was originally derived (like JavaScript was) from Java...
"If it can't be done with just CSS and HTML5, or on the server end, you probably shouldn't be doing it on the client side."
Ugh. This again.
The example I used last time was sorting a table by different columns. It is trivial. It shouldn't require a full HTTP round trip. Without Javascript, you are effectively doing the HTML-only calculator again. NO.
Don't get me wrong, many sites go over the top, how much script do you really need to show a page that is just text and images (with perhaps a few flourishes)? You *needed* JS for different screen sizes before CSS caught up.
However, this draconian "Web Pages shall only *ever* be text and images forevermore" bullshit belongs to the days of RealPlayer.
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
