What's new

Web Front-End Development gone too far

  • Thread starter NukeZilla
  • Start date
  • Views 554

Do you agree?

  • Yes

  • no

  • Kinda


Results are only viewable after voting.
N

NukeZilla

Enthusiast
Messages
144
Reaction score
40
Points
105
Sin$
0
Hands up if your currently using a 3rd party framework (Angular, Aurelia) or large libraries (React and Jquery, Backbone). Now task yourself why are we all relaying on over engineered frameworks. It's got so bad many developers are even turning to Sass or less to help them write reusable code. About a year ago I was contently driving to write website with the latest tools for performance and quick development. I was even spending hours every weekend looking for better pre-compilers to increase delivery.

But why?
When I first started working with Angular I turned to my manager and asked why are we using angular? His response was reusability and maintainability The same response when I asked a different manager why are we using SASS.

We live in 2016, not the past.
AAEAAQAAAAAAAAkHAAAAJGM2Yzk1YWFkLTk0MTQtNDY0Yi1iZjExLTU5MTQyM2VmNDFmYw.jpg

In the past front-end development was a nightmare, and required tools like sass and less. But this is 2016! new development standards are coming out yearly. Take SASS and Less, I use to love it as you can create a variable file to set out your branding guidelines and common typography. But the people over at W3 been listening. You can now declare native variables in CSS. You can even use Calc to work out maths.
Code:
:root {
  --main-bg-color: brown;
}

.one {
  color: white;
  background-color: var(--main-bg-color);
  margin: 10px;
  width: 50px;
  height: 50px;
  display: inline-block;
}
ECMAScript Yearly Updates
It's not just W3 that's making improvements. ECMAScript (ES) the community behind setting the specification for scripting-language (JavaScript & ActionScript) has pledged yearly updates. The current proposals of ES7 can be found on [Click here to view this link]. Many thanks to Angular many developers are converting over to TypeScript. Again I ask you why? Many responses I've been given comes down to Type checking and because google guys over at Angular promotes it. But I found this extremely lazy. Better still I recall asking a few of these people, do you know how TypeScript compiles into JavaScript? Majority answered "no". One person even went as far as saying "I write this piece of code and does its thing and It works. That's all I care about"


Many like the fact that TypeScript offers so-called "private fields" Yet when compiled into JavaScript it's not even placed in WeakMap. But thanks to [Click here to view this link](chromium) and [Click here to view this link] (Salesforce) who are currently working on a Babel transform you will soon be able to write [Click here to view this link] shortly.
Code:
class Person{
   static #currentId
   static get getNewId() { return #currentId++; }

   #id;
   name;

   constructor(name = "Joe Blogs") {
       #id = Person.getNewId();
       this.name = name;
   }

   get id() { return #id }

}

Drive for Reusability resulted in messy Frameworks
AAEAAQAAAAAAAAgVAAAAJGE3ZTJkYTQ5LTM0NjMtNGNlZS04OGM0LWI0Y2QyNjczYjY1YQ.jpg

In a drive for reusability, we have resulted in Frameworks. The image on the above is simple Angular Project. Does this look familiar? We are not making stupid components for everything. What every happened to the good old day's of development when you only have a couple of folders and easy to navigate? Many will try and explain the reason for this mess results in more complex websites. I understand this but have you notice something? The real problem is down to popular frameworks. Angular and react promote everything as a component, however in reality it's not. You actually destroying your consumer's bandwidth and eating heavily into machine memory usage.


AAEAAQAAAAAAAAiiAAAAJDUwNjhhZGY0LWVhOTYtNDYwMi04MWJhLWRlNzQ2MWMzN2E4OQ.png

History API and Shadow DOM

Now a day's on linked in I read people asking what front-end framework should I learn now. Every time I see this I end up laughing to myself. Looking at the image above thanks to Eric Wastl over at vanilla-js if you are after performance then you can't beat using vanilla-js. I honestly believe that the majority of JavaScript developers have a) forgotten how to write plain JavaScript or b) Don't even know what it full stop.

Let us take a look at SPA applications. In a quest to lower HTTP call we now requiring full frameworks to only fetch the components that's required, This was good back in 3G days where mobile companies were offering "unlimited" Bandwidth. But now we are on 4G and soon to be 5G Mobile companies are become tight again and limiting to a couple of GB. So scrapping frameworks for smaller required functionality would be better. So let's see what's available using "plain old boring" JavaScript.

