Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vue.js is Wikimedia Foundation's future JavaScript framework

lists.wikimedia.org

Post reply on HN
Print view View original

151–160 of 204 posts

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#151

Post by hitekker »

nanagojo wrote: post #35
ggregoire wrote: post #21

Earlier quoted context omitted.

Although I understand what you saying about big shifts and kinda shared your opinion, specially about hooks, I started a new project from scratch last week and decided to give hooks a try (and, for reference, I've been using React on a daily basis for 5 years). Oh boy I was wrong. Hooks are way more easier and intuitive than what I thought. It makes code so much more readable and easier to reason about. Especially wh…

IMO it is good that the React team was open into investigating different paradigms. It's a good thing and you rarely see this with other big projects.

Well-led projects tend to create new spin-offs rather than overextend their original idea. The former is riskier and more liable to fail, whereas the latter chases diminishing returns and undermines the conceptual integrity of the system.

Microsoft forcing Windows on mobile devices in the 2000s is an easy example of that kind of failed leadership.

This subject matter is covered extensively in: https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#152

Post by manigandham »

dmitriid wrote: post #137
manigandham wrote: post #132

Earlier quoted context omitted.

Text inside script tags is parsed as JavaScript by default. It can be other languages too, like typescript inside a .Vue file. Again, it’s all just text in different syntax. Programming languages are just a very large and well defined syntax compared to a template language, but that’s all it is. Vue’s directives offer just enough control to handle 99% of scenarios while remaining within HTML.

> Text inside script tags is parsed as JavaScript by default. It can be other languages too It can be, but usually isn't. > Again, it’s all just text in different syntax. Again, it's not. And the reason is simple: the browser literally knows nothing about other syntaxes but Javascript [1] So, no, "text in Vue" is literally not the same as "text in script tags". It is a mish-mash of: - Vue's own DSL (see v-for) - JS e…

The point is that all code starts as simple text, and is parsed and compiled into some lower layer until it finally gets to machine code. What actually does the compilation is irrelevant.

All of these JS frameworks (React+JSX, Vue+HTML, Angular, Svelte, etc) require template compilation into an actual JS render function before a browser ever runs it, but compilation is the same fundamental process regardless of language or environment: https://en.wikipedia.org/wiki/Compiler

So yes it's all just text following a different syntax, and Vue's documentation already describes exactly what you can run: https://v3.vuejs.org/api/directives.html

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#153

Post by manigandham »

baybal2 wrote: post #129
manigandham wrote: post #110

Earlier quoted context omitted.

All JS frameworks will share some features. What specifically about Vue do you think is unnecessary or shows that the Vue team doesn't understand?

I tried React during its early years, and switched to Vue. It's just a little bit more coherent platform than React. There are core Vue projects, and they go in lockstep with Vue releases. Second, Vue understood how fragile, and the same time important tooling is. There are many very mature Vue packages to scaffold, and manage your Webpack, or other build system setup for you. This saves a lot of hours because if thi…

Vue still has the same progressive-enhancement low-tooling approach as before. It's only broadened in its ability to be used in more complex environments with full toolchains but you can just add a tag and start coding.

I do agree that Vue 3 was rather badly released though, as everything from the websites and docs to the plugins and devtools were all at different stages.

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#154

Post by nojvek »

Over more than a decade I have gone through Adobe Flex, jquery, vanilla js, angular 1 & 2, vue 1 & 2, React, a bit of svelte, web components, my own custom state mgmt libraries.

The fundamental idea behind most modern FE frameworks remain the same. View is a function of state. The hardest problems in FE are state management and CSS/dom layout.

So as long as someone knows what they are doing any of the modern frameworks do a decent job. I have seen bad code in every framework.

So if the Wikipedia team knows Vue very well and yield its powers, may the force be with them.

Use the framework your team knows best. It’s really about the players more than the instrument.

I personally like React. It solves many of the pain points I’ve experienced over 10+ years. I’ve invested a lot of time learning it in depth. If someone told me to write react from scratch with hooks api, I know how to do it.

Seems Wikipedia chose Vue because folks knew Vue in depth. That’s a good way to move forward.

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#155

Post by seph-reed »

gherkinnn wrote: post #108
seph-reed wrote: post #15

Earlier quoted context omitted.

"The freedom of React" is a hard statement for me to digest. I stopped using React specifically because it was so incredibly limiting. And my life has been a lot better without it.

Within its area, React is very unopinionated. Ask three different devs and you’ll come back with five answers. Vue doesn’t have that. And yet it doesn’t lock you down the way Angular does. Now, what that “area” is, remains up for discussion

I don't use Vue either. It's also a bit too opinionated IMO.

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#156

Post by zkldi »

likeclockwork wrote: post #88
zkldi wrote: post #58

Earlier quoted context omitted.

> :href="xxx" isn't a string, that is javascript in there. This is the part I don't really follow, though. Technically: href here isn't a string, it's python, but it's stored as a string, representing python. In the :href example for JS, that's not JS - an engine isn't seeing that - that's a string that is evaluated as JS at some point in the vue lifecycle.

It's not stored anywhere. You seem to be upset that it's written with quotes around it. Are you aware that most computer programs are just text?

Yes.

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#157

Post by masklinn »

lmm wrote: post #141
masklinn wrote: post #127

Earlier quoted context omitted.

People like templates, and the clear and declarative correspondence between input and output. You can write React without using JSX, and I assume Vue without templates, but unless the components system has a declarative layer so thin it might as well be templates (e.g. elm, or clojure’s hiccup) and it is entirely expression based, they’ll want templates. Wicket looks like absolute nonsense of the worst kind. It compl…

> People like templates, and the clear and declarative correspondence between input and output. You don't get that clear correspondence if you can have logic in your templates, and even supposedly simple expression languages in templates somehow always end up growing ifs, looping constructs and so on. Plain HTML fragments are good, but they need to be kept absolutely simple. > Wicket looks like absolute nonsense of t…

> You don't get that clear correspondence if you can have logic in your templates

You absolutely do.

> I don't understand your position at all. The problems of Struts and Spring are the problems of templates only more so - if I were to make a spectrum I'd have Struts (and Tapestry) at one end, Wicket (and hiccup) at the other, and traditional templates somewhere in the middle.

The struts I got to use was full of "smart JSP custom tags" because "components are the right way" and subclasses all the things, it looked exactly like the examples I see of Wicket: keep bouncing through layers and files of useless nonsense because all the logic has to be out of the markup but all of the markup has to be out of the code, and formatting a list takes you through 3 templates and 5 classes.

> Wicket (and hiccup) at the other, and traditional templates somewhere in the middle.

That makes no sense whatsoever. Wicket and hiccup have nothing in common.

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#158

Post by seph-reed »

vagrantJin wrote: post #98
Aeolun wrote: post #25

Earlier quoted context omitted.

React does not seem like a good fit for doing any of these things. Aside from keyboard navigation, which works just fine as far as I’ve seen. I dunno, every time I see someone hating React they’ve been kind of stuck in doing things the jQuery way, and their components become this horrible frankenstein of modifying HTML both through React and directly.

> their components become this horrible frankenstein of modifying HTML both through React and directly. I need to know what the problem is with modifying HTML inside a browser that knows and expects the HTML to be modified, even providing DOM APIs for this exact reason. What is the benefit of modifying a not the DOM besides the dubious claim of performace++? I use react everyday now BTW. I needed to do something triv…

Nothing at all. I've been using a custom made framework for 3 years that does everything React does and more. I could write the whole thing in a weekend. It's not hard, you just cache some functions that create HTML Elements, keep track of what state variables are used inside those functions, and rerender whenever those variables change.

React was a dumb idea from the very beginning, and anyone who knew vanilla js well could tell you that.

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#159

Post by zkldi »

Exuma wrote: post #78
zkldi wrote: post #58

Earlier quoted context omitted.

> :href="xxx" isn't a string, that is javascript in there. This is the part I don't really follow, though. Technically: href here isn't a string, it's python, but it's stored as a string, representing python. In the :href example for JS, that's not JS - an engine isn't seeing that - that's a string that is evaluated as JS at some point in the vue lifecycle.

Without refreshing my knowledge on it, I don't think it's actually a string. A block is actually a "single file component" which is a special vue plugin/loader/whatever for webpack. It compiles template/script/style tags into a single compiled version. I'm like 60% sure that your "string' example is never run in production. So I believe that it gets compiled before vue even sees it (at build time, or dev-server compi…

Then that sounds pretty good that it's not ran in production and compiled out!

I guess my remaining alien issue is that the DSL for Vue is a mish-mash of JS, custom syntax, dom attribute context and possibly more?

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#160

Post by zkldi »

Drew_ wrote: post #67
dragonwriter wrote: post #62

Earlier quoted context omitted.

> "It reads like storing code in a string and evalling it" sounds very funny in this context because that's exactly what every solution does. Its not, though. JSX-based solutions (not just React, but Solid and others) don't (actually, neither do many frameworks with more traditional-looking templates, including, AIUI, Vue, actually compile templates to render functions, so it just looks like old school “string with e…

I know it's pedantic but this is still JavaScript we're talking about not binary so the "compiled render function" is still ultimately just "a string that gets evaled". In any case the implementation details aren't important it's what it appears to be that is apparently the problem.

> it's what it appears to be that is apparently the problem.

Yep, Someone mentioned in another part of this thread that Vue compiles most of this out before production, so my remaning confusion pretty much stems from the DSL being a mishmash of html attribute context, vue custom syntax, and evaluated JS.

Post reply on HN