7 ms·

I took a peek at the "Explorer" app code base. PHP + JS + jQuery, but surprisingly readable (but a lot of practices in there that are not exactly considered "be

by hliyan 3y ago

I took a peek at the "Explorer" app code base. PHP + JS + jQuery, but surprisingly readable (but a lot of practices in there that are not exactly considered "best" today). Perhaps we have sunk too deep into the SPA/API rabbit hole that we can no longer appreciate simplicity. https://gitlab.com/hsleisink/orb/-/blob/master/public/apps/explorer/explorer.js?ref_type=heads#L420 https://gitlab.com/hsleisink/orb/-/blob/master/public/apps/e... https://gitlab.com/hsleisink/orb/-/blob/master/public/apps/explorer/explorer.php?ref_type=heads https://gitlab.com/hsleisink/orb/-/blob/master/public/apps/e...

FpUser 3y ago
>"but a lot of practices in there that are not exactly considered "best" today" Considered by whom?
DGCA 3y ago
I still identify with the “frontend developer” title, even though my skill set has grown beyond it. Best practices are framework dependent, the tooling one should choose is dependent on their problem space, and we do appreciate simplicity. No one is forcing people to use React, Svelte, Vue, etc. The sentiment of wishing for a simpler time has never felt right to me, cause no one is policing what people use. If you feel like people are forcing you into frameworks, I’m sorry, and I feel like I have a piece of advice. If you truly believe a framework isn’t worth it, tell your team why. You might be right, and you might be wrong. I’ve worked at large and small companies; discussions about what technologies to use have always been welcome. I’ve advocated for and won when making a case for “simpler solutions,” when it makes sense. All that said if you think using a framework framework === complexity for the sake of complexity, you’re wrong. OP I’m not saying you think this, but I have to imagine that it’s the sentiment of at least part of the folks who made this the top comment.
Takennickname 3y ago
We are, indeed, in a world where Jquery is now the preferable choice. Frontend development is going through what video games went through in the 80s, so much new shovelware every day that people are eventually going to get tired of it.
- yashg 3y ago
  Few days back I became aware of youmightnotneedjquery.com so we can even do away with jquery.
- amiga-workbench 3y ago
  jQuery is completely unnecessary now, you can use the built in element selectors to do all the same stuff without pulling a huge lib in. The value in jQuery was acting as a shim to smooth over IE's deficiencies back in the day. Now, its a waste of bandwidth.
  - zelphirkalt 3y ago
    Still preferable over how most SPAs are written these days, especially when looking at overhead.
  - distantsounds 3y ago
    yeah, I'm very glad that we have a dozen and a half Javascript libraries that aren't jQuery instead!
    - danShumway 3y ago
      GP isn't saying you should use React, they're saying that if you don't need React you probably don't need jQuery either and you might as well just use pure Javascript. Most of the functions people used jQuery for are natively supported in every major browser that runs Javascript, and the few that aren't have decent polyfills. I mean, let's be real; most of what people were using jQuery for was stuff like `querySelector`, `closest`, `classList`, etc... For those people, pure Javascript is JQuery now. If you don't want a framework and you don't want reactive/declarative interfaces, then you probably don't need a library. I would say the same thing (maybe to a lesser degree) about "standard" libraries like Lodash. Native Javascript has a `reduce` function now, it's widely supported. And if you have to target any of the very few browsers that don't have it, then polyfilling is (usually) the better choice. See also Blueberry and promises; just use JS promises, they're fine.
kreetx 3y ago
I hear PHP is a pretty good language nowdays. Now, if we could just optionally drop the $ sign from the beginning of every variable and use them only for string templating ;).
- psychoslave 3y ago
  What is so special about string templates that they should be have a different naming scheme? And $ really won't ease your life to search with regexp. Would it only depends on my own preferences, I would use only letters and dash for any identifier in code bases I work with.
  - anamexis 3y ago
    > What is so special about string templates that they should be have a different naming scheme? The fact that you have to distinguish between literal strings and interpolated values
    - jdiff 3y ago
      Maybe string interpolation is just a bad idea. Let strings be strings, use string formatting functions if you want to shove data in them.
      - anamexis 3y ago
        Or maybe they're a very nice convenience, which is why a lot of modern languages are implementing them. String formatting functions use special strings themselves.
        jdiff 3y ago
        They do, but very well-defined ones, little placeholders that just concern themselves with formatting. You include the whole variable name and that makes it brittle, now random bits of string data have to be kept in sync with actual code, and makes it a lot more unwieldy to format in a way that isn't the default representation.
