DEV Community

loading...

Discussion on: CSS in JS - have we done something wrong?

Collapse
thorstenhirsch profile image
Thorsten Hirsch

Your answer has got the most likes, congratulations, but I think you've got it all wrong. Here's why:

  • Fashion trends just come and go, but technical trends have a reason for why they come. They almost always solve a problem we had with the previous technology. Such things won't just fade away like a fashion trend. You either have to come up with a better solution or render the problem obsolete.

  • Speaking of "someone important enough" sounds like a conspiracy theory, in which there's a hidden puppet master controlling all the technology being used worldwide. Nothing can be further from the truth. Compared to other business sectors today's open source driven IT landscape is probably the most democratic place in which everybody has the chance to succeed with a new technology just by showing everybody else that it's better than the rest.

  • Javascript has been laughed at when it came out, yes, but it seems like it isn't that lousy after all, now that (the single focus on) object oriented programming is not king anymore. Additionally JS has been "upgraded", making it one of the easiest languages to implement async programming.

  • SPA vs. multi page application doesn't match the author's question whether to pack HTML and CSS into JS files; you can very well put each technology in separate files when programming an SPA as you can see in Angular.

However I agree that including the CSS stuff into component oriented programming leads to a conflict between frontend developers and designers. We see a growing specialisation in all IT roles, so the need to come up with a workflow that decouples the designer's and the developer's workflow like it was when you could write all CSS code in a separate css file. Maybe we'll see these again if we accept that having a single CSS namespace is not as bad as forcing designers to learn JS.

Collapse
siy profile image
Sergiy Yevtushenko

Unfortunately IT is not driven by the technology quality, despite open source. Just like any other sector it's heavily influenced by the marketing and advertising campaigns performed by large companies. This is the reason why, for example, technically inferior solutions like Spring flood the market. Or zero real value dummies like Kotlin called "next big thing".

While I totally agree that IT is one of the most democratic places, I also realize that such a democracy is quite easy to affect and drive into necessary direction for those who has enough resources.

Thread Thread
pamprog profile image
PamProg

Hey, i'm late to the party, but could you explain why Spring is a technically inferior solutions ? And inferior to what ?
I'm not trying to annoy you with this question, I'm genuinely asking.

Thread Thread
siy profile image
Sergiy Yevtushenko • Edited

Spring:

  • Heavily relies on reflection
  • Consumes a lot of memory
  • Uses exceptions as a part of normal request processing flow
  • In many cases shifts error detection to run time
  • In many cases relies on text constants

Any of the above might be a sign of technically poor solution, but Spring collects them together and this indeed an achievement.

Spring is easy to start writing app, but at subsequent stages of development this is compensated by:

  • need to write more tests than necessary (see note above about shifting errors to run time), famous "check that context loads" tests is an example
  • hard to nail down and fix issues caused by "Spring magic" and dependency management. For example, adding yet another Spring module to dependencies may easily break your application even if you not actually use this dependency yet.

As a consequence, almost all Spring applications share the same properties - they are slow, consume a lot of memory, are hard to maintain and extend.

As for your question about "inferior to what?". I'd say that it is inferior to almost any alternative solution in each particular area. Lets take a look, for example, at core of Spring Boot: Spring DI and Spring MVC.

Spring DI is the slowest DI container. It even unable to complete all tests in the following benchmark github.com/greenlaw110/di-benchmark.

Spring MVC is one of the slowest among Java web frameworks: techempower.com/benchmarks/#sectio... Note that this is not a fluctuation, Spring is consistently lands among slowest through all tests.

Thread Thread
pamprog profile image
PamProg

Thanks for your extensive response !
I think I didn't work enough with Spring to be aware of all of this, except maybe your point about "Spring magic", but thanks again :)