Seems to happen a lot though. Company makes custom stuff early on, gets big, then migrates to something "standard".
Then a few months ago I decided to write a TS project from scratch. For the record I have 18 years of JavaScript experience. What I found was that the biggest barrier to entry was configuring webpack to be "just right". Other devs on my team with similar level of experience would have their eyes glaze over when webpack came up and get annoyed. For good reason. It took me several days to get it to work right. The fact that the tsconfig has 20 options that can effect the transpiler and not have good docs is a problem. The fact that there needs to be two tsconfigs in a react native project that compiles down to web as a secondary build target is another problem. The fact that you need a very experienced dev to spend days configuring webpack is another problem. Finding information about the right configuration is like the blind leading the blind. Most search results on the topic are riddled with half truths and non sense. Many devs rely on a preexisting webpack config and if they do anything to mess it up they are many times completely unable to fix it.
Typescript is fine. I guess. The code produced is nicer. But having to rely on webpack is an issue.
I actually like TS but I wish I didn't need to transpile anything or have to bang my head against a webpack config for days. It's by far the biggest barrier to entry because while you're banging your head against it you're not writing code. And for none technical stake holders when you have nothing visual to show at stand ups that can create friction and make the engineers seem like they aren't doing anything.
So far at multiple companies I've had to configure webpack for extremely complex JavaScript based single page apps which took me literally months of messing around with it until it worked just right. And until it does work "just right" the non technical folks think you're wasting time.
As someone who has just spent a whole week trying to plumb Vite + Rollup into an ASP.NET web application, I can relate to this on many levels.
I can produce 90% of our functionality with vanilla javascript + a sprinkling of JQuery, but to get something 'modern' in Vue.JS fitting into the application comfortably is a bloody chore. Sparing the gory details, it feels like orchestrating a thousand moving parts while being blind with a gun named 'ship or die' held to your back.
For comparison, the EF core at least gives me logs. C# is a delight to debug. Print statements can tell me what I need. These parts feel wholistic.
Yet the web stuff is just so scattered, so much to configure, so many options where if you want to do something even slightly non-standard you are in the dark, mashing the conf files until it works and you aren't even sure why but you have to move on.
This feels different from mastering one language, even though it has a steep learning curve. I hit roadblocks in perl but they weren't as frustrating and it felt like everything was feeding back to a cohesive whole. With webdev, it doesn't feel like that at all. I don't know why, I wish it wasn't so.
All the pieces exist to make it work, but you won't find much documentation to help you. You'll have to rely finding blog posts, but of course if the post is more than a year old most of the libs or tools they're talking about will have totally changed. Once you do get everything up and running you'll often find that the dev experience is less than great.
They do fundamentally the same things but with very different approaches and tradeoffs.
Webpack and Vite are very different approaches to the same problem with different tradeoffs[0][1]
[0]: namely, webpack and its inevitable successor rspack, are way more flexible and arguably powerful but at the cost of higher complexity and more proprietary features like the webpack/rspack specific runtime. Superior in asset handling though, in many respects, and the high level of optimizations you make once you hit a certain complexity threshold is greater than what Vite/Rolluo has currently without extensive custom plugins
[1]: Vite or Rollup is most likely what most projects need. I’d recommend always starting there, as most of the advanced and flexible features of webpack/rspack are very much not what most need
Between the various TypeScript module options and various package.json module options (and various code patterns used), modules make JavaScript way more painful than it should be.
I think most of the JS language standards work the past 10 years has been awesome, but modules was definitely rushed and poorly thought though, causing years of frustration.
- SSR rendering of react in an express app (both typescript).
-Trying to get VSCode visual debugger to work for both the client and server code paths.
- Getting the various test libraries to work correctly (I still can’t get the NYC code coverage library to work).
- Mix of ESM, CommonJS, misconfigured npm packages that don’t expose their types correctly.
I ultimately used Vite, and got things working 90% the way I wanted and called it good enough.
On the Vue vs React debate, honestly it comes down to preferring templates vs components. Vue is simpler but there are good reasons for a lot of the React complexity, and React still has a stronger ecosystem and more developers.
Remix is moving to Vite as its default compiler. https://remix.run/docs/en/main/guides/vite
My project is relatively tiny too. I’ve never regretted a choice more than Remix.
It leads to scenarios where I receive OpenApi specs that loom like this:
type:
- string/integer
They could use:
oneOf:
- type: string
- type: integer
So thank you for actually caring about types in PHP.
I’ve done Webpack configurations and Browserify before that. I’ll be glad if I never go there again.
I’ve been using remix for the last 6 months and I’m super happy with it.
Next really fucked up with the app router, and people are realizing everything is just a trap to get more customers on vercel.
As soon as you hit an edge outside of their matrix of management you open the dark Pandora box of front-end development.
As a corollary, though, I think those kinds of cultures are only possible if your team is composed of primarily brilliant people, because these brilliant people can move faster than most competitors even if they do wander down an unproductive path for a while, and there is total trust that the folks on your team are capable and self-motivated.
Then comes a point where the community catches on and has bigger momentum than the company, so it makes sense to move to the standard implementation.
I'd kinda see Google's Borg -> k8s move as slightly similar, though they're the one inviting the community around the standard they built themselves.
Now they also have modern PHP and some other languages alongside with hack from what I understand.
https://medium.com/@aarthimanikandan2006/does-facebook-still...
PHP and its community were dying by the time FB used it. People here on HN kept talking php down.
In 2014 FB made their own flavour of php with a bunch of perf features, called hack.
Eventually a lot of the perf features hack made its way into php.
FB is still on its own flavour. Php community is still dying.
But maybe the php forums + guestbooks was what you had in mind with 'php community', in that case you have a point. Most of the kids have moved on.
The popular frameworks are still growing steadily and WordPress is starting to slowly shift off some of its stranglehold on old versions now that most webhosts don’t even offer old versions. That said, even Wordpress will work out of the box with old versions (they just don’t write new features against new PHP versions).
This is arguably the most exciting time to be a PHP dev!
I've started to learn the ecosystems of the other languages. It's all the same shit. Really.
I used PHP to run some service workers managed with supervisord and it was fine. I just get annoyed with the class-based hierarchy but I'd guess they've evolved since 2017 or whenever I used it last.
To me, what PHP needs is a simple module system with scoped functions and variables, an object literal syntax rather than `new \stdClass`, and first-class simple to use threading/async/promises for concurrent requests and IO.
The worst thing about PHP: shared nothing architecture.
It works extremely well until it doesn’t really scale anymore.
There's still a ton of stuck that could be fixed, and php will always be talked down in some way or another but I don't think it's in a bad position as it is now. There's pretty significant code bases newly built on php right now, even if it's not making the headlines.
> Php community is still dying.
https://www.tiobe.com/tiobe-index/php/
https://w3techs.com/technologies/overview/programming_langua...
Yeah I dunno about that one.
Want a real example? Everybody knows that Instagram runs Python. But https://w3techs.com/sites/info/instagram.com can't tell which server side language it runs. There you have it.
I would not use the number unless it can be validated, rather than use it simply because it's "the best we have". No, it's not even remotely good.
If you can maintain your Unicorn hiring criteria long term, maybe fully custom stacks are maintainable. For most organizations, they need to move to something that the average hire can maintain going forward. That means big name boring software vendors for the most part.
Sometimes it's worth it if the speed boost is huge, or if you can write safer code, or if you actually want to gatekeep hiring to people who like learning new languages.
Like, all those people that chose Flow now have something "non-standard."
(insert canned laughter)
Coffeescript is still better than js with many ideas - everything is an expression, comprehensions, existential operator, extended switch statement, chained comparisons overall terse, readable syntax.
Some things are terrible ie. type annotations through clunky comments.
I have a ton of respect for the language and all of the stuff it cross-pollinated into JS, but it’s an interesting object lesson in how a seemingly tiny design choice can turn out to be disastrous.
I guess when exploring uncharted territory it's a bit of a dice roll - you can't keep winning all the time.
Otherwise great contrib to advance frontier.
Coffeescript was before my time so I never used it, can you give an example of the problems this caused?
So what can happen is that you have some large block of code where, for example, near the top, you’ve said “x = 1”. Then, maybe a few hundred lines down you have a loop, and inside the loop you say “x = getWidget()”. You think you’re declaring a new variable, but actually you’re reusing a variable from the outer scope. There’s no way to know if you’re accidentally doing this except to search the entire enclosing scope.
It’s even worse in the other direction. You have a small block way down in a function where you’ve said “x = getWidget()” and this is all fine and correct. But you need to add something to the top of the function, and you add “x = 0”. You’ve now retroactively changed the scope of some random variable you weren’t even thinking about.
Edit: Actually my memory’s a little rusty, but I think they actually removed any kind of block scoping entirely by version 1, but everything I said above still applies to nested functions, which you tend to use liberally in CS.
JavaScript has had this for a bit now and it is really nice.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
if window?
env = 'browser'
...
if (typeof window !== "undefined" && window !== null) {
env = 'browser'
...
}
Also, was Typescript really as claimed in its "infancy" at the time mentioned in the article? They didn't mention a particular year.
I don't follow. Where did I do this?
"Smell" has negative connotations in English. If you say that "this code smells" it means it's bad, and likewise it's very easy to read your "It does smell like" as you meaning it's a bad thing.
Custom is great right up to when the lead eng leaves.