tambourine_man 3y ago
> but a lot of practices in there that are not exactly considered "best" today You mean fashionable? > Perhaps we have sunk too deep into the SPA/API rabbit hole that we can no longer appreciate simplicity I’m certain of it.
Tade0 3y ago
SPAs are here due to organisational, not technical reasons. For large organisations it's easier to manage a team of workers with narrow specialisations than a single, but almost equally productive developer like here. It's particularly visible in banking applications, where modules are almost completely independent and built by non-overlapping teams, so they take forever to load due to the limitation on concurrent requests in browsers.
- throwaway60707 3y ago
  I've been evaluating some self-hosted/open source company management systems this weekend. Most of them are classic multi-page PHP apps. It's terrible. I can't stand how it always reloads each time I click on something. I remember it didn't bother me much in the past when everything was like that, but today we have much better options. I went for a SaaS built as a SPA. When I click on something, for example to create a new entity, I get a modal/side-panel immediately. When I want details, I get them much quicker and can return back to the listing immediately. > It's particularly visible in banking applications, where modules are almost completely independent and built by non-overlapping teams, so they take forever to load due to the limitation on concurrent requests in browsers. They just can't code SPAs well. It's perfectly possible to have both quick loading times and very separate modules.
  - JeremyNT 3y ago
    You really don't need an spa for this. You can do the same ux with Turbo from Hotwire (and before it Turbolinks) and traditional server side rendering.
  - gunapologist99 3y ago
    you're typing this on one of those classic multi-page apps. it's not terrible. it's the web.
    - throwaway60707 3y ago
      There's a massive difference in how I use a forum and how I use a company management system. MPA is fine for a forum, not for a company management system. This is the web indeed, and the company management app is just using the web browser as an app platform. No reason to conflate the two.

by hliyan 3y ago

FpUser 3y ago

>"but a lot of practices in there that are not exactly considered "best" today" Considered by whom?

DGCA 3y ago

I still identify with the “frontend developer” title, even though my skill set has grown beyond it. Best practices are framework dependent, the tooling one should choose is dependent on their problem space, and we do appreciate simplicity. No one is forcing people to use React, Svelte, Vue, etc. The sentiment of wishing for a simpler time has never felt right to me, cause no one is policing what people use. If you feel like people are forcing you into frameworks, I’m sorry, and I feel like I have a piece of advice. If you truly believe a framework isn’t worth it, tell your team why. You might be right, and you might be wrong. I’ve worked at large and small companies; discussions about what technologies to use have always been welcome. I’ve advocated for and won when making a case for “simpler solutions,” when it makes sense. All that said if you think using a framework framework === complexity for the sake of complexity, you’re wrong. OP I’m not saying you think this, but I have to imagine that it’s the sentiment of at least part of the folks who made this the top comment.

Takennickname 3y ago

We are, indeed, in a world where Jquery is now the preferable choice. Frontend development is going through what video games went through in the 80s, so much new shovelware every day that people are eventually going to get tired of it.

yashg 3y ago
Few days back I became aware of youmightnotneedjquery.com so we can even do away with jquery.
amiga-workbench 3y ago
jQuery is completely unnecessary now, you can use the built in element selectors to do all the same stuff without pulling a huge lib in. The value in jQuery was acting as a shim to smooth over IE's deficiencies back in the day. Now, its a waste of bandwidth.
- zelphirkalt 3y ago
  Still preferable over how most SPAs are written these days, especially when looking at overhead.
