[HN Gopher] RFC: Adopt a modern JavaScript framework for use wit...
___________________________________________________________________
RFC: Adopt a modern JavaScript framework for use with MediaWiki
Author : aliveupstairs
Score : 266 points
Date : 2020-03-19 08:17 UTC (14 hours ago)
(HTM) web link (phabricator.wikimedia.org)
(TXT) w3m dump (phabricator.wikimedia.org)
| austincheney wrote:
| Do they really need a large framework? It is possible to write
| fast elegant applications in JavaScript without a framework.
| MatthewPhillips wrote:
| 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.
| brabel wrote:
| 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!
| otterlicious wrote:
| > a static site generator
|
| You really think 140,000 people are going to learn git all of
| a sudden?
| Fnoord wrote:
| Learning Git (there are GUIs for it as well) can aid one in
| so many additional ways though.
| EvanYou wrote:
| 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).
| MatthewPhillips wrote:
| 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.
| longtermd wrote:
| A warm Welcome to the Vue family! :)
| heinrichhartman wrote:
| 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.
| speedgoose wrote:
| 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.
| cheapsteak wrote:
| >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
| HumblyTossed wrote:
| > 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_.
| untog wrote:
| 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.
| anchpop wrote:
| > 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.
| untog wrote:
| 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.
| anchpop wrote:
| 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.
|
| [1]: https://en.wikipedia.org/wiki/Matthias_Hansen_House
| untog wrote:
| 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.
| sequoia wrote:
| Go look at the lighthouse score on my blog:
| https://sequoia.makes.software/
|
| Also a 100 on performance & time to interactive 0.9
| seconds. What are the key features of React that you use to
| set your blog apart from mine?
| [deleted]
| Richicoder wrote:
| 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.
| Kiro wrote:
| Vue is just like Angular 1 but with less boilerplate. As your app
| grows you will run into the same issues. Never had the same
| feeling with React.
| jeroenhd wrote:
| 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.
| k__ wrote:
| I'm a React fanboy, but I have to admit, the Svelte performance
| and code size is impressive.
|
| Maybe that would be a feasible way to get a modern developer
| experience without the bloat?
| marcus_holmes wrote:
| One of their criteria is widespread adoption. Svelte isn't
| there yet. One day it probably will be, but today is not that
| day.
| slantyyz wrote:
| I think that's a chicken egg thing. If Wikimedia adopted
| it, adoption rates would skyrocket.
| ivanfon wrote:
| 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.
| joshwcomeau wrote:
| 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.
| draw_down wrote:
| HN will never pass up an opportunity to shit on JS or
| especially web frameworks, without fail. It's actually sort
| of entertaining.
| jeroenhd wrote:
| 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.
| spyckie2 wrote:
| 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.
| t0astbread wrote:
| The proposal stresses the need for Server-Side Rendering so I
| suppose they're thinking about this.
| otterlicious wrote:
| 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._
| marcus_holmes wrote:
| No idea why you were downvoted - this is the answer to that
| question
| hombre_fatal wrote:
| > but Wikimedia is a website and not a web application
|
| Check out the /edit mode for any page. It's already a non-
| trivial JS app.
| bawolff wrote:
| 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.
| mch82 wrote:
| Another interesting note is that Parsoid, the nodejs
| service that turns wikitext into the Visual Editor, is
| being ported from js to PHP.
| folmar wrote:
| The texarea is also currently the default, at least on
| English edition.
| est31 wrote:
| 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.
| aww_dang wrote:
| >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.
| nwsm wrote:
| >Will Vue and React work on 2G cell phones running super basic
| browsers?
|
| Yes
|
| >Will screen readers support all elements created by the
| Javascript framework?
|
| Yes
| untog wrote:
| React won't work _well_ on 2G cell phones with slow CPUs.
| It's a giant library both to download and parse and most of
| it is entirely unnecessary.
| layoutIfNeeded wrote:
| Please don't make Wikipedia a JS monstrosity :(
| k__ wrote:
| 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.
| jcarlosweb wrote:
| I think you should have supported Web components
| Alex_P13 wrote:
| Top 20 free and premium dashboard template in 2020
|
| To track all the performance on your website, these free
| dashboard templates come very helpfully for your website. With a
| dashboard template, you'll know exactly how well your online
| project is doing. For example, track sales, new members, likes,
| profits, tickets, you name it, it can all be done inside your
| ultimate dashboard.
|
| https://is.gd/P7BmMm
| lwansbrough wrote:
| 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.
| user34234 wrote:
| 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.
| ddevault wrote:
| 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.
| ricardobeat wrote:
| 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.
| unionpivo wrote:
| 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
| ddevault wrote:
| 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.
| azangru wrote:
| > 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.
| TeMPOraL wrote:
| > _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.
|
| > _If their site requires heavy client-side code_
|
| It doesn't.
| tcd wrote:
| 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.
| darkcha0s wrote:
| You seem to completely have missed what the foundation is
| about.
| ddevault wrote:
| Wikipedia is just hyperlinked documents. The WWW has been
| suited for this from the start. Not everything needs to be
| new and shiny forever.
| azangru wrote:
| > Wikipedia is just hyperlinked documents.
|
| Wikipedia at the very least has the editor for all those
| documents.
| tln wrote:
| 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
| draw_down wrote:
| 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.
| spyckie2 wrote:
| 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.
| aliswe wrote:
| Technology isn't an argument IMO. I know that is misrepresenting
| the rfc a bit.
|
| As a joke, why not wait for the hype to go full circle and then
| pick vanilla javascript/es6?
| noodlesUK wrote:
| Just in time for v3.0!
| [deleted]
| katabasis wrote:
| 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).
|
| [1]: https://www.mediawiki.org/wiki/Compatibility#Browsers
| trynewideas wrote:
| For context about OOUI and OOjs:
| https://www.mediawiki.org/wiki/OOUI/Using_OOUI_in_MediaWiki,
| https://www.mediawiki.org/wiki/OOjs
|
| 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
| tjpnz wrote:
| Not knocking Vue but what exactly is meant by modern? I work on
| the backend and hardly (if ever) see frameworks described in
| those terms.
| aliveupstairs wrote:
| 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.
| oleskiewicz wrote:
| 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.
| Richicoder wrote:
| The intent of this RFC is to improve the places _where
| JavaScript is already used_ like management tools and editing.
| superkuh wrote:
| 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.
| maps7 wrote:
| Isn't Vue 3 vastly different to Vue 1 and 2?
|
| Also why not Svelte?
| rk06 wrote:
| 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
| alphachloride wrote:
| What's wrong with plain old JS? Wikipedia is not a software
| company that it needs to use <insert-word-of-the-day> framework
| just to look hip.
| EvanYou wrote:
| 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.
| cptskippy wrote:
| > 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.
| abbe98 wrote:
| 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.
| BiteCode_dev wrote:
| This is IMO one of the killer features of vue.
|
| 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.
|
| Thank you.
| ng12 wrote:
| > 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.
| BiteCode_dev wrote:
| 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.
| ng12 wrote:
| > 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.
| TheDong wrote:
| 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.
| est31 wrote:
| 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?
|
| [1]: https://vue-hn.herokuapp.com/item/22625556
|
| [2]: https://ssr.vuejs.org/
| spyckie2 wrote:
| 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.
| [deleted]
| EvanYou wrote:
| 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.
| eknkc wrote:
| 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.
| darkcha0s wrote:
| 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.
| sdan wrote:
| +1 on Svelte. Seems like the better/faster option.
| MaxBarraclough wrote:
| Is it really faster for real-world uses?
|
| I know Svelte does clever things to avoid a virtual DOM, but
| is the difference in practice really appreciable?
| kreetx wrote:
| 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.
| MaxBarraclough wrote:
| 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.
|
| https://hn.svelte.dev/top/1
|
| https://vue-hn.herokuapp.com/top
|
| _Edit_ This site says the Svelte one wins on load times:
| https://hnpwa.com/
| wildpeaks wrote:
| 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.
| woutr_be wrote:
| 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.
| NetOpWibby wrote:
| If you wanna see Svelte in production, I'm using it for my
| homepage: https://webb.page
|
| I'm glad to see Svelte growing in popularity here.
| benbristow wrote:
| That page could literally just be a static web page or
| built using a static site builder like Jekyll/Hugo etc?
| NetOpWibby wrote:
| Of course it could but once you have a starter template
| setup it becomes an easy to jump right in.
| leadingthenet wrote:
| What exactly are you using Svelte for? It seems to
| literally be one HTML page...
| NetOpWibby wrote:
| To put it simply, I like it. Plus, I have a starter
| template project that makes it easy to just code and go.
| cmroanirgo wrote:
| 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.
| woutr_be wrote:
| > 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)
| currysausage wrote:
| https://html.spec.whatwg.org/multipage/syntax.html#option
| al-...
| slantyyz wrote:
| If you use Svelte with Sapper, you will get the "best of
| both worlds".
|
| The first page you hit has the content baked into the
| HTML, and all subsequent content "pages" load like a
| single page app.
|
| [1] https://sapper.svelte.dev/
| NetOpWibby wrote:
| Interesting, Firefox is my main browser and it's always
| looked fine to me.
|
| I also built https://socii.network in Svelte/Sapper but
| that's in need of a rewrite. Just a smidge.
| woutr_be wrote:
| Is it open-source? Otherwise it just looks like any other
| website, the code would be a lot more useful.
| NetOpWibby wrote:
| Yup! Here it is: https://code.webb.page/Webb/Homepage/com
| mits?branch=primary
| omnimus wrote:
| 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.
| twsted wrote:
| > 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.
| KaoruAoiShiho wrote:
| 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.
| rutierut wrote:
| 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.
| belval wrote:
| 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.
| whycombagator wrote:
| > 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.
| belval wrote:
| 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.
| tantalor wrote:
| Page Previews is a great example of leveraging "web app" that
| solves many problems at once:
|
| - quickly inform on a topic without clicking through (lower
| latency)
|
| - increase scanability (hence readability)
|
| - decrease expensive whole page loads
|
| - eliminate need to open many tabs
|
| https://www.mediawiki.org/wiki/Page_Previews
| enriquto wrote:
| Whatever, but if wikipedia somehow becomes unusable without
| javascript, it will be a real tragedy.
| jdlrobson wrote:
| 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.
| belval wrote:
| If that's the case then I am sorry for my earlier
| comment, Wikipedia is a treasure and you are doing
| amazing work!
| enriquto wrote:
| I cannot express how reassuring your words are, and how
| happy I am to hear them. Thank you very much!
|
| Well; it turns out that I can: just made a donation.
| vorpalhex wrote:
| 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.
|
| [^1]: See Gwern.net for an example of an easy pure JS
| hovercard - https://www.gwern.net/DNB-FAQ
| majewsky wrote:
| 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.
| [deleted]
| 112 wrote:
| 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.
|
| Angular has never been an option for me.
| fraktl wrote:
| What you wrote is blatant lie, particularly the part with
| creating a typed component library. I've created 7 components
| as of yesterday, using TS, zero hacks and zero problems.
|
| It's so annoying when a person with clear lack of understanding
| decides they're competent to critique a tool and then they
| literally - lie.
|
| Keep using React, it's awesome you like it but please - do some
| fact checking. I know you want to believe that Vue and TS don't
| play together, but that's just not true.
| nullc wrote:
| 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.
| fraktl wrote:
| > 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?
|
| Yes.
|
| > Even if they were intentionally lying
|
| Never wrote anyone lied intentionally.
|
| > it would hurt no one to humor it and be polite, and it
| would do a lot towards making this a more enjoyable places
| to read.
|
| I'm a programmer used to relay information in least words
| possible, so I just refer to factual observation. Whether I
| used word "lie" or had I masked it in a wall of text to
| spare feelings of flowers - meaning is the same. I consider
| all people my peers so I don't do to them what I don't want
| done to me - saying pretty words to hide the meaning.
|
| > Your post was informative, too bad it made me just want
| to close this tab.
|
| But you had to type what you have before you closed it. I
| mean, you're calling me out for being impolite by being
| impolite. I get the whole hypocrisy move and SJW reflex,
| but my stance is that IT and developers need to relay truth
| to one another in form of information, not prettify the
| stuff so people's feelings don't get hurt.
|
| Your feelings got hurt? You didn't get coronavirus because
| of my text, you'll be ok.
|
| Take care :)
| baybal2 wrote:
| 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.
| manigandham wrote:
| Why? Typescript just compiles down to JS, and type
| definitions are used IDEs so they still help when writing JS.
|
| How does removing typescript help you?
| baybal2 wrote:
| > How does removing typescript help you?
|
| https://github.com/microsoft/TypeScript/issues
|
| Please count the number of open bugs
|
| 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.
|
| No, it does not pay off at all
| cageface wrote:
| 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.
| smichel17 wrote:
| 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.
| williamdclt wrote:
| 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
|
| This is just not a thing.
| miffy900 wrote:
| > https://github.com/microsoft/TypeScript/issues > Please
| count the number of open bugs
|
| 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.
| SaxonRobber wrote:
| 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.
| cvlasdkv wrote:
| 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. :)
| manigandham wrote:
| 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?
| baybal2 wrote:
| 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.
| rpastuszak wrote:
| > 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.
| baybal2 wrote:
| Of course we do that, and I looked at Flow a few times.
|
| But typing errors are such a minor thing in comparison to
| everything else, than "everything else" is of much higher
| on the priority list
| [deleted]
| kashug wrote:
| 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.
| sbergot wrote:
| 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.
| thawaway1837 wrote:
| 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.
| scrollaway wrote:
| 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?
|
| This is some prime dailywtf material.
| afiori wrote:
| 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.
| MaxBarraclough wrote:
| > 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.
| matthewmacleod wrote:
| _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._
|
| It's genuinely terrifying to think that people out there
| with this attitude are producing software that I might be
| at risk of using.
| karatestomp wrote:
| 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.
| blackoil wrote:
| 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.
| inertiatic wrote:
| >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?
| 112 wrote:
| These mythical people are dinosaurs that have lost (or
| never had) their love for the work they do, and are not
| interested in improving.
| danShumway wrote:
| 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.
| orange8 wrote:
| 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.
| inertiatic wrote:
| >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?
|
| Okay.
| orange8 wrote:
| > 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.
| danShumway wrote:
| > 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.
| Udik wrote:
| > it will happily allow you to say that a method always
| returns a string when sometimes it returns a number
|
| Just replace "say" with "assume" and you have the
| javascript situation: javascript is just typescript with
| documentation stripped off.
|
| > Typescript is just documentation that compiles.
|
| Exactly. And we're arguing whether code should contain
| documentation or not.
| danShumway wrote:
| 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.
| Udik wrote:
| > 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.
| orange8 wrote:
| > 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.
| Udik wrote:
| > 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.
| manigandham wrote:
| Typescript is as strongly typed as you want it to be. You
| can easily work with dynamic types and it will fill in
| where it can.
| danShumway wrote:
| 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.
| giantDinosaur wrote:
| 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.
| orange8 wrote:
| Wow! What a mature, thoughtful response \s
|
| 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.
| boomlinde wrote:
| _> 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.
| ThePhysicist wrote:
| 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?
| capableweb wrote:
| 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)
| christophilus wrote:
| 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.
| capableweb wrote:
| > How are your production bundle sizes?
|
| 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 :) )
| LandR wrote:
| IntelliJ with Cursive is a very good Clojure IDE.
| capableweb wrote:
| 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.
| 112 wrote:
| 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.
| Kiro wrote:
| Sorry, but that's just crazy. I would avoid your company like
| the plague.
| W4ldi wrote:
| 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.
| watwut wrote:
| 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.
| anton_gogolev wrote:
| > ...the better your code style, guidelines, linting,
| infrastructure, error reporting and tests
|
| Doesn't TypeScript kind of solves (at least partially)
| those issues?
| wues wrote:
| "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."
| gherkinnn wrote:
| It's not either/or. Nice strawman you put up here.
| wues wrote:
| 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.
| sbergot wrote:
| 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.
| [deleted]
| bregma wrote:
| 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.
| Vinnl wrote:
| > 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.)
| chvid wrote:
| I agree with this.
|
| 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.
| dynamite-ready wrote:
| 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.
| marcus_holmes wrote:
| 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).
| STRiDEX wrote:
| so what you're saying is you avoid vue's poor typescript
| support by not using typescript
| izelnakri wrote:
| ember with typescript should be an option for you
| z0mbie42 wrote:
| I would love to know why are you saying this.
|
| I use Vue2 + Typescript, and for me it works great!
|
| Even Auto-completion works.
| fraktl wrote:
| Because he never used Vue with TS. It's a blatant lie and
| utter bullshit.
| 112 wrote:
| 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
| mcny wrote:
| 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?
| 112 wrote:
| 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.
| se7enzer0 wrote:
| Vue 3 is not too far off and has first class TypeScript
| support.
| manigandham wrote:
| 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.
| sebazzz wrote:
| Vue 3 is getting delayed, isn't it? Not weird for a community
| project, but still something to note.
| manigandham wrote:
| I don't know, there's no hard deadline but you can check
| the official roadmap:
| https://github.com/vuejs/vue/projects/6
| DanielBMarkham wrote:
| 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
| oefrha wrote:
| 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.
| frosted-flakes wrote:
| 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.
| manigandham wrote:
| 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.
| DanielBMarkham wrote:
| 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.
| StreamBright wrote:
| >> 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.
| williamdclt wrote:
| 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
| manigandham wrote:
| 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.
| honopu wrote:
| I think you're talking about universal or isomorphic
| rendering, but each of these allow for it.
| manigandham wrote:
| No, I'm talking about using hundreds of existing server-
| side web frameworks that output HTML, not Node/React SSR
| which is far more limiting.
| azangru wrote:
| > 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.
| manigandham wrote:
| This is only if you use SSR and is the opposite of being
| able to render with any existing web framework.
| kumarvvr wrote:
| Fantastic point.
|
| Vue has a bit more flexibility in that regard.
| keithnz wrote:
| 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.
| TekMol wrote:
| Can someone give a quick code example for the follwing?
| The framework allows UI elements to be defined in a
| declarative way
|
| How can you use Vue so that what you do is more declarative then
| when using a template engine like handlebars?
| aliveupstairs wrote:
| 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"/>
|
| Instead of an imperative JavaScript for loop.
| otabdeveloper2 wrote:
| How in seven hells is moving imperative loop constructs from
| Javascript to HTML supposed to be "declarative"?!
|
| If anything, it's the opposite - you're now polluting HTML
| with imperative programming features where there previously
| were none.
| TekMol wrote:
| 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.
| tannhaeuser wrote:
| 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.
| torgian wrote:
| This looks like a backwards solution to a modern problem.
| pier25 wrote:
| 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.
| jeswin wrote:
| 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().
|
| Couldn't see the value there.
| manigandham wrote:
| 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.
| shirshak55 wrote:
| and using promises with vue is nightmare.
| manigandham wrote:
| Using promises where? And what's difficult about them?
| idoubtit wrote:
| 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.
| manigandham wrote:
| 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
| mmis1000 wrote:
| 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.
| keithnz wrote:
| 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.
| rk06 wrote:
| do you want to see the value? if so, here it is:
|
| 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
| untog wrote:
| > Couldn't see the value there.
|
| 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.
| martin_a wrote:
| 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.
| shirshak55 wrote:
| 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.
| boobsbr wrote:
| That feels like learning Angular template syntax, and I really
| dislike it. React has its warts, but I find JSX very readable,
| much more flexible.
| ptrwis wrote:
| 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).
| boobsbr wrote:
| That feels like JSP to me, and I don't have fond memories
| of JSP.
| imtringued wrote:
| JSF somehow managed to be even worse than JSP.
| pmarin wrote:
| Most of Wikipedia works perfectly without Javascript I hope it
| will continue to do so.
| k__ wrote:
| Modern JavaScript runs on the server just fine, they will
| probably use server side rendering and build time rendering.
| vorpalhex wrote:
| Server side rendering is _slow_ and _expensive_. Wikipedia
| needs to be fast for all of it 's users, and needs to be very
| cost centric.
| karatestomp wrote:
| 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.
| k__ wrote:
| Static site generation is very cheap in terms of generation
| and delivery.
| vorpalhex wrote:
| Yes, SSR and static are not the same.
| b34r wrote:
| The developer experience of working with Vue is significantly
| worse than React in my personal experience...
|
| Too much file separation, "magic" in the templates, etc.
| [deleted]
| otabdeveloper2 wrote:
| Good, I needed a reason to stop using Wikipedia.
|
| Good bye.
| a_imho wrote:
| It reads as a solution looking for a problem.
| lwh wrote:
| Not needing JS is a key feature of MediaWiki. It would be great
| if the old CSS+HTML skins still worked with this.
| [deleted]
___________________________________________________________________
(page generated 2020-03-19 23:01 UTC)