Hi HN – I'm one of the authors of this proposal. I'd like to clarify a few points here:
* Wikipedia is not becoming an SPA
* Wikipedia is not dropping support for non-js users
* This proposal is not about changing our current browser-support matrix[1] (which includes IE11 as a first-class target; Vue.js ecosystem still supports IE 11)
* This proposal is about changing the way we develop enhanced, JS-only features across our projects; many such features exist already, but they are written in jQuery and an in-house framework called OOUI
* These features will continue to be delivered in a progressively-enhanced way on top of the PHP-rendered baseline for the forseeable future. We are interested in how server-side rendering of JS components can integrate with this but we're still looking into how this might work
* We will continue to prioritize accessibility, internationalization, and performance in everything we ship
I don't think that Vue is "better" than React, but I think it has some features which are especially helpful in our progressive-enhancement, ES5 (for now, anyway) use-case. But it's great to have so many amazing tools to choose from.
Previously we've been using a framework we created in-house for complex JS features, but it's a product of an earlier era of the web and is increasingly out of step with the current paradigms in UI development. We think that one big benefit of moving in this direction is lowering barriers to contribution (both for new developers at the foundation, as well as folks in the wider community).
A deeper dive presentation into the move into OOUI (which started meaningfully plotting and happening ca. 2013) from storing state in DOM elements, and challenges implementing it: https://www.youtube.com/watch?v=T_CUN2o4faw
Team lead of Vue.js here. Clarifying a few points being raised in this thread:
- This does not mean Wikipedia is becoming an SPA. One of the reasons they picked Vue is because Vue can be used to progressively enhance a statically rendered page (just like jQuery, but with a declarative development paradigm), and it allows you to do so without a build step (while keeping the going-full-build-step option open).
- Wikimedia is not just Wikipedia. There are many other use cases across the Foundation where heavy interactivity is needed. Even within Wikipedia, there are cases like the editor / edit mode which can be considered non-trivial JavaScript applications.
- Adopting a new framework !== More JavaScript. Wikimedia already has an in-house framework which has become outdated and difficult to maintain. Adopting Vue allows the team to implement the same features with less code. It will shave off instead of adding to the bloat.
Sure, you can plug react components in a progressive way, but you still have to move the HTML into the JS file. And you certainly won't ship the babel behemoth to the client so, no JSX.
With Vue, you have a friendly migration path, with a style close to angular 1, if you need.
It's also awesome for prototyping or making quick and dirty projects.
Evan, every time I use Vue I can see how you pondered seriously those things. The docs are amazing. The API is full of little details that show you care (I smile every time I see you can do '.prevent" - "oh right, they though of that!").
It's not just a great product. It makes you feel the authors are your friends.
> The API is full of little details that show you care (I smile every time I see you can do '.prevent" - "oh right, they though of that!").
I tend to have the opposite reaction. I want a framework with a small API I can keep cached in my head. I don't want to worry about finding the magic switches to get it working the way I want.
I see that a lot in the JS world, "libraries over frameworks" and all that.
The result is that when you go from project to project, people solve the same problems, again and again, in a different way. And create their own custom abstractions, badly tested and documented.
Eventually, the API you could "keep cached in your head" lead to a system you MUST keep in your head because it's very hard to follow how things work and you need to remember it all to be productive. Debugging, extending and onboarding suffers.
Another consequence is that there is still no Django/RoR equivalent in JS. Building any medium size app is a total waste of time, doing the same boiler plate over and over for problems solved 10 years ago.
Everybody has a boilerplate one of course. Nothing is standardized, so the ecosystem is not reusable. Any pluggable library must carefully chosen, then be manually integrated in your own Frankenstein creature, not to mention you end up with a TON of dependencies.
Vue doesn't have a big API. I learned the entire of vue in an afternoon.
It took me 2 weeks to understand react, and much more to actually write decent code with it. Practically, react is very unproductive without something like create-react-app because you have to take so many decisions about it for every new project. Simple things like placing a setInterval()/clearInterval() at the right place, or conditionally settings classes on stuff is not straightforward, anything more complicated must be meticulously though.
Because of this, when I give a training in react and one in Vue, the people from the vue training will immediately be 3 times more productive: their projects move faster, it rarely hit a read block later. I also get way, way less questions in the vue training.
Let's not confuse "barebone API" and "easy API". It's not the same.
> It took me 2 weeks to understand react, and much more to actually write decent code with it. Practically, react is very unproductive without something like create-react-app because you have to take so many decisions about it for every new project.
I won't argue that bootstrapping a React project is more complicated than a Vue project. I will argue that React's developer ergonomics are much better.
> Everybody has a boilerplate one of course. Nothing is standardized, so the ecosystem is not reusable.
Not sure what you mean. We use CRA at my company and I can comfortably drop into projects I've never seen before with complete confidence.
> Simple things like placing a setInterval()/clearInterval() at the right place
This doesn't make sense to me. The pattern for setting/clearing an interval with the class-based React API is identical to Vue. With React's hook API it becomes even easier.
> or conditionally settings classes on stuff is not straightforward
How? It's just JavaScript, write a conditional. This is exactly what I'm talking about: you don't need to know how to conditionally set a class in React, you just need to know how to conditionally set a value in JavaScript. I get really tired of the "how do I do task X in Framework Y". I want to ask that question as few times as possible.
My go-to example to explain why I find React so much simpler is Vue's slots. It's an entire API that many people find confusing to replicate something that comes for free in React.
> I will argue that React's developer ergonomics are much better.
Depends for what. For industrial size project, a little, because of the better typescript support. But that's it. You have the same vscode and browser extensions otherwise.
> we use CRA at my company and I can comfortably drop into projects I've never seen before with complete confidence.
First, on this part I'm talking about JS in general. Only a minority of projects use react.
Of course, not all projects use CRA. Many projects use different versions of react with different things you can do with it. Many projects will chose different convention for adapting components, passing children rounds, talking to parent, binding function, etc.
And I _never_ see two react projects with the same me directory tree. There is no strong convention on it.
Then you must chose.
One project is using an inhouse store with useContext, on other use manual redux with that convention, on use redux with that other convention, one use redux-toolkit, one use manual mobx with that convention, one use mobx react, etc. None of them work the same. None of them integrated the same.
And that's just for one lib. One project as many of such libs, all integrated manually.
And yet, the CRA experience is supposed to be one of the best integration you can have.
When you come from another world like Ruby or Python, it's a mad house.
In fact, I'll argue than only experienced programmers manage to get a consistent experience in the JS world.
> Simple things like placing a setInterval()/clearInterval() at the right place
Nope, in react you can use lifecycle OR hooks. You have to choose. And they don't work the same at all.
In vue, for a simple hello world, you can even place the setInterval outside of the component and hapily modify the model, it will update. You don't have to figure out the lifecycle for small app, only for a reusable component.
>How? It's just JavaScript, write a conditional. This is exactly what I'm talking about: you don't need to know how to conditionally set a class in React, you just need to know how to conditionally set a value in JavaScript.
C strings are just an arrays of char, so you don't have to learn those pesky high level string objects in those modern language with all their new fancy API.
> My go-to example to explain why I find React so much simpler is Vue's slots. It's an entire API that many people find confusing to replicate something that comes for free in React.
In both case the user will google "how to get a reference on children components". There is now way you can guess that it's passed as props.
And then, you will want to have several children at different places. And now the illusion breaks, because props.children doesn't work, you have to manually pass each children as props, and you can use them nested as before. And because it's not a "feature", but a convention, you have to know that you need to do that for components that use it. So it's no more natural that slots.
While in vue, you still use slots, you just give them names. The feature is congruent from the simple use case, to the advanced one.
So maybe for the simple case it took 5 minutes in react, and 6 in vue, and the same time for the complex case. For a rarely used feature.
They don't have to deal with the DB, the authentication, the permissions, the deployment, the creation of a REST API, the migration, the mix of several run times, uploads, logging, sending emails, session management, etc.
And yet.
Their support for i18n, validation, routing, caching, pagination, data formating and presentation - what they should be good at - is abysmal compared to what you can do with django/ror.
The only thing they are better at is templating and creating a hierarchy of components. Which is the least they can do given they are literally there to render the UI.
Unfortunately, javascript web frameworks build on top of the javascript APIs browsers expose.
If you're starting from a set of APIs that are too complex for someone to keep in their head, it's hard to end up with a much simpler API.
Especially since people do use a large portion of the web's APIs.
For example, "prevent", the thing in the parent comment, is needed if you use javascript to submit your forms, but isn't needed if you have a form that is expected to be submit by the normal browser mechanism.
Webframeworks rarely are prescriptive to the point where they can default in one direction or the other on that point.. and thus we end up with another option.
That repeats many times over and we end up with a large API surface.
> This does not mean Wikipedia is becoming an SPA. One of the reasons they picked Vue is because Vue can be used to progressively enhance a statically rendered page (just like jQuery, but with a declarative development paradigm), and it allows you to do so without a build step (while keeping the going-full-build-step option open).
I was not aware of this. That's actually really cool. I've dabbled a little in Vue and Angular but haven't taken the plunge and deployed an actual App because I prefer to have sites that degrade gracefully.
Exactly this. Currently MediaWiki and many of its extensions have its interactive parts (editor/maps, etc) written in jQuery and the in-house developed framework OOUI. These are the pieces which might slowly be replaced by Vue.
Hopefully this will also make it easier for new contributors to get started with MediaWiki development.
As long as there is no accepted non-vue replacement for the server side rendering technology, one has to assume that WP will replace php based rendering with Vue templates on a large scale, even for the static content. However, Vue templates require usage of node.js. I couldn't find any standalone serverside vue template parser/renderer written in something like C++, Rust or Go. So if they adopt Vue, they'd still be locked into a project ran by a single company, namely v8, which they listed as one of the things they wanted to avoid.
Also, why does the hn clone that claims to be statically rendered using vue still display spinning icons during page load [1]? I'm asking because it's not just any vue js app, but one mentioned in the official server side rendering docs of vue [2]. Edit: doing view-source on the hn clone shows that it's really just loading the comments from the network. Not sure what definition of server side rendering the docs are working with, but that demo doesn't give confidence.
Will I get spinning icons on wikipedia pages in the future? Will it be like discourse where the scroll bar is hijacked?
I don't get the impression that WP will replace php templating. That just doesn't make any sense to do. First the code is already written (no need to rewrite), probably well tested, php is extremely fast already, and I'd imagine their php development does not have dated tooling that makes development painful. There's little to no reason to switch php code out.
However, it does make sense to replace JQuery snippets or custom in house dated JS frameworks, especially if they lack modern tooling surrounding it like pipelines, code splitting, etc. In that sense, vue and vue's paradigm is a perfect fit because of it's ability to play well with the primary goals at any level of JS-ification, from simple JS actions to full SPA.
AFAIK there is currently no plan to replace existing php rendering with Vue SSR. They just wanted to make sure the framework they went with supports SSR so they are not locking themselves out of the possibility.
The HN implementation renders the comments on the client side because it was using the Firebase HN API which doesn't provide a friendly API for fetching the entire comment tree. Notably, some other HNPWA implementations were using a custom API endpoint. We didn't switch to it because the Vue HN was built as an educational demo rather than a benchmarking subject.
> One of the reasons they picked Vue is because (...) it allows you to do so without a build step
I think it's great that Vue is capable without a build step; however, this implies one restriction, which is that you must have all the components loaded before the application starts. And Async components don't help here because you would have to mantain a list of components names, which without a build step become cumbersome.
I would like that my proposal for lazy loading components (https://github.com/vuejs/vue/pull/8807) would be accepted, then we would have the ability to load components on demand without a build step.
What does this mean for Wikimedia? Will they extend file uploaders and such with some fancier animations and code or will Wikimedia turn into another one of these God-awful Javascript applications running an HTML renderer inside the browser's HTML renderer?
Don't get me wrong, Javascript web applications have their place, but Wikimedia is a website and not a web application.
Will Vue and React work on 2G cell phones running super basic browsers? Will screen readers support all elements created by the Javascript framework?
I have seen too many sites collapse into an empty white page because whatever javascript they were running couldn't access a resource and the shitty JS framework just stopped, leaving me with an empty page. I hope the Wikimedia foundation can stay clear of unnecessary javascript development as long as possible.
A lot of the questions you're rhetorically asking are answered in the RFC you're commenting on.
Specifically, they had real problems with their current system, which they documented here: https://phabricator.wikimedia.org/T225453. Then they explored the available options in the ecosystem and came up with the one they thought would best fit their needs.
If you're gonna be critical, at least take the time to understand what they're doing and why.
I understand them wanting to rewrite their old javascript code. After all, in the frontend world, the toolset currently used is ancient.
However, almost all of my experience with any Javascript framework describing itself as "modern" is a white page with no content of {{ placeholder }}a everywhere text should be.
Several comments on the RFC already seem to state the intention to slowly change Wikimedia into a more "interactive" experience. What I fear is that a framework such as Vue will make it _too_ easy to make everything flashy and modern and suddenly you end up with another SPA where a website should be.
The RFC talks about this shortly and mentions server side rendering but not much about what should be rendered server side and what shouldn't. The overview of problems seems more like a lack of structure than a need for a heavy JS library.
I am very cautious of anyone claiming they need JS for a web page. Applications such as the editors and turning into javascript programs is not something I worry about, but several annoyances new Wikipedia features have already brought me (especially on mobile) make me cautious of any suggestion to add even more javascript.
At a certain level of complexity of web application, it becomes impossible to not have javascript without compromising on your user experience.
I'd argue the opposite - I'm extremely cautious of anyone claiming they don't need JS. People can very easily forget the terrible, terrible experience that a full page refresh brings, and having only full page refreshes as the option greatly limits the kinds of experiences you can give users.
Yeah it's very clear that they still plan to have the website work without JavaScript.
In the longer term, adding support for a frontend build step in deployment and for server-side rendering (SSR) of UI components are two tasks that would be particularly useful here...
Until such features are in place, use of Vue.js would be limited to cases where server-rendered elements can be progressively enhanced within the user’s browser.
I'm ok with their interactive editor being written in SPA style. Most of Wikipedia's billions of users aren't editing pages though. For them, WP should focus on rendering speed which means lowest complexity possible, which means keeping the serialized DOM technology.
The edit view that most power users use is definitely not an spa.
There are multiple "editors" in use on wikipedia et al. Visual editor and mobile edior are more SPA-ish, however the old fashioned <textarea> full of code, editor is still very popular among users.
Disclaimer: work for wikimedia, but not on stuff related to this. My opinions are my own.
Svelte is my favourite framework right now (it's really reignited my love for web development after using React for a long time), but unfortunately one of their criteria/use cases was "build step as well as no build-step", which doesn't work since Svelte is a compiler.
While I thought dropping the "no build-step" requirement wouldn't be a big deal nowadays, they later say:
> We should still explore introducing a full build step in the future (including full support for module bundling, ES6+ transpilation via Babel, etc), but this is a non-trivial change to the architecture of MediaWiki.
I can see why going with something that doesn't need a build-step could be appealing.
There's also the other factor (mentioned below) about community. If MediaWiki chose Svelte, they would definitely have to invest a lot into the framework and it's community, and I'm not sure if that's something they want to or are capable of doing. The biggest pain point with Svelte right now (at least for me) is the tooling, it's real bad.
This is the only mention about Svelte:
> Svelte, Inferno, and Preact are aggressively optimized for performance but have much smaller communities of users (Preact suffers from this issue to a lesser extent, but only as long as it maintains a very high level of compatibility with mainstream React, which may not be the case forever).
I'd be interested in seeing a bit more discussion about it.
nope, the best type of evangelism is evangelism. adoption by most heavily used sites jsut proves technical feasibility.
Unless the devs of "most heavily used sites" evangelize, it makes no matter which sites use svelte. As a matter of fact, Vue's adoption increased after Taylor Otlwell (Laravel's creator) and other started _telling_ people that they are planning to use Vue, instead of react.
>I have seen too many sites collapse into an empty white page because whatever javascript they were running couldn't access a resource and the shitty JS framework just stopped, leaving me with an empty page.
It is even worse when these pages are basically images and text. SPAs have their place and people can develop them as they wish, but I fail to understand why these frameworks have become the go to solution for every page.
This thread reads to me like the engineers went into it already knowing they wanted Vue.js, and retroactively doing the necessary mental gymnastics to come up with a rationale. A better justification would have started with "these are our pain points, and this is our evaluation of how these options address our problems." Instead, it's full of weird things like this:
>Better support for usage without Webpack/Babel/front-end build tools
>We should still explore introducing a full build step in the future (including full support for module bundling, ES6+ transpilation via Babel, etc), but this is a non-trivial change to the architecture of MediaWiki.
A non-trivial change to the architecture of MediaWiki, such as, for example, overhauling the frontend JavaScript with Vue.js? 90%+ of all software has a build step, this is a well-understood problem and has been since before Wikimedia existed in the first place.
They also mentioned that they want a framework which "has a thriving community (and we anticipate this will continue to be the case for years to come)", then picked the framework which has been the underdog since its inception (not that I think any of the other choices they evaluated would have been wise, either). They wanted to use Vue, so they're going to use Vue.
For a website like Wikipedia, it would have been better to consider the alignment with their core mission. A lot of new technology doesn't work in older browsers whose collective market share is still ~5%. A project like Wikimedia is used by effectively 100% of the population, which means that designs which eschew 1% of the population are eschewing tens of millions of people. That's not to mention that these technologies, even when supported, require more computational resources to work, which will make Wikimedia harder to use on low-end or older devices. They considered performance - but only as far as the libraries they "evaluated" compare to each other, not to their baseline.
These kinds of kangaroo court evaluations of technologies for use in a software engineering team make me sick, especially because I'm guilty of having done this before.
I'm happy to see another big project commiting to Vue, but found the rationale funny to say the least, having seen the same kind of analysis multiple times. For example, these requirements:
- UI elements created within the framework are reactive (update automatically in response to changes in data or user input) by default
- The framework is heavily optimized for performance
should automatically exclude React itself, but it seems to have been the second option. Despite appearances React is not very reactive, especially with hooks where you do dependency management yourself. Performance is not a given either, nothing is memoized by default and it's all up to the implementer (or the state management system) to actually optimize rendering at all.
The 'large community' mindset which automatically dismisses Svelte and Preact all the time is the most heartbreaking. If we worked with the herd mentality five years ago, neither or React or Vue would have been born and some variant of Backbone would still be the most used view library.
no offense but it sounds like you're doing a kangaroo court evaluation of their evaluation by making assumptions to what they did and didn't consider and not looking deeper into the context of the RFC.
They expect to have server side rendering, so end user will get just HTML (except the parts that require js even today), so older browsers should still work
Server-side rendering isn't a panacea. I would be surprised if they were using it to do more than bootstrap an interactive frontend web component, which would then inherit all of the problems I'm referring to. That's how everyone else does server-side rendering, at least.
> A lot of new technology doesn't work in older browsers
But given that, how do we move forward? We shouldn't be stuck in the past forever. We shouldn't probably even be stuck in 2013, when IE11 was released. If their site requires heavy client-side code, and if they want to build it in a fast and reliable way, they have almost no other choice but to think of frameworks.
> But given that, how do we move forward? We shouldn't be stuck in the past forever.
Wikipedia is essentially a public utility now. It's not their responsibility to move technology forward by forcing their users to upgrade their machines. There's loads of other players that do that already.
It's our collective responsibility to decide what user agents work with what platforms.
The beauty of the internet is that any website is free to decide as they see fit - if they don't want to support IE/Edge/etc then that is their choice.
No website is a 'public utility' bound by laws which dictate what browsers must be supported - that remains a free and open decision.
IE11 is a dead browser, and the sooner it breaks for good, the better.
I agree that no build step is a false economy. With a build step writing Vue and react are better... Use up to date JS, minified and split bundles, single file components, etc
Points 2 and 3 I agree with though. Vue is more complete than react the library and the Vue stack has had less churn.
I see your point about potentially leaving behind very old devices. I don't know Wikipedia's compatibility stance. It may not be fair to say it's overlooked as the decision within this RFC is only about modern JS frameworks. The decision to adopt could take that into consideration
I have to disagree about the Kangaroo court accusation, that seems unfair
Hmm, in principle I would agree but in practice, I think it wouldn’t make a difference here. Even if it were more even-handed the contenders they would be choosing among are acceptable substitutes for one another. Like, I couldn’t see this being a failure with React but succeeding with Vue. In a lot of these sort of situations, you just need to pick something. I agree that those criteria sound contrived, though.
Personally, I work in React all day and I’m comfortable with it, but I could just as easily use another. There would be minor differences that may annoy to some degree, but it wouldn’t make a huge impact. They all do basically the same thing.
I've loved Vue for a long time, worked two years with it almost daily, but right now I avoid it as much as I can, as I can't stand working with JavaScript without TypeScript. The TypeScript support in the current version of Vue is crap, and the simplest things, such as creating a (typed) component library, are hard and require numerous hacks.
If I were to use something that lacks TypeScript support, it would be Svelte, because it brings unique advantages. By adding hooks, React became the winner for me.
Vue 3 will change all that. It's written in typescript with first-class support and the composition API is like React hooks but better for most cases.
Vue's templating is standard HTML which means it can be delivered by any server-side language/framework. This is where Vue shines in adding interactivity to many typical apps without going fully SPA.
It is standard HTML in the sense that it's valid HTML, which React JSX isn't, of course. But without the JS runtime it won't do anything, so in the end what's the advantage over React? You can add interactivity without going full SPA with React too after all
It's a subtle but huge difference. In React, using JSX means you can create components and mount them on top of the existing elements on the page.
With Vue's HTML templates, the page itself can be the component and everything can become interactive. For example, you can easily output a HTML table from server-side code, then Vue can convert that into a interactive component while using the existing structure and data.
This lets you render the page using existing web frameworks, it's faster because the server puts it together, it's progressive enhancement and works without JS and on slow devices, and Vue can seamlessly add on top with nothing more than a single JS tag and no compilation step.
> For example, you can easily output a HTML table from server-side code, then Vue can convert that into a interactive component while using the existing structure and data.
If you're using vue, you inherently use state or props, and those are handled using {{ myState }} syntax. If you load everything from the backend, it's going to have the actual data in the table. How would you convert the already-rendered HTML to something interactive if the template isn't set up that way?
> In React, using JSX means you can create components and mount them on top of the existing elements on the page.
I am not sure this analysis is entirely correct.
In case of server-side-rendered React pages, React takes the html that arrives from the server and makes it interactive ("hydrates" it, according to the common React community parlance), provided that that DOM generated from that HTML corresponds to the virtual DOM that React generates. It doesn't throw the original DOM away.
you can use the composition api already in Vue2, which is what I have been doing, and I'm using typescript for everything. There is a chance the api may change, but it seems pretty stable. I combo this with using tailwindcss and I think that makes for a pretty productive combo.
>> This is where Vue shines in adding interactivity to many typical apps without going fully SPA.
That is good to know. I wasn't aware. Most of the apps we are working on cannot be SPAs easily, so it matters if the JS framework supports operating without it.
Apologies, I a bit confused. SPA stands for Single-Page Application, does it not? So if you have a single page that works as an application, it is a SPA, no?
I understand the desire to use webkit, Typescript, and so forth to develop modern apps, I'm just confused at why Vue in a stand alone page delivered by ftp or usb drive isn't a
"full" SPA
You can mix and match traditional server-rendered content and JS framework (in this case Vue)-rendered components on the same page (not considering SSR here). Going full SPA means using the latter exclusively.
You can easily do that with React too. In fact, that's how Facebook first used it, using it for just the chatbox (or something) with the rest of the page as it was.
React with JSX means you can easily mount a component into an element, but you can't easily add interactivity to all of the existing HTML on the page as delivered by the server.
Got it. Thanks. We have several content-delivery pipelines at work. It had been so long since I used server-side dynamic content creation that it had slipped my mind.
A reverse situation here. I deal with strict no typescript policy, so besides a problem of finding typescript devs, we have a problem of having to "de-typescript" a lot of 3rd party code.
Typescript has a lot of adoption within with ex-Java devs, and with that comes a lot of "Java-think." It's hard for these people to adapt to not doing things "the Java way" and vice versa.
And another part of the problem is that people have burnt themselves badly with Coffeescript, Clojurescript, and few other *scripts that were coming and going trends, and were an enormous LTS burden because of tooling that breaks as fast as you fix it.
I'm also avoiding typescript as much as I can, but not because typescript itself, but because of how typescript projects tends to be outlined. Lots of the projects are way over-engineered for where they are on the timeline and typescript makes people reach for classes too early. Seeing the same with vanilla JS projects now too when `class` been introduced.
Instead I'm stricly using ClojureScript as the tooling is really solid in everything Clojure, backwards compatibility is a huge selling point in everything Clojure and projects using Clojure/Script tends to be just of the right size and think more about the data structures themselves instead of what many refer to "proper engineering" (SOLID patterns and other nonsense)
I’m spinning up a few new projects at the moment, and was sooo close to doing them in ClojureScript. I ended up going with JavaScript, Preact, and Rollup just because of familiarity allowing me to move faster. That, and my build times are sub-second, something that was not true of my previous Webpack and typescript projects. My total application bundle size is still smaller than React alone.
ClojureScript is really good, though, I gotta say. How are your production bundle sizes? Are you using shadowcljs? If not, what tooling are you using? Also, what editor? I’m a VSCode guy, and last time I used Clojure (a year or more ago), Calva wasn’t up to snuff. I wonder if that’s changed.
Application I'm working on is not that complex, 20 something different pages with multiple sub-sections themselves, bundle ends up being 1.5MB or something like that, 300kb gzipped. Main weight comes from using multimethods which pulls in a lot of cljs.core, so not using that would make it a lot smaller.
Also gonna start splitting the bundle per page but haven't yet.
> Are you using shadowcljs? If not, what tooling are you using?
No, using figwheel-main, project was started before shadowcljs starting to look as good as it looks today. Starting a project today I would probably look into shadow-cljs first. But we're not using any npm dependencies, but shadow-cljs seems to have better introspection properties than figwheel-main (like seeing partitions of bundle size easier, we're currently doing it by looking at the sourcemaps...)
> Also, what editor?
Using vim + fireplace which been working really well for me.
> Calva wasn’t up to snuff. I wonder if that’s changed
Haven't used Calva myself but tons of people in the community swear by it, so I'm thinking it's been improving since the last time you tried it.
I'm not sure when was the last time you tried Calva but Calva been in at least two Clojurists Together (https://www.clojuriststogether.org/) funding cycles, so if you tried it before mid-2019, give it a try again (and report back :) )
Tried it out before (and your comment actually triggered me to try it out again just to see) but I'm struggling to find anything it does that vim + fireplace doesn't do while vim is way faster and takes less screen-estate so I can have my browser + editor side-by-side.
TypeScript makes Java and .NET developers think they understand the language and platform and causes a lot of irrelevant design to be copied over into the JS world where it mutates and becomes absolutely poisonous.
Just look at Angular where the boilerplate and crazy dependency injection completely surpasses anything seen in the Java / .NET world.
It's especially apparent when Java / C# developers are introduced to a simple idea like a Flux pattern store.
Store structures, despite the initial difficulty in learning the pattern, simplify things enormously, but can somehow become nightmarishly complicated in the hands of a developer who expresses API/client relationships in terms of Factories and Services... When it's not hell to work with, it's actually quite interesting to observe.
JS tooling is already an enormous jenga tower as it is, with tooling breakages eating a double digit of developer time. Adding typescript on top of that would be the real madness.
Typescript will not help us a dime with type checking for most of devs we hire are long past the stage when typing errors are a thing for them.
On the down side, even certainly not cheap to hire devs with 6-7-8-10+ years of experience have to battle JS tooling every day.
Like half of all genuine bug triage time is already spent on webpack, bable, and other things in the tooling stack. 200 hours a month for $30-$40 per hour devs.
Imagine doubling that digit when they have to also spend time on learning typescript, and fixing it.
You're removing typescript because you think it's creating bugs...
You realize you're probably creating bugs yourself by removing typescript manually, which is a thing.. typescript itself can do, by compiling down to JS?
Well not exactly, the parent said something quite different, in the comment they were comparing tooling not languages and they say that the tooling makes for a significant part of the bugs they have to solve so they want a build process as slim as possible.
Nothing was said about whether typescript code is more or less buggy, just that the typescript tooling had issue to work with other tooling.
>Typescript will not help us a dime with type checking for most of devs we hire are long past the stage when typing errors are a thing for them.
Who are these mythical people?
Do they just magically decipher what interface an argument conforms to? What methods are accessible on a returned result from any random library they're using?
I'm not a myth.
Some of us started JS programming over a decade ago, with no strong typing and IDE to hold our hand and tell us every time you make a mistake. The key is just discipline, good design patterns and a good linter.
I see TypesScript as a VERY opinionated linter that affects how you think and write JS. JS is a dynamically typed language, which means you loose a lot of its power and flexability by shoe-horning it into strongly typed languange patterns. Yes, I get it, many programmers think best and are most productive using strongly typed languages, but for those of us that can think dynamic or both, TS just gets in the way.
>> Do they just magically decipher what interface an argument conforms to?
This is a good example of the object oriented, strongly typed way of thinking. Explore languages that follow different paradigms, where interfaces just don't apply.
>> What methods are accessible on a returned result from any random library they're using?
Do not use random libraries. A good library should have even some basic docs outline its API and how to use it.
I don't even get this criticism - the problem with Typescript is that it's far too easy to bypass the type system and allow the dynamic parts of JS to do whatever you want. You can lie about your interfaces all day and <any> to your dynamic heart's content.
For what it's worth, my experience with programmers who think like you is that rarely they're actually genuinely talented and right, and mostly they just spew forth bugs which often sit dormant until they rear their ugly heads years later. Most people are better off thinking about their API's before they implement them, much like one would do in a real engineering discipline. Types are often (and yes, not always) a good way to draw the effort out to the front of your process.
Only the first and last sentences actually addressed the topic, the rest was just an angry emotional attack on those who think differently from you. Hope you're feeling better now.
It's kind of funny how you boast that you don't want any hand holding from the compiler or IDE, yet you proudly proclaim and demonstrate that you're careless about syntax, spelling, and punctuation. And how you sarcastically complain about immature thoughtless responses, yet you're insulting and patronizing. ;) At least you're consistently self contradictory.
Are you now clear on what Andrew Hejlsberg, the designer of TypeScript and C#, meant by "multi-paradigm" languages?
>I do think one of the things that is luckily happening is that, like as Larry says, everyone's borrowing from everyone, languages are becoming more multi-paradigm.
>I think it's wrong to talk about "Oh, I only like object oriented programming languages, or I only like imperative programming, or functional programming".
> Explore languages that follow different paradigms, where interfaces just don't apply.
Interfaces as a general concept applies whether there is a type system to ensure that they are satisfied or not. Do you have function parameter lists? Do you have expected shapes for function inputs and outputs? Do you have distinct types? Then you have interfaces. Your shit breaks when they aren't conformed to. It has nothing to do with strong typing or object orientation. Strong, static typing is just a way to ensure at compile-time that the expected interfaces are satisfied.
> Do not use random libraries. A good library should have even some basic docs outline its API and how to use it.
Hearing this assurance from someone who just complained about their jenga tower of tooling causing issues, I'm not convinced.
Not really. My definition of a language feature is something the compiler supports and checks for. JS does not have interfaces. What you're talking about are patterns and best practices, so you're getting there...
JS is a dynamic language. Just deal with it already... you sound smart enough to support both paradigms at the same time in your head.
> Not really. My definition of a language feature is something the compiler supports and checks for. JS does not have interfaces.
It doesn't matter what your definition of a language feature is. The person you responded to was obviously talking about interfaces in the general sense of the word and was asking a question about it.
> What you're talking about are patterns and best practices, so you're getting there...
Nope, what I'm talking about is interfaces. The nature of function signatures as interface points is not a matter of patterns and best practices. They simply are exactly that, whether it's spelled out for you or not.
> JS is a dynamic language. Just deal with it already... you sound smart enough to support both paradigms at the same time in your head.
This doesn't constitute an argument or an objection to anything I've said. It presumes that I won't "deal with it" when there is no evidence that I'm not. It supposes that "support[ing] both paradigms at the same time", whatever that means, is a matter of my intelligence. It doesn't argue for any of this.
> It doesn't matter what your definition of a language feature is. The person you responded to was obviously talking about interfaces in the general sense of the word and was asking a question about it.
Really? So now this has devolved into a debate about semantics? I thought this was about JS and TS, not the "general meaning of interfaces". Using that way of thinking, even HTML and CSS have interfaces. Arguing over semantics is a very common tactic by the way, if you just want to win a debate for arguments sake. Let us keep it specific. My point is JS, as a functional language does not have or even require many of the features and constructs of a strongly typed OOP language, interfaces being a good example. The inverse also applies.
Different programming paradigms = different patterns and best practices
>>Nope, what I'm talking about is interfaces. The nature of function signatures as interface points is not a matter of patterns and best practices. They simply are exactly that, whether it's spelled out for you or not.
Are you saying an interface is a function signature and is this what you mean by interfaces in general?
>>This doesn't constitute an argument or an objection to anything I've said. It presumes that I won't "deal with it" when there is no evidence that I'm not. It supposes that "support[ing] both paradigms at the same time", whatever that means, is a matter of my intelligence. It doesn't argue for any of this.
My responses do not have to be blow by blow objections to every single point you make. This is a discussion, not a computer program. And I stand by the sentiment: for optimal results, think functional when working in a functional language.
> Really? So now this has devolved into a debate about semantics?
You just reasoned on the basis of your "definition of a language feature" that I am wrong. Don't blame me for turning it into a discussion about semantics.
> I thought this was about JS and TS, not the "general meaning of interfaces". Using that way of thinking, even HTML and CSS have interfaces.
It is about JS and TS. A poster asked, about JS developers, "Do they just magically decipher what interface an argument conforms to?". There is a reasonable answer to that, and it isn't "This is a good example of the object oriented, strongly typed way of thinking. Explore languages that follow different paradigms, where interfaces just don't apply", which doesn't answer his question and instead assumes that the poster simply hasn't explored languages that for some unargued reason will change his question.
Obviously he is not talking about interfaces as a language feature, since he acknowledges that JS doesn't have explicitly defined interfaces.
You yourself have been talking about library APIs. I'm sure you know what the I stands for.
> Are you saying an interface is a function signature and is this what you mean by interfaces in general?
I am saying that they are interfaces. I am not saying that function signatures constitute the entirety of interfaces in general, and I'm not sure what I wrote that makes you even ask that question.
> My responses do not have to be blow by blow objections to every single point you make. This is a discussion, not a computer program.
It's a discussion, and I participate to discuss things, not to hear you tell me to "deal with it". But sure, I can't stop you from participating on whatever basis you prefer. I just want to point out that I get absolutely nothing out of it, so if you're writing that for my sake you can stop.
> And I stand by the sentiment: for optimal results, think functional when working in a functional language.
This is not about functional vs. non-functional. It's about JS and TS, as you've pointed out yourself.
>This is a good example of the object oriented, strongly typed way of thinking. Explore languages that follow different paradigms, where interfaces just don't apply.
I'm not sure whether you intended this to sound so patronizing, but wow.
What languages should I explore while talking about Javascript?
You are called to edit a function that takes 2 arguments:
function handle_req(request, options):
What is request in this context and what is options?
What makes me more productive, going up the stack and seeing who might call this function and with what argument, or instantly knowing what the domain of values it operates on is and being able to treat this as a separate unit?
>Do not use random libraries. A good library should have even some basic docs outline its API and how to use it.
A whole lot of the time, especially in Javascript land you will join projects where libraries are being used, and where documentation is lacking. Your advice here is basically to not be part of those projects? Instead of developing and using tooling that will ensure that these situations no longer happen?
> that will ensure that these situations no longer happen?
Well... but Typescript doesn't ensure those situations won't happen, ironically because it's a superset of Javascript and it's not strict enough. Typescript is just documentation that compiles. If a library has bad documentation, it's likely to have bad Typescript as well, and bad Typescript can be a giant curse.
Typescript will happily allow you to force a typecast that doesn't reflect reality -- it will happily allow you to say that a method always returns a string when sometimes it returns a number, and it will happily compile in those scenarios.
Tracking those bugs down are a giant pain. I don't hate Typescript, but people who look at this and think, "I don't have to care about what libraries I'm using, I can just trust the interface" are fooling themselves. I've debugged plenty of errors in Typescript code that ended up being the result of me trusting an interface that didn't reflect the reality at runtime.
There's value in Typescript for some projects, but it does not remove the need to be careful about documentation and dependencies, because it's so easy for both dependencies and downstream code to circumvent the protections Typescript gives you.
This is kind of a subtle idea, but in some instances, the illusion of safety can be harmful. It is occasionally (not always) better not to give people the illusion of safety when that safety doesn't actually exist. Sometimes putting an ineffective railing along a mountain path increases accidents, because it's human nature for people walking on that path to watch their footing less when they see the railing.
>> Do not use random libraries. A good library should have even some basic docs outline its API and how to use it.
> A whole lot of the time, especially in Javascript land you will join projects where libraries are being used, and where documentation is lacking. Your advice here is basically to not be part of those projects? Instead of developing and using tooling that will ensure that these situations no longer happen?
I'm not here to hate on Typescript, I think it has its uses. I use Typescript in some places. I generally avoid it for personal projects, but I would probably encourage it for larger orgs.
But the idea that Typescript protects you from needing to care about interfaces is exactly the problem with over-reliance on Typescript, and is the source of a lot of really badly written code that treats interface design like an afterthought. If you're using Typescript for documentation and you're treating it like a tool, you can write some really elegant code, you can catch some shallow bugs around types and assumptions, you can integrate your documentation into your IDE. If you're looking at Typescript and saying, "this is an efficient way for me to document what my code does", then this is all very good.
But if you're using Typescript and saying, "now I can pull in any dependency I want", then Typescript is doing you more harm than good.
The specific advice orange gives in those two sentences is good advice. If Typescript is giving you a false sense of confidence about using random libraries, then that's a real negative.
I use both pure JS and Typescript almost daily, and I consume plenty of dependencies written in Typescript. I still occasionally need to debug the stack traces in those dependencies. I still occasionally need to read through their source code to figure out what they're doing. Badly documented dependencies are not a problem that Typescript solves.
> in some instances, the illusion of safety can be harmful
> you can catch some shallow bugs around types
> If Typescript is giving you a false sense of confidence about using random libraries
> Badly documented dependencies are not a problem that Typescript solves.
Seriously, what is your claim? That if you have a badly documented third party library with wrong typings then typescript doesn't help? Well, that's some news! Try the same library with no documentation at all then, so you won't get a false sense of safety. If that is your problem, why don't you just avoid importing typings for libraries?
And I don't get this insistence on bugs and safety. Sure, typescript probably prevents you from doing really stupid stuff sometimes, but that's not the main reason I use it. I use it because it both allows me to write much more complex code and speeds up dramatically the development- because the tool takes on itself what is otherwise a heavy cognitive load: remembering and inferring interfaces and signatures that are there all the time, even if implicitly.
> If that is your problem, why don't you just avoid importing typings for libraries?
Yes? That's exactly what people are doing when they import a dependency written in Typescript into a pure JS project.
> A whole lot of the time, especially in Javascript land you will join projects where libraries are being used, and where documentation is lacking. Your advice here is basically to not be part of those projects? Instead of developing and using tooling that will ensure that these situations no longer happen?
My claim is that Typescript does not solve the problem of joining a project with poorly written, undocumented libraries.
I'm not bashing on Typescript. If the primary way you use it is as an organizational tool to reduce cognitive load and make interfaces more explicit, then that's great. You're using Typescript as intended. And there are some scenarios where a compile-time type-checker is just obviously the right tool for the job.
You started this thread by asking how JS devs could manage 3rd-party interfaces without Typescript. I assume you genuinely want an answer to that question. The answer is that for some people on some projects, using well defined interfaces and keeping a reference page open with documentation is about as fast and about as easy as using Typescript, and that following that process doesn't increase their bug count or cognitive load to the point where they feel the need to introduce a compilation step.
> Yes? That's exactly what people are doing when they import a dependency written in Typescript into a pure JS project.
Except that in this way they also lose good typings for any other library and for their own code as well. I understand an outdated definition file can be annoying, but there can be various ways to only ignore type definitions for that specific library.
> My claim is that Typescript does not solve the problem of joining a project with poorly written, undocumented libraries.
That is a problem that no language or tool can solve.
> You started this thread by asking how JS devs could manage 3rd-party interfaces without Typescript.
No, I didn't, you're confusing me with someone else. Inertiatic asked at the beginning of this thread
"Who are these mythical people? [the developers who never make typings mistakes] Do they just magically decipher what interface an argument conforms to? What methods are accessible on a returned result from any random library they're using?"
Then the thread proceeded by 1) ignoring the first part of his question, about having to remember signatures in general, including of your own code; 2) interpreted "random" in a strictly negative way, as if it meant "any junk library" instead of "every library".
> 1) ignoring the first part of his question, about having to remember signatures in general, including of your own code; 2) interpreted "random" in a strictly negative way, as if it meant "any junk library" instead of "every library".
The answer to 1) is that remembering type signatures in general (or primarily referencing them through a separate spec sheet) turns out to be about as easy as Typescript for some projects and some people. The answer to 2) is that not "every library" is complicated enough to need extensive bindings, and that since Typescript doesn't help you with junk libraries anyway, the benefits to well-documented libraries turn out to be relatively minor.
I mean, I don't even use an IDE for development. I'm on Vim/Emacs, so the immediate documentation benefits of Typescript you describe literally just don't apply to me. And there are plenty of JS devs in the same position, where their only interaction with the type checker will be during a compile.
The short answer to how people magically know the type signature of random methods is they don't. They use documentation, or they look at source code, which is something I still regularly have to do in the projects where I use Typescript.
----
> Who are these mythical people? [the developers who never make typings mistakes]
In general, typings mistakes aren't a major source of bugs in most of my projects. I only observe them to be a major source of bugs in large orgs where lots of teams are coordinating on large interfaces. And that's not because I'm a genius programmer or have a magic power, there are normal programmers who will find themselves in that situation.
> Do they just magically decipher what interface an argument conforms to?
No, I look at the documentation. In general, I also spend a lot of time on interface design so my interfaces are small enough and consistent enough that I can hold the entire API in my head without much cognitive load and without needing to check documentation very often.
> What methods are accessible on a returned result from any random library they're using?"
I look at the documentation, or the source code if I don't trust the documentation.
You are always going to be able to make the argument that I just don't understand how much time I could be saving. I don't know how to prove to you that this isn't a massive drop in productivity for me, in the same way that I don't know how to prove to you that it's not a massive drop in productivity for me to write DOM manipulation code in Vim instead of Webstorm with tab-completion. All I can say is, I use both JS and Typescript on an almost daily basis, and I pay attention to the cognitive loads, bugs, and time-sinks I have in each environment. The JS environments aren't any slower to program in.
> javascript is just typescript with documentation stripped off.
JS, at its core is a dynamically typed, functional language. Typescript aims to model a strongly typed, OPP language. The two programming paradigms have their own strengths, weaknesses and most importantly: patterns and best practices.
If the only difference between your pure javascript code and your typescript code is the annotations, you are doing it wrong.
> Typescript aim to model a strongly typed, OPP language.
Do you think? I just take TS for what it gives me, documentation and static code analysis. I can write down my knowledge and expectations about the code and have the tool keep track of it for me, removing the cognitive load of doing it myself- which I'd have to otherwise.
Can you give me an example of a pattern that is "good" in JS and not in TS, or the other way round? I'm curious.
A good indirect example is an actual feature added to JS recently, which are classes. Classes are the main unit of OOP, while functions are the main unit in the functional paradigm. The class syntax in JS is not a real new structure added to the language, but just syntax sugar. Underneath it all, the JS compiler just converts it to a regular JS function using a specific pattern. You could, if you wanted, save the compiler that work by just coding using that pattern to begin with.
When using TS the class syntax fits in perfectly for me, an in pure JS I'd stick to functions.
So you're giving a javascript feature as an example of a pattern that doesn't fit javascript. Then you claim to use an equivalent but syntactically different form in js? How does this constitute a different pattern?
> Typescript aims to model a strongly typed, OPP language
That's a rather puzzling statement, to be honest. Strong type system is explicitly one of the non-goals[0]. I write typescript code everyday and most of it is functional. Things like fp-ts[1] make it even more enjoyable.
Am comfortable using both OOP and functional styles, though I do enjoy the flexibility and terseness that can be produced from the functional approach.
What I meant by the comment is that when using TS, I just find it more easy and natural to go with the proper OOP approach. I think the very existence of a separate library to enable a more functional style in TS proves this goal has not been met yet.
It's not very strongly typed at all, and it absolutely doesn't force you into the OOP paradigm.
Why don't I consider it strongly typed?: Structurally subtyped as opposed to nominal typing, the pervasiveness of any, allowance for vanilla JS coercion, exceptions and promise rejections are untyped, etc.
Typescript won't save anyone from intentional writing bad code or using a broken library. Nothing will. I don't see how that's a criticism of TS itself.
> I'm not sure whether you intended this to sound so patronizing, but wow. What languages should I explore while talking about Javascript?
Why would the suggestion to explore non OOP, strongly typed languages sounds patronizing to you? The more different languages you play with, the broader your mental modelling toolset becomes. It
is painfully obvious to me that someone worried about interfaces in JS is not very familiar with more dynamically typed or/and functional languages. JS is a VERY FLEXIBLE language which can be coded in any style, which is why I've suggest playing with something more opinionated to get the gist. Languages like XSLT, Erlang, LISP, Haskell etc.
> You are called to edit a function that takes 2 arguments:
> function handle_req(request, options):
> What is request in this context and what is options?
The fact that you can edit handle_req means it is application code. So how you figure that out comes down to the structure and patterns you and your team use (if any) and the available documentation (if any). You'd be surprised how far Eslint and JSDoc will take you. TypeScript accomplishes the same, and I've no problem using it within a team that needs it but personally, it feels like an overkill I don't really need to.
> A whole lot of the time, especially in JavaScript land you will join projects where libraries are being used, and where documentation is lacking. Your advice here is basically to not be part of those projects? Instead of developing and using tooling that will ensure that these situations no longer happen?
The decision to use TypeScript or any other tooling should really be made at the BEGINING of a project, so why are we talking about projects that already missed the boat, and even worse lack documentation and tests? This just proves my point, what you really need is discipline (documentation, tests, best praise etc) and a good linter, not a whole new language or programming paradgim.
Eh... people say this, and in theory it should be true.
If you actually use Typescript with a lot of dynamic/unsafe types, in practice you will very quickly end up with a lot of code littered with `any` casts, and those unsafe code blocks will end up (for lack of a better word) infecting the rest of your code and making the compile-time errors much less useful.
For whatever it's worth, my advice is in the instances where you decide Typescript is right for you, commit to it. For the most part, use interfaces, and use strict types that don't get recast a whole bunch.
You don't want Typescript to be guessing too much about your code, because some of those intuitions are fragile and can turn into bugs later if you assume Typescript just knows what you mean. I've had code that works until it gets refactored and Typescript stops being able to intuit what a type is. At that point, going back and retroactively trying to make things more explicit becomes a lot harder and a lot more error prone. The temptation there is to just shortcut the entire process and force Typescript to accept that a type is what you say it is -- and that can lead to very subtle bugs that are hard to track down.
The best Typescript code I've seen is code that embraces the rigidness. When I see a Typescript project with a lot of `any` casts, I start to get kind of nervous.
>Some of us started JS programming over a decade ago, with no strong typing and IDE to hold our hand and tell us every time you make a mistake. The key is just discipline, good design patterns and a good linter.
A decade ago isn't very long ago. JavaScript is more than 24 years old, and we had to get along without good design patterns or good linters or good debuggers or good libraries or good documentation or good IDEs or good compilers or even good interpreters back then. It sounds like you were late to the party and missed all the fun! ;)
You do now understand that TypeScript didn't lose any of the flexibility, power, or paradigms of JavaScript, since it's by definition a strict superset of JavaScript, so it only adds programming paradigms, not subtracts them, right? Or do you disagree with Andrew Hejlsberg, its designer, or the definition of "strict superset"?
>TypeScript is an open-source programming language developed and maintained by Microsoft. It is a strict syntactical superset of JavaScript, and adds optional static typing to the language.
>"IDEs let me get a lot more done a lot faster. I mean I'm not -- I -- I -- I -- I -- I'm really not into proving my manhood. I'm into getting things done." -James Gosling
Andrew Hejlsberg also made some good points in that same discussion:
>Maybe I'll just add, with language design, you know one of the things that's interesting, you look at all of us old geezers sitting up here, and we're proof positive that languages move slowly.
>A lot of people make the mistake of thinking that languages move at the same speed as hardware or all of the other technologies that we live with.
>But languages are much more like math and much more like the human brain, and they all have evolved slowly. And we're still programming in languages that were invented 50 years ago. All the the principles of functional programming were though of more than 50 years ago.
>I do think one of the things that is luckily happening is that, like as Larry says, everyone's borrowing from everyone, languages are becoming more multi-paradigm.
>I think it's wrong to talk about "Oh, I only like object oriented programming languages, or I only like imperative programming, or functional programming".
>It's important to look at where is the research, and where is the new thinking, and where are new paradigms that are interesting, and then try to incorporate them, but do so tastefully in a sense, and work them into whatever is there already.
>And I think we're all learning a lot from functional programming languages these days. I certainly feel like I am. Because a lot of interesting research has happened there. But functional programming is imperfect. And no one writes pure functional programs. I mean, because they don't exist.
>It's all about how can you tastefully sneak in mutation in ways that you can better reason about. As opposed to mutation and free threading for everyone. And that's like just a recipe for disaster.
>Anders Hejlsberg also made the point that types are documentation. Programming language design is user interface design because programmers are programming language users.
>"East Coast" MacLisp tended to solve problems at a linguistic level that you could hack with text editors like Emacs, while "West Cost" Interlisp-D tended to solve the same problems with tooling like WYSIWYG DWIM IDEs.
>But if you start with a well designed linguistically sound language (Perl, PHP and C++ need not apply), then your IDE doesn't need to waste so much of its energy and complexity and coherence on papering over problems and making up for the deficiencies of the programming language design. (Like debugging mish-mashes of C++ templates and macros in header files!)
I think what Andrew Hejlsberg himself, the designer of C# and TypeScript, said speaks to the claims orange8 is making about TypeScript being a "VERY opinionated linter" and that "you loose a lot of its power and flexability by shoe-horning it into strongly typed languange patterns".
Andrew Hejlsberg's point is that TypeScript is a "multi-paradigm" language: it's not just strongly typed, but also structurally typed, interface based, plus everything else JavaScript itself is: dynamically typed, duck typed, functional, imperative, event driven, class based, prototype based, object oriented, etc.
Even the term "object oriented" has a broad spectrum of independent meanings: JavaScript has many but not all of the a la carte menu of features or properties of "object orientation" that Jonathan Rees listed in response to Paul Graham's essay "Why Arc isn't Especially Object-Oriented".
>I think it's wrong to talk about "Oh, I only like object oriented programming languages, or I only like imperative programming, or functional programming".
It's a mistake to think that TypeScript restricts you to just one way of programming, and you have to give up the ways you used to program JavaScript. TypeScript ADDS to the number of ways you can program JavaScript. It's a superset of the multiple programming paradigms that JavaScript supports.
You don't "loose a lot of its power and flexability by shoe-horning it into strongly typed languange patterns" -- quite the opposite, you don't "lose" anything: you actually gain more "flexibility" and more "language" patterns.
>> you don't "lose" anything: you actually gain more "flexibility" and more "language" patterns.
You do not need TS to use OOP language patterns in JS. Remember TS is compiled down to JS, so all that flexibility comes from JS. The same flexibility that makes the concept of TS and the 100 other "compile to JS" languages possible. Some of that flexibility is lost because you let the TS compiler make some decisions for you as it generates the JS output.
You're factually wrong: zero flexibility is lost. Not even any "flexability". (But I'm glad we're both using the same word now -- I was worried you had some completely different definition of "loose languange flexability" that you were arguing, because you don't seen to be making any sense, and your facts about TypeScript are wrong. Programmers who scoff at IDEs and compilers like you do should be more careful about your own spelling and punctuation and grammar and logic and facts and definitions and semantic arguments.)
The TypeScript compiler will BY DEFINITION compile any JavaScript code to equivalent JavaScript code that does exactly the same thing. So no flexibility is lost, which is obvious if you know TypeScript, or have bothered to read the second sentence of the first paragraph of the TypeScript wikipedia page. TypeScript is a "strict syntactical superset" of JavaScript. So it's impossible for the TypeScript compiler to decrease the flexibility of TypeScript, because all JavaScript is valid TypeScript. Understand?
>TypeScript is an open-source programming language developed and maintained by Microsoft. It is a strict syntactical superset of JavaScript, and adds optional static typing to the language.
Just the opposite of your claim, and consistent with what Wikipedia and Andrew Hejlsberg say, the TypeScript compiler "ADDS optional static typing to the language", which INCREASES the number of programming paradigms.
Yet you wrote:
>Remember TS is compiled down to JS, so all that flexibility comes from JS.
C++ is compiled down to machine language, but machine language is not object oriented, while C++ is. Do you claim that the flexibility of C++ comes from machine language's innate object oriented-ness, not the C++ compiler? That's simply wrong.
Somehow the C++ compiler is adding object oriented programming to machine language, just as the TypeScript compiler is adding generic programming and structured typing and static typing and other features to JavaScript, even though JavaScript doesn't have those features itself. They came from the compiler, not the target language. JavaScript simply isn't capable of checking types before running a program, and you know that.
You're really not getting the point, or just purposefully trying to avoid it. Read what Andrew Hejlsberg himself said about multi-paradigm languages, which I've quoted to you twice but you haven't acknowledged. Do you really so blatantly disagree with the guy who wrote TypeScript, about his own language?
If you so strongly disagree with Andrew Hejlsberg and the TypeScript manual, then why don't you go edit the Wikipedia articles about TypeScript and JavaScript, and remove the parts about TypeScript being a "strict syntactical superset of JavaScript" that "adds optional static typing to the language", and also remove the part about Javascript being a "multi-paradigm language", and see how long those edits lasts?
>JavaScript (/ˈdʒɑːvəˌskrɪpt/),[6] often abbreviated as JS, is a programming language that conforms to the ECMAScript specification.[7] JavaScript is high-level, often just-in-time compiled, and multi-paradigm. It has curly-bracket syntax, dynamic typing, prototype-based object-orientation, and first-class functions.
N=1, but type errors are extremely rare for me in Javascript. I don't think I'm a magical or exceptional programmer. I think it's just if you spend a lot of time in dynamic languages, there's a certain style of programming some people end up adopting that makes those errors much less common.
If you held a gun to my head and forced me to recklessly provide conjecture on what the difference is, I would say that static languages encourage devs to build large interfaces that take tons of options and pass around a bunch of parameters. This is highly, highly subjective, but:
I think there's a grain of truth in what other people are saying about how Typescript projects tend to be kind of verbose. People start reaching for interfaces that are split across multiple files, people start reaching for classes. When you have really rigid types that need to be formally extended all over the place, this also encourages a lot of casting, which tends to be error prone.
I've seen some really complicated logic/type flows in Typescript that would be extremely error prone in Javascript, but there's basically no reason for them to be that complicated in the first place. There are paradigms in Javascript the codebases are not taking advantage of which are forcing them into these over-complicated logic/data flows. Basically, the more crazy boilerplate, casting, and giant interfaces that a codebase has, the more type errors will occur. The more a project is split up into dozens of dependencies and modules and whatever, the harder it is to reason about what a method or class needs passed in. But Typescript projects tend to grow in that direction very quickly, so the need for Typescript tends to become a self-fulfilling prophecy.
As a comparison, most of the personal projects I work on don't have classes at all, they're using a lot of functional interfaces, and they don't include a bunch of random libraries. Most of the dependencies in my projects are libraries that I've personally vetted. Most of my projects are careful about where state is being stored and how its being passed around.
I dunno. All of that is pure conjecture, but people in general are very dismissive of dynamic typing, but it's just not a real problem for me. There's a general consensus that dynamic languages were a mistake, and I don't dismiss the people saying this, but I also pay a lot of attention to where bugs are coming from in my own code, and I can't get past the point that typing really doesn't seem to matter that much in most things I build.
I was on the Typescript train for a while. I still use it in some projects, there are some org structures where it makes a lot of sense. If I'm working with a Java-to-Javascript dev, I want strong interfaces for them. The projects where I don't use it are because I've spent a long time paying attention to where my bugs are coming from. I can't prove to you its not a problem, I can only speak to the experiences I've had.
Yea bugs exist, yet there are still thousands of teams using it to build very complex projects with less bugs because of Typescript safety and features.
TS tooling either replaces JS tooling or interacts with it seamlessly. It's not like you're skipping JS altogether and there's no type-checking in JS anyway so where's the interference?
Can you give a concrete example where TS is a blocking issue for your development?
If you get less bugs because of type checks and you are a serious JS/web dev with 5+ years experience, then your skills are plainly not good enough.
People who spent time with JS and webdev in general got to learn that JS is a minefield of a language, and they work with that in mind. Typing discipline is pretty much the first thing people learn when they try doing JS seriously.
How to say. There is no way just adding typing to JS will make JS less of a JS. You still have to be a very disciplined dev to work with a typescript for it retaining many other tricky parts from JS.
> Can you give a concrete example where typescript is a blocking issue for your development?
Typical example: the tsc transpiler plainly dies, and you know nothing how to debug it, you know nothing of its internals, and you loose the rest of the day doing fruitless email exchanges with typescript dev team, and trying to trace a breaking commit.
Second example: you got a prod breakage report in some hard to reproduce case. You fire a debugger in chrome through vscode, and then you find out that the debugger completely loses the execution flow in transpiler/tooling garbage, and broken source maps. Having a debugger pick code that went through webpack (be it cursed) is already a 50/50 lottery, and additional layer of tooling makes it even worse.
Do you still put your seat belt in your car after 5+ years of driving experience? If yes, would you say that you do that because your driving skills are "plainly not good enough"?
Typescript allow you to spend less energy on minor issues like typos and more energy on design. It also provides you with the ability to reason locally about some code. When you inspect a function in js, you cannot know what are the contracts that it has to deal with. To be sure you have to unravel all the calling and called functions.
Typescript also enables better intellisense.
About your issues:
- I never had tsc dying on my hand in 5 years.
- About the transpilation noise: it can be as noisy as you want. Have you checked the default result for the es6 target? It litteraly look like your source code with only your type signatures stripped. The noise comes from the transpilation to lower versions and bundling and those are independent of typescript.
Considering typescript compiles down to JS, and incredibly readable JS at that, the fact that your developers are unable to debug the JS directly may indicate that they are not as amazing at JS as you may believe they are.
> If you get less bugs because of type checks and you are a serious JS/web dev with 5+ years experience, then your skills are plainly not good enough.
What about linters, static analysis, code highlighting, IDEs? Should we skip those too? Should I dig out my "made with notepad" badge?
Types and good static analysis tools allow me to focus on more important things, such as business logic, scale, planning. We don't pay developers for mental gymnastics, but solving real world problems.
When I am writing plain JS I often end up having to write loads of tests to check that I don't to wrong things with types. Did I remember to consider null/undefined? What if I sent in something totally different?
With TS I don't need to spend as much time with these types of tests. I just let the compiler do it for it. If my function says in it's signature the argument can't be null I don't need to do null-checks.
This is the weirdest and least convincing thing I've read about Typescript. I won't comment on such experienced devs spending so much time struggling with tooling that shouldn't change all that often, but I have to react that "fixing Typescript" means "fixing your code".
If you're saying that you can't handle the overhead of Typescript config because your devs already spend so much time struggling with the rest of your tooling, by all mean get your shit together with your tooling, this amount of time spent on it isn't any sort of acceptable. You have huge problems.
> most of devs we hire are long past the stage when typing errors are a thing for them
You do realise the large number of open issues almost certainly relates to Typescript's compiler and language implementation? When a project is written in Typescript, it does not mean all those bugs will inevitably plague the project itself. If I wrote "hello world" in Typescript with a Webpack + Babel project starter, it doesn't suddenly mean I now have thousands of open Typescript bugs to deal with.
Also: the number of closed issues outnumbers open ones by almost x5. Moreover, the total number of issues exceeds 20 thousand; the number is only so high because so many people have already adopted Typescript into their dev workflows. It's a sign it's been battle tested extensively.
> Like half of all genuine bug triage time is already spent on webpack, bable, and other things in the tooling stack. 200 hours a month for $30-$40 per hour devs.
Half? This just seems totally implausible; this could only be true if you were constantly modifying your webpack and babel setup and config files and breaking things.
I would never hire a JS dev with this attitude towards typescript nor work for one.
I’ve done JS with and without types. I’d find a new job before going back to working without them. That’s how dramatic the benefits have been in my code.
I like going type-less for prototyping (pun intended), then converting to or rewriting in typescript for anything I'm going to need to maintain or refactor.
Ratio of open/closed issue is a very strong indicator of how active a project is. My perspective, with 21k closed and 4k open issues, shows a very active project where I should not be finding major blockers if I adopt it. If it has an issue 1000s of people are actively looking at it and it will be caught at beta stage or will be solved quickly.
> long past the stage when typing errors are a thing for them
Nonsense. Static type systems help you write correct code. They're also extremely helpful for refactoring. They also help readability. Outside the JavaScript world, they also help performance. The list goes on.
No-one is too smart for type systems to be helpful.
> it does not pay off at all
You've entirely ignored that TypeScript helps reduce bugs, and helps catch them earlier.
Seriously. “We manage OK without static types” is one thing but “LOL we’re not n00bs so we don’t need your productivity-killing static types” is... wow. WTF. Keep anything that team writes far away from important data and processes, please.
Sounds like you need to raise the bar on hiring if learning static typing is an impediment. I recommend less JS monkeys and looking for actual engineers.
Their 6+ year engineers are getting paid less than many interns do in America according to said poster. The big tech monopoly means that hiring good senior engineers is nearly impossible. :)
Why do you have to de-typify Typescript dependencies? You can mix typed and untyped code with a gradual typing approach, and tools like webpack make this very easy?
To be fair, cargo-cult programming is a scourge in any domain. Since the cult many folks started with when they took their college (or free online) programming course was Java, all cargo looks like Java.
> we have a problem of having to "de-typescript" a lot of 3rd party code.
What do you mean by this? npm packages at least are already "de-typescripted", in the sense that they're just .js files with accompanying .d.ts files describing the former to people using editors with TypeScript support.
(Also, it feels like you've experienced a weird subset of TypeScript code. It also happens to be an enormous help when doing things "the Javascript way", which is what it's actually designed for. But I can imagine that encountering bad apples can sour the experience for you.)
Every language comes with its own culture, and with its own stereotypes. Java's over-engineering and boredom, JavaScript's throwing shit on the wall and see what sticks, PHP's developers that do stackoverflow-driven development.
There are experts, average people, and bad people in every field. TypeScript brings sanity that is valuable for both experienced developers and less experienced developers.
The peace of mind that you get with types when doing refactoring is invaluable. I would never be able to go back and write vanilla JavaScript, because it's broken.
You can over-engineer and write crap code in any language.
Also a comment on anyone that says experienced devs get no benefit from types: you think you're good, but you're not. As good as you think you are, if you seriously deny the benefits of static typing, you're probably shit as a developer.
If you understand static typing and it's benefits then you agree it's a good trade, if you don't understand it and still have a strong opinion against it, then you're just a lazy human.
I've worked with both. And I have to say: It depends. Mostly I feel like typescript slows me down A LOT.
In my opinion, the better your code style, guidelines, linting, infrastructure, error reporting and tests - the less you need typescript.
I worked in a team that had about 150 micro-apps and services, it was maintained by roughly 15 devs. Each microservice had it's very small scope and it was very very easy to work with it. Everything was very predictable, which made it easy to work without having types.
I mean, I would be willing to work in company that does not uses typescript.
But a company that goes to irrational length of rewriting dependencies because they use typescript? A company that assumes that seniors don't make simple mistakes? Those are warning flags.
"We have problems, let’s introduce some code style guidelines, linting, error reporting and most importantly tests!"
"Nah, let's just switch to Typescript, it will solve all those problems. At least partially."
I mean, look at the number of tests needed to replace a few lines of types. You have to check the behavior of your functions for all kinds of invalid inputs. With typescript you still need tests but less of them. And also you can get rid of a lot of input validation in your production code.
No I didn’t. The statement was that Typescript solves the listed issues, which is obviously not true. There may be of course discussion whether TS _helps_ to solve such issues but you won’t be able to convince me that TS _solves_ e.g. lack of testing.
It's OK for the most common scenarios, I didn't comment on the regular "build a web app" case, but more complicated ones. I think @vue/cli is very nice, but I've had many issues dealing with the magic behind it, so much that it became easier to swap vue-cli-service with rollup and custom setups.
I'm sure Vue3 will fix all this, and it will be awesome. Very much looking forward to it
I've only used angular but I'm curious, why has angular never been an option for you?
I've never used react but I think you can use typescript with react if you wanted to, right? it just isn't the default but if you're in react land, you probably don't care much for defaults?
React with TypeScript is a joy. I have the utmost respect for Angular, and for the way it pushed forward progress on frontend. Vue itself has taken many great ideas from Angular.
It hasn't been an option for me because I found it quite opinionated for personal projects, and in my work context I didn't enjoy / respect the people that were working on Angular projects. This is not about Angular, it's about where I was working and the people there.
It's easy to judge a tool by it's users, but we mustn't.
I use Vue without a compile step (I abuse Go's templating engine to achieve this). Mostly to avoid the security nightmare of Webpack's 434583593e4735683 dependencies (and most of the other options are not much better) so Typescript is not an option. I love that I can do this with Vue (I can't with React).
Would it be so hard to start with an assumption that the person you're responding to is working with outdated information or that they're just confused?
Even if they were intentionally lying (why??) it would hurt no one to humor it and be polite, and it would do a lot towards making this a more enjoyable place to read.
Your post was informative, too bad it made me just want to close this tab.
This is a bad idea. If you look at the list of advantages to doing this only 1 is user-centric (things would be reactive). The rest are all related to how it makes development easier. When you choose a developer-centric workflow your users will suffer.
You only have to look at the numerous server to SPA conversions to see how consistently bad of a choice this tends to be; Reddit is a big and obvious example.
They could take a half-measure and move away from the brittle jQuery based front-end they are currently using by adapting those to use something like Preact, while leaving the rest of the page alone. This would give you more dynamic and more maintainable page widgets without the sacrifices that inevitably occur when you move the entire site to being front-end rendered.
Who said they are going to make the entire page SPA? They picked Vue specifically because Vue allows them to progressively enhance parts of the page with interactivity without going full SPA (AND without hard reliance on a build step).
They listed SPA capabilities as a requirement when choosing a framework.
Every framework allows only rendering to part of the screen, but all of them also allow and encourage the building of SPAs, including Vue. Building SPAs is the overwhelming norm when using any of these frameworks.
If they are bucking the trend here, that's great, I encouraged using a declarative library for the truly dynamic parts in my above post. However this post contains a lot of red flags such as the term "Server-Side Rendering" that are unnecessary if using it not for a SPA. So it's worth pointing out the risk.
It's not just a bad idea... it's a horrible, dangerous idea.
All of their points can be easily addressed with a static site generator or just some CMS that lets you write pages using templates instead of just pure HTML. That's absolutely declarative, a lot more than a JS-framework based app. The only point that would be missing is the reactive part as you mention: but who the hell expects a wiki to be reactive?! I expect it to be as close as possible to the printed version! A Wiki is NOT a web app!
The requirements listed for a "modern JavaScript framework" are completely generic. Of course, if you include requirements such as "declarative" and "broad mindshare", you can only arrive at React, Angular, or Vue - at the moment that is.
Is this for internal Wikimedia apps or intended as a long-term replacement for Wikipedia/MediaWiki? If the latter, a prime requirement surely would be to support MediaWiki markup wouldn't it?
The problem with this kind of assessment starts with the deliberate decision that you need a JavaScript "framework" at all in the first place (that isn't just motivated by a junior dev seeking to pad his/her resume). Going from there, since you desperately want to persuade yourself that today's frontend landscape isn't just a result of big media influence (Fb, Google), you necessarily choose Vue (I know several companies who settled on Vue because they couldn't stand the React hype).
In other words, decisions for a particular JavaScript framework are as generational as ever, and the hope for a choice with a long-term perspective is futile, because a new generation of webdevs will soon re-invent their generation's framework since maintaining daddy-o's web framework isn't fun, and because every developer wants to carve out a niche for creativity.
Weird, most of the fastest-feeling sites I use are server-side rendered. Though I doubt they use any JS in that path. Maybe basic html Gmail does but probably it’s Java or something.
> The need to evolve our platform is very evident when it comes to how we design, develop, and deliver experiences to users in the browser.
> Requirements:
> The framework allows UI elements to be defined in a declarative way
> UI elements created within the framework are reactive (update automatically in response to changes in data or user input) by default
> The framework is open-source, widely used, and has a thriving community (and we anticipate this will continue to be the case for years to come)
> Flexibility: the framework supports the widest-possible range of use-cases (client-side as well as server-side rendering, progressive enhancement as well as full "SPA" usage, build step as well as no build-step etc.)
> The framework is heavily optimized for performance.
Only ONE of those has anything at all to do with the user.
To be blunt, this is an extremely common thing in web development and it makes me very sad. But whenever I raise it I’m rebuffed with the vague argument that “developer productivity = more features = better user experience”. Which sounds great in theory but a crappy experience is a crappy experience no matter how many features you put on top.
Go look at the lighthouse scores for pages that use React + Redux + whatever + blah blah and tell me the user experience isn’t sub par. Especially for an organisation like MediaWiki page load time is absolutely critical. I really hope they are sensible enough to choose something lightweight.
> Go look at the lighthouse scores for pages that use React + Redux + whatever + blah blah and tell me the user experience isn’t sub par
I looked at the Lighthouse score for my blog (written in React and all that blah blah). It got a 100 for performance, 100 for accessibility, 100 for best practices, and 100 for SEO. So I am happy to tell you the user experience is not sub par.
Serious question: why are you using React for a blog? What interactive elements are there on the page that require it?
EDIT: Saw the link in your profile. I see lower numbers than you, though not by much. But I also see 2.6 seconds time to interactive with 3.1 seconds of main thread work.
Broadly speaking, that's fine for your blog. But if it was a site that you expect to add more and more features to over time that number is only going to go up. 3.1 seconds of main thread work to render an entirely static page isn't good. It's acceptable at best.
There are no interactive elements, I just enjoy using React more than the alternatives, even for static content. Instead of asking "what requires react", a better question is "what are the tradeoffs of using react in this situation". In my case React allows me to use Gatsby, a wonderful static site generator, and it also makes it easy for me to add any interactive content I want in the future.
My site will load fine without javascript, so it's hard to imagine react is slowing things down much (although if you've visited before the PWA will mess it up if you try to turn JS off).
For something like Wikipedia, time to interactive isn't that important (which is good, because lighthouse tells me that this page [1] has a TTI of 7.4s). First meaningful paint matters much more. I really disagree with the narrative that anything written with React is going to have a much worse user experience compared to the "old" stack.
I’d say your use case isn’t really all that applicable to how React is normally used. Zero interactive elements and doesn’t require JS... that really isn’t typical for a React deployment.
> I really disagree with the narrative that anything written with React is going to have a much worse user experience compared to the "old" stack.
Why only compare to the old stack? When you’re evaluating a brand new solution would should be looking for the best one, not any solution that improves your current situation.
That's because the issue they're trying to solve is being slowed down by existing JavaScript tooling and infra. This is very explicitly to improve Dev UX. And they already called out the most important concern when switching to a new lib:
> The framework is heavily optimized for performance.
Well I guess you can not go wrong with either React or Vue at this point as they have mature communities.
However I feel like while React is just fantastic on its corner, Svelte seems like a better built Vue than Vue. It lacks the community but technically feels like a refinement and enhancement of Vue’s ideas. I wish it would gain more traction.
Why would the WM foundation use a relatively unknown framework? They don’t just care about the actual coding itself, the have to concern themselves with community, support and longevity. You said yourself you wish it would gain more traction, and that’s something an Org like that doesn’t take a gamble on to be fair.
To me the difference is that Svelte is a lot more pure JavaScript than Vue. I haven't had the chance to use it in any larger project, but in my small playgrounds, I've definitely enjoyed it more than Vue.
Viewing the source shows an html page without a closing body nor html tag: it's probably not the best case for showcasing it seems.
The layout it all over the place too using FFox, (it's fine on Chrome and Safari) so it also seems to be lacking in some basic cross browser testing, which again, is not good news when show-casing a framework, as a frameworks' prime responsibility is to ensure cross browser/platform uniformity.
Hopefully this all boils down to a simple 'oopsie' in your project, rather than svelte.
> Viewing the source shows an html page without a closing body nor html tag
It's actually not required to close those tags, the browser will interpret them correctly. (You can see this when inspecting the elements on the page, not just the raw source)
I was tempted by Svelte for a while, but in the end Preact remained the best fit for our needs because the output filesize grows slower with Preact than Svelte.
I like keeping things small because it delays having to add complexity (and simple is easier to maintain, especially when you have better things to do) and saves on bandwidth.
Of course I'll keep evaluating new versions as they come (given nothing is sacred in my pipelines), so that might change in the future.
The bigger the virtual dom the larger the performance gap is supposed to be. But, true, would like to see some benchmarks from the real world, i.e rewrites and such.
Perhaps not a great comparison, but here are the Svelte and Vue HackerNews feeds. Not a great deal of difference, but perhaps it's too simple for performance to really matter.
Actually using Svelte its main downside is the giant file size. I consider it unusable for that reason alone. Any minor speed advantages is entirely negated.
But react and vue are underneath much closer to each other than Svelte. Sure vue and svelte use templates and react doesn't but that's about it.
Anyway since svelte must be compiled i dont think it's good choice for something like mediawiki where you might have plugins and addons that want reuse core components and connect to each other in runtime.
> Anyway since svelte must be compiled i dont think it's good choice for something like mediawiki where you might have plugins and addons that want reuse core components and connect to each other in runtime.
Compiled Svelte components are highly reusable and cross-framework like few others.
So how do i extend component in mediawiki without having to recompile its source?
How would i reuse that <mediawiki-table/> distributed in core and reuse it in user installed plugin?
I'm not a frontend dev, in fact I know little about the current "cool" JS framework.
That being said, I donate to Wikipedia/Wikimedia every year and I will reconsider if this goes through. This is exactly the kind of bloat that no one needs.
The Wikimedia sites should be seen as a public library where accessibility is the most important thing. Creating a web app with apparently no measurably good impact is pure idiocy.
Page Previews, specifically Hovercards can be implemented in a very simple way with plain JS [^1] and is clearly an enhancement - everything works just fine if hovercards don't load.
But most features on Wikipedia aren't like that, and would be really hurt if you had to a JS bundle or otherwise deal with the usual bloated webapp nonsense. Wikipedia primarily needs to load quickly and be semantic with preferably simple infrastructure to help their budget.
Each such feature individually can be implemented in a very simple way with vanilla JS. All such features taken together create a horrible unmaintainable mess. Speaking from experience.
You dont need to be worried about this. Our morales and principles are not changing.
I built the Wikipedia mobile site and there's a reason our hamburger menu, lazy loaded images and editor actually work without JS. We are for everyone regardless of internet connection speed, device value and internet stability.
That's a a hill at least I as an employee am prepared to die on.
> I'm not a frontend dev, in fact I know little about the current "cool" JS framework.
> That being said, I donate to Wikipedia/Wikimedia every year and I will reconsider if this goes through. This is exactly the kind of bloat that no one needs.
The latter seems an overreaction given the former.
It is absolutely an overreaction, and I don't see myself going through with something like that. I use the site probably daily and feel like I have to donate.
We adopted Vue for the same reason. We had a large ASP.NET + jQuery code base which we were able to enhance with Vue.js over time. Eventually we built an SPA code base and porting over our existing components was a breeze.
I’ve used React extensively but I agree with their assessment that the API is a moving target, which ends up being horrific DX when you’re using third party libraries.
I looked at Vue.js and came away with the impression that it requires me to learn a lot of framework-specific implementation details. For instance, a list requires that you know the v-for directive, while in React it's just JavaScript's Array::map().
These directives take less than a day to learn. 99% of the time it's far easier to write HTML tags with data and event binding directives than hack around with JSX and passing all those props.
You can also use JSX with Vue if you want. Just add a render() function to the component. That's what happens anyway when you use a normal template, the Vue compiler turns it into a render function the same way JSX is compiled by React.
Using Vue's pseudo-HTML directives might be easier for many cases, but it is less powerful than JavaScript. In some cases, these restrictions leads to workarounds or rewrites. I agree with the grand-poster that the added value is controversial.
As for JSX with Vue, it's clearly a second class citizen. For instance, last I checked, JSX + TypeScript was broken, though both are officially documented with Vue.
I actually found make it restricted (compare to js) improve general code quality as you don't have too much items to abuse. Probably not ideal for personal project because it won't let you fly as you want. But it is awesome for collaboration because you can't really write something way too off with it.
Yea, the 1% of the time you need that extra control then you can easily use JS render function or JSX. The documentation covers all of this: https://vuejs.org/v2/guide/render-function.html
I haven't found it very limiting, however, because it is very well defined, in Vue3 they are looking to actually use this to make massive optimizations in rendering that you simply can't make when you use javascript anyway you like to assemble things.
I dislike both. Most readable template syntax for me is PHP's "alternative syntax for control structures" (the one with colons instead of braces and closing keywords).
When you're choosing a JS framework you need to factor in the experience the user has along with the experience you have. I don't know much about Vue but React comes with a huge amount of bulk. A lot of JS that has to be parsed before anything can even be done on the page.
If you're choosing React because it allows you to fall back on what you know rather than learn something new you're making an ill-informed choice.
Right now, Corona made some time for that, I'm rewriting something I tried to do in Vue. I don't work with Vue daily and that makes it real hard to do even the simplest things. I'm back to vanilla JS, few sprinkles of jQuery and HTML5. Works well for me.
exactly. React works so well with js. And vue claims to be simple but tbh its hard. working with async await function, promises are so weird. And you need packages for simple stuff also.
By itself, there is no inherent value in either v-for or Array::map(). However, these choices do not exist in a vacuum, they are other decisions in place, which do provide significant value:
- React, allows full power of js when writing template. and easy to express and decompose components into functions. while Vue does not allow the fine-grained in template unless you go into Vue's JSX)
- Vue, via template-based approach, enables Developers to deploy apps without a build step, while React forces devs to add a build step(and a compelx one at that) to pipeline
I have been donating to Wikimedia for years, but have sent an email to let them know that I will stop the day Wikipedia becomes inaccessible without JavaScript.
Wikipedia is a unique project because of how reliable it is -- in both its merit and its tech. It would be sad to see it go.
Reminds me of when archive.org "improved" their site with javascript a year or two back and it stopped working entirely if you don't run JS and don't use a modern commercial browser.
They can say whatever they want about how this won't happen but likely it's not up to them (because it's a corporation and because they won't control the decisions of the JS framework they pick). Wikipedia isn't broken. Fixing it is bad.
I have the opinion that Vue and React are ideal when you do need a SPA (example: when you want to make something that works offline, uses a lot of browser side storage, etc).
For every other application, my favourite tool is https://unpoly.com/, and alternatively Turbolinks + Stimulus.
Most applications do not need Vue or React there is a HUGE abuse of client side JavaScript these days.
Needless to say that this is subjective, but I think Single Page Applications and components-based UI in webdev is fairly modern as opposed to imperative, jQuery-esque Front-end development.
I have used react and vue and I prefer vue. React is fine but it has a few issues such as having to write className instead of class in the html templates (yes I know why). It's not a big difference between all these new frameworks though, and it will be a huge improvement over html generated from PHP with some jQuery.
At least the content is freely available, so I can stand-up my HTML-only Wikipedia clone if they render the official version unusable with this reactive JS madness.
Turns out HTML over HTTP is GREAT way to deliver encyclopedic content.
So I've been working with React/Vue/etc since 2015 and I agree that if you are looking for an ES5 jQuery replacement Vue is the best candidate of the most popular options. You can work old school, just import it via a script tag and start writing ES5 .js files.
That said, ES5 is going to die at some point and big projects like Wikipedia need to prepare for that. Making long term decisions that do not take that into account will be essentially flawed. It would be better to adopt TS than to keep writing ES5 in 2020.
Developer experience in React is orders of magnitude better than in Vue. Also, the React community settles on great conventions and patterns to help you be really productive early on. This is great because you end up with projects that are a pleasure to code in and easy to maintain. Debugging experience is far superior in React, finding the root cause of an issue is much quicker than with vuejs. Working in a vuejs project, I continuously wish we could just abandon it and rewrite everything in React.
>Better support for usage without Webpack/Babel/front-end build tools
It looks like it's reasonably easy to setup run-time JSX compilation by using a service worker with babel to intercept and transpile .jsx files. I imagine the performance tradeoffs would be similar to using Vue with string templates? Could be faster actually since you could memoize/cache in the service worker
It is not. The devs initially wanted to make some drastic changes. But Community feedback was very vocal and very negative. Since their main source of income is the community(not FAANG), they reverted their stance
I believe the templating is what's declarative, here. For instance, in Vue you can insert logic such as for loops, conditionals, event listeners, two-way data binding and so on right in the template with directives (HTML attributes).
<Todo v-for="(todo, index) in Todos" :key="index"/>
It is the same with handlebars. You put your todo element between {{#.}} and {{/.}} which means "do this for all elements" and then pass only the "Todos" array to the template. No loop in Javascript either.
As someone who has been using Vue for a long time and recently fell in love with Svelte, I really hope they wait for a bit and go with the Vue 3 version. It brings a lot of huge advantages to Vue that make it much much more maintainable.
Contemporary framworks all allow for server side rendering and build time rendering.
Sure, you won't get 100% of the goodies, if you disable JS, some stuff simply can't be done with HTML/CSS, but at least the important parts would still work.
Also, solutions like Svelte are rather fast and small, compared to Vue/React but also compared to previously known small frameworks like HyperApp.
* Wikipedia is not becoming an SPA
* Wikipedia is not dropping support for non-js users
* This proposal is not about changing our current browser-support matrix[1] (which includes IE11 as a first-class target; Vue.js ecosystem still supports IE 11)
* This proposal is about changing the way we develop enhanced, JS-only features across our projects; many such features exist already, but they are written in jQuery and an in-house framework called OOUI
* These features will continue to be delivered in a progressively-enhanced way on top of the PHP-rendered baseline for the forseeable future. We are interested in how server-side rendering of JS components can integrate with this but we're still looking into how this might work
* We will continue to prioritize accessibility, internationalization, and performance in everything we ship
I don't think that Vue is "better" than React, but I think it has some features which are especially helpful in our progressive-enhancement, ES5 (for now, anyway) use-case. But it's great to have so many amazing tools to choose from.
Previously we've been using a framework we created in-house for complex JS features, but it's a product of an earlier era of the web and is increasingly out of step with the current paradigms in UI development. We think that one big benefit of moving in this direction is lowering barriers to contribution (both for new developers at the foundation, as well as folks in the wider community).
[1]: https://www.mediawiki.org/wiki/Compatibility#Browsers