8 ms·

I've working at large F100 financial services companies as an engineer and technical manager for 10 years. I've seen front ends built using a myriad of techniqu

I've working at large F100 financial services companies as an engineer and technical manager for 10 years. I've seen front ends built using a myriad of techniques and frameworks. Leaving bytes and bundle weight aside, in 2020 JS frameworks like React are far and away the best approach for front-end engineering from a large organizational standpoint. 1)Not difficult to hire for. JS frameworks are currently in the sweet spot where they're both widely popular and "cool". Consequently it's not hard to find good candidates. That wasn't the case 5 years ago where React/Angular developers were still uncommon. 2) The HUGE and helpful community of developers. There are so many excellent resources for learning and solving problems with JS frameworks. JS developers are eager to show off on medium and similar sites. I've never seen such a large and enthusiastic community. This will inevitably subside as JS fall out of favor but I hope it doesn't for a long time. 2)Rapid UI development. The JS ecosystem make it easy to build UIs quickly that don't completely suck and look good for the ever-important demos to senior leadership. 3)Opinionated frameworks naturally enforce best practices and ensure relatively consistent architecture. This makes it easy to move engineers from one team to another and make grokking new codebases a lot easier. New engineers are productive quickly and begin creating value for the company. This was not the case with the inevitable jquery monstrosities that resulted after a critical mass of code or # of engineers. 4)Fewer bugs. JS ecosystem makes it very easy to write unit and integration tests. Companies with IT budgets that are 9+ figures will happily pay for extra bytes across the wire in exchange for those benefits

ng12 6y ago
Absolutely agreed. I have never in my life had a stakeholder get on my case because our site was 3mb when it could have been 1mb. I have had many stakeholders get on my case because we couldn't turn around features fast enough, or the site was buggy, or our UX was worse than our competitors. Those are the things that the people who pay me and my team care about and if I could 10x our bundle size for a 1.5x improvement in development speed I would do it in a heartbeat.
- tiborsaas 6y ago
  Dev experience and productivity is key, but don't forget that 10x bundle size has effects you can't simply dismiss. It does cause a UX problem since a slower pageload is part of the UX. SEO. Google also takes into account page / paint times. These are the things your stakeholders probably don't know about but you should.
  - deleted 6y ago
    [deleted]
  - ng12 6y ago
    The majority of the projects I work on target users on desktops with modern browsers. You have to get into the massive 10mb range before noticing any lag, and even then only on an empty cache. SEO isn't a concern either, all of our marketing pages (when we have them) are static sites. It's all about picking the right tools for the job. If low latency is a business requirement by all means don't use a framework.
  - dirtnugget 6y ago
    As a Frontend Engineer I can assure you there are ways to counter that issues but they're not exactly popular: Server Side Rendering. It adds another step t the build process in which HTML is prerendered, so you get the speed of loading plain HTML. It then loads the actual JS in the background. It's a PITA to implement
    - tiborsaas 6y ago
      With tools like Next.js or Gatsby it's not that bad. We use Next at work on a large scale and it works for us. But do you know what language gives you instant SSR? PHP :) It's funny how we had to invest so much effort to replicate with another language supports out of the box. I've built a blog in a few hours with Craft CMS, perfect tool for the job this case, I didn't even have to touch PHP files, just the templates.
