Which frontend technology or frameworks do you use

i’m experiencing js-fatigue here.

seems like js is moving waaaaaay too fast, like every month a new framework/tool is the new future.

you learn x now, then next year it is obsolete.

“dude you code x ?? that’s so 2016, we use y now, it is so hype and hot right now.”

it seems like js people is creating problem for their own problem, it is a circular thing.

2 Likes

You’re a perfect canddate to escape frameworkhell then. https://blog.smartdraw.com/how-we-wrote-a-desktop-quality-app-in-javascript-that-avoids-framework-hell/
(discussion: Is JavaScript framework necessary for frontend?)

1 Like

HTML5 brought many new features such as videos, Pega mp3’s, canvas, svg and new semantic tags which were relying heavily on flash and java apis. With this huge jump in web technologies there has been some tremendous changes in technologies.

1 Like

In reality it’s more like every few years
Angular 2010
Ember 2011
React 2013
Angular 2 2016 or 2017

1 Like

Totally agree. The problem is that very few people are willing to admit what the real use case for their application is. To justify the time for an full frameworked SPA you need something that is going to stay open in a browser for long periods of time where partial interface updates are going to be necessary and beneficial often.

The vast majority of web apps are “open, check, close” or “open, do thing, close” experiences that do not justify the extra complexity, dev time, dependencies or upgrade/maintenance paths.

4 Likes

Looking at your list 2 questions immediately come to my mind:

  1. What percentage of Angular 1.x sites will actually migrate to Angular 2 (eventually) - I assume the rest is going to “give up” on Angular entirely.
  2. Is anybody actually going to migrate from a React-based implementation to Angular 2?

In a way I’m wondering whether Angular 2 is going to be less popular/successful than Angular 1.x.

2 Likes

I’m guessing most people feel similarly. I think there is a maturity level where after 3 or 4 roller coaster bumps of thinking - THIS IS THE PERFECT SET OF TOOLS… oh… no it’s not, then your perception of the ecosystem changes. I’ve certainly become wrapped up in the hype, turned on my turbo thrusters - and burnt myself out.

I remember when I realized that jQuery was a ‘library’, what that meant, and that some people had just built up a bunch of useful things they needed often in an accessible collection. Each framework is also a collection of ‘things’ that can be useful - and conventions that make common tasks readable. I wrote a router once, and I don’t want to do that again. I’d rather have 100 smart programers with a variety of edge use-cases write the router. The confusions arise when the framework feels ‘magic’ - but at some point (I wouldn’t say I’m fully there yet) the framework becomes clear as just a big object with methods and prototypes and functional bits that cascade and build on top of their parents. It becomes less magic.

Design is more about actually understanding what needs to be done, and how it needs to be done. The frameworks are just there for you to use - if you find that any particular set of methods and conventions will suit you project. It’s tempting to build your own library and sets of functions. Depending on your work flow - that may be a good idea. If you build out many of the same type of sites that do similar things. For me, I’ve been looking for something I can count on - and help build on - that also has the strength of the community. Backbone, Angular, Meteor, React, Vue.js–each of those things all have strengths and if your company has money and time to put towards learning new things, then learn a little of each. If you need to just get something done, use what you know. I think Ember is more than just a framework. I think it’s attempt to become the SDK for the web is going strong.

Frameworks are like those ugly photo sliders everyone has on their sites. People who aren’t really programers, who are more ‘website designers,’ use them - don’t understand them - and then fill stack overflow with questions about them that reveal they don’t understand what arrays are or what absolute positioning is. I probably did that at one point. People use frameworks, because they promise 2 way binding and snappy animated transitions and you can copy and paste from the docs / until you can’t. I think that mostly those people are the ones creating the hype. The “I’m killing it!” mentality. If you can step away from that, and maybe just investigate each of the frame-works for fun little projects, then you’ll be able to make an informed decision about which set of tools are solid and stable and useful. It ends up being about what is maintainable and what is a well structured file system, and can you make component and addons that are truly reusable. Is there a good comunity? Are they going to pull the rug out from under you in 2.0?

I’d love to think that I can write apps with Ember and Pheonix until I don’t do this anymore… but that’s probably not how it’s going to happen… I’ll likely have to learn some new stuff or build some new stuff. It’s a good thing I like learning. One of the things I’ve had to learn, is how to avoid burnout - and how to relax in this fast paced environment. Just catch the good waves, and let the other ones go.

That being said, from what I can tell, most of the internet is trash. And although I dream of a native feel across all devices screen sizes - Pretty much everything people are doing could be done with PHP or rails and some jQuery. Except things that may need many threads… which is why I’m interested in Elixir.

2 Likes

If only I could predict the future :slight_smile:

  1. They are working hard to make it possible to migrate apps gradually so I would guess it’s likely that many people will upgrade
  2. I personally like Angular 2 syntax but I would think migrating existing React app to Angular 2 is not a very smart use of developer time

Globally I think Angular 2 will not be as successful as Angular 1 because there are strong mainstream alternatives (React, Ember)

Who’s saying that? I’ve never heard anyone seriously say this and I’ve been doing JS for years.

I think a lot of the recent community has settled on React mostly because of its massive adoption by many big companies. A lot of devs really enjoy it (myself included!), so it’s a safe choice.

Just find a set of tools that work you and your clients and keep using them, but be aware of new developments. Ignore what silly people say online.

1 Like

I think that the JavaScript ecosystem is trying to be all things to all people. Make JS support any programing paradigm: interpretive, object oriented, functional, etc. Create new frameworks that work this way, or that way, ad infinitum. Seems everyone wants JS and JS frameworks to work their way, because their way is better or best.

I don’t think this is going to end, unless some very brilliant people come up with a framework that most everyone thinks is best.

I do think that web assembly may be the solution to the JS mess. Compiling to JS is a step in the right direction, but still holds on to the JS baggage. It is very early in the web assembly game, so it may take a while for this to shake out, but the potential exists for a new language and framework to finally leave the JS baggage behind.

It’s possible it will be source of even bigger mess :slight_smile:

1 Like

Yes, just like when I implemented flux on my app, it’s almost 70%, then suddenly we refactored them all into redux.

And now redux is obsolete, because MobX is the new, trendy and better solution.

If you your application doesn’t need a full-on SPA type experience and you don’t want to get too deep in complex JS tooling and learning curves, I can recommend intercooler.js

The examples are the best way to see what it can do and how: http://intercoolerjs.org/examples/index.html

5 Likes

Sounds like you just need a more mature team honestly. It’s not MobX’s creator fault your team switched to them for no good reason.

I welcome new and crazy things in JavaScript—I just don’t use them :slight_smile:

1 Like

I have eyes on elm…

So what are your thoughts guys, when should one use React, Angular2 and Elm?

In my opinion:

  1. If you have an old React application or absolutely need some React libraries, use React.
  2. If you have an old Angular2 application or absolutely need some Angular2 libraries, use Angular2.
  3. If you want something ‘right now’ that will be reliable, use Elm.
  4. If you want to build for something longer term, use Bucklescript (basically Elm but a better language (OCaml) and just hit version 1.0.0 but client-side libraries are still being built).
4 Likes

No love for purescript? :slight_smile:
I would also mention you can build react application using purescript
I think big plus for react is variety of components you can reuse.

2 Likes

I had looked at Purescript a bit around when I went to Elm, however its tooling was exceedingly insufficient at the time, probably better now. As an example it did not even have a brunch builder yet at the time. ^.^

You could make React apps from Bucklescript too, simple bindings, and as I recall I ran across one a few days ago that someone already made too.

I’d love for something to just “win” so I can stop learning all these crappy tools/frameworks and languages :slight_smile:

2 Likes