what the hell is wrong with front-end development?
+each four months there is a new thing trying to replace the last new thing? typescript => 'flow' => ES.6 => ES.7 => ES.8 => ES.Next => WebAssembly (and back to square one - the days of flash)
The ES* thing can be explained like this:
The plan is to have every year a new ES version with some new features, so got to get used to it 🙂 That's what ES.Next points to, the "next" one.
ES2015 is the most important, the one that introduced the most features due to an accumulation of features that lasted a few years, ES7-8 had important features but way less in number. Also, it has now a lot of browser support, so you can use many features without using a transpiler (Babel).
I wrote a guide about it last week if you want to check it out: https://flaviocopes.com/ecmascript-guide/
WebAssembly, that's mainly for people optimizing the internals, or building very high performance parts of apps/games, not "regular frontend developers".
TypeScript and Flow in my opinion are completely optional.
Microsoft is actually working on an experiment to allow .NET developers to use .NET languages and Razor (the markup language used in ASP.NET) to build WebAssembly applications. One of the use cases is definitely to use it as an alternative to existing SPA frameworks such as Angular, React etc.
As an ASP.NET and C# developer, this definitely excites me...
See more at
https://blogs.msdn.microsoft.com/webdev/2018/02/06/blazor-experimental-project/
http://blog.stevensanderson.com/2018/02/06/blazor-intro/
Yes this is the kind of things that make WebAssembly great! I think I was saying that a regular frontend JavaScript dev does not even need to know about it, but that's a tool for programmers building on tools for other programmers (like in this case) or also I read about using it to run very CPU-intensive games, for example.
How about the support in different browsers ? Is it reasonable to adopt these new standards ?
That depends on each single feature, which you can check using https://caniuse.com. Of course the more time passes by, the more features are available for more users, who will not all be using the latest and greatest version of a browser.
So going forward I think it will always be mandatory - unless you like to be more conservative - to use Babel and transpile your JS to ES5 or ES6 so more browsers are able to interpret your code.
I think that if you are using a modern front-end framework you'd transpile your codel with Babel anyway, so it's not really a problem. You can use something like https://www.npmjs.com/package/babel-preset-env
Front-end development has never been in a better position, whether that's from the developer productivity standpoint, cross-browser support, or technical capabilities.
For what it's worth ES6, ES7, etc. refer to ECMAScript (https://en.wikipedia.org/wiki/ECMAScript) which is the specification that JavaScript follows. All of these are considered vanilla JS but adoption of each specification lags behind at different rates for each browser.
It's similar to Java and how we are now on Java 9. Every new version of Java introduced new features and syntax for doing different things.
Don't feel pressured to use the "latest and greatest" but use whatever tool you're comfortable with.
+i very well understand what and why
ECMAScriptneeds gradual upgrades, what i don't understand is how the currently implementation of new stuff is nearly completely incompatible with the previous one...Can you provide an example of incompatible changes? I'm not aware of any incompatibility changes.
+by
incompatiblei meant inconsistent browser support, with chrome implementing nearly everything current, while other browsers lag behind ...i understand this is not a language problem, but i kinda feel that the changes are happening slightly too fast... backward compatibility is, in all cases zero, which requires polyfils, which you never know how they will react to what and when...For JavaScript compatibility, there is babel.
All the new features in ES are "backwards compatible", meaning: All your old code is still working fine in new browsers.
This also means there is no need for you to start using any of the new features. If you have the feeling that you get no benefit in using async/await or destructuring or classes - simply don't use them.
The same applies to stuff like WebAssembly, Flow/TypeScript or the newest shiny framework. No one is forcing you to use it.
It's sometimes hard to not fall into this trap of always wanting to use the new and shiny stuff - but sometimes it's just not worth it if you just want to get something done.
That's one of the downsides of the frontend and but that's also a trigger for the main advantage of it - user doesn't have to download any special app, it's just his favorite browser and your code. And for sure it's getting better over time, several years ago most browsers didn't have autoupdates so there were people with IE6-7 that had a lot of bugs in it but would never update.
For now I would say you mostly need to know js basics, es5-6 stuff (there is not too much of it) and you are good to go.
The best approach that worked for me regarding other libraries and frameworks is - learn it when you need it. Just read some articles about the frontend technologies to know which technologies are there and what problems they solve and when you are about to get the problem - you already know what to use or where to search for it.
I'm a frontend developer by trade, I understand your pain, so far I only keep myself update with es6, and abit of es7, I think that's more than enough to do the job, if you're a product person, forget about the hype of all these shining technology, as long as the project is maintainable it's good for the business.
I feel like EMCAScript is turning into C++. They should try to keep it minimal like how JavaScript the Good Parts book describes it
Javascript fatigueeeeeeee!
Just stick with what you're comfortable with. Don't have to chase after new trends.
I use Typescript for all my projects. The TS dev team tends to be very conservative when it comes to adding new JS syntax, features, etc.. So that makes refactoring / upgrading very easy.
I don't see any problem on this. For me, front-end is in it's best shape right now. It can be a bit overwhelming when you start and to update if you are a bit behind but when you are there is incredible good to work with.
Javascript is terrible but CSS is also screwed: https://medium.com/the-node-js-collection/modern-javascript-explained-for-dinosaurs-f695e9747b70
This comment was deleted 6 years ago
This comment was deleted 7 years ago
I'd actually say using Vue would be a mistake for an indie hacker who doesn't already have a decent amount of front-end experience and/or a reasonable amount of resources.
Making a single page app is a significant investment and often not justified, especially at the outset. Just use an MVC that does a lot of the work for you (Rails or Laravel would each be good choices), and get your MVP out there. After you've found something people are interested in, then you'll maybe the investment in a front-end JS framework will be worth it.
Although I’ve had more experience starting from the back-end, I find making MVPs to be faster and easier on the front-end with Vue/Polymer. There are some really good services/APIs for data storage, authentication and deployment that make things relatively easy.
As always, your mileage may vary. Take into consideration your abilities/background, but also your product needs, before jumping in either direction — and try out different stacks when possible.
That's very surprising to me considering my experience was mostly front-end! What was your back-end stack?
Funny how that is. I used (and still use) Node/Express and previous to that various PHP frameworks.
I find it more intuitive to work with the logic of the front-end because its easier for me to design my application architecture to follow user actions (simplistic example: 'When a user inputs text here, send it to the database service, then go to the next route'). From my experience, things tend to get a bit more abstract on the server side and I start to think about things that don’t have to do with MVP.
Ah, ok. I don't find Node that productive either. The real eye-opener was after working with it for years and then messing around with Rails for 2 weeks, I was already getting more done with Rails due to the higher level of abstraction. Ditto for Elixir/Phoenix, which is my current stack.
Good to know, I'll have a look at those next time around.
This comment was deleted 7 years ago
...Don't rule out Angular 2+ (now at version 5). I greatly prefer it over React.
why? I moved out of angular because too much magic happening within the framework; with react I know what I'm doing when I have options to choose what to use for my projects.
+currently, am using the good old Knockout.Js. it really solves most of my problems regarding reactive programming. after doing some research, i found out that Vue.Js is simpler than React.Js, hence better, but somehow similar to Knockout.Js, only varying in implementation... my rule of the thumb is to never use a full framework to retain flexibility...by the way, i still use jQuery...
create-react-app
ant.design
mobx
And you will build products with rocket speed. I used to use JQuery few years ago, but believe me - it's nothing to compare when it comes to development speed...
+the
ant.designlooks quite cool, and this would really be useful when creating something using a design that is already conceptualized... if you look at something i created like https://curriculum.co.ke/ , i think you will spend 40% of the time fighting the framework regarding some scenario the creators of the framework never imagined....for that reason, my next investment isVue.js. i prefer libraries to frameworks...and it's not that i usejQueryto doDOM manipulation, i use it for things like scroll animations and to support third party libraries like acalendarorselect2.js...This comment was deleted 7 years ago
Or just a teetering pile of Zapier integrations!