So we are here. It didn't took so long for vue to go from "will vue be new react ?" To "vuejs alternative".
Let the curious create and share their creation with the world.
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.
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.)
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.
Parent said it is overkill, a different thing from what you're reading. And boy, as somebody who doesn't already know it, is that right.
https://github.com/angular/angular.js/commits/master
Kind of glad about that, as it's what I'm still using. :)
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.
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.
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.
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.
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...
So... not for me then! Ha! :)
I've had a few more discussions with a webdev friend and it looks like Vue is the way to go. Thanks all.
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.
I wouldn't call an app with "minimal interactivity" an app, anymore than I'd call a newspaper interactive reading material.
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.
https://www.bloomberg.com/graphics/2015-paul-ford-what-is-co...
"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."
No.
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.
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.
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
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
Here's how I describe it: https://medium.com/front-end-hacking/how-it-feels-to-learn-j...
I just submitted it: https://news.ycombinator.com/item?id=15108546
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).
BE is 100x worse.
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.)
That's a first. Is that a common saying somewhere? Does it refer to literal oral sex with a goat?
More like compensating for JavaScript's very real shortcomings.
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.
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
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.
...
> There are several libraries/frameworks > browser support for the spec isn't fully there.
The irony is lost on frontend developers