- thinkloop 6y ago
  Wait another year or two and your stakeholders will smarten up - users are noticing. Svelte JS, for example, has everything you listed minus the costs. React is very far from the end of the road.
  - aardvark1 6y ago
    Can't wait to figure out how to staff a 5+ person engineering team who can deliver a SvelteJS product , oh and also maintain the codebase for 5+ years when likely a small minority (if any) of the original engineers are still around!
    - thinkloop 6y ago
      It's about a 4 hr learning curve from react - but I'm not shilling svelte, just showing that there are already superior models. Pre-compiling is really objectively better in every way except popularity, and that will change because of its betterness.
      - aardvark1 6y ago
        Superior in what way? Do you really trust that SvelteJS is going to be a better product in 5 years over something like React that Facebook invests millions of dollars every year?
        deleted 6y ago
        [deleted]
        thinkloop 6y ago
        A hello world react app with everything you would typically need (redux, router, etc.) starts at 100K+. Svelte is a couple K. A react app has massive abstraction to render on every frame, Svelte compiles out the framework to render instant straight vanilla js (wins all perf tests). Pre-compiling allows for beautiful syntax and more flexible app structure, since you aren't limited to the runtime. SSR and code-splitting are significantly easier and more straightforward. React is designed for a billion-user site and it shows. There really is zero cost to pre-compiling except mind-share, and only benefits. Of course an F100 company has many concerns above tech awesomeness, so no judgement on your selection criteria. But I assure you this movement is coming, react/vue/angular will adapt/change and/or people will move to Svelte-like solutions. You can already see it happening in the article facebook released today [1]: "By using rems, we can respect user-specified defaults and are able to provide controls for customizing font size without requiring changes to the stylesheet. Designs, however, are usually created using CSS pixel values. Manually converting to rems adds engineering overhead and the potential for bugs, so we have our build tool do this conversion for us." [1] https://news.ycombinator.com/item?id=23116300 https://news.ycombinator.com/item?id=23116300
- goatlover 6y ago
  2 more MBs is going to matter to some users with limited data or bandwith.
  - ng12 6y ago
    Sure, that's a trade-off you have to make a decision on when designing the core architecture. If your users are sitting behind corporate T1 connections near an AWS data center bundle size doesn't matter at all. If your users are still on 3G phones it matters a ton. For somewhere in between it becomes a business decision: how much performance are you willing to trade for developer productivity?
    - hundchenkatze 6y ago
      You're comparison implies that T1 is faster than 3G, but that's probably not the case except in really poor coverage areas. T1's maximum data transmission rate is 1.544 megabits per second. [0] While 3G's theoretical maximum is 21.6 Mbit/s for HSPA+. [1] [0] https://en.wikipedia.org/wiki/T-carrier#Transmission_System_1 https://en.wikipedia.org/wiki/T-carrier#Transmission_System_... [1] https://en.wikipedia.org/wiki/3G#Data_rates https://en.wikipedia.org/wiki/3G#Data_rates
      - entha_saava 6y ago
        In practice, 3G is quite slower than that.
- untog 6y ago
  That depresses me because it's clear who is being ignored here: the user. A 3MB bundle size instead of 1MB does make a difference, and if you're working on the kind of site that relies on conversions/purchases to succeed then you're absolutely leaving money on the table. Not to mention that Google factors in page load time to rankings. > our UX was worse than our competitors If your competitor has a < 1MB bundle and yours is 3MB then any user on a low end Android phone is absolutely going to have a worse UX experience. Maybe stakeholders aren't aware of all this. Maybe you should tell them.
  - ng12 6y ago
    Most of the apps I've worked on don't have conversions and aren't indexed by search engines. One app I worked on recently did have a mobile version that received a small fraction of all traffic, and even then overwhelmingly from relatively modern iOS devices. It's like all engineering: use the right tools for the job. If low-end Android users are a significant portion of your target audience you have to design your system around that.
- milesvp 6y ago
  I was lucky at one point to work with product owners who understood that latency translated to lost revenue and so they helped champion the idea that engineering excellence was actually valuable, and that squeezing out performance was itself a worthy goal. It helped that we could compare our metrics to comparable sites, and could give upper management bragging rights when our pages loaded faster than bigger higher staffed “competitors”. But otherwise, I think you tend to be right, in a lot of areas even an extra second of latency doesn’t matter, and more features will move the needle more.
- nojito 6y ago
  >I have never in my life had a stakeholder get on my case because our site was 3mb when it could have been 1mb. As cloud costs become tougher to swallow, this is going to change.
zankly 6y ago
It’s like Java... tons of orgs will trade off perf to enable an engineering team of mixed quality to deliver projects.
- xeromal 6y ago
  Exactly. Ensure the average developer can contribute. Of course top tier devs can deliver better products using bare JS.
- gautamdivgi 6y ago
  What is wrong with java performance? I think the garbage collection in Java is probably (if not) one of the best. Start-up times are an issue. But once warmed-up the JVM is very performant provided tuned well.