First, we have History API. Surprisingly or not through all of Facebook react-router and angular-router HUGE unneeded file, it uses HISTORY API. Using Push states and Fetch API (Yes, that's right folks. ECMAScript making complex calls simpler). You can make a single page application in 100 lines of code!

OK so I see your point on routing but I use Frameworks for components! Introducing Shadow DOM. You can create components using just JavaScript, all you have to do is query the dom for HTML 5 standard custom attributes.

Code:
document.querySelectorAll('div[data-jh-widget-prices]');

And then attach your shadow DOM from a component folder to your elements. it's extremely simple and flexible. You know have reusable components without the overheads.

Finally, take a look at decorators. You can create simple but effect reusable code with minimal effort, for instance, creating a Dependency injection using a decorator is much easier than writing long complex code over and over again. But once more Decorators can be great in Unit Testing and even for validating types. We could a decorator called types which take in an object to check against. This allows you to have strongly typed language in JavaScript and using Unit testing frameworks to validate the types are correct. I've found this on GitHub of someone using decorators for type [Click here to view this link].

Complex build instead of complex systems
Some of you may be thinking this is all great but ES6 and Css variables is only supported on latest browsers, never mind ES7 and CSS4. The solution to your problems can be resolved with a build system.

CSS Next is a plugin for PostCss. This allows you to write none browser specific code and CSS 4 Today and CSS Next will compile NATIVE CSS with backdated support. Meaning in 5 years time there no need to remove browser supported code.

Babel will translate any ES... into an older version of ES standards using polyfill and code transformers. Just like CSS Next you have the latest standards today meaning in a couple of years time, your code won't need to be updated.

Final Thoughts
Using frameworks sounds like a good idea. But how many developers are having to learn Angular 2 way or even worst another framework because angular 1 will soon no longer be supported? What happens if both Google and Facebook stops support on Angular and react? Might be thinking that won't happen or we will just recede and waste money. Will remember [Click here to view this link]? most will but some lucky people won't. It was a popular Node Package which in March 2016 was responsible for "crashing majority of the internet. The person behind the package took package down because of some legal fight. So never think something won't happen and always plan for the unexpected.
 
Last edited:
Forgoten Dynasty

Forgoten Dynasty

Free Sosa #bangbang
VIP
Retired
Messages
5,830
Reaction score
2,613
Points
645
Sin$
0
You are both right and wrong here. Javascript does move fast and it is absolutely unnecessary (and not even possible) to learn everything. However, that doesn't mean you shouldn't learn as much as you can. Don't look at amazing engineering and dismiss it because of a benchmark. Benchmarks are subject to data dredging (AKA P-hacking) which basically just means you take any data that supports your claim and throw everything else away.

For instance, you will often see benchmarks which show how react is slower at DOM manipulation. This however, is a false positive because react is meant to work through virtual DOM. This means react batches your DOM updates to help optimize the browsers repaints. You may not be able to touch the DOM 9001 times a second but the truth is you shouldn't anyway because the browser can only repaint so fast. React will FEEL faster to the user because it works in synergy with the browser.

I will agree with you that a lot of new terms have been coined and that can sometimes make a project confusing to navigate. You will commonly see react projects thrown around with terms like ducks, component, container. I personally have moved away from this. I just simply name these folders model, view, controller (respectively).

For Instance, here is a relatively small project I did for a class where I use this structure.

[Click here to view this link]

I stack a ton of technologies together which may be confusing if you're not familiar with them but you cannot say that this folder/file structure is more complex than any other program.

Many like the fact that TypeScript offers so-called "private fields" Yet when compiled into JavaScript it's not even placed in WeakMap. But thanks to [Click here to view this link](chromium) and [Click here to view this link] (Salesforce) who are currently working on a Babel transform you will soon be able to write [Click here to view this link] shortly.

Understand that even though TypeScript may offer "private fields" it is an opinion that is subject to change. Since Microsoft wants to keep typescript as a super set of javascript they will adapt their implementation if javascript goes in a different direction. Thus Typescript's private fields are no more stable than transpiring them through babel.

It is currently a practice that every single proposal must have a babel plugin written for it BEFORE it gets brought in front of the standards body. This is so people can play with the new feature and get a feel for how it works before it needs to be implemented in browsers. You will always see a proposal made through babel before it gets added to typescript (which makes babel cooler than you probably thought). Microsoft doesn't just add things to typescript out of thin air they wait until their is a general consensus amongst TC39 about a proposal.

If you want to play with all strawman proposals you can configure your babel compiler to use all proposals.

https://babeljs.io/docs/plugins/preset-stage-0/

Private Fields are currently stage 2 which is decently stable, Since MS is behind it with typescript that give it a little more street cred than other stage 2 proposals.
To understand the different stages and what they mean you can reference this page.

https://tc39.github.io/process-document/

Lastly, I believe your final thoughts are a bit misguided. Even if tomorrow facebook decided to ditch React, the lessons learned will still exist in the world. Libraries such as Preact and Inferno follow lots of the same practices react does and can often be used as drop in replacements for react. Angular 1 was pioneering, and as such it made mistakes. There have also been steps taken to prevent issues such as left pad happening again. Yarn will give you much more consistent CI builds because it caches packages. This is the beauty of javascript if a problem rises up there are usually 6 solutions to it. You just need to know how to orchestrate them.
 
Last edited:
N

NukeZilla

Enthusiast
Messages
144
Reaction score
40
Points
105
Sin$
0
Don't get me wrong I do like using both react and angular 2. The reason why react gets better branchmark than angular is because of the virtual dom. However, I'm not a huge fan of its implementation. It takes a copy of the whole dom so it eats at your memory. Where as incremental dom will only take a copy of what it's required. It's why depending on devices depends on the benchmark results.

I know typescript is a superset of JavaScript but personally I believe the implementation is weak and I don't see the point of it. Many developers will use typescript to write less unit tests.

Finally, frameworks exists to fix a problem but not the solution for everything. Rxjs was being considered is ES7 but for some reason they decided to drop it. I would love to see it back in es8. Yarn with its caching much quicker than npm but still has some work to do with private packages. It's the only reason I've not fully moved across to yarn on some projects.

I take it your a developer at your day job? Your more clued up than most I've worked with.
 
C

Cyimking

Enthusiast
Messages
83
Reaction score
14
Points
70
Sin$
0
That's just how the software industry is. What people used last year is not what people will use next year. Why? Well because the field is based on how fast and efficient something is. Today OLED TVs are cool but in 3 years, OLED tvs will cost $299.99 on black friday.

Another thing is because a lot of developers want to make the NEXT big thing which is why they are new technologies coming out, once per month. I do think that Angular will be around for some time but I also know that they are developers who are currently working at Google who are working on the next big JS framework as well to get that promotion. I do not think that front end development is going too far... there are just a lot of options which may be overkill for a lot of projects.
 
Top Bottom
Login
Register