- distantsounds 3y ago
  yeah, I'm very glad that we have a dozen and a half Javascript libraries that aren't jQuery instead!
  - danShumway 3y ago
    GP isn't saying you should use React, they're saying that if you don't need React you probably don't need jQuery either and you might as well just use pure Javascript. Most of the functions people used jQuery for are natively supported in every major browser that runs Javascript, and the few that aren't have decent polyfills. I mean, let's be real; most of what people were using jQuery for was stuff like `querySelector`, `closest`, `classList`, etc... For those people, pure Javascript is JQuery now. If you don't want a framework and you don't want reactive/declarative interfaces, then you probably don't need a library. I would say the same thing (maybe to a lesser degree) about "standard" libraries like Lodash. Native Javascript has a `reduce` function now, it's widely supported. And if you have to target any of the very few browsers that don't have it, then polyfilling is (usually) the better choice. See also Blueberry and promises; just use JS promises, they're fine.

kreetx 3y ago

I hear PHP is a pretty good language nowdays. Now, if we could just optionally drop the $ sign from the beginning of every variable and use them only for string templating ;).

psychoslave 3y ago
What is so special about string templates that they should be have a different naming scheme? And $ really won't ease your life to search with regexp. Would it only depends on my own preferences, I would use only letters and dash for any identifier in code bases I work with.
- anamexis 3y ago
  > What is so special about string templates that they should be have a different naming scheme? The fact that you have to distinguish between literal strings and interpolated values
  - jdiff 3y ago
    Maybe string interpolation is just a bad idea. Let strings be strings, use string formatting functions if you want to shove data in them.
    - anamexis 3y ago
      Or maybe they're a very nice convenience, which is why a lot of modern languages are implementing them. String formatting functions use special strings themselves.
      - jdiff 3y ago
        They do, but very well-defined ones, little placeholders that just concern themselves with formatting. You include the whole variable name and that makes it brittle, now random bits of string data have to be kept in sync with actual code, and makes it a lot more unwieldy to format in a way that isn't the default representation.

tambourine_man 3y ago

> but a lot of practices in there that are not exactly considered "best" today You mean fashionable? > Perhaps we have sunk too deep into the SPA/API rabbit hole that we can no longer appreciate simplicity I’m certain of it.

Tade0 3y ago

SPAs are here due to organisational, not technical reasons. For large organisations it's easier to manage a team of workers with narrow specialisations than a single, but almost equally productive developer like here. It's particularly visible in banking applications, where modules are almost completely independent and built by non-overlapping teams, so they take forever to load due to the limitation on concurrent requests in browsers.

throwaway60707 3y ago
I've been evaluating some self-hosted/open source company management systems this weekend. Most of them are classic multi-page PHP apps. It's terrible. I can't stand how it always reloads each time I click on something. I remember it didn't bother me much in the past when everything was like that, but today we have much better options. I went for a SaaS built as a SPA. When I click on something, for example to create a new entity, I get a modal/side-panel immediately. When I want details, I get them much quicker and can return back to the listing immediately. > It's particularly visible in banking applications, where modules are almost completely independent and built by non-overlapping teams, so they take forever to load due to the limitation on concurrent requests in browsers. They just can't code SPAs well. It's perfectly possible to have both quick loading times and very separate modules.
- JeremyNT 3y ago
  You really don't need an spa for this. You can do the same ux with Turbo from Hotwire (and before it Turbolinks) and traditional server side rendering.
- gunapologist99 3y ago
  you're typing this on one of those classic multi-page apps. it's not terrible. it's the web.
  - throwaway60707 3y ago
    There's a massive difference in how I use a forum and how I use a company management system. MPA is fine for a forum, not for a company management system. This is the web indeed, and the company management app is just using the web browser as an app platform. No reason to conflate the two.