- eitland 6y ago
  Except Java is extremely performant and if your engineering team doesn't know exactly what they're doing there's often a good chance they'll both use more time and create a slower product with a low level language as far as I know.
  - to11mtm 6y ago
    umm wat. > Except Java is extremely performant and if your engineering team doesn't know exactly what they're doing there's often a good chance they'll both use more time and create a slower product with a low level language as far as I know. So agreed that it'll probably take more time if the team doesn't know what they're doing. But as for slower product? Ehh I think that was the point GP was making; Yeah, its' an overenginnered product that results at times, but it's got just enough guardrails that you hopefully just get a slow, or at worst buggy product, versus a product that doubles as a loot box of future CVEs.
    - eitland 6y ago
      The point is: for the majority of programmers - including a number who can write both reasonable reasonable C and reasonable Java - they will create better, faster programs with Java than with C and in shorter time. There are absolutely times when Java doesn't cut it but at that point your options are getting increasingly limited in many ways: who can build and maintain it, what kind of languages and libraries you can use, the hardware you use, tuning etc.
troughway 6y ago
Not only this, but eventually we will ditch JS in favor of something more "isomorphic" with whatever the back-end is using. Tech like Blazor and related asm.js type thinking will eventually replace JS when it bypasses asmjs completely and ships bytecode that the browser executes directly. I doubt these frameworks will be much different compared to what we are doing today, because we will still need to deal with layouts, alignments, the color and shape and proportion of things, event handlers etc. The usual stuff. Ragging on React, Vue, Angular is misguided. These frameworks allow developers to write front-ends as if they are applications, because in a lot of cases, this is what the modern "website" really is. They are training the next generation of front-end developers much like how jQuery did in mid 2000s.
- nitsky 6y ago
  > Not only this, but eventually we will ditch JS in favor of something more "isomorphic" with whatever the back-end is using. Why not use JavaScript itself for this? That is the strategy employed by Next.js/Nuxt.js/Sapper/etc. Your React/Vue/Svelte components are rendered on the server and then hydrated on the client.
  - james-mcelwain 6y ago
    Because Node.js isn't appropriate for a lot of back-end applications, or for legacy back-end applications that already exist.
  - bcrosby95 6y ago
    Why not just have everyone code in Javascript now and forever? Same reason we didn't settle with everyone coding in C. Or C++. Or Java. Or Python. The web is just a method of distribution. Not every problem or domain takes equally well to each programming model or language. It would be nice to be able to pick a tech stack that works for my domain and the characteristics of my project, rather than picking a tech stack because of how users access it.
  - jerf 6y ago
    Mostly because for all the development done on it, Javascript is still a %50 accurate name; it ain't Java, but it is definitely a scripting language. Node may be popular, but it's lightyears away from being able to say that it's chasing all the other languages out of the server niche, and it's been around for long enough that we can judge it's unlikely ever going to. In 5 years it's going to be a lot easier to get a non-scripting language compiled on to the client than it is to make a scripting language work as your sole backend language.
fooey 6y ago
One of my main things I argue strongly for on any new project is "don't do anything weird". Don't use weird fringe languages, don't use weird fringe frameworks. If the thing you want to do doesn't exist, think real hard about why it does not. At my office, we've somehow ended up with a critical graphql server that's written entirely in Kotlin, which is cool but completely impossible to hire for or get any kind of community support for it. It feels like absolutely everything you want it to do, you have to do build yourself, whereas if we'd used a normal off the shelf graphql server it all already exists. I'm so sick of maintaining old weird forks and unnecessary custom code that doesn't need to exist.
- james-mcelwain 6y ago
  I think the advice is sound, but Kotlin and Graphql are pretty mainstream. This sounds like a local market problem.
  - deleted 6y ago
    [deleted]
  - karatestomp 6y ago
    I think if you're putting out "Senior dev with 3+yrs experience in GraphQL and Kotlin" ads you're going to have real trouble in most markets, if not all. Of course you shouldn't be doing that, is the thing, but that's how most job ads read.
    - fooey 6y ago
      Yeah, this is what I mean Kotlin is fine, and GraphQL is fine, but when you combine those, you have a very small niche.
      - ptx 6y ago
        Kotlin is really very similar to C#. Java developers shouldn't have much of a problem either (now that Java finally has lambdas), and I hear Scala is mostly a superset of Kotlin. GraphQL and (Kotlin or C# or Java or Scala) probably isn't that small of a niche. Edit: Also, Kotlin does have near total compatibility with Java and can use any Java library (aside from the most magical bytecode-rewriting annotation processors) so I don't understand what you're saying about having to rewrite things that exist.
nitsky 6y ago
> This will inevitably subside as JS falls out of favor but I hope it doesn't for a long time. I don't think JS will fall out of favor for a long time. Languages that compile to wasm are unlikely to be competitive until native dom access has broad browser support, which could be years. On top of that, compilers will have to be written to do code splitting and compile times will have to drop. Languages with strong type systems are unlikely to be competitive because TypeScript is good enough that JS projects are now manageable.
untog 6y ago
The common thread in a lot of this is disregard for end user experience. But I think the biggest reason that these discussions never go anywhere is that people are using the same tools for wildly different purposes. At a guess, I'd say that a webapp for a financial services company is going to be loaded once then interacted with heavily? Single Page App model. In that instance the time taken to download, parse and execute JS upfront isn't a big deal. Same as Gmail: when it loads, it takes a couple of seconds, then I leave the tab active for who knows how long. Plus in this situation the audience is relatively monolithic: a lot of desktops, and most of them fast. The problem is people taking lessons learned in that environment and applying them elsewhere. Shopping sites, news sites, essentially anything that people arrive to from a Google search pay a much bigger price for a giant payload. Users can and will leave your site if it's taking too long to load. They'll be running on all kinds of devices, including low-end Androids with very underpowered CPUs. Whenever I see a site like that implementing a full React page with Redux and who knows what else bolted on, I cringe. It's not an appropriate use of tools. But these days people only look at developer productivity (we can add so many more features so much faster!) rather than focusing on the experience in the user's hand.
metalforever 6y ago
The extra bytes across the wire come at a cost of worse search engine performance (extremely costly for ecommerce) and bad accessibility for people using screen readers. #2 I also don't agree with. The JS ecosystem seems like the opposite of "build UIs quickly". You can't swing a stick without hitting like 5 tools you have to use.
jve 6y ago
> 1)Not difficult to hire for. JS frameworks are currently in the sweet spot where they're both widely popular and "cool". Consequently it's not hard to find good candidates If someone is good at JS why not hot hire him? Wouldn't a professional be up & running with ANY framework you throw at him in a month or less?
- scarface74 6y ago
  I know JS like the back of my hand, I’ve been working with it off and on throughout the years since it was first in beta for Netscape Navigator. I’ve had to do some relatively complicated JS logic on the front end and back end. But, I wouldn’t work for any company crazy enough to hire me as a modern front end developer.
sbayeta 6y ago
This is also true for other well established web (not JS) frameworks like Django or Rails

ng12 6y ago

Absolutely agreed. I have never in my life had a stakeholder get on my case because our site was 3mb when it could have been 1mb. I have had many stakeholders get on my case because we couldn't turn around features fast enough, or the site was buggy, or our UX was worse than our competitors. Those are the things that the people who pay me and my team care about and if I could 10x our bundle size for a 1.5x improvement in development speed I would do it in a heartbeat.

tiborsaas 6y ago
Dev experience and productivity is key, but don't forget that 10x bundle size has effects you can't simply dismiss. It does cause a UX problem since a slower pageload is part of the UX. SEO. Google also takes into account page / paint times. These are the things your stakeholders probably don't know about but you should.
- deleted 6y ago
  [deleted]
- ng12 6y ago
  The majority of the projects I work on target users on desktops with modern browsers. You have to get into the massive 10mb range before noticing any lag, and even then only on an empty cache. SEO isn't a concern either, all of our marketing pages (when we have them) are static sites. It's all about picking the right tools for the job. If low latency is a business requirement by all means don't use a framework.
- dirtnugget 6y ago
  As a Frontend Engineer I can assure you there are ways to counter that issues but they're not exactly popular: Server Side Rendering. It adds another step t the build process in which HTML is prerendered, so you get the speed of loading plain HTML. It then loads the actual JS in the background. It's a PITA to implement
  - tiborsaas 6y ago
    With tools like Next.js or Gatsby it's not that bad. We use Next at work on a large scale and it works for us. But do you know what language gives you instant SSR? PHP :) It's funny how we had to invest so much effort to replicate with another language supports out of the box. I've built a blog in a few hours with Craft CMS, perfect tool for the job this case, I didn't even have to touch PHP files, just the templates.
thinkloop 6y ago
Wait another year or two and your stakeholders will smarten up - users are noticing. Svelte JS, for example, has everything you listed minus the costs. React is very far from the end of the road.
- aardvark1 6y ago
  Can't wait to figure out how to staff a 5+ person engineering team who can deliver a SvelteJS product , oh and also maintain the codebase for 5+ years when likely a small minority (if any) of the original engineers are still around!
  - thinkloop 6y ago
    It's about a 4 hr learning curve from react - but I'm not shilling svelte, just showing that there are already superior models. Pre-compiling is really objectively better in every way except popularity, and that will change because of its betterness.
    - aardvark1 6y ago
      Superior in what way? Do you really trust that SvelteJS is going to be a better product in 5 years over something like React that Facebook invests millions of dollars every year?
      - deleted 6y ago
        [deleted]
      - thinkloop 6y ago
        A hello world react app with everything you would typically need (redux, router, etc.) starts at 100K+. Svelte is a couple K. A react app has massive abstraction to render on every frame, Svelte compiles out the framework to render instant straight vanilla js (wins all perf tests). Pre-compiling allows for beautiful syntax and more flexible app structure, since you aren't limited to the runtime. SSR and code-splitting are significantly easier and more straightforward. React is designed for a billion-user site and it shows. There really is zero cost to pre-compiling except mind-share, and only benefits. Of course an F100 company has many concerns above tech awesomeness, so no judgement on your selection criteria. But I assure you this movement is coming, react/vue/angular will adapt/change and/or people will move to Svelte-like solutions. You can already see it happening in the article facebook released today [1]: "By using rems, we can respect user-specified defaults and are able to provide controls for customizing font size without requiring changes to the stylesheet. Designs, however, are usually created using CSS pixel values. Manually converting to rems adds engineering overhead and the potential for bugs, so we have our build tool do this conversion for us." [1] https://news.ycombinator.com/item?id=23116300 https://news.ycombinator.com/item?id=23116300
goatlover 6y ago
2 more MBs is going to matter to some users with limited data or bandwith.
- ng12 6y ago
  Sure, that's a trade-off you have to make a decision on when designing the core architecture. If your users are sitting behind corporate T1 connections near an AWS data center bundle size doesn't matter at all. If your users are still on 3G phones it matters a ton. For somewhere in between it becomes a business decision: how much performance are you willing to trade for developer productivity?
  - hundchenkatze 6y ago
    You're comparison implies that T1 is faster than 3G, but that's probably not the case except in really poor coverage areas. T1's maximum data transmission rate is 1.544 megabits per second. [0] While 3G's theoretical maximum is 21.6 Mbit/s for HSPA+. [1] [0] https://en.wikipedia.org/wiki/T-carrier#Transmission_System_1 https://en.wikipedia.org/wiki/T-carrier#Transmission_System_... [1] https://en.wikipedia.org/wiki/3G#Data_rates https://en.wikipedia.org/wiki/3G#Data_rates
    - entha_saava 6y ago
      In practice, 3G is quite slower than that.
untog 6y ago
That depresses me because it's clear who is being ignored here: the user. A 3MB bundle size instead of 1MB does make a difference, and if you're working on the kind of site that relies on conversions/purchases to succeed then you're absolutely leaving money on the table. Not to mention that Google factors in page load time to rankings. > our UX was worse than our competitors If your competitor has a < 1MB bundle and yours is 3MB then any user on a low end Android phone is absolutely going to have a worse UX experience. Maybe stakeholders aren't aware of all this. Maybe you should tell them.
- ng12 6y ago
  Most of the apps I've worked on don't have conversions and aren't indexed by search engines. One app I worked on recently did have a mobile version that received a small fraction of all traffic, and even then overwhelmingly from relatively modern iOS devices. It's like all engineering: use the right tools for the job. If low-end Android users are a significant portion of your target audience you have to design your system around that.
milesvp 6y ago
I was lucky at one point to work with product owners who understood that latency translated to lost revenue and so they helped champion the idea that engineering excellence was actually valuable, and that squeezing out performance was itself a worthy goal. It helped that we could compare our metrics to comparable sites, and could give upper management bragging rights when our pages loaded faster than bigger higher staffed “competitors”. But otherwise, I think you tend to be right, in a lot of areas even an extra second of latency doesn’t matter, and more features will move the needle more.
nojito 6y ago
>I have never in my life had a stakeholder get on my case because our site was 3mb when it could have been 1mb. As cloud costs become tougher to swallow, this is going to change.

zankly 6y ago

It’s like Java... tons of orgs will trade off perf to enable an engineering team of mixed quality to deliver projects.

xeromal 6y ago
Exactly. Ensure the average developer can contribute. Of course top tier devs can deliver better products using bare JS.
gautamdivgi 6y ago
What is wrong with java performance? I think the garbage collection in Java is probably (if not) one of the best. Start-up times are an issue. But once warmed-up the JVM is very performant provided tuned well.
eitland 6y ago
Except Java is extremely performant and if your engineering team doesn't know exactly what they're doing there's often a good chance they'll both use more time and create a slower product with a low level language as far as I know.
- to11mtm 6y ago
  umm wat. > Except Java is extremely performant and if your engineering team doesn't know exactly what they're doing there's often a good chance they'll both use more time and create a slower product with a low level language as far as I know. So agreed that it'll probably take more time if the team doesn't know what they're doing. But as for slower product? Ehh I think that was the point GP was making; Yeah, its' an overenginnered product that results at times, but it's got just enough guardrails that you hopefully just get a slow, or at worst buggy product, versus a product that doubles as a loot box of future CVEs.
  - eitland 6y ago
    The point is: for the majority of programmers - including a number who can write both reasonable reasonable C and reasonable Java - they will create better, faster programs with Java than with C and in shorter time. There are absolutely times when Java doesn't cut it but at that point your options are getting increasingly limited in many ways: who can build and maintain it, what kind of languages and libraries you can use, the hardware you use, tuning etc.

troughway 6y ago

Not only this, but eventually we will ditch JS in favor of something more "isomorphic" with whatever the back-end is using. Tech like Blazor and related asm.js type thinking will eventually replace JS when it bypasses asmjs completely and ships bytecode that the browser executes directly. I doubt these frameworks will be much different compared to what we are doing today, because we will still need to deal with layouts, alignments, the color and shape and proportion of things, event handlers etc. The usual stuff. Ragging on React, Vue, Angular is misguided. These frameworks allow developers to write front-ends as if they are applications, because in a lot of cases, this is what the modern "website" really is. They are training the next generation of front-end developers much like how jQuery did in mid 2000s.

nitsky 6y ago
> Not only this, but eventually we will ditch JS in favor of something more "isomorphic" with whatever the back-end is using. Why not use JavaScript itself for this? That is the strategy employed by Next.js/Nuxt.js/Sapper/etc. Your React/Vue/Svelte components are rendered on the server and then hydrated on the client.
- james-mcelwain 6y ago
  Because Node.js isn't appropriate for a lot of back-end applications, or for legacy back-end applications that already exist.
- bcrosby95 6y ago
  Why not just have everyone code in Javascript now and forever? Same reason we didn't settle with everyone coding in C. Or C++. Or Java. Or Python. The web is just a method of distribution. Not every problem or domain takes equally well to each programming model or language. It would be nice to be able to pick a tech stack that works for my domain and the characteristics of my project, rather than picking a tech stack because of how users access it.
- jerf 6y ago
  Mostly because for all the development done on it, Javascript is still a %50 accurate name; it ain't Java, but it is definitely a scripting language. Node may be popular, but it's lightyears away from being able to say that it's chasing all the other languages out of the server niche, and it's been around for long enough that we can judge it's unlikely ever going to. In 5 years it's going to be a lot easier to get a non-scripting language compiled on to the client than it is to make a scripting language work as your sole backend language.

fooey 6y ago

One of my main things I argue strongly for on any new project is "don't do anything weird". Don't use weird fringe languages, don't use weird fringe frameworks. If the thing you want to do doesn't exist, think real hard about why it does not. At my office, we've somehow ended up with a critical graphql server that's written entirely in Kotlin, which is cool but completely impossible to hire for or get any kind of community support for it. It feels like absolutely everything you want it to do, you have to do build yourself, whereas if we'd used a normal off the shelf graphql server it all already exists. I'm so sick of maintaining old weird forks and unnecessary custom code that doesn't need to exist.

james-mcelwain 6y ago
I think the advice is sound, but Kotlin and Graphql are pretty mainstream. This sounds like a local market problem.
- deleted 6y ago
  [deleted]
- karatestomp 6y ago
  I think if you're putting out "Senior dev with 3+yrs experience in GraphQL and Kotlin" ads you're going to have real trouble in most markets, if not all. Of course you shouldn't be doing that, is the thing, but that's how most job ads read.
  - fooey 6y ago
    Yeah, this is what I mean Kotlin is fine, and GraphQL is fine, but when you combine those, you have a very small niche.
    - ptx 6y ago
      Kotlin is really very similar to C#. Java developers shouldn't have much of a problem either (now that Java finally has lambdas), and I hear Scala is mostly a superset of Kotlin. GraphQL and (Kotlin or C# or Java or Scala) probably isn't that small of a niche. Edit: Also, Kotlin does have near total compatibility with Java and can use any Java library (aside from the most magical bytecode-rewriting annotation processors) so I don't understand what you're saying about having to rewrite things that exist.

nitsky 6y ago

> This will inevitably subside as JS falls out of favor but I hope it doesn't for a long time. I don't think JS will fall out of favor for a long time. Languages that compile to wasm are unlikely to be competitive until native dom access has broad browser support, which could be years. On top of that, compilers will have to be written to do code splitting and compile times will have to drop. Languages with strong type systems are unlikely to be competitive because TypeScript is good enough that JS projects are now manageable.

untog 6y ago

The common thread in a lot of this is disregard for end user experience. But I think the biggest reason that these discussions never go anywhere is that people are using the same tools for wildly different purposes. At a guess, I'd say that a webapp for a financial services company is going to be loaded once then interacted with heavily? Single Page App model. In that instance the time taken to download, parse and execute JS upfront isn't a big deal. Same as Gmail: when it loads, it takes a couple of seconds, then I leave the tab active for who knows how long. Plus in this situation the audience is relatively monolithic: a lot of desktops, and most of them fast. The problem is people taking lessons learned in that environment and applying them elsewhere. Shopping sites, news sites, essentially anything that people arrive to from a Google search pay a much bigger price for a giant payload. Users can and will leave your site if it's taking too long to load. They'll be running on all kinds of devices, including low-end Androids with very underpowered CPUs. Whenever I see a site like that implementing a full React page with Redux and who knows what else bolted on, I cringe. It's not an appropriate use of tools. But these days people only look at developer productivity (we can add so many more features so much faster!) rather than focusing on the experience in the user's hand.

metalforever 6y ago

The extra bytes across the wire come at a cost of worse search engine performance (extremely costly for ecommerce) and bad accessibility for people using screen readers. #2 I also don't agree with. The JS ecosystem seems like the opposite of "build UIs quickly". You can't swing a stick without hitting like 5 tools you have to use.

jve 6y ago

> 1)Not difficult to hire for. JS frameworks are currently in the sweet spot where they're both widely popular and "cool". Consequently it's not hard to find good candidates If someone is good at JS why not hot hire him? Wouldn't a professional be up & running with ANY framework you throw at him in a month or less?

scarface74 6y ago
I know JS like the back of my hand, I’ve been working with it off and on throughout the years since it was first in beta for Netscape Navigator. I’ve had to do some relatively complicated JS logic on the front end and back end. But, I wouldn’t work for any company crazy enough to hire me as a modern front end developer.

sbayeta 6y ago

This is also true for other well established web (not JS) frameworks like Django or Rails