Just because something exists doesn't mean one has to care. The problem with "frontend fatigue" is similar to what we see elsewhere; caring about problems one doesn't have or own in the first place. I'm not addressing you specifically (as your comment seems more observatory) - but I reckon it's still worth pointing out.
Let the curious create and share their creation with the world.
I agree about the principles but not about how it happens on the real world. Many front-end jobs now require you to know at least one front-end framework (normally React), which is a totally different and focused problem-solving tool. Before you had jQuery that scaled from small, personal projects to mid-size projects. This worked great as a learning progression, however now you have React (and others) that don't make sense for small projects and are a bit overkill for mid-size projects.
So new developers get thrown in this crazy world where they have to learn a thing that has no real practical use just because they want a job in the field. IMHO, new tools must make things easier for everyone and specially for newcomers, while React seems to make large-scale problems easier but a LOT harder for beginners.
And finding a new job is a problem that we all have from time to time.
I really dunno - I find React to work really, really well in the small and medium projects where I do (any) web work. Coming to React after years away from frontend development, and avoiding it because of things like jQuery, was really awesome because it demands that you enforce separations of concerns in a way that really appeals to me.
Hell, I generate HTML email with React, now. No reason not to; it's great. Simple, understandable tree of reusable components that have understandable data flows--sign me right up.
The biggest problem with it is the initial activation energy of a new project, which is partially solved through create-react-app and largely solved by doing it once in a replicable way. (I've been creating React projects off of the same base for quite awhile now.)
Tooling and build process is still a problem for trying out react in personal small/micro projects. I miss the days when I just drop in jquery.min.js and boom! We can hack something to our heart's content.
Dunno, the only apps I can think of that don't benefit from React are just toy apps or little things like <form> upgrades.
You're way off if you think React doesn't work for anything other than large apps.
I've been bitten this many times where my "little app" grew, and the non-framework code complexity would grow quadratically where I regretted not just using a framework like React in the first place. So when I hear "React is just for large apps", I can't take it very seriously.
I once told my non-technical friend about the hypewars and giant refactorizations that websites go through every few years and she couldn't believe it. Websites have hardly changed from the users perspective for like the past five years, yet in the background we keep modifying our tools.
I love this epic Businessweek story by Paul Ford that explains what's involved with coding by using a (hilarious) story of being a non-technical VP at a medium company trying to manage a website replacement.
"Technology conferences are where primate dynamics can be fully displayed, where relationships of power and hierarchy can be established. There are keynote speakers—often the people who created the technology at hand or crafted a given language. There are the regular speakers, often paid not at all or in airfare, who present some idea or technique or approach. Then there are the panels, where a group of people are lined up in a row and forced into some semblance of interaction while the audience checks its e-mail."
I have yet to do anything on my webapp that uses a JS framework (the minimal interactivity is raw JS and at most a touch of jQuery) precisely because I've yet to see a framework that I was somewhat confident would be relatively stable over the long term, say 10 years?
Something like "COBOL for the web" would be ideal. But if I were starting now I wouldn't choose Angular 1.x, would I? Any recommendations.
Angular 1 has its flaws but I've found it to be pretty stable, has developed some pretty consistent paradigms, and gets certain jobs done well. Don't put the round peg in a square hole, but I think it serves many web apps well, particularly if you're going the SPA route and don't care too much about things like viewing without javascript or ultra fast load times.
I used it first in a personal project, then in a job, and have used it after in a personal project. I think that says it's at least not the worst. I've wanted to look into Vue and React for some time but I'm mostly a back end developer. Angular is getting the job done to the point that I haven't been forced to switch.
My position exactly: backend developer who only wants to do the minimum on the frontend.
But for the next stage of the system (rich media streaming), it will require a whole lot more interactivity on the front end and the time has come to decide on something!
I'm leaning towards Vue because it seems easier to grok as a solo developer while still having plenty of power and support... but I'm indecisive!
Vue - It's been described as "Angular 1 without the flaws" before to me. I think it'd probably be the easiest transition. It also seems to have the advantage of being able to be sprinkled in lightly or heavily, dealers choice.
React - As someone who loves functional programming, Redux immediately clicked for me, and I do enjoy that idea of state. However, it seems like a lot more work to learn it coming from Angular 1 for someone who is doing the minimum front-end and when it comes to any serious project will be working with a true front end developer.
I'm just hearing of Moon obviously but I'll be keeping an eye out for the name when I am forced to switch from Angular 1.
As somebody who does a mix of front end and back end fairly regularly, I think you're pretty on the nose here.
If I can extend a little further, React is favoured (outside of the potential as a state machine) as the front-runner in isomorphic front-end apps. Of course there are also some lighter-weight similar frameworks like InfernoJS, and Preact, but React is certainly the one with the largest community and more robust support.
If you're looking for mainly UI event handling, 2 way binding, etc, Vue is extremely capable and will probably keep your fingers (and maybe mind) a little cleaner. It can take a lot of the load and repetitive work out of developing that end.
If you're looking to build out a UI with a large number of repeating elements, again state-handling, then I have to say I love working with React. It even caused me to change my way of thinking toward building out framework-less front end applications.
Another plus with React is the large number of pre-built UI design frameworks and components that you can simply drop in everywhere and modify to the extent you really need to, if at all.
As for media streaming, HLS.js (https://github.com/video-dev/hls.js) is a dream tool! There are some tricky bits to figure out that aren't documented overly well (like where the ID3 data is hiding amongst a single Uint8 array that has to be encoded and spliced), but the demuxer works like a dream without a heavy load increase and the event system is easy enough to work through.
That is if you're building out your own custom player. I work at a media company and had to build out a custom player to diagnose some issues with stream metadata coming from a number of radio stations through a series of nodes (with no streaming media experience at that level previously) and I was able to get it up and running inside of a day or two.
Thanks for the comments: very helpful! As I said in another comment, Vue looks increasingly the best choice given the use case and my experience.
It's actually going to be everything except streaming video; going to send through audio, image links, and some extra data, and mush it all together at the client.
Fortunately I don't have to worry much about adaptive bandwidth, since for the target audience we can just kick them off if they don't have enough bandwidth... if they can't get the 24 kbps for the Opus stream, then too bad!
I'll have a good look at HLS.js. But I'm prototyping out using WebRTC to do it rather than HLS, given that iOS 11 will support it natively. Unless people have a strong argument against doing that way...
Best advice is probably to prepare for a lot of front end. Doing "the minimum" takes considerable skill and experience.
Angular 1 or 2 makes some things simple by providing a proper "framework" in the place-logic-here sense.
OTOH it can also be constraining because anything not matching that framework will be almost impossible to force in.
And when things gets a little more advanced than the todo-app you suddenly have to learn lots of complex parts of the framework at once.
React falls on the other end. Things stay relatively simple from todo and up, so easy to grow with. But there is no framework and no real consensus, so you need to evaluate a lot of debates and variations on how to approach things to move forward, this can require a lot more experience.
My system is a number of independent components that are each individually simple enough to not require a framework, and don't share any common code. It's only a few hundred lines of JS and jQuery.
One of the components is a keypad and display for a judge to enter scores... basically a web-connected traditional calculator in its design. :) So "minimally interactive" is probably a poor description on my part; it's nothing but interactions, just really simple ones.
If anything, I wouldn't be surprised if to many users websites are much shittier than they were five years ago. No wonder so many people I know pretty much exclusively stay within the clean confines of facebook for much of their information consumption...
No: it leaves no goat unblown. Particularly for people new to it.
Back in the day anyone could hack together a bit of JS for their website and get something up and running, even if it was a bit Heath Robinson. You actually still can do this but you wouldn't necessarily come away with that impression from reading about front-end development. Cynically, it sometimes feels like front-end developers are overcompensating for years of JS derision from "real" programmers with the plethora of tools and technologies you "need" to know.
If people want to use this, well, they're welcome. I can even see some benefit to a very lightweight UI/framework, especially if you don't have to worry about any version of Internet Explorer below 11, because the browser APIs these days are pretty comprehensive, and tend to behave reasonably consistently. Likewise CSS. [1]
Still, I can't get in any way excited about yet another library/framework. Go ahead and use it if you like but don't be trying to evangelise me about it.
([1] As an aside: I will say that IE11 is still something of a problem child in terms of not supporting some things I use, or not supporting them well - flexbox is an obvious example. Conversely, "scumbag" Chrome can be a problem child simply because it lets you get away with doing things that you shouldn't be allowed to do at all. E.g., `element.style = 'display: none'` instead of `element.style.display = 'none'`, meaning that when you come to test your code in other browsers... it breaks.)
"blows goats" goes back decades, but tbh I never really thought about what it meant until this comment came forth with the hyperbole of fellating literally every goat in existence.
I'm pretty new to it still, and boy do I disagree with this. I hadn't touched web development for about five years, prior experience being largely JavaScript-free after being chased well off by an employer's MooTools monstrosity, and coming to the modern JS world, with React and even Redux (though I think its APIs feel really clunky), was awesome.
These tools are less "Heath Robinson" and more prove that you understand what your stuff is doing, but that's a feature--I'd rather put in the spadework up front and be more assured of it doing expected things when it runs.
When you code something, choose the most strict browser/compiler you can. Then you get it right the first time and don't have to see it break so much later when tested elsewhere.
Funny thing: mobile Safari is a deeply frustrating browser to work with simply because it lacks proper full screen support and is very twitchy about showing/hiding its chrome (problematic for my use case). However, desktop Safari does often seem to nail the standard, at least for the APIs I use most.
Well, I think that compared to other fields, it's quite hard to get on board - there is so much tooling that it's really hard to catch up. There is node, npm/yarn, webpack, gulp, scss/sass. If you're back-end dev coding in ruby, you just pick rails and you're done if you're python webdeveloper, you pick django, and so on.
With front-end? After hours of fighting with Babel and Webpack, you can pick Angular, React or Vue. And it's hard to know witch one to choose if you're some beginner who just want to code efficiently.
if you make a simple backend thing, pick up rail and you're done, but you're essentially building something that's a solved problem.
The frontend equivalent is dropping a script tag on a page and uploading it by FTP.
But there's a reason backend communities accepted devops long before frontend. Between all of the various BE platforms, all with their own dependency management intricacy, all the various databases, big data stores, queues, streams, object stores, cache systems, containers (docker, VMs, etc), the OS (for FE you can just drop your stuff on S3 and stick a CDN in front and it will scale to near infinity...try to scale your rails app like that for giggles).
Yes, but STARGING in backend is easier. I don't try to say that FE is harder, just that this wall between beginner and modern standards is higher here. After this wall it's probably harder in BE that in FE, but I think this wall is higher for FE devs.
Hell yeah! We're finally iterating on the problems that have made web development suck -- state management, non-imperative models, reasonable abstraction layers, modularization, etc. Fatigue is a good problem to have, it means people are trying really hard to solve important problems.
Part of the fatigue is the analysis paralysis everyone is suffering waiting for things to settle down. Also rewriting everything every five years has a way of fatiguing a person.
Meanwhile I have 20 year old object pascal code continuing to work and run in production.
Even iOS which is a fast moving target provides fantastic compatibility with older code that I wrote in 2009
This is why I am orienting my frontend work towards Web Components.
There are several libraries/frameworks that enable us to write Web Components now, even though browser support for the spec isn't fully there. E.g. [Aurelia](http://aurelia.io/) and [Polymer](https://www.polymer-project.org/) have great features, component APIs, and cross-browser support.
I came to frontend development on the peak of web 2.0 craze, when 10mb of jQuery "bells and whistles" on a corporate front page was considered hip and progressive. No matter how awful these 10mb of animation scripts were, they ran faster than 1mb of "highly optimised" react spa today.
Can you really prove that feeling? because that's far from my experience and far from logical too..
Additionally, this 'fatigue' with front-end is getting a bit over told, I suspect it might be more alienation from developers who hacked jquery scripts together and feel they need to transition to app frameworks (I see so many simple websites and landing pages as react etc now).. where as those sites should just transition to vanilla js + dom..
The thing about inspired frameworks and 'churn' isn't a javascript/front-end thing, it happens everywhere, constantly... how many IOC, DI, ORM frameworks did Java and .NET have..
A lot of people got a lot of productive work done 'hacking' together jquery and jquery-ui scripts. The result wasn't pretty and was a bit of a maintenance nightmare.
They are not only a bit of alienated by having to work with frameworks, but they're expected to be as productive with these frameworks as they were hacking together jquery scripts and snippets, but are still the 1-man or 2-man developers within a wider business.
These frameworks are great in a business built around the web such as a SAAS business, but a lot of people are in businesses where their saas part is secondary, or are trying to maintain sites which just aren't the main product of the business.
They're pressured by well meaning but often misguided higher-ups to use the latest and greatest and feel the pressure of churn.
>They are not only a bit of alienated by having to work with frameworks, but they're expected to be as productive with these frameworks as they were hacking together jquery scripts and snippets, but are still the 1-man or 2-man developers within a wider business.
So so so true... but I can give a correction to the size of the team. I personally witnessed 10 to 45 man teams doing things as simple as a web app with a sole function being "login, enter account number to send money to, enter amount of money to send, and press the button"
While 45 is a bit of exaggeration on my side, as it counts team's own accountants, HRs, and 20 something PMs, "change manager" types, and other obscure managers of managers
>Can you really prove that feeling? because that's far from my experience and far from logical too..
Cyclomatic complexity went up many times. Going over a simple for loop in under 100 kilocycles for client side page generation was considered ok back 10 years ago. Even then, browsers had no problem with that.
Compare that with 20 plus layers of deep merges, with closure tricks, with prototype swapping on the fly in a transpiled observer pattern style input event handler - things like that you have in relatively simple SPAs today
I'm a big fan of Vue and I think Moon looks very promising.
I have some questions w.r.t Vue API compatibility:
- In Vue, you can call a method or access a variable directly using this.var or this.fn, did you deliberately choose to do it in a different way or are you planning to implement this using defineProperty?
- Are you planning to implement filters and refs?
- Are you planning to make it compatible with Vue to make it a drop-in replacement?
If it's gonna be a drop-in replacement and existing code can be reused, I can imagine testing it for some projects (framework7 based).
Edit: Another idea would be to integrate all the performance improvements in Vue, Evan You is a great developer who single-handedly built this great framework and I think it's a good idea to make your ideas available for the whole Vue ecosystem. Are you having plans to do that?
1. I'm not planning for this, as it has a runtime cost, but it can easily be done with a plugin[1].
2. I'm not planning to implement filters, as you can use methods instead. Refs might be coming if there is enough demand.
3. Moon is actually going in a different direction from Vue now. The core API will be very similar, but it might not be a drop in replacement for some of the advanced features of Vue. Most directives work, components are similar, but it won't be fully compatible.
EDIT: To answer your edited question: I agree, Evan is a super smart developer, kudos to him for building Vue!
Applying some of the performance improvements might be a little complex for Vue, because Moon's compiler is fundamentally different in a couple ways. It generates code for a stricter HyperScript-like syntax (called "HyperMoon"), while Vue aims to be compatible with JSX as well.
Differences like these, while might seem small, are actually pretty complex when implemented in code.
That's a tough path you took and I wish you'll reach your goals. There are currently many frameworks who want to get the mind share. Would you mind to share your mindset behind the decision to split and build a new framework?
Is there something in Vue you oppose or new concepts you would like to introduce?
Would be very interested to hear your thoughts, I'm always on the lookout.
No problem! I wanted to build a new framework mainly because my Vue app was becoming slow and I wanted something small. Moon is 7kb minified and gzipped, that makes it really fast to load on mobile.
If you take out the compiler (similar to Vue's runtime version), Moon is only 3kb minified and gzipped!
Check out the Medium Article[1] and the README for more information on why I made it.
Ah thanks, missed the "Another library?" part. I think it's a good idea to address this question because this is the first one someone has after reading the title (Vue, but faster & smaller). Maybe I'll use it for some side projects, would be interesting to see if it is still easy to develop with a subset of Vue's API.
Can you explain what makes moon so much smaller and faster than vue ? What are the key differences ? Does it lack features ? Could vue use some tricks from moon ?
It's 7kb minified and gzipped. Vue is almost 30kb. If you use a runtime version of Moon, it becomes 3kb. This makes it faster to load on mobile devices.
Along with that, it also has lots of official plugins similar to what Vue provides.
Sure, don't get me wrong—I'm not saying it's useless or it isn't an achievement.
You have to realize though that as developers we invest a lot of time on learning a technology. Companies invest a lot of money into stacks. It's not always easy to find developers and if your stack is "standard", it makes it easier to both grow your team and get up to speed with the code.
For a developer, company, or team, 23KB of JavaScript aren't going to be a very good incentive to ignore the advantages that come with using a standard framework like Vue. Websites are easily 10MB in size nowadays, 23KB are a drop in the ocean. I can optimize the logo and get 23KB without have my team learn a whole new framework.
What I'm trying to say is that I don't think "smaller Vue alternative" is a good selling point. If anything, because as your framework gains acceptance people will want more features, and it will inevitably grow, and there goes your competitive advantage.
It should do something better, or differently in a big way or a way people care about.
Just my two cents. I've never created anything that a huge number of people use, so I'm no institution in this area.
> You have to realize though that as developers we invest a lot of time on learning a technology
But plenty of front-end developers have not developed in Vue. If I'm starting a new project and someone suggests doing it in Vue, and I have to learn it all anyway, I might consider this as an alternative.
The size is not a factor at that scale. Mobile suffers from issues latency, not with the 10-50K size difference.
You can't compare your framework to something else (in size) if your framework does not account for backward compatibility and is missing some of the features.
Does it support native mobile development? To me that's an important issue. Vue has Weex. React has React Native. Angular has NativeScript. I'd need something similar to switch to a new frontend framework.
it's significant because code has to be additionally parsed and JIT-compiled. which is not true of images which simply blit pixels to screen as they decompress; it's not simply about size on the wire.
>it's significant because code has to be additionally parsed and JIT-compiled.
Which again be insignificant compared to the time it takes to download those assets from a cellular connection.
Not to mention that today's (and 2015's) mobile CPUs aren't that slow, they are comparable to mid-level laptops from 2010 or even later. If you're catering to the developed world, visitors wise, you'll be ok with 30K.
Even in parse time, a 23kb difference would be barely if at all noticeable on the worst performant devices. That chart is for 1MB of JavaScript, and I assume the x-axis is in milliseconds.
But many libraries that has a primary focus on library size are usually sacrificing runtime performance to reduce size. Yes, they've reduced parse time, but significantly increased bootstrap time.
I understand that they are doing it because of marketing reasons, because many people think that smaller means faster.
The title here says 7kb your front-page on moonjs.ga says 5kb and on the overview page comparing it to other frameworks it says 6kb. All say minified and gzipped.
I chose to be different in small things, such as being explicit about getting and setting properties on an instance. There are a couple oddities I didn't like with Vue as well, such as the syntax for a couple directives.
Check out the Medium article[1], it has the main reasons on why I made Moon.
How does Moon automatically detect static virtual nodes? What makes Moon faster than the alternatives? Finally, how does Moon avoid GC pressure with large trees?
The compiler treats everything as static by default. When the compiler detects something dynamic (such as a {{mustache}} template), it will mark the current node as dynamic, and the parent node as well.
These propagate up the tree so Moon eventually has a render function that is extremely optimized and can skip everything static, and the diff will only hit the nodes that can change.
Moon also has a stricter syntax for virtual DOM, allowing for less checks to be made at runtime compared to alternatives like HyperScript. This is made possible because Moon's compiler itself is in charge of creating the render functions, allowing it to give certain hints to the virtual DOM diffing engine.
There is really no way to avoid GC when you have a virtual DOM. The virtual DOM trees are pretty light and have memory usage similar to that of React and Inferno.
Typed arrays are essentially tightly packed chunks of memory that the GC won't walk. If you know what you're doing, you can use them to both save memory (shaving off the per-object overhead of JS objects) and reduce the time spent on GC collections (but you have to do your own memory management on the typed array). That the typed array contains only objects of a single data type probably also helps the JIT to optimize.
what's the cost of resetting & reusing pre-allocated memory vs letting the GC discard stuff.
if the cost of resetting is greater than the cost of collecting & re-allocating, then you're in the same place. at least in my experiments of trying to reuse already-allocated virtual nodes and resetting their properties was slower than simply unreferencing them for the GC and re-allocating new ones.
have you tested the tradeoffs of your approach in modern browsers? (i see the repo is somewhat dated).
I just reran the test page in the repo and browsers have certainly improved. The gains have shrunk to the point (2x speedup at best) that the use of an unsafe API would not be recommended for general use. The test can also run a 'Simple' virtual dom which is a naive implementation with Javascript Objects. That one is currently faster than the typed arrays in Firefox, but in Chromium, the typed arrays are still much faster.
As a vdom hidden behind an API like in the case of Moon or Vue, typed arrays could still make sense.
> The gains have shrunk to the point (2x speedup at best)
call me a skeptic, but i suspect that whatever impl you're comparing against is not terribly good.
this bench [1] allocates (and discards) ~3,000 virtual nodes per redraw, and each redraw is ~1.3ms, pegged @ 60fps.
the GC time is ~2% [2], so even if all GC went away, a 2x speedup is plain impossible. unless you're suggesting that the majority of the time spent in "Scripting" is heap allocations, which i'll concede may be a good amount - do you know if there's a way to measure cumulative time spent growing the heap?
> whatever impl you're comparing against is not terribly good.
Indeed it is not. The reference is a naive Object based DOM. The benchmark is also not using complete rendering and diffing: it uses versioning on the nodes. It replaces the updated dom nodes at a configurable rendering frequency. So it's very different and probably slower than current frameworks.
The remark that triggered the mention of baredom was the supposed unavoidability of the GC. Baredom does not use it and WebAssembly might make non-GC VDoms popular. Still, JS engines GC has gotten very good.
This is really great to see the emphasis on static vs dynamic parts in templates. Polymer, Glimmer, and some other template systems make the distinction between static and dynamic content, but React and most other vdom libraries don't.
I was looking for options for HTML templating in JS found that JS template literals very naturally separate static and dynamic sections between the literals and expressions. I've been testing a library based on them [1], and for real-world templates with large static sections, it's indeed faster than traditional vdom.
> This is really great to see the emphasis on static vs dynamic parts in templates. Polymer, Glimmer, and some other template systems make the distinction between static and dynamic content, but React and most other vdom libraries don't.
All other "static" optimizations doesn't make any noticeable difference in performance in highly optimized vdom libraries. In fact, they are usually decrease overall performance because of increased implementation complexity.
Yes, and that is because Vue uses hyperscript. This allows you to use JSX, but at the same time makes a render function slower. Since Moon's virtual DOM syntax is stricter, it allows for the compiler to make lots of optimizations.
Thanks, that makes a lot of sense. It sounds like the compiler is providing most of the benefit. Agreed about GC. It's a significant portion of time in Asana for large task lists.
The performance improvements are impressive if they translate to real-world apps, however speed is only one of the reasons I use Vue.js. The other big reasons are stability and incredibly good documentation.
I've lurked a while and seen people give all the js is shit js fatigue blah blah and again we have this on this.
question I've got to ask to people posing this question is are you not adaptable enough as a programmer to learn things fast?...I was a c# programmer and in 1 month it was like yeah no problem I understand the new tools. in fact the new frameworks taught me a lot about functional programming which was fantastic.
You can winge all you want but it's here. It's not going away due to corp IE9 and to be honest it annoys me because the js ecosystem as well is the nearest to open source ideals at the moment as a lot of people are sharing code. I can fix any bug in my dependency because I can read the source.
Yeah maybe some packages are useless. but tbh they're the ones that will sink to the floor but the good ideas are passed about like a zep cd. js is the first meme language (in the Dawkins sense) and it's extremely interesting to see it develop in the public eye
It's not that it's hard to learn this stuff. More so, it's tiresome and hard to care after watching the JS community re-inventing the same wheel(s), repeatedly.
Personally, I'd rather see the JS community solve a wider variety of problems.. instead of the same ones, over and over.
The amount of talent focused on building JS tools really is incredible. But it seems like the tools that generate the most hype always do the _same_ things, just in a shinier newer package. Which is frustrating.
I wasn't around at the time, but reading about programming languages past -- it seems like these are the same kinds of problems that fractured Lisp, back in the day.
The problem is this: It's fun, exciting, and relatively simple to roll your own X. So everyone does it. That's good. But too much fractures the community, instead of uniting it. Which.. may be more harmful than helpful, in the long-run. Time will tell. But the strongest & most productive communities typically converge on 'best-practices', once a problem is solved well enough. JS doesn't seem to do that. (At least not yet.)
I just want someone to take another look at ontercooler js, the best CSS and JavaScript is the CSS and JavaScript I don't have to write. Every time we hire someone fresh out of college they ask if we can learn angular and my reply is why do you need it? Because you heard of it? And basically that's the only reason they mentioned it.
indeed, it is; i don't need to tell you, though :p
when i originally asked the author to submit Moon to js-framework-benchmark [1] i was surprised to hear that Moon's users have never needed or asked for keyed updates [2].
there are some authors (myself included) that consider libs without keyed DOM reconciliation to be seriously deficient.
Thank you. It would actually have been more difficult to submit a PR to Vue, as Moon's internals are completely different. It would have tons of breaking changes as well, so I created a new project as a result.
Not knocking on your effort here, but you think that it would have taken more effort to submit a PR to Vue than building an entirely new open source framework from scratch over the course of several years?
If so, there is something very wrong with the state of open source development.
Working on Vue would take similar effort, deleting tons of the code and rewriting it.
Part of it is that this is project started as a way for me to learn what goes on under the hood of libraries like React and Vue. While I made this, I wrote a compiler (lex + parse + generate), virtual DOM engine, reactivity system, and more!
I've started to take Moon in a different direction than Vue, and in the future it will most likely be even more different than Vue.
Moon is a part of js-framework-benchmark[1] (in the non-keyed results), and it performs faster than Vue there. The article I wrote a while back also has some benchmarks[2]. Finally, the overview section of the documentation also has benchmarks[3].
He tried to solve performance problems in complex applications, and obviously complex applications doesn't need to preserve internal state when children list is changing :)
I dont particularly care whether or not its faster than vue or react. If I'm going to build a heavy use production app I would use one of those just because it has so much of a community supporting it. But sometimes less is more. The api here is simple, and yes similar to vue and react. The guts of the docs took like 5 minutes to read through. Over time, the novel concepts introduced by these frameworks turn into general best practices. That's what we see here. A boiling down of the reactive web framework into a small set of core methods. Certainly not the most powerful or extensible. But perhaps the most simple.
If your web app is highly interactive and has a very complex user interface with lots of animations and small http requests you would be well served to use React, vue or this thing.
If your web app doesn't have that, which I imagine the majority do not, don't use any client side framework at all. Javascript still works, even without a framework.
the issue is that, for product development, it is really about the whole package, the ecosystem that is, which includes third-party modules/add-ons, documents, longevity concerns, road maps, tools around it and so on. one shining improvement is normally not enough.
My comment that said "So far, the Infinite monkey theorem is just giving us an infinite number of javascript frameworks, and no Shakespeare" acquired 29 points but then has been deleted. Why is it so?
Honestly, I think libraries are great, if they improve on existing solutions and actually bring something new. Don't try and stop innovation just for the sake of having to make less decisions.
Moon's purpose is to provide an API similar to Vue, while being less than half of the size, and having improved performance in most cases. Why try and stop something new without giving any valid criticism? If we all have a mindset like this, the web isn't going to ever improve.
Well, to be a bit crotchety for a moment: Copying someone else's idea but doing it a little smaller or faster isn't exactly revolutionary. At this point, UI libraries are turning into the JS equivalent of programming languages (everyone is writing one, and few of them are that interesting).
If you really want to improve the web, we're gonna need to think a bigger than this...
It might not be revolutionary, but it _is_ an improvement. I just don't like when people say they hate something because they don't want to make decisions. I'd rather have feedback than someone ranting about "just another Javascript framework".
Moon has the core features of Vue, but it's started going in a different direction. I'd love any feedback and to hear your thoughts :)
Well, so first of all, it wasn't a rant, it was a joke and a bit of a jab, and you gotta admit these days there's good reason for people to be... uhh... skeptical about yet-another-JS-library.
Second, that reaction isn't about not wanting to "make decisions"... that simplifies a rather complex set of thoughts and beliefs that are driven by the often-comical Javascript world, which appears to favour extreme complexity, constant churn and obsolescence, a near-complete absence of standards or best practices, duplication of effort, and fragmentation. Of course, the flipside of this is rapid evolution, competition in a marketplace of ideas, etc, etc.
Third, if you don't want people to see this effort as yet-another-UI-framework, it'd probably be a good idea to position the project as something other than "everyone else's good ideas, but smaller and faster" (lightly paraphrasing from the project landing page)!
Yeah, I was just saying my thoughts against the hate towards new JS frameworks in general. While this reaction was a joke, there are tons of people that would have been ranting about another Javascript framework.
I am by no means trying to force people to use Moon. Instead, I am trying to show something that you might want to consider if you use and like Vue, as it is smaller and faster.
I agree I might need to reposition this project and state a little more. But I've already clarified why I made this in an article I wrote[1].
And, I should just point out: the original commenter, and myself, may have our... let's call it lack of patience with the JS community. But don't be discouraged by a little bitterness... as you mention in your blog post, there's definitely javascript library fatigue out there, and for good reason. But if the work is good, it'll speak for itself! Everything else is just marketing, and if you're not interested in pushing the project toward broader adoption, just keep on keeping on! Either people will use it or they won't, and either way you'll have learned a lot along the way, and there's nothing wrong with that.
Fair enough. I take it that you weighed the cost of fragmentation versus the advantage that a rewrite would give you. Even so, it feels to me - as an outsider, without having looked in depth at either code base - that it might have been better to see how far you could have pushed vue.js with respect to your improvements before deciding to roll your own. After all, now you are comparing apples with oranges, many of your improvements likely would have applied to vue.js as well and then the difference between your offering and theirs would have been a lot smaller, possibly small enough not to justify a for and yet another incompatible API.
I guess that's where a bit of "static type" would make it easier. Different framework could explicitely back themselves against an API. With js, it's all implicit.
This is what research looks like. You keep trying new things, making small improvements if you can. But sometimes you just try something different and it's not better.
The truth, with software, is you don't really know what the implications of a design change are until you use it. We know a lot about what's good and bad about React now because we used it for a ton of stuff. That's the equivalent of taking your test vehicle out on the roads and testing it. In order to do that testing, these things get posted on Hacker News. Making your library mostly error free, putting docs up on GitHub... That's just getting it ready to actually test the ideas in that library.
The JavaScript community is one of the most research friendly communities out there. That's because we basically don't have a standard library, we have to send our entire application over the wire in less than a second, we can't really change the runtime, and people often want us to build new applications in a matter of days.
I get it, there are other realms of software development where you just have standardized tools, where stability is supreme, where you want to write huge checks and get back predictable quantities of mostly error free software. I get that.
But this comment shitting on JavaScript for changing too much, it's like making fun of a kid for saying weird stuff. If you want something comprehensible and predictable, go use something else! Let things be what they are. Appreciate that we have choices and different languages have different goals. Don't beat the same drum over and over of "JavaScript is too JavaScripty!"
This isn't a response. It's a dodge. Instead of responding to the substance of my reply, you've just pivoted to talking about "ridicule", which is a completely different issue that is only a symptom of the issues in the JS community: the lack of stability and comprehensibility that you seem to be willing to excuse, going so far as to tell people to go elsewhere if they don't like it, without seriously offering up a viable alternative (probably because there isn't one... The web is the web and it's unfortunately unavoidable despite the absurdity it frequently embodies).
So are you choosing not to reflect and respond to my comment? Or did you really just completely miss the point I made?
I'm not trying to be flip. You didn't really write anything substantive. I'm happy to respond if you want to say something more than "I think what you're describing is ridiculous."
It's not detached. Even if a thread is detached by a mod, in my experience it appears at the bottom of the post. A new feature was rolled out recently where some get rolled up and hidden by default. They're accessible by clicking the [+n] link in the header of the top-most comment of the thread. That's how this subthread appears to me currently.
I'll look for the comment where I saw more details on this. Edit to add: I haven't been able to find the comment where this was mentioned. It was within the past couple of months, though.
well by logical extension the theorem provides that at least one of these frameworks should end up being Shakespeare..so at least we have that going for us?
So moon is the alternative to vue which is the alternative to angular(ui engine)/react... Oh dear... How those frameworks want to get used in a wider manner when they place themselves in a 10% of 10% of 30% of the market segment?
But I also do push-ups. See, it is rarely an either-or proposition. One could push vue.js to the limit and then decide to do a rewrite. But to take the rewrite option as the first available exit whilst explicitly referring to the original is fragmentation where I wonder if it is actually needed.
Well, it is either-or. All time spent has an opportunity cost. Just doesn't strike me as an argument. Nothing is needed, and need doesn't describe why most software exists.
These sorts of comments amount to judging how others spend their time. It's just as silly to me as me suggesting that you spend your time credentializing in React so you can improve it for free.
I'd say there's plenty of value to offer the world by creating alternative projects that stand on their own, experimenting with different approaches.
Well, we're going to have to disagree on that. I feel that a lot of the fragmentation in open source is due to the fact that it sounds good to be the maintainer of some project, the fact that github presence is now considered a factor in getting hired certainly contributes to that.
Fragmentation - without sufficient forethought - is not cost free and 'more wood behind fewer arrows' works both for commercial entities and for open source.
Most of these 'alternative projects that stand on their own' are announced with great fanfare and die a silent death a few months later, the same effort spent on improving what is already out there would go a much longer distance.
Obviously everybody is entirely free to spend their time in whatever way they want.
Technically, one can pull down any mature framework, decouple all of the features into smaller segments, get rid of all the code responsible for backward compatibility, and re-brand it as 'lighter' alternative.
How is this any different? You can't claim that X is better or faster than Y just because X is smaller or has fewer features. There are a lot of other factors in play here.
Can all the JS framework people lock themselves in a building for a year and figure our the right way to do this -- and only then share it with the world?
I'd love to know why you think Moon is ridiculous, so I can try to improve it. I honestly think what you're doing here is really ridiculous, try and give some feedback instead.
Edit: Sorry, I misunderstood your comment. I interpreted your comment as saying all of these new frameworks are making things ridiculous. This implies that Moon is contributing to that, and I'd rather have feedback.
Incivility and acerbic swipes will get you banned here. You've done this many times on HN, unfortunately. Would you please fix this? Among other things, it sets the wrong example for the less laconic.
Template literals in JS give us a way to always tell the static from dynamic parts of a template. HTML <template> elements let us stamp out pre-defined trees of DOM quickly. Combined we can then only update the dynamic parts without a virtual DOM.
T7 is quite a bit larger than lit-html, and requires a vdom reconciler still. lit-html is self-contained and < 2k minified and gzipped.
I also didn't want to use vdom because it doesn't encode whether nodes are static or dynamic, and even static sections are diffed. That's extremely important feature for performance and memory overhead, which is why I'm happy to see that emphasized in Moon.
Also, coming from the Polymer team, where we've had a lot of success using <template> elements to stamp out large pre-defined DOM trees, I wanted a system backed by those.
You could point to frameworks which have had majority usage at any given point and say those were the "right" ways at the time. But ideas evolve, which isn't so ridiculous.
The correct analogy would be "There are 14 competing standards with a new one released each week that creates doubt about the ongoing use of existing established standards and know one knows what the fuck is going on".
Do you want an open ecosystem or a controlled one? There is no in between, and you will hate it no matter what you choose. On the Open ecosystem side of things you have things like Linux with 10,000 independent distributions doing slightly different things. On the controlled you have Microsoft, Apple, and Oracle telling developers the "right" way to do things.
