I'd say Teams is NOT a chat tool. You can find on the web many pieces of critique towards Teams as a chat tool and most of them have a lot of merit to them.
Teams is good at what it does and serves its niche well, however unless your daily matters are not well aligned with the particular framework Teams is designed for expect significant friction. It's not really the team size that matters, but rather how you structure your daily work.
A lot of the power of teams comes from integration with Active Directory, Sharepoint and Office. Sharing a presentation in a meeting that viewers can browse (e.g. to check back on something in a previous slide), calendar syncing with scheduling assistant, meetings scheduled in a team, meeting recordings and recaps, linking directly to a single page in OneNote, etc. are all quite powerful features, but most of the power is relevant if your organizational matters are structured more or less as a traditional enterprise and around AD/Office.
Inviting third parties or contractors can be quite a pain, especially if chat history is relevant. Meetings having their own chat can create information searchability issues. Integrating with third party tools is less straightforward and consequentially ecosystem of integrations is a bit of wasteland.
Look over quick starts of React and Angular, for example. One is a well structured application, the other is a spaghetti script, all held by magic and conventions.
If you recall the (in)famous "PHP: a fractal of bad design", React basically ticks every box in this rant and then some. It's not surprise knowing it's origins, but still.
The reasons React has got traction are the same reasons PHP got traction or web frontend dev in general and have nothing to do with being well designed: it tries to "render" something visible, which makes early adoption much more interactive (hey, I've changed one line and now instead of 15 errors I have 25 different ones and the text moved!), however at the cost of any shot at long term maintainability. Before someone comes and tells me React is just a tool and you can make good products with any tools I encourage you to look at all the headliner star projects by Meta: if they cannot make websites in React at least somewhat functional and stable, no one can. Google headliners built with Angular, for all their warts, are at least for the most part functional.
> If you recall the (in)famous "PHP: a fractal of bad design", React basically ticks every box in this rant and then some.
I dare you to walk us through that blog post and explain to us in detail how React "basically ticks every box".
Not only does React not compare to PHP in the slightest, I also find this comparison rather wild because other web frameworks rank so much higher than React on the "quirks & arcane code you need to understand" scale. (I have PTSD from Angular and Vue in particular.)
I guess it's all subjective, but I'll take learning a new Angular codebase over a React one any day of the week and twice on Sundays.
That's simply because you learn Angular once, and then you learn the half dozen things that can differ between projects, and then you know how it works. For React, every project has its own stack and conventions.
I probably won't disagree that the ceiling for a good React project is higher than that for a good Angular project, simply because you have more freedom to make good decisions. But in the same vein, you also have more freedom to make bad decisions, and most people tend not to be very good at making these kinds of decisions.
Angular: Where is the code for the <foo/> component that is used here? Anywhere in the codebase, maybe defined multiple times, depending on module configuration one or another may be used. Good luck finding which one.
React: Where is the code for the <Foo/> component that is used here? Either defined in the same file or imported, like any other javascript thing.
In modern day Angular, everything is standalone, so the module issue doesn't apply.
I've been coding in Angular since 2 and I have never had a duplicate component with the same name. Almost every Angular app uses nearly the same folder structure.
> because companies work around them by replacing full-time roles with contract positions, something that's much harder to regulate.
Yes, then a regulator sniffs on that, company is unable to prove absence of employment-like relationship, then is fined and owes backpay on all the unpaid taxes with interest.
Yes and no. Natural language processing querybox will be one of the interfaces for two reasons: some people already (still?) associate that with trustworthy search, however since it is like "I'm feeling lucky" button it is perfect place to hide paid advertisements.
On the other hand, your PO dismisses the value of windowshopping and I don't see good catalogs disappearing anytime soon.
While there is some truth to your comment, it has no practical engineering relevance. Since energy transfer rate is proportional to temp difference, therefore you compute the flow rate required, which is going to be different if the chips are in series or in parallel.
If you're heating up the water by 10 or so degrees on typical computer hardware, I bet you're not bottlenecked by energy transfer. Your flow rate is based on how hot you want the water to get, so series or parallel goes back to not mattering.
It's never either/or: you don't have to choose between white and black lists exclusively and most of the traffic is going to come from grey areas anyway.
Say you whitelist an address/range and some systems detect "bad things". Now what? You remove that address/range from whitelist? Doo you distribute the removal to your peers? Do you communicate removal to the owner of unwhitelisted address/range? How does owner communicate dealing with the issue back? What if the owner of the range is hosting provider where they don't proactively control the content hosted, yet have robust anti-abuse mechanisms in place? And so on.
Whitelist-only is a huge can of worms and whitelists works best with trusted partner you can maintain out-of-band communication with. Similarly blacklists work best with trusted partners, however to determine addresses/ranges that are more trouble than they are worth. And somewhere in the middle are grey zone addresses, e.g. ranges assigned to ISPs with CGNATs: you just cannot reliably label an individual address or even a range of addresses as strictly troublesome or strictly trustworthy by default.
Implement blacklists on known bad actors, e.g. the whole of China and Russia, maybe even cloud providers. Implement whitelists for ranges you explicitly trust to have robust anti-abuse mechanisms, e.g. corporations with strictly internal hosts.
There is a reason we tend to call "the new internet" "web 2.0": it's dominated by platforms. For better or worse, the dynamics are entirely different. In the new internet interactions are facilitated by the algorithm, whereas in the old internet it was a web of peers.
Funnily, a substantial amount of interaction over the past some years has been shifting back to private, invite-only spaces, e.g. private Discord servers. Being old farts without real-world contacts in those spaces we are getting left out a bit, not too dissimilar to the old farts of yesteryear.
Web browsers from 90s can render html perfectly well.
> if a website cannot "do" it, you as a user of the site, won't be able to experience it
Ever heard of native applications? Those could always do the thing, there is not only no reason for web browsers to implement "web apis", but every one of those is actively harmful.
When "web developers" can finally implement a page where focus does not jump around and layouts do not shift around we can start talking about being allowed access to more than plain html.
Native applications is a relatively fragmented market of different hardware and OS for platform, made more complicated by relative lack of interest (which is because the market is fragmented, a catch-22), and factors like needing to learn another programming language when you already know JavaScript and how it works on the Web, which is taught to more people every year for obvious reasons. Which is all why Github Electron, essentially a Google Chrome married to Node.js, both _JavaScript_ platforms, made such an impact when it was released. There's zero-install on the Web, too -- just follow a link and you're surfing applications. Python+Qt applications have to be installed, even if that means downloading these -- there's plenty of hosts configured to deny the user the privileges of running software they downloaded, no matter how native and how well mannered it is otherwise. There's fewer pairs of hands on the job (part of catch-22), and there's more standards and APIs to deal with, due to the fragmentation, even for all the cross-platform offerings. All this no doubt contributes to the market staying behind the juggernaut that the Web has become.
Before you roll your eyes and label me a millennial who's not seen anything but the absolutely appalling Web applications of yesteryear, fresh off inexperienced hands of developers who think they invented caching and what not -- I started off with x86 assembler and C then C++ in early 90's, and I hold genuine interest in everything we learned since before Intel made 8088 -- but I am simply describing the reality I see, not necessarily reality I want.
You're drawing a border on water -- there's no need to "separate" the Web from native. The Web is an application platform developed from a hypertext network (the old Web I re-label for comparison's sake), and the platform has tremendous value. You need to have tunnel vision to want to put genie back into the bottle, but again -- I absolutely hear and understand your argument. Do you have realistic suggestions?
Drew DeVault suggested another protocol, Gemini, a while back, having become frustrated with much the same observation you did. Just text mark-up served with efficient text-based protocol -- essentially a regression back to HTTP and HTML anno 1995 (possibly with more semantic elements). I think it's not only a fantasy but also a poor idea -- not because it's a bad idea in itself but because it assumes there's no possibility to do any of it with today's Web, but there is -- it's just that everyone's reaching for the fancy and the flashy once they start coding. What you were referring to with "focus jump around" and "shifting layout". We're sacks of flesh driven by hormones -- that's the best reason I can give you why the same platform that allows you to slap [a HTML that's worth reading](http://motherfuckingwebsite.com/), possibly [with a simple stylesheet that does the bare minimum to improve user's experience](http://bettermotherfuckingwebsite.com) -- is _not enough_ for authors. I'd call it "author's prerogative" -- the person who pays for the domain and the hosting, wants to exercise their authoring power and gets carried away with all the bells and whistles they slap on their pages. Users pull their hair out, in silence (or mostly ignored because "do I paint the walls in your house?").
Anyway, this is getting long -- the gist of my argument is that technically the Web is capable of supporting all the static HTML without an ounce of "shitty" scripting that makes everything border on "unconsumable". You're making a "dictatorship" argument along "if you can't make good readable sites, we're going to neuter the platform". But the platform _is_ what drives adoption of the Web, I say, albeit now nearing some cancerous growth from a skeptic's perspective. And yet: fix the _content_, not the _platform_. "Native" is just a word -- there's no native, everything is translated or compiled one way or another, including JavaScript (which _I_ consider a relatively bad general purpose programming language, even under ECMA oversight which fixed a lot of its warts, admittedly). Unless you're one of those ["real programmers"](https://xkcd.com/378/).
Fitting the entire problem domain in their head is what engineers do.
Engineering is merely a search for optimal solution in this multidimensional space of problem domain(-s), requirements, limitations and optimization functions.
Teams is good at what it does and serves its niche well, however unless your daily matters are not well aligned with the particular framework Teams is designed for expect significant friction. It's not really the team size that matters, but rather how you structure your daily work.
A lot of the power of teams comes from integration with Active Directory, Sharepoint and Office. Sharing a presentation in a meeting that viewers can browse (e.g. to check back on something in a previous slide), calendar syncing with scheduling assistant, meetings scheduled in a team, meeting recordings and recaps, linking directly to a single page in OneNote, etc. are all quite powerful features, but most of the power is relevant if your organizational matters are structured more or less as a traditional enterprise and around AD/Office.
Inviting third parties or contractors can be quite a pain, especially if chat history is relevant. Meetings having their own chat can create information searchability issues. Integrating with third party tools is less straightforward and consequentially ecosystem of integrations is a bit of wasteland